Mit Exchange Server 2016 wurde das Cmdlet Get-MailboxServerRedundancy eingeführt. Mit Hilfe dieses Cmdlets können Sie den Betriebsstatus der Postfach-Server einer Datenbankverfügbarkeitsgruppe (DAG) abfragen, bevor Sie einen Exchange Server in Wartung nehmen.
Leider exisitiert zu diesem Cmdlet keinerlei Hilfeinformation, weder in Microsoft Docs, noch direkt in der PowerShell per Get-Help.
Das Cmdlet verfügt eine tabellarische Standardausgabe der wichtigsten Informationen.
In der Standardausgabe werden angezeigt:
- Identity
Name des Mitgliedsservers der DAG
- IsServerFoundInAD
Hier sehen Sie, ob das zum Exchange-Server zugehöriger AD-Objekt in Active Directory exisitert
- IsInMaintenance
Diese Spalte zeigt an, ob für einen Server aktuell der Wartungsmodus aktiviert ist
- RepairUrgency
In dieser Spalte wird der Reparaturstatus der Postfachdatenbanken und Suchindizes angezeigt
- SafeForMaintenance
In dieser Spalte zeigt das Cmdlet an, ob für einen Server In sicher der Wartungsmodus aktiviert werden kann
- HealthInfoLastUpdateTime
Dies ist der Zeitstempel der letzten Aktualisierung der Health-Daten für den Server
Beispiel – Vor einer Wartung
Das folgende Beispiel zeigt die Informationen einer DAG mit sechs Mitgliedsservern, bevor für Server LOCEXS06 der Wartungsmodus aktiviert wird.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 09:10:11
LOCEXS02 True False Normal True 17.02.2020 09:10:11
LOCEXS03 True False Normal True 17.02.2020 09:10:11
LOCEXS06 True False Normal True 17.02.2020 09:10:11
LOCEXS05 True False Normal True 17.02.2020 09:10:11
LOCEXS04 True False Prohibited False 17.02.2020 09:10:11
Als Exchange Administrator interessieren uns besonders die Spalten RepairUrgency und SafeForMaintenance.
Für keinen der sechs Server ist in diesem Screenshot der Wartungsmodus aktiv. Für die Server S01 und S04 wird angezeigt, dass beide Server nicht sicher in Wartung genommen werden können und die RepairUrgency den Status Prohibited hat.
Was ist der Grund hierfür?
Serverinformationen
Für jeden einzelnen Mitgliedsserver der DAG können Sie Einzelinformationen abfragen. Bei Abfrage der Informationen zu einem Server erhalten wir in der Standardausgabe keine ausführlicheren Informationen zum Status.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 09:11:11
Da der Server LOCEXS01 gegenwärtig nicht sicher in Wartung genommen werden kann, interessiert uns natürlich, welcher Status genau dafür entscheidend ist.
Diese Information erhalten Sie über die Abfrage der Detailinformationen des gewünschten Servers.
Detailinformationen
Die Detailinformationen erhalten Sie einfach durch die Ausgabeformatierung mit Format-List oder kurz FL.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL RunspaceId : 70d82f8d-e6ca-4bfc-863f-11300a9784ff Identity : LOCEXS01 IsServerFoundInAD : True IsInMaintenance : False RepairUrgency : Prohibited SafeForMaintenance : FalseServerContacted Fqdn : LOCEXS04.VARUNAGROUP.DE HealthInfoCreateTime : 15.06.2018 15:16:19 HealthInfoLastUpdateTime : 17.02.2020 09:11:11 ServerFoundInAD : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16; LastInactiveTransition: InMaintenance : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 AutoActivationPolicyBlocked : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50; LastInactiveTransition: 09.01.2020 11:00:51 ActivationDisabledAndMoveNow : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition: 15.06.2018 15:22:16 HighAvailabilityComponentStateOffline : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 CriticalForMaintainingAvailability : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49; LastInactiveTransition: 31.01.2020 16:56:49 CriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06; LastInactiveTransition: 29.01.2020 11:42:06 PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37; LastInactiveTransition: CriticalForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36; LastInactiveTransition: 06.05.2019 09:20:36 CriticalForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02; LastInactiveTransition: 10.02.2020 09:06:02 IsSafeForMaintenance : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35; LastInactiveTransition: 12.11.2019 06:29:58 IsValid : TrueObjectState : Unchanged
Interessant sind die Information in den Zeilen 24-27. Der CurrentState-Wert für die Status-Parameter CriticalForMaintainingRedundancy und PotentiallyCriticalForMaintainingRedundancy ist für beide Active. Das bedeutet, dass der Primary Activation Manager (PAM), zuständig für die Aktivierung von Datenbanken innerhalb der DAG, die Verfügbarkeit dieses Servers als kritisch einstuft, um die Verfügbarkeit der auf diesem Server konfigurieren Datenbankenkopien zu gewährleisten.
Für jeden Status-Parameter werden drei Informationen angezeigt:
- CurrentState
Dieser Wert gibt den aktuellen Status an
- LastActiveTransition
Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Active gewechselt ist
- LastInactiveTransition
Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Inactive gewechselt ist
Warum werden im Regelbetrieb zwei Server als nicht sicher für die Wartung angezeigt?
Der Grund hierfür ist recht simpel. Die auf den sechs Servern eingebunden Postfachdatenbanken werden aus Kapazitätsgründen mit einer unterschiedlichen Anzahl an Datenbankkopien betrieben. Die Datenbanken für Standardpostfächer werden mit jeweils vier Kopien betrieben, die gleichmäßig über alle sechs Server verteilt sind. Die Datenbanken für Archivpostfächer wiederum werden mit je drei Kopien je Postfachdatenbank betrieben. Mit diesen beiden Szenarien ist es jederzeit möglich, einen Exchange Server sicher in Wartung zu nehmen, ohne die Redundanz der Postfachdatenbanken zu gefährden.
Auf den Servern LOCEXS01 und LOCEXS04 sind jedoch auch Postfachdatenbanken eingebunden, die nur mit je zwei Kopien betrieben werden. Einen dieser beiden Server in Wartung zu nehmen würde bedeuten, dass während der Wartung keine Redundanz von Datenbanken mehr vorhanden ist. Dies ist der Grund, warum uns der PAM über das Cmdlet mitteilt, dass wir diese beiden Server nicht sicher in Wartung nehmen können.
Beispiel – Während einer Wartung
Das folgende Beispiel zeigt den Betriebszustand der Mitgliedsserver der DAG, während der Server LOCEXS06 in Wartung ist. Auf dem Server wurden zu diesem Zeitpunkt die monatlichen Windows Updates installiert.
Der Exchange Server wurde mit Hilfe des PowerShell-Skriptes StartDagServerMaintenance.ps1 in Wartung genommen.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 11:04:12
LOCEXS02 True False Normal True 17.02.2020 11:04:12
LOCEXS03 True False Prohibited False 17.02.2020 11:04:12
LOCEXS06 True True High True 17.02.2020 11:04:12
LOCEXS05 True False Prohibited False 17.02.2020 11:04:12
LOCEXS04 True False Prohibited False 17.02.2020 11:04:12
Wenn sich ein Server innerhalb der DAG in Wartung befindet, wirkt sich dies natürlich auch auf die verbleibenden Server aus. Weitere zwei Server (LOCEXS03 und LOCEXS05) können nicht sicher zusätzlich in Wartung genommen werden, da ansonsten die redundante Verfügbarkeit der Postfachdatenbanken nicht mehr gewährleistet ist.
Beispiel – Nach einer Wartung
Der durchgeführter Installation der Windows Updates oder eines Kumulativen Updates, wird die Wartung des Servers mit StopDagServerMaintenance.ps1 wieder beendet.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 11:23:12
LOCEXS02 True False Normal True 17.02.2020 11:23:12
LOCEXS03 True False Normal True 17.02.2020 11:23:12
LOCEXS06 True False High True 17.02.2020 11:23:12
LOCEXS05 True False Normal True 17.02.2020 11:23:12
LOCEXS04 True False Prohibited False 17.02.2020 11:23:12
Der Server ist zwar nicht mehr im Wartungsmodus, jedoch ist der Status der RepairUrgency weiterhin auf High, da die Exchange Replication Engine damit beschäftigt ist, die während der Wartung aufgelaufenen Protokolldateien einzuspielen und die Suchindizes zu aktualisieren.
Tipp
- Wenn Sie für einen Exchange Server, der nicht sicher in Wartung genommen werden kann, den Wartungsmodus mit StartDagServerMaintenance.ps1 -serverName [SERVER] aktivieren möchten, wird es zu einer Fehlermeldung kommen.
In diesem Fall müssen Sie den Wartungsmodus mit folgendem Aufrauf aktivieren
.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true
Viel Spaß mit Exchange Server!
