Inhaltsverzeichnis

Systemupdates im AD

DCs

Terminalserver

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}

Exchange

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:

Geplantes Update mit Wartungsskripten

Installation von Microsoft Updates auf Exchange Servern

Vorbereitung

Installation

Die Exchange Server mit den folgenden Schritten aktualisieren:

  1. Backup mit dem folgenden Befehl kontrollieren:
    Get-MailboxDatabase -Status | ft Name,LastFullBackup
  2. Plattenplatz prüfen
  3. DB-Replikation prüfen:
    Get-MailboxDatabaseCopyStatus -Server <Servername>

    (das Status der Datenbanken soll „Healthy“ sein)

  4. im DNS den email.secunet.de Host-Eintrag für die IP-Adresse dieses Servers entfernen
  5. (!! als Admin) den Exchange PowerShell öffnen
  6. auf einen anderen Server verschieben (Exchange
  7. den Server in den Wartungsmodus setzen:
    cd $exscripts
    .\StartDagServerMaintenance.ps1 overrideMinimumTwoCopies
  8. den Server neu starten
  9. Windows Updates installieren (!! noch nicht das Exchange Update)
  10. den Server neu starten
  11. ggf. Avira Security for Exchange aktualisieren (als Admin)
  12. den Server neu starten
  13. das Exchange Update installieren
  14. den Server neu starten
  15. Event Log prüfen
  16. den Server aus dem Wartungsmodus nehmen:
    cd $exscripts
    .\StopDagServerMaintenance.ps1
  17. die Datenbanken auf dem Server aktivieren:
    .\RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference
  18. im DNS den email.secunet.de Host-Eintrag für die IP-Adresse dieses Servers hinzufügen

Inhalt der Wartungsskripte

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

Serverstatus prüfen

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

Wartungsmodus beenden

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

Einsatzbereitschaft des Servers prüfen

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