Exchange 2016: Server Component States

The concept of "Server Component States" was introduced with Exchange 2013. The Server Component States provide detailed control over the status of the components that make up an Exchange Server. With Exchange 2016, there is only one installable role (mailbox, edge transport not included). However, the mailbox role consists of various components. Components of the Mailbox role are, for example, email transport and various interfaces such as OWA, EWS and ActiveSync.
The Server Component States are useful if an Exchange 2016 server is to be partially or completely decommissioned for a certain period of time (e.g. for the installation of updates). The Exchange services on the server will still run. As long as the Exchange services are running, some problems can be diagnosed more easily. Especially in larger environments, the Server Component States can also be used to control upstream load balancers, for example to carry out maintenance work without having to deactivate individual servers on the load balancer or remove them from the pool.

The Exchange feature "Managed Availability" (MA) also uses the Server Component States. If MA detects that an Exchange component is not working properly, MA switches the component off until the problem has been resolved.

However, it can also happen that one or more components are not reactivated after an update of the Exchange Server.

The following command can be used to display the status of the components of an Exchange server, in this case the server has the name "Exchange":

Get-ServerComponentState -Identity Exchange | ft Component,State

Most components can be assigned to their function based on their name. The components "ForwardSyncDaemon" and "ProvisioningRps" are not relevant in local Exchange environments (on-premises) and therefore have the status "Inactive" (keyword: "born in the cloud").

The "ServerWideOffline" component is used to manage the status of all components together. The "Monitoring" and "RecoveryActionsEnabled" components are an exception; these are not included in the "ServerWideOffline" component and are used for maintenance work.

Note: The status of the components can easily be misunderstood. Example: The status "Active" for the "ServerWideOffline" component means "All good" and not "The server is completely offline". Or in other words: The status "Inactive" for the "ServerWideOffline" component means "Nothing is working" and not "Everything is fine". The name of the "ServerWideOffline" component is perhaps somewhat contradictory.

Components can be in one of three states: "Active", "Inactive" or "Draining". Draining is only relevant for the "FrontendTransport" and "HubTransport" components. The other components are either "Active" or "Inactive".

Most Exchange Server components can change their status during operation. Exceptions are "FrontendTransport" (assigned to the "Microsoft Exchange Frontend Transport" service) and "HubTransport" (assigned to the "Microsoft Exchange Transport" service). Changes are only applied the next time these services are restarted.

If the status of a component is to be changed, this must be done via a "requester". The requester is a label (or tag) that indicates the reasons for the change of state of the component (e.g. Maintanance or Unhealthy)
Different states with different requesters can be set up for the same component. In this case, the "Inactive" state always has priority.

Changing the Server Component States

The Server Component States can be changed using the Exchange Management Shell. For example, to set the OWAProxy component to Inactive status, the following command can be used:

Set-ServerComponentState -Identity Exchange -Component OwaProxy -State Inactive -Requester Maintenance

The login via OWA still works, but other Exchange servers are informed that OWA is currently in maintenance mode on this server. Upstream Load balancers, which use the Health URLs also receive the status change, as the Health URL for OWA no longer reflects the status 200:

The following command can be used to cancel maintenance mode for OWA:

Set-ServerComponentState -Identity Exchange -Component OwaProxy -State Active -Requester Maintenance

This means that the HealthCheck URL also returns the status 200:

This procedure is identical for the remaining components. As already mentioned, the components can be influenced by several requesters. The following screenshot shows that the OWAProxy component has been set to the "Inactive" status by the "Maintanance" requester, while the "Functional" requester remains in the "Active" status:

As the Inactive status has priority, the OWAProxy component has the Inactive status. The command shown above can therefore also be used to check which requester has set which status. This information is important in order to set the status back to Active:

(Get-ServerComponentState -Identity Exchange -Component OwaProxy).LocalStates
Set-ServerComponentState -Identity Exchange -Component OwaProxy -State Active -Requester Maintenance

The state of the components is published in two places, locally in the Exchange Server registry and in the Active Directory. The Server Component States are located in the registry under the following path:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates\

In the Active Directory, the information is located in the configuration partition on the server object under the following path:

• Configuration / Services / Microsoft Exchange / Administrative Groups / Exchange Administrative Group / Servers

The information from the Active Directory can also be displayed in the Exchange Shell. The following command can be used for this purpose:

(Get-ServerComponentState -Identity Exchange -Component OwaProxy).Remotestates

The following small script can be used to set all component states of the Exchange Server to Active status:

$ComponentStates = Get-ExchangeServer | Get-ServerComponentState | where {$_.Component -ne "ForwardSyncDaemon" -and $_.Component -ne "ProvisioningRps" -and $_.State -eq "Inactive"}
foreach ($ComponentState in $ComponentStates)
{
$LocalStates = $ComponentState.LocalStates | where {$_.State -eq "Inactive"}
foreach ($LocalState in $LocalStates)
{
Set-ServerComponentState -Identity $ComponentState.Identity.Name -Component $LocalState.Component -State Active -Requester $LocalState.Requester
}
}

This can be quite helpful after an update.