Exchange Server 2013/2016 Components in an Inactive State


updated – I  made this post more than a year go when I encountered an issue doing maintenance on Exchange Server 2013. Coming from Exchange 2010 maintenance experience it was a quite a different change and for some time I was not sure why the service were not coming backup online. And then it was all related to Exchange 2013/2016 Managed Availability. When I looked it up (only possible via Powershell) I fond that all the services were in InActive State.

You can also use the script to bring the component state back to active state

Original post from 08/7/2014
After applying update or patches on Exchange 2013/2016 and bringing back to out of maintenance you notice that server components are still Inactive as shown below.  In a situation like this you need to go extra mile to bring the server as is before maintenance. Below is the set of cmdlet when you put the server on maintenance where requester is calling for maintenance.

cmdlets/ script is bringing the server out of the maintenance but the component state is still Inactive
Set-ServerComponentState $Server -Component ServerWideOffline -State Active -Requester Maintenance
Set-ServerComponentState $Server -Component UMCallRouter –State Active –Requester Maintenance
Resume-ClusterNode $Serve
Set-MailboxServer $Server -DatabaseCopyActivationDisabledAndMoveNow $False
Set-MailboxServer $Server -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState $Server -Component HubTransport -State Active -Requester Maintenance


In addition to the single components which can be managed individually, there’s also a component called “ServerWideOffline”, which is used to manage the state of all components together, with the exception of “Monitoring” and “RecoveryActionsEnabled”. For this purpose, “ServerWideOffline” overrides individual settings for all other components. It doesn’t touch “Monitoring” and “RecoveryActionsEnabled” because these two components need to stay active in order to keep MA going. Without them, no “OnlineResponder” could bring “ServerWideOffline” back to “Active” automatically. But in this case both Monitoring and RecoveryActionEnabled are Inactive which will not bring the ServerWideOffline back to Active.

 So the server is not 100% functional even though you took it out of maintenance. You will need to perform  the following cmdlet to bring the server in ACTIVE State

Set-ServerComponentState -Component ServerWideOffline -State Active -Requester Functional
Set-ServerComponentState -Component Monitoring -State Active -Requester Functional
Set-ServerComponentState -Component RecoveryActionsEnabled -State Active -Requester Functional



You can also get  the Get-ServerComponentState cmdlet from the Shell to retrieve these settings along with timestamp


You can also use the script to bring the component state back to active state



Microsoft Exchange Server Deployment Assistant – Need Some Improvements


[mp_span col=”12″]

The Exchange Server Deployment Assistant is a web-based tool that asks you a few questions about your current environment and then generates a custom step-by-step checklist that will help you deploy different versions of Exchange Server for different types of scenarios.

Screen Shot 2016-04-26 at 9.53.40 PM

Microsoft Exchange Product Team has done a phenomenal job introducing this tool and keeping it updated on regular basis.  While I was working on some scenario I figure there need to be some re-ordering and and couple of new links needs to be added. Hope it make sense to ExchangeTeam 🙂

I’ve selected On-Premises Scenario

Screen Shot 2016-04-26 at 9.55.20 PMScreen Shot 2016-04-26 at 9.55.40 PM

Next I selected
Disjoint namespace – No
Migrate Public Folders – Yes
Edge Co-Existance – No

Next you will see the navigation checklist
Screen Shot 2016-04-26 at 10.17.21 PM

Suggestion #1 Re-Order Service Connection Point (SCP)

The improvement I’m talking about is SCP order should be either in Install Exchange 2016 OR or Should be the 2nd step in Configure services. I think it has to be be the next step right after you install the Exchange Server 2016



Suggestion #2 – In Finalize Your Deployment – Add More Steps or link into that section.

Screen Shot 2016-04-26 at 10.21.21 PM

Modify or Remove Exchange 2010, this link only cover the scenario where you have only one mailbox server or mailbox server with Database Availability. It does not cover the details if the legacy Exchange Server 2010 has Database Availability Group. So to cover a DAG scenario those two link are very important. and it has to be part of the deployment assistant in my opinion.





Finding and Fixing DAG Cluster Owner

If you are working with Exchange 2010 DAG and run into the issue where it can’t failover to a passive note then you may need to find who is the cluster owner and you may need to move the cluster owner . You may also restart the cluster service depending on the scenario. Below are few steps which will identify the current cluster owner and how to move from one node to another. Specially this will help in the DAC (Data Center Activation) scenario where the cluster owner is on the remote site and after failover cluster owner remains there and database does not mount on the primary site.

In my lab DAG name is ‘DAG1’ and nodes are E14-SRVR1 & E14-SRVR2

[PS] C:Windowssystem32>cluster.exe ‘dag1’ group ‘cluster group’/moveto:e14-srvr2

Moving resource group ‘cluster group’…

Group                Node            Status
——————– ————— ——
cluster group        E14-SRVR2       Online

[PS] C:Windowssystem32>Get-DatabaseAvailabilityGroup -Identity dag1 -Status | fl name,primaryactivemanager

Name                 : DAG1
PrimaryActiveManager : E14-SRVR2

Now moving the cluster owner back to E14-SRVR1

[PS] C:Windowssystem32>cluster.exe ‘dag1’ group ‘cluster group’/moveto:e14-srvr1

Moving resource group ‘cluster group’…

Group                Node            Status
——————– ————— ——
cluster group        E14-SRVR1       Online

[PS] C:Windowssystem32>Get-DatabaseAvailabilityGroup -Identity dag1 -Status | fl name,primaryactivemanager

Name                 : DAG1
PrimaryActiveManager : E14-SRVR1





Error: Microsoft Exchange Search Service may not be running on server – Specific RPC error message: Error 0x6d9

If you are trying to update the Catalog on one of the Mailbox DatabaseCopy you may see the following error

[PS] C:Windowssystem32>Update-MailboxDatabaseCopy “db01mbx1-10” -catalogonly

A source-side operation failed. Error Content indexing operation failed with the following message: The seeding operati on encountered an error while trying to contact the search service. Error: Microsoft Exchange Search Service may not be  running on server MBX1-10. Specific RPC error message: Error 0x6d9 (There are no more endpoints available from the end point mapper) from cli_Dismount. [Database: DB01, Server: MBX1-10.TRADERS.COM]     + CategoryInfo          : InvalidOperation: (:) [Update-MailboxDatabaseCopy], CiSeederRpcOperationFailedException     + FullyQualifiedErrorId : EEBEE7FA,Microsoft.Exchange.Management.SystemConfigurationTasks.UpdateDatabaseCopy





You may have to start Microsoft Exchange Serach Indexer service but it may not solve the issue so make sure it is running Microsoft Exchange RPC Client Access server

Once these services are started you will notice the same action after running the above cmdlet again





Cheers 🙂