Mit Exchange 2013 gibt es die so genannten „ServerComponentState“s. Die sollen dafür genutzt werden, um Dienste, die zwar laufen, über eine interne Variable zu kontrollieren. Sprich – Dein Transportdienst läuft zwar, er nimmt jedoch nichts an, dann könnte es am Status der Server- Components liegen. Microsoft nutzt diese Funktion, um die Dienstverfügbarkeit z.B. während eines Updates zu kontrollieren. Um so anstrengender, sollte ein Update fehlschlagen…
Der Administrator stellt fest, die Dienste laufen doch, warum passiert da nichts und ruft im Regelfall dann spätestens bei seinem Dienstleister an. Ich möchte hierzu anmerken, dass ein Exchange Server erst aktualisiert werden sollte, wenn der Gesundheitszustand der Domäne und des Exchange-Servers überprüft wurde.
Du wirst diesen Zustand also auch feststellen, wenn ein kumulatives Update auf Exchange Server fehlgeschlagen ist. In aller Regel hilft es, sich zunächst auf den Grund bzw. die Ursache des Fehlschlags zu konzentrieren und den Fehler zu beheben, bevor Du ein nächstes Mal mit dem Update beginnst. Das gelingt Dir jedoch nur, wenn die Dienste wieder verfügbar sind. Und damit meine ich nicht die Windows-Dienste, sondern die Servercomponents. Auf dieses Problem wirst Du z.B. auch hingewiesen, wenn Du den Exchange Best Practices Analyzer aus dem ECP starten kannst (ja, ist mir bekannt, immer noch BETA aber dennoch: Es geht auch ohne Office365 Account). Hier wirst Du dann darauf hingewiesen, dass „ServerWideOffline“ offensichtlich Im Status „Inactive“ markiert ist.
Hinweis für die nachfolgenden Exchange Powershell-Konsolenbefehle: IDENTITY = Dein Exchange Servername (Identiy), bekommst Du über „Get-ExchangeServer“ als „Name“ zurückgegeben.
Mit dem Exchange-PS-Befehl
Get-ServerComponentState -Identity IDENTITY
Siehst Du im Idealfall folgende Übersicht (Beispiel)
Da das jedoch bei Dir (wenn Du diese Seite aufgrund Deiner Suchanfrage bei Google gefunden hast) nicht der Fall ist, sondern das wohl eher wie folgt aussieht:
Hinweis (ACHTUNG!): Jetzt muss man wissen, dass die Informationen über diesen Zustand nicht nur auf dem lokalen Microsoft Exchange Server in der Registry gespeichert werden, sondern auch im Active Directory. Für die nachfolgenden, beiden Informationen gilt daher: Nur gucken, nicht anfassen!
In Active-Directory findest Du die Zustände im Regelfall im Namespace „Konfiguration“ Deiner Domäne, im Attribut „msExchComponentStates“
In der Registry findest Du das in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates:
Jetzt ist es möglich, die Information über den lokalen (LocalStates) Status (Registry) und über den Status im AD (RemoteStates) herauszufinden. Und das ist auch wichtig, da dieser Dir den sogenannten „Requester“ mitteilt, dazu gleich mehr.
Hier zunächst ein Beispiel über den Komponentenstatus für „ServerWideOffline“ (Dazu gleich auch mehr), einmal lokal und einmal remote:
$scs = Get-ServerComponentState -Identity EDG-VSRV10-EX -Component ServerWideOffline $scs.localstates $scs.remotestates
Eine Beispielausgabe für einen „funktionierenden“ Komponentenstatus wäre:
Sonderrolle „ServerWideOffline“:
Der Komponentenstatus „ServerWideOffline“ ist dabei der globale Schalter, für alle untergebenen Komponenten, wie z.B. HubTransport oder EcpProxy. Wird dieser Status durch Dich oder durch einen Patch oder einen Fehler auf „Inactive“ gesetzt, so werden alle anderen Komponenten ebenfalls auf „Inactive“ gesetzt und das gesamte System außer Dienst gestellt, obwohl die Windows-Dienste selbst noch laufen können.
Ebenso ist es jedoch möglich, dass lediglich einzelne Teilkomponenten nicht laufen, bzw. im Status „Inactive“ stehen.
Der „Requester“:
Der Requester spielt dabei eine wichtige Rolle. Hier kannst Du herausfinden „warum“ der Status geändert wurde. Hierbei ist auch wichtig, dass die einzelne (oder die globale Komponente „ServerWideOffline“) nur wieder auf den „Active“ Zustand gesetzt werden kann, wenn der passende Requester gewählt wurde. Es ist im übrigen auch möglich, dass zwei unterschiedliche Requester den Status auf inactive gesetzt haben, in diesem Fall muss auch der zweite Requester in einem zweiten Aktivschaltungsanfrage gewählt werden.
Die 5 unterschiedlich möglichen Requester sind:
- Deployment
- Functional
- Sidelined
- Maintenance
- HealthApi (Im Regelfall, wenn ein Update fehlgeschlagen ist)
Damit Du den Status wieder zurücksetzen kannst, musst Du also zunächst herausfinden, welcher oder welche Requester den jeweiligen Komponentenstatus auf „Inactive“ gesetzt haben. Verfahre also, wie zuvor mit dem Befehl „Get-ServerComponentState“ erläutert. Anschließend kannst Du den Status mit folgenden Befehl „Set-ServerComponentState“ wieder in den Status Active versetzen:
Set-ServerComponentState -Identity IDENTITY -Component ServerWideOffline - State Active - Requester HealthApi
Weitere Hinweise:
Du kannst die Konfiguration des Servers auch manuell auf „Inactive“ setzen, wenn Du einzelne Bestandteile deaktivieren oder isolieren möchtest, z.B. zu Wartungszwecken.