Site icon Franky's Web

Exchange 2016: Server Component States

Mit Exchange 2013 wurde das Konzept der „Server Component States“ eingeführt. Die Server Component States bieten eine detaillierte Kontrolle über den Zustand der Komponenten, aus denen ein Exchange Server besteht. Zwar gibt es mit Exchange 2016 nur noch eine installierbare Rolle (Mailbox, Edge Transport mal außen vorgelassen). Die Mailbox Rolle besteht aber aus verschiedenen Komponenten. Komponenten der Mailbox Rolle sind zum Beispiel E-Mail Transport und diverse Schnittstellen wie OWA, EWS und 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").

Die Komponente „ServerWideOffline“ wird verwendet, um den Status aller Komponenten gemeinsam zu verwalten. Eine Ausnahme bilden die Komponenten „Monitoring“ und „RecoveryActionsEnabled“, diese sind nicht in der Komponente „ServerWideOffline“ eingeschlossen und dienen für Wartungsarbeiten.

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.

Komponenten können sich in einem der drei Zustände befinden: „Active“, „Inactive“ oder „Draining“. Draining ist nur für die Komponenten „FrontendTransport“ und „HubTransport“ relevant. Die anderen Komponenten sind entweder “Active” oder “Inactive”.

Die meisten Exchange Server-Komponenten können ihren Status im laufenden Betrieb ändern. Ausnahmen sind „FrontendTransport“ (dem Dienst „Microsoft Exchange Frontend Transport“ zugeordnet) und „HubTransport“ (dem Dienst „Microsoft Exchange Transport“ zugeordnet). Änderungen werden erst beim nächsten Neustart dieser Dienste übernommen.

Wenn der Zustand einer Komponente geändert werden soll, muss dies über einen „Requester“ erfolgen. Der Requester ist ein Label (oder Tag), das auf die Gründe für die Zustandsänderung der Komponente hinweist (z.B. Maintanance oder Unhealthy)
Dabei lassen sich verschiedene Zustände mit unterschiedlichen Requestern für dieselbe Komponente einrichten. In diesem Fall hat der Zustand „Inaktiv“ immer Vorrang.

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:

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

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.

Exit mobile version