Um zu verhindern, dass sich während eines Updates Benutzer an einem Terminalserver anmelden, kann die Benutzeranmeldung vorrübergehend mit dem folgenden Befehl de- bzw. wieder aktiviert werden:
change logon /disable change logon /enable
Die Wirkung der Befehle bleibt auch nach einem Neustart erhalten. Wenn die
/enable Option nicht vor dem Neustart gesetzt wurde, ist auch für den Administrator einen Anmeldung am Terminalserver-Dienst nicht möglich.
In diesem Fall kann über PowerShell-Remoting der gewünschte Zustand wiederhergestellt werden (entsprechende Admin-Rechte des PowerShell-Benutzers am Zielsystem vorausgesetzt):
Invoke-Command -ComputerName ZIELSYSTEM {change logon /enable}
WICHTIG:
Ausführen des Wartungsprozesses auf DAG-Mitgliedern
Bevor eine Soft- oder Hardwarewartung für ein DAG-Mitglied ausgeführt werden darf, muss das DAG-Mitglied zunächst in den Wartungsmodus versetzen. Dazu müssen alle aktiven Datenbanken vom Server verschoben werden. Es muss sichergestellt werden, dass während der Wartung aktive Datenbanken nicht wieder auf den Server zurückverschoben werden. Außerdem muss sichergestellt sein, dass alle wichtigen DAG-Unterstützungsfunktionen, die sich möglicherweise auf dem Server befinden (z. B. die PAM-Rolle), auf einen anderen Server verschoben und daran gehindert werden, wieder auf diesen Server zurück verschoben zu werden. Dazu ist vor dem Einspielen der Updates das folgende Prozedere zu durchlaufen:
Installation von Microsoft Updates auf Exchange Servern
Die Exchange Server mit den folgenden Schritten aktualisieren:
Get-MailboxDatabase -Status | ft Name,LastFullBackup
Get-MailboxDatabaseCopyStatus -Server <Servername>
(das Status der Datenbanken soll „Healthy“ sein)
cd $exscripts .\StartDagServerMaintenance.ps1 overrideMinimumTwoCopies
cd $exscripts .\StopDagServerMaintenance.ps1
.\RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference
Gelegentlich kommt es zu Problemen beim Durchlauf der Skripte, die den Server in den Wartungsmodus versetzen bzw. ihn wieder daraus herausholen sollen. Die Skripte arbeiten die folgenden Schritte ab. Es kann im Problemfall hilfreich sein, einige der folgenden Schritte einzeln durchzuführen, wenn das Skript abbricht. 1. Abgleich der Transportwarteschlangen:
Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance Restart-Service MSExchangeTransport
2. Unified-Messaging-Aufrufe abgleichen:
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance
3. Nachrichten, für die die Übermittlung in den lokalen Warteschlangen noch aussteht, an den durch den Target-Parameter angegebenen Postfachserver umleiten.
Redirect-Message -Server <ServerName> -Target <MailboxServerFQDN>
4. Den Clusterknoten anhalten, um zu verhindern, dass der Knoten der PAM ist oder wird:
Suspend-ClusterNode <ServerName>
5. Verschieben der aktiven Datenbank auf einen anderen DAG-Server:
Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $True
6. Verhindern, dass der Server aktive Datenbankkopien hostet
Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Blocked
7. Den Server in den Wartungsmodus zu versetzen.
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance
Prüfen, ob ein Server zur Wartung bereit ist:
1. Prüfen, ob der Server sich im Wartungsmodus befindet.
Get-ServerComponentState <ServerName> | ft Component,State -Autosize
2. Prüfen, ob der Server keine aktiven Datenbankkopien hostet.
Get-MailboxServer <ServerName> | ft DatabaseCopy* -Autosize
3. Prüfen, ob der Clusterknoten angehalten wurde.
Führen Sie Get-ClusterNode <ServerName> | fl
4. Prüfen, ob für alle Transportwarteschlangen ein Ausgleich vorgenommen wurde.
Get-Queue
Nachdem die Wartung abgeschlossen und das DAG-Mitglied bereit ist, den Dienst wieder aufzunehmen, kann es aus dem Wartungsmodus zurück in den Produktionsmodus versetzt werden. Dazu sind die folgenden Schritte auszuführen:
1. Im DAG veröffentlichen, dass der Server sich nicht mehr im Wartunmgsmodus befindet.
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance
2. Zulassen, dass der Server Unified Messaging-Anrufe annimmt.
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance
3. Den Knoten im Cluster fortsetzen und die vollständige Clusterfunktionalität für den Server aktivieren.
Resume-ClusterNode <ServerName>
4. Zulassen, dass Datenbanken auf dem Server aktiv werden.
Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $False
5. die automatischen Aktivierungsblockierungen entfernen.
Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Unrestricted
6. Die Transportwarteschlangen aktivieren und zulassen, dass der Server Nachrichten annimmt und verarbeitet.
Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance
7. Die Transportaktivität fortsetzen.
Restart-Service MSExchangeTransport
1. Sicherstellen, dass sich der Server nicht im Wartungsmodus befindet.
Get-ServerComponentState <ServerName> | ft Component,State -Autosize
Wenn ein Exchange-Update installiert wurde und der Updateprozess fehlschlägt, können dadurch einige Serverkomponenten in einem inaktiven Zustand verbleiben. Dies wird in der Ausgabe des oben aufgeführten Cmdlets „Get-ServerComponentState“ angezeigt. Zum Beheben eines Problems die folgenden Befehle ausführen:
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