#Exchange #2013 Server Component Inactive (ServerWideOffline) nach CU-Update- oder Patchfehler

Menu:/#Exchange #2013 Server Component Inactive (ServerWideOffline) nach CU-Update- oder Patchfehler

#Exchange #2013 Server Component Inactive (ServerWideOffline) nach CU-Update- oder Patchfehler

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

Siehst Du im Idealfall folgende Übersicht (Beispiel)
Bildschirmfoto 2016-02-18 um 14.43.39
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:
Bildschirmfoto 2016-02-17 um 19.14.27 Kopie

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“

Bildschirmfoto 2016-02-18 um 14.54.59

In der Registry findest Du das in

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:

Eine Beispielausgabe für einen „funktionierenden“ Komponentenstatus wäre:

Bildschirmfoto 2016-02-18 um 16.25.35Sonderrolle „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.

Bildschirmfoto 2016-02-18 um 16.25.35

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:

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.

By | 2016-02-18T17:57:04+00:00 18.02.2016|Allgemein|Kommentare deaktiviert für #Exchange #2013 Server Component Inactive (ServerWideOffline) nach CU-Update- oder Patchfehler

About the Author:

John Lose
John Lose ist Informationstechnologe und Datenreisender. Manche mögen ihn als "Aluhut-Träger" bezeichnen, denn er mag nur kleine Rechenzentren, die er selbst kennt. Public Clouds kommen für Ihn höchstens für Webseiten in Frage. John ist Katzenliebhaber, hat aber keine Katze, fährt gerne nach Südfrankreich und hört Tech-House. Mehr über John Lose erfährst Du in seiner Vita.  Wenn Dir dieser Beitrag gefallen hat, so kannst Du auch Danke sagen, wenn Du möchtest:  >> Dankeschön <<.