Seit Exchange Server 2016 werden alle Exchange Rollen mit Ausnahme der Edge Transport-Rolle auf dem gleichen System betrieben. Die aktuelle Version erlaubt also keine Rollentrennung mehr. So handelt es sich bei der Exchange Mailbox-Rolle nicht mehr nur um die Datenbank-Engine, sondern auch um Backend-Transport-Funktionen. Was muss nun bei Updates beachtet werden und wie geht man mit den mitgelieferten PowerShell-Scripts um?
Vorgehen
Um sicherzustellen, dass es bei der Installation von Updates auf einem Mailbox Server nicht zu Datenverlust kommt, reicht es daher nicht aus, die aktiven Datenbankkopien auf einen zweiten Mailbox Server innerhalb der DAG zu verschieben, sondern sind auch weitere Schritte notwendig, damit auch alle Transportwarteschlangen geleert und nicht mehr neu gefüllt werden.
Hierzu habe ich ein kleines PowerShell-Script zusammengestellt, das dafür sorgt, dass die Warteschlangen geleert, Nachrichten auf einen anderen, zufällig ausgewählten, Postfachserver verschoben und der Transport-Dienst neu gestartet werden. Im Failover Cluster werden der Server angehalten, alle aktiven Datenbankkopien innerhalb der DAG verschoben und gleichzeitig verhindert, dass diese wieder auf dem Server aktiviert werden. Danach wartet das Script 5 Minuten lang und prüft danach, ob alle Datenbankkopien verschoben wurden. Ist dies nicht der Fall, wird der Verschiebevorgang nochmal angestoßen. Danach erfolgt noch eine Ausgabe, aus der ersichtlich ist, ob der Server nun wirklich „offline“ ist, also keine Exchange-Funktionen mehr bereit stellt.
$Servername = $ENV:ComputerName
$Test = Test-Path "C:Temp"
If (!$Test) {
mkdir C:Temp
}
$Filename = "C:Temp" + $Servername + "_DatabaseCopyAutoActivationPolicy.txt"
$MailboxServers = Get-ExchangeServer | where {$_.ServerRole -like "*Mailbox*"}
$TargetMailboxServers = @()
$MailboxServers | where {$_.Name -ne $Servername} | Foreach {$TargetMailboxServers += $_}
$TargetServerFQDN = (Get-Random $TargetMailboxServers).FQDN
Set-ServerComponentState $Servername -Component HubTransport -State Draining -Requester Maintenance
Restart-Service MSExchangeTransport
Redirect-Message -Server $Servername -Target $TargetServerFQDN
Suspend-ClusterNode $Servername
Set-MailboxServer $Servername -DatabaseCopyActivationDisabledAndMoveNow $True
Wait-Event -Timeout 300
(Get-MailboxServer $Servername).DatabaseCopyAutoActivationPolicy > $Filename
Set-MailboxServer $Servername -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState $Servername -Component ServerWideOffline -State Inactive -Requester Maintenance
Wait-Event -Timeout 300
If (Get-MailboxDatabaseCopyStatus -Server $Servername | where {$_.status -eq "Mounted"}) {
Move-ActiveMailboxDatabase -Server $Servername
}
Get-ServerComponentState $Servername | ft Component,State –Autosize
Danach kann der Server gepatcht oder mit einem neuen Exchange-CU versehen und neu gestartet werden.
Nach Abschluss der Arbeiten ist es wichtig, den Wartungsmodus zu beenden, damit der Server wieder seine Arbeit aufnehmen kann. Auch hierzu habe ich einzelne Schritte in einem Script zusammen gestellt.
$Servername = $ENV:ComputerName
$Filename = "C:Temp" + $Servername + "_DatabaseCopyAutoActivationPolicy.txt"
$OriginalDBCopyAutoActivationPolicy = Get-Content $Filename
Set-ServerComponentState $Servername -Component ServerWideOffline -State Active -Requester Maintenance
Resume-ClusterNode $Servername
Set-MailboxServer $Servername -DatabaseCopyActivationDisabledAndMoveNow $False
Set-MailboxServer $Servername -DatabaseCopyAutoActivationPolicy $OriginalDBCopyAutoActivationPolicy
Set-ServerComponentState $Servername -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport
Get-ServerComponentState $Servername | ft Component,State –Autosize
Mitgelieferte PowerShell-Scripts
Daneben liefert Exchange-Server fertige Scripts mit, beispielsweise zum Aktivieren oder Deaktivieren des Malware Scannings, zum Trennen einer Public Folder Mailbox oder eben zur Wartung eines Mailbox Servers innerhalb von DAGs. Die Scripts befinden sich bei Exchange Server 2013 und 2016 im Verzeichnis „C:Program FilesMicrosoftExchange ServerV15Scripts“, unter Exchange Server 2010 handelt es sich um das Verzeichnis „C:Program FilesMicrosoftExchange ServerV14Scripts“. Die Exchange Management Shell kennt dieses Verzeichnis als $exscripts.
Über das Script StartDagServerMaintenance.ps1 wird der Wartungsmodus auf einem DAG-Mitglied gestartet, StopDagServerMaintenance.ps1 beendet ihn wieder. Nach Abschluss der Wartung kann mit Hilfe des Scripts RedistributeActiveDatabases.ps1 dafür gesorgt werden, dass alle Datenbanken wieder auf den Servern mit der jeweils höchsten Activation Preference aktiviert werden.
Die Scripts sind parametrisiert, lassen sich also ähnlich wie CMDLETs bedienen. Der Aufruf
cd $exscripts
.StartDagServerMaintenance.ps1 <ServerName>
wechselt in das Script-Verzeichnis und startet den Wartungsmodus auf dem Server, der als Parameter angegeben wird.
.StopDagServerMaintenance.ps1 <ServerName>
beendet den Wartungsmodus wieder. Über den letzten Befehl werden alle Datenbanken wieder auf die Server mit der jeweils höchsten Activation Preference verteilt und das Ergebnis danach angezeigt.
. RedistributeActiveDatabases.ps1 -DagName <DAGName> -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution
Wie Sie sehen, ist es einerseits wichtig, über den Wartungsmodus innerhalb von Exchange Server informiert zu sein und dass Exchange Server andererseits wichtige Funktionen bereits über vordefinierte Scripts out of the box liefert. Schauen Sie sich gerne mal in dem oben genannten Verzeichnis um und entdecken Sie vielleicht die ein oder andere Funktion, die Ihnen so noch nicht bekannt war.
