wiki.nunatakker.de

Eine ältere Version des Dokuments wurde geladen! Beim Speichern wird eine neue Version des Dokuments mit diesem Inhalt erstellt.

====== Systemupdates im AD ======

===== DCs =====
  * Immer nur einen DC gleichzeitig aktualisiern :!:
  * Ansonsten keine Besonderheit zu berücksichtigen.

===== 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:\\
<code>change logon /disable
change logon /enable</code>

:!: 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):
<code powershell>Invoke-Command -ComputerName ZIELSYSTEM {change logon /enable}</code>

===== Exchange =====
__**WICHTIG:**__ :!:
  * Die Systeme nicht unbeaufsichtigt patchen lassen
  * Vor dem Beginn sicherstellen, dass kein Backup der Datenbanken läuft. Ansonsten lässt sich die Aktivierung der Datenbank-Kopien nicht ändern
  * Alle Systeme in einem Arbeitsablauf patchen, auch die Systeme mit den Verwaltungskonsolen. Da die verwaltungskonsole auf DotNET und Powershell-Commandlets basiert, müssen diese auf allen Systemen einen einheitlichen Stand haben
  * MAIL-DRESDEN-01 sollte immer als erstes System gepatcht werden. Treten hier Probleme auf, sollten Updates an den anderen Mailsystemen nicht mehr eingespielt werden

__**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 ===
  * Installationsdateien herunterladen:
  * prüfen, welches Exchange Rollup Update installiert ist: Control Panel > Programs and Features > View Installed Updates
  * prüfen, welches Exchange Rollup Update aktuell verfügbar ist (Microsoft Downloads)
  * falls es ein neues Exchange Rollup Update gibt UND __**dies mindestens sechs Wochen alt ist**__, diese herunterladen
  * prüfen, welche Avira Security for Exchange Version installiert ist: (Control Panel > Programs and Features > Avira Security for Exchange)
  * prüfen, welche Avira Security for Exchange Version aktuell verfügbar ist
  * falls es eine neue Avira Security for Exchange Version gibt *UND* __**diese mindestens vier Wochen alt ist**__, diese herunterladen; falls es eine neue Version gibt, die nicht vier Wochen alt ist, mit der Installation vom Exchange Update abwarten, bis die Avira Security for Exchange Update auch vier Wochen alt ist :!:
  * falls die Exchange Admin Tools auf anderen Rechnern installiert sind, das Exchange Rollup Update auf diesen Rechnern installieren
=== Installation ===
Die Exchange Server mit den folgenden Schritten aktualisieren:

* (am Vorabend) neue Client-Verbindungen verhindern:
  * am Wartungstag:
  - Backup mit dem folgenden Befehl kontrollieren: <code powershell>Get-MailboxDatabase -Status | ft Name,LastFullBackup</code>
  - Plattenplatz prüfen
  - DB-Replikation prüfen: <code powershell>Get-MailboxDatabaseCopyStatus -Server <Servername></code> (das Status der Datenbanken soll „Healthy“ sein)
  - im DNS den email.secunet.de Host-Eintrag für die IP-Adresse dieses Servers entfernen
  - (!! als Admin) den Exchange PowerShell öffnen 
  - auf einen anderen Server verschieben (Exchange 
  - den Server in den Wartungsmodus setzen: <code powershell>cd $exscripts
.\StartDagServerMaintenance.ps1 overrideMinimumTwoCopies</code> 
  - den Server neu starten
  - Windows Updates installieren (!! noch nicht das Exchange Update)
  - den Server neu starten
  - ggf. Avira Security for Exchange aktualisieren (als Admin)
  - den Server neu starten
  - das Exchange Update installieren 
  - den Server neu starten
  - Event Log prüfen
  - den Server aus dem Wartungsmodus nehmen:<code powershell>cd $exscripts
.\StopDagServerMaintenance.ps1</code>
  - die Datenbanken auf dem Server aktivieren:<code powershell>.\RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference</code>
  - 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:
<code>Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance
Restart-Service MSExchangeTransport
</code>

2. Unified-Messaging-Aufrufe abgleichen:
<code>Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance</code>

3. Nachrichten, für die die Übermittlung in den lokalen Warteschlangen noch aussteht, an den durch den Target-Parameter angegebenen Postfachserver umleiten.
<code>Redirect-Message -Server <ServerName> -Target <MailboxServerFQDN></code>

4. Den Clusterknoten anhalten, um zu verhindern, dass der Knoten der PAM ist oder wird:
<code>Suspend-ClusterNode <ServerName></code>

5. Verschieben der aktiven Datenbank auf einen anderen DAG-Server:
<code>Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $True </code>

6. Verhindern, dass der Server aktive Datenbankkopien hostet
<code>Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Blocked</code>

7. Den Server in den Wartungsmodus zu versetzen.
<code>Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance</code>

=== Serverstatus prüfen ===
Prüfen, ob ein Server zur Wartung bereit ist:\\

1. Prüfen, ob der Server sich im Wartungsmodus befindet.
<code>Get-ServerComponentState <ServerName> | ft Component,State -Autosize</code>

2. Prüfen, ob der Server keine aktiven Datenbankkopien hostet.
<code>Get-MailboxServer <ServerName> | ft DatabaseCopy* -Autosize</code>

3. Prüfen, ob der Clusterknoten angehalten wurde.
<code>Führen Sie Get-ClusterNode <ServerName> | fl</code>

4. Prüfen, ob für alle Transportwarteschlangen ein Ausgleich vorgenommen wurde.
<code>Get-Queue</code>

=== 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.
<code>Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance</code>

2. Zulassen, dass der Server Unified Messaging-Anrufe annimmt.
<code>Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance</code>

3. Den Knoten im Cluster fortsetzen und die vollständige Clusterfunktionalität für den Server aktivieren.
<code>Resume-ClusterNode <ServerName></code>

4. Zulassen, dass Datenbanken auf dem Server aktiv werden.
<code>Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $False</code>

5. die automatischen Aktivierungsblockierungen entfernen.
<code>Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Unrestricted</code>

6. Die Transportwarteschlangen aktivieren und zulassen, dass der Server Nachrichten annimmt und verarbeitet.
<code>Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance</code>

7. Die Transportaktivität fortsetzen.
<code>Restart-Service MSExchangeTransport</code>

=== Einsatzbereitschaft des Servers prüfen ===
1. Sicherstellen, dass sich der Server nicht im Wartungsmodus befindet.
<code>Get-ServerComponentState <ServerName> | ft Component,State -Autosize</code>

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:

<code>
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
</code>

Zusammenfassung