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
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
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:
Um den Wartungsmodus für OWA wieder aufzuheben, kann der folgende Befehl genutzt werden:
Set-ServerComponentState -Identity Exchange -Component OwaProxy -State Active -Requester Maintenance
Somit gibt auch die HealthCheck URL wieder den Status 200 zurück:
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”:
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\
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
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.
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
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
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. :/
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!!
Herzlichen Dank… nach 17 Stunden die paar Zeilen … und ich kann schlafen gehen.
DANKE
Bester Mann. In letzter Zeit postest du immer genau die Themen mit denen ich mich auch beschäftige.
Oh mein gott ich liebe diesen Blog.
Vielen Dank für das Teilen dieser verständlichen und hilfreichen Texte.
Keep em up!