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.
Die Server Component States sind nützlich, wenn ein Exchange 2016 Server für eine bestimmte Zeit (z. B. für die Installation von Updates) teilweise oder vollständig außer Betrieb genommen werden soll. Die Exchange-Dienste auf dem Server werden dabei trotzdem ausgeführt. Solange die Exchange Dienste gestartet sind, lassen sich einige Probleme einfacher diagnostizieren. Gerade in größeren Umgebungen, können die Server Component States auch dazu verwendet werden, vorgelagerte Loadbalancer zu steuern um beispielsweise Wartungsarbeiten durchzuführen, ohne das einzelne Server am Loadbalancer deaktiviert oder aus dem Pool genommen werden müssen.

Auch das Exchange Feature “Managed Availability” (MA) greift auf die Server Component States zurück, stellt MA fest, dass eine Exchange Komponente nicht ordnungsgemäß funktioniert, schaltet MA die Komponente ab, bis das Problem behoben wurde.

Es kann allerdings auch mal vorkommen, dass nach einem Update des Exchange Servers ein oder mehrere Komponenten nicht wieder aktiv geschaltet werden.

Mit dem folgenden Befehl lässt sich der Status der Komponenten eines Exchange Servers anzeigen, in diesem Fall hat der Server den Namen “Exchange”:

Get-ServerComponentState -Identity Exchange | ft Component,State

Server Component States

Die meisten Komponenten lassen sich schon anhand des Namens ihrer Funktion zuordnen. Die Komponenten “ForwardSyncDaemon” und “ProvisioningRps” sind in lokalen Exchange Umgebungen (on-premises) nicht relevant und sind daher im Status “Inaktiv” (Stichwort: “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.

Hinweis: Der Status der Komponenten kann leicht falsch verstanden werden. Beispiel: Der Status “Active” für die Komponente “ServerWideOffline” bedeutet “Alles gut” und nicht etwa “Der Server ist komplett offline”. Oder anders: Der Status “Inactive” für die Komponente “ServerWideOffline” bedeutet “Nichts geht mehr” und nicht etwa “Alles gut”. Der Name der Komponente “ServerWideOffline” ist da vielleicht etwas widersprüchlich.

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.

Ändern der Server Component States

Die Server Component States können mit Hilfe der Exchange Management Shell geändert werden. Um beispielweise die Komponente OWAProxy in den Status Inaktiv zu setzen, kann der folgende Befehl genutzt werden:

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

Server Component States

Das Login via OWA funktioniert jetzt zwar noch, aber anderen Exchange Servern wird mitgeteilt, dass sich OWA auf diesem Server gerade im Wartungsmodus befindet. Vorgeschaltete Loadbalancer, die die Health URLs auswerten, bekommen die Status Änderung ebenfalls mit, da die Health URL für OWA nicht mehr den Status 200 wiedergibt:

Exchange Health Check URL

Um den Wartungsmodus für OWA wieder aufzuheben, kann der folgende Befehl genutzt werden:

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

Server Component States

Somit gibt auch die HealthCheck URL wieder den Status 200 zurück:

Exchange Health Check URL

Dieses Vorgehen ist für die restlichen Komponenten identisch. Wie schon erwähnt, können die Komponenten von mehreren Requestern beeinflusst werden, im folgenden Screenshot ist zu sehen, dass die Komponente OWAProxy vom Requester “Maintanance” in den Zustand “Inactive” gesetzt wurde, der Requester “Functional” verbleibt im Status “Active”:

Server Component States

Da der Status Inactive Vorrang hat, ist die Komponente OWAProxy im Status Inaktiv. Mit dem oben gezeigten Befehl lässt sich somit auch prüfen welcher Requester welchen Status gesetzt hat. Diese Information ist wichtig um den Status wieder auf Aktiv zu setzen:

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

Der Zustand der Komponenten wird an zwei Stellen veröffentlicht, lokal in der Registry des Exchange Servers und im Active Directory. In der Registry befinden sich die Server Component States unter folgemdem Pfad:

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

Server Component States Registry

Im Active Directory befinden sich die Informationen in der Konfigurationspartition auf dem Server Objekt unter folgendem Pfad:

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

Server Component States Active Directory

Die Informationen aus dem Active Directory lassen sich ebenfalls in der Exchange Shell anzeigen. Dazu kann der folgende Befehl verwendet werden:

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

Das folgende kleine Script kann verwendet werden, um alle Component States der Exchange Server in den Status Active zu setzen:

$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
   }
 }

Nach einem Update kann dies schon mal ganz hilfreich sein.

9 Gedanken zu „Exchange 2016: Server Component States“

  1. Hallo Frank

    Ein davor geschalteter Lastenverteiler erkennt, bis auf den FrontendTransport auf Port 25, alle Services als Down erkennt, wenn ich den Server ComponentWideOffline nehme.

    Ich verwende das Skript Start-ExchangeServerMaintenanceMode.ps1 von Sammy Krosoft, welches auch die Services Frontend und Transport neu startet. Läuft alles fehlerfrei … doch leider bleibt der geöffnete Port 25 für den Loadbalancer ansprechbar, wenn auch keine Mails daran angenommen werden.

    Hast Du irgendeine Idee, woran das liegen könnte? Ich finde es nicht besonders schön, bei einer Wartung den Dienst zu stoppen und zu deaktivieren.

    Liebe Grüße
    Michael

    Antworten
  2. Hallo zusammen,
    Ich hatte auch seitdem CU11 Update riesen Probleme es ging nichts mehr.
    Da ich aber auch keine Server Admin bin, habe ich jetzt 2 Tage benötigt, das alles endlich wieder läuft.

    Exchnage PowerShell als Administrator gestartet:

    Damit wurde alle Dienste wieder Aktiv:
    Get-ServerComponentState servername | ft Component,State -Autosize

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

    Get-ServerComponentState servername | ft Component,State -Autosize

    Set-ServerComponentState servername -Component FrontendTransport -State Active -Requester Maintenance
    Set-ServerComponentState servername -Component FrontendTransport -State Active -Requester Functional

    Reboot

    Get-ServerComponentState servername | ft Component,State -Autosize

    Danke

    Antworten
    • Vielen Dank für deine PS-Befehle! Die haben mir sehr geholfen! Ich hatte Probleme bei CU14. Auf 2 von 3 Servern lief das Update von CU14 problmelos durch. Auf dem 3. Server hat das Setup ständig abgebrochen. Ich wollte das Update dann vertagen und den Wartungsmodus beenden. Alles soweit gut, bis ich dann eine DB schwenken wollte. Nach Fehlersuche habe ich festgestellt, dass alle Exchange-Dienste auf „Inactive“ stehen! Durch deine o.g. PS-Befehle wurden alle Dienste wieder aktiviert und im Anschluss konnte ich die DB dann erfolgreich schwenken!

      Die nächsten Tage werde ich weiterhin mit den CU Updates beschäftigt sein. Ich möchte auf CU 17 kommen. Durch die notwendigen net Framework Updates muss ich jedoch einige Zwischenschritte gehen. :/

      Antworten
    • Danke, Danke, Danke!!

      Ich war schon kurz vorm Durchdrehen.
      Die Powershell-Befehle haben mir nach einer schlaflosen Nacht am Rechner zumindest den Tag gerettet.
      Da wäre ich nie drauf gekommen.

      Hut ab!!

      Antworten

Schreibe einen Kommentar