Exchange Pause

Ich habe nicht vor, meine Arbeit mit und an Exchange einzustellen aber vielleicht müssen Sie ihren selbst gehosteten Exchange Server für einige Stunden oder gar Tage "offline" nehmen. Auf was sollten Sie dann achten und wie können Sie die Pause im Betrieb möglichst schadlos überstehen.

Warum?

Mailserver sind 24x7-Systeme, die in der Regel immer durchlaufen und wem selbst die kurzen Unterbrechungen zur Installation von Updates und Servicepacks zu lange sind, installiert eben einen Exchange im Cluster, so dass Sie einzelne Knoten im Wartungsmode ändern können ohne den Betrieb zu stören. Es gibt aber auch Gründe, warum sie wirklich alle Exchange Server zur gleichen Zeit "Offline" nehmen müssen oder besser sollten. Hier ein paar Beispiele:

  • Arbeiten an Stromversorgung oder Klima
    Gewisse Arbeiten an der Energieverteilung, insbesondere zwischen USB und Servern kann man nur im "stromlos"-Zustand machen und dazu müssen die Server nun mal abgeschaltet werden.
  • Arbeiten am Netzwerk, LAN, WAN
    Viele Dinge lassen sich schon im laufenden Betrieb "Parallel" umbauen. Aber ich kenne Fälle, wo es einfacher war, alle Server offline zu nehmen und nach dem Umbau oder der Neuverkabelung der Racks wieder online zu nehmen.
  • Geografische Umzüge
    Ganz typisch ist der Fall bei kleineren Firmen, die den Standort wechseln und ihre Server quasi mit per LKW "umziehen".
  • Security Incident
    Wenn das Risiko besteht, dass ihre Infrastruktur kompromittiert ist, dann habe ich auch schon Server "ganz schnell" heruntergefahren, ehe sie auch verschlüsselt werden.

Manchmal sind es auch Änderungen, die Exchange nicht direkt betreffen, sondern z.B. ein Ausfall des Active Directory o.ä., ohne das Exchange auch nicht funktionieren kann oder sie wollen einfache nicht das Risiko eingehen, dass eine Infrastrukturstörung ihren Exchange Server mit beschädigt oder zumindest ins Risiko bringt.

Sie sollten sich also durchaus damit befassen wie Sie nicht nur einzelne Server zum Patchen kurzfristig offline nehmen, sondern auch komplette Dienste für Stunden oder länger außer Betrieb nehmen und danach wieder geordnet reaktivieren.

Auswirkungen

Wenn aber nun alle Server "offline" sind, dann kann sich natürlich kein Client mehr mit dem Server verbinden. Wenn Sie ihre Mitarbeiter und Nutzer über die geplante Unterbrechung informieren, ist das aber handhabbar. Keinen Einfluss haben Sie aber z.B. auf die externen Systeme, die Mails an ihre Domain senden und ihre Exchange Server oder vorgeschaltete Firewall und Spamfilter nicht erreichen. Selbst wenn die Spamfilter ihre Mails noch annehmen müssen Sie diese nun deutlich länger die Mails puffern, denn die nachgelagerten Systeme alle nicht mehr erreichbar sind. Wenn ihre Spamfilter ebenfalls durch die längere Unterbrechung betroffen sind, dann könnten Sie über einen temporären Backup-MX nachdenken.

Auch der Neuanlauf kann Probleme bringen. Wenn Sie z.B. durch Arbeiten an der Energieversorgung die Server nach Wiederherstellung gleich wieder starten, werden sie sicher Probleme bemerken, die sich mit einem etwas verzögerten Start nicht haben. Sie sollten nach so einer Unterbrechung die Exchange Server z.B. erst wieder starten, wenn die Stromversorgung wirklich "sicher" wieder da ist und auch die Batterien der USV wieder etwas aufgeladen wurden, dass Sie ein sauberes herunterfahren erlauben. Viel wichtiger ist aber, dass auch das Netzwerk (Router, Switches, Loadbalancer) und Infrastrukturdienste (NTP ,DNS, Active Directory) funktionstüchtig sind. Wer auf SAN und Virtualisierung setzt, muss auch hier erst einmal sicherstellen, dass der Storage- und Compute-Unterbau wieder bereitgestellt wurde.

Je länger die Unterbrechung dauert, desto mehr wartende Mails haben sich an den verschiedenen Stellen angesammelt und sobald Exchange startet, werden ganz viele Mails in kurzer Zeit ihre System belasten. Es kann schon einige Stunden dauern, bis ein solches Backlog abgearbeitet ist. Wenn SMTP-Sender aber keinen "Retry" starten, was bei automatischen Systemen mit "Send-Mailmessage", BLAT, Scan2Mail, PHP-Formulare etc. eher der Regelfall ist, dann fehlen diese Mails.

Auswirkungen minimieren

Ohne Exchange und ohne Infrastruktur können natürlich auch keine Client auf Exchange zugreifen. Das ist eine Aufgabe für die Unternehmenskommunikation, diese Unterbrechung und den Umgang damit zu erläutern. Auch andere interne Systeme könnten gleich mit "Down" sein, so dass im Hinblick auf Exchange nur externe Systeme zu berücksichtigen sind. Mit fallen da erst einmal zwei Absender ein

  • Mailserver im Internet
    Einen Mailserver betreiben Sie, um Mails zu empfangen. Wenn der MX auf die Server verweist, die nicht erreichbar sind, dann stellen die externen Systeme die Mails in eine Warteschlange und versuchen es immer wieder. In den Anfangszeiten des Internet war es üblich, dass Server es oft bis zu 3 Tage immer wieder mit längeren Intervallen versucht haben. teilweise konnten Sie die Mails sogar bei anderen Servern zur Weiterleitung abliefern. Das war für Firmen mit "Wählverbindungen" wichtig, um teure Online-Zeit zu optimieren. Heute ist es oft schon so , dass eine Mail nach einem Tag als "Unzustellbar" gilt und die Absender schon nach wenigen Stunden eine Information bekommen, dass die Mails verzögert sind.
    Hier könnte ein temporärer Mailserver bei einem Dienstleister helfen, zu dem Sie in der Zeit ihren MX-Record umleiten und der ihre Mails solange annimmt und länger zwischenspeichert.
    Vielleicht ist ein temporärer Postfix bei einem Hoster auf einer Linux VM mit ausreichend Disk eine Option. Siehe auch Backup-MX
  • Eigene Cloud-Dienste
    Dann gibt es immer mehr Firmen, die nicht mehr alle Dienste im eigenen LAN oder RZ betreiben, sondern Cloud-Dienste nutzen. Ihre "Firmenwebseite" läuft dann beim Provider und das Feedback- oder Kontakt-Formular sendet die erfassten Daten per PHP-Mail an ihren Mailserver. Wenn der nicht da ist, kann das Formular keine Mails senden und der Besucher bekommt eine unschöne Fehlermeldung. Solche Lösungen könnten natürlich auch an einen lokalen SMTP-Relay zustellen, der dann eine Warteschlange verwaltet. Oft wird das aber einfach nicht gemacht.

Sollte ihr Ausfall also "länger" dauern, und ich würde da bei 6h anfangen drüber nachzudenken, dann wäre ein alternative Mailserver als Zwischenspeicher durchaus eine Überlegung. Es gibt sogar Dienste, bei den Sie die wartenden Mails in der Queue "anschauen" können und so in der Downtime vielleicht einen Notbetrieb zu ermöglichen. In Exchange Online ist die maximale Haltezeit aber auf 24h beschränkt und damit keine echte Lösung als Zwischenspeicher für ein lokales Mailsystem zu dienen.

Exchange geplant abschalten

Bei den meisten Firmen laufen Exchange Server 24x7 durch und werden nur zur Updates, Upgrades oder Security Updates durchgestartet. Selbst dann ist die Downtime minimal und wir starten ja mit einem funktionsfähigen Server in einer aktiven Umgebung. Wer mehrere Server hat, kann mit dem "Wartungsmode" einen Server geplant und geordnet außer Betrieb nehmen. Die Datenbanken werden auf andere Server geschwenkt, der SMTP-Dienst nimmt keine Mails mehr an und leert seine Warteschlangen und wenn der Loadbalancer die Exchange HealthCheck-URLs prüft, werden auch die Client auf die anderen Server umgestellt.

Wir wollen aber nun alle Server herunterfahren. Da macht es wenig Sinn, einen Server nach dem Anderen erst in den Wartungsmode zu setzen und damit die letzten Server zu überlasten. Ich würde daher wie folgt vorgehen, damit die Warteschlangen "clean" und die Datenbanken auch einen "Clean Shutdown" haben und damit alle Server konsistent sind. Je nach Größe und Anspruch können Sie Punkte natürlich weglassen.

Aktion Status

Vorzeitiges Wiedereinschalten verhindern

Wir haben die Server noch gar nicht herunter gefahren und mein erster Punkt beschäftigt sich schon wieder mit dem späteren Hochfahren. Die Überlegungen sind aber wichtig, denn wenn später der Strom wieder kommt, würden viele Server einfach loslaufen. Das ist im dem Fall aber ungeschickt denn die Exchange Server sollten erst wieder starten, wenn die Umgebung "steht" und dazu zählen:

  • Strom
    Ihr USV wurde gerade umgebaut und alles ist wieder verdrahtet und eingeschaltet. Aber haben die Batterien schon wieder genug Energie, um bei einem externen Ausfall lange genug ihr System für einen geplanten Shutdown am Leben zu halten? Vielleicht sollten sie mit Exchange und den "empfindlichen Datenbanken" auch einfach noch etwas warten, bis andere Infrastrukturdienste gestartet sind
  • Netzwerk
    Dazu zählt insbesondere das Netzwerk (Switch, Router, Links, Firewall), denn wenn Windows Server keine DCs erreichen können, dann funktionieren keine Gruppenrichtlinien, Anmeldedienst aber auch kein Cluster-Heartbeat etc.
  • Verzeichnisdienste
    Grundsätzlich braucht Exchange ein funktionierendes Active Directory und die verbundene Dienste (DNS, NTP, DHCP). Vielleicht warten wir erst einmal auf ein "OK" vom Domain Admin, dass seine DCs alles grün sind. Es kann ja durchaus sein, dass bei einem Start sehr vieler System mit ganz vielen Anmeldungen hier eine temporäre Überlastung für Folgefehler zuständig ist.
  • Storage und SAN
    Exchange Datenbanken sind gerne etwas "Größer". werde die Daten über Virtualisierung und SAN auf Storage-Systemen betreibt, muss auch erst einmal prüfen, dass die Disks auch alle wieder bereitgestellt sind

Sie sehen also, dass Sie vor dem eigentlichen Start von Exchange noch einige zu prüfen haben und ein blinder automatischer Start mehr Schaden anrichten kann als ihnen dies nutzt. Bei physikalischen Servern könne Sie im BIOS oft einstellen, dass nach "Wiederherstellung der Stromversorgung" das System nicht alleine bootet oder sie ändern den Boottimeout von Windows temporär entsprechend ab. Bei VMs können sie meist in der Konfiguration das Neustartverhalten einstellen.

All das können sie lange vor dem Wartungsfenster anpassen und testen. Daher erfolgt es besser einige Tage vorher.

 

Eingehendes Routing

Wir gehen davon aus, dass Exchange aber auch die vorgelagerten Spamfilter und Firewalls alle für einige Zeit aus sein werden. Für einige Stunden versuchen externe Server ein "Retry" aber wenn das nicht reicht dann sollten sie überlegen, ob ein Mailserver an einem ganz anderen Ort, z.B. beim einem Provider, in Azure o.ä. als Zwischenspeicher dienen kann. Das wäre dann:

  • TTL des MX-Record reduzieren, z.B. auf 1- 5 Minuten
    Das gibt Flexibilität beim Umschalten und späteren Zurückschalten. Wenn der aktuelle TTL mehrere Stunden ist, dann sollten Sie die Reduzierung einige Tage vorher schon vornehmen, damit alle Server im Internet den neuen TTL kennen.
  • Zwischenspeicher-Mailserver einrichten
    Er nimmt Mails für ihre Domain an, sollte die gültigen Empfänger kennen und TLS unterstützen. Zudem muss er Mails als Relay für ihre Domains annehmen und ausreichend lange vorhalten. Inwieweit sie für die wenigen Tage auf einen Spamschutz verzichten, müssen Sie selbst bewerten. Denken Sie auch an den erforderlichen Festplattenplatz für die Queue
  • Routing zum OnPremises Server konfigurieren
    Der Zwischenspeicher muss später die Mails entweder wieder über Internet "vorne" an ihren Spamfilter einkippen, der dann natürlich die IP-Adresse des Zwischenspeichers nicht auf SPF/RBL prüfen oder Connection Limits anwenden darf.
  • Testen des Zwischenspeicher-Servers
    Wir halten die Queue zum richtigen Server an, stellen eine Mail an Ersatzserver zu und sehen, wie sie in der Queue liegen bleiben. Wenn wir dann die Zustellung wieder erlauben, sollte die Mail aus der Queue zum realen Server zugestellt werden
  • Eingehendes Routing umstellen
    Vor dem "Down" des produktiven Servers stellen wir dann den MX-Record auf den Zwischenspeicher und warten, bis am richtigen Server keine Mails mehr ankommen.

Clients aussperren

Der nächste Schritt ist die Blockade des Zugriffs durch Clients. Das können wir über eine Regel in der Netzwerk-Firewall oder notfalls auch auf dem Exchange Server machen. Sie können auch die POP3, IMAP4-Dienste und die Frontend Webseite oder die virtuellen Services auf einem Loadbalancer beenden. Damit können Clients keine Mails mehr lesen oder einliefern. Outlook, ActiveSync und Co bekommen natürlich Fehlermeldungen. Eine passende Kommunikation sollte zu den Anwendern vorab erfolgt sein. Tipp: Vielleicht legen Sie eine temporäre Webseite "status.<firmendomain>" bei einem externen Webhoster oder ein Wordpress-Blog an, über welches sie ihre Mitarbeiter und Nutzer über den Fortschritt, den Status und mögliche Korrekturen informieren können. Das Hilfsmittel "E-Mail" haben sie ja nun nicht mehr. Ob ein Status in einem Teams Team funktioniert, hängt von der Anmeldung der Anwender an Office 365 ab, wenn das lokale AD nicht mehr vorhanden ist.

TransportQueues leeren

Aus dem Internet sollten schon länger keine Mails mehr ankommen. Eventuell gibt es noch interne Prozesse aber die werden mit dem Shutdown des Standorts dann auch nicht mehr arbeiten. Da auch die Clients nicht mehr tun, sollten die Warteschlangen langsam leer laufen. Prüfen Sie dies aber, denn wenn ein Server z.B. 2-3 Tage down ist und dann wieder startet und in der Warteschlange so eine alte Mail liegt, dann könnte es sein, dass Exchange diese als Unzustellbar verwirft. Sie können gerne den Transport-Dienst "pausieren damit er keine Mails mehr annimmt aber weiter seine Queues leert

# Transportdienst pausieren (auf allen Servern)
Suspend-Service MSExchangeTransport

# Anzeige der Mails in den Queues
Get-Queue

Datenbanken offline nehmen

Anstatt nun die Server in den Wartungsmode zu stellen, würde ich die Datenbanken "geplant" offline nehmen.

# Entfernen der Datenbanken
Get-Mailboxdatabase | Dismount-MailboxDatabase

Damit sollten Sie auf allen Server einen „Clean Shutdown“-State haben und vor allem wirklich „identisch“ sein. Also keine ist älter als die andere Version. Es gibt hier keine einzige "richtige" Version. Natürlich können Sie auch die Datenbanken in den Wartungsmode setzen oder ein "AutoActivate" deaktivieren etc. Sie müssen danach aber wieder dran denken, diese wieder zu reaktivieren. Informieren Sie sich vielleicht auch noch einmal zur Funktion des DAC (Database Activation Coordinator) und die Funktion des Witness-Servers, wenn alle Server Down sind.

Dienste deaktivieren

Wer noch mehr Sicherheit haben will, kann es wie das Exchange Update machen. Es exportiert die Startup-Konfiguration aller Dienste und beendet diese dann und setzt den Startup-Type auf disabled, um später Windows ohne Exchange zu starten.

Get-Service | Where {$_.DisplayName –like “Microsoft Exchange*”} | Set-Service -StartupType Disabled
Get-Service | Where {$_.DisplayName –like “Microsoft Exchange*”} | Stop-Service

Sie können sich natürlich auch auf die wesentlichen Dienste beschränken:

Set-Service MSExchangeTransport -StartupType Disabled
Stop-Service MSExchangeTransport
Set-Service MSExchangeIS -StartupType Disabled
Stop-Service MSExchangeIS

Das können Sie auch noch für den IIS und Cluster-Dienst machen, Aber ohne Exchange Dienste ist Exchange nicht aktiv und der IIS liefert über den Exchange Health Check auch einen Fehler, damit ein Loadbalancer den Service nicht aktiviert.

Server Down

Wenn Exchange keine Clientverbindungen mehr bekommt, die Queues leer sind und die Datenbanken sauber beendet wurden, können Sie den Exchange Cluster stoppen und die Server herunterfahren.

Stop-Cluster
Stop-Computer

Warten

Nun können Sie das "OK" an den Hauselektriker, die Spedition etc. geben oder war auch immer die längere Pausenzeit begründet. Sie können nun nur noch warten, bis alles wieder für den Neustart der Exchange Server bereitgestellt wurde

Exchange wieder anfahren

Im Abschnitt "Exchange geplant abschalten" habe ich als ersten Punk "Vorzeitiges Wiedereinschalten verhindern" aufgeführt, welche Vorarbeiten erforderlich sind und genau diese müssen wir nun prüfen:

  • Strom ist "sicher" da?
  • Netzwerk ist vorhanden
  • Active Directory ist betriebsfähig
  • VM-Hosts und Storage-Systeme sind vorhanden

Erst wenn hier von allen Fachabteilung ein "Daumen hoch" kommt, können Sie Exchange starten. Wenn Sie vorher die Dienste deakiviert haben, dann wird erst einmal nur Windows starten. Sie können sich dann schon einmal anmelden und etwas die Umgebung prüfen, z.B.

  • Können Sie ihr Default Gateway anpingen
  • Können Sie die DCs auflösen und erreichen
    z.B. per NSLOOKUP, per DCDIAG/NETDIAG oder Zugriff auf \\domain.tld\sysvol
  • Sehen sie die Festplatten mit allen Datenbanken und sind diese beschreibbar
  • Gibt es problematische Meldungen im Eventlog
  • Läuft der Windows Cluster an sich und sind alle Knoten online?
    Das ist insbesondere wichtig, wenn Sie den DAC-Mode aktiviert haben.

Hier haben natürlich die Exchange Administratoren einen Vorteil, die solche Prüfungen schon an das Monitoring ausgelagert haben und nun einfach in der Überwachung den Status prüfen können. Sollten Sie nun ziemlich sicher sein, dass Exchange bereit ist, dann können Sie die Dienst wieder auf "automatisch" stellen und starten, z.B. mit:

Get-Service | Where {$_.DisplayName –like “Microsoft Exchange*”} | Set-Service -StartupType Automatic
Get-Service | Where {$_.DisplayName –like “Microsoft Exchange*”} | Start-Service

Wenn Sie vor der Abschaltung den Wartungsmodus nicht genutzt haben, dann sollten auch die Datenbanken automatisch starten und die Replikation wieder aufnehmen. Die korrekte Funktion von Exchange kann idealerweise das Monitoring bestätigen oder sie nutzen etwas PowerShell, z.B.

(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Get-MailboxDatabaseCopyStatus -Server $_}}
(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Test-ReplicationHealth -Server $_}}

Die Client sollten sich nun wieder verbinden können und neue Mails intern und nach extern versenden. Nur eingehende Mails gibt es noch nicht, wenn Sie als Vorarbeit den MX-Record zu einem "Zwischenspeicher" umgeleitet haben.

Damit sollten die Server dann wieder im normalen Betrieb sein. Es wird sicher am Anfang alles etwas langsamer sein, weil sich viele Clients und kurzer Zeit neu anmelden müssen, Mails aus eingehenden Warteschlangen eine temporäre höhere Last erwarten lassen etc. Es wird aber auch Dienste geben, die sich nicht alleine wieder fangen oder während der Downtime keine Mails zustellen oder abfragen konnten und es nicht weiter erneut versuchen.

Externe Verbindungen zulassen

Wenn Exchange soweit bereitgestellt ist, dann können wir auch die Clients und SMTP wieder zulassen. Prüfen Sie das aus dem Internet, indem Sie eine Mail an die IP-Adresse senden, die bisher durch den MX-Record definiert war. Wenn Sie so die Funktion für eingehenden Mails geprüft haben, dann können Sie den MX-Record wieder auf ihren regulären Server umstellen. Durch den anfangs reduzierten TTL werden die Server im Internet die Änderung recht schnell bekommen aber das bedeutet nicht, dass diese nun sofort alle wartenden Mails auf die Reise senden. Je nach Konfiguration des Absenders müssen einige Minuten oder teils sogar Stunden vergehen, bis die eine Übertragung erneut versucht wird. Dies können Sie nicht beeinflussen.

Wer einen Zwischenspeicherserver aufgebaut hat, muss sich nun noch darum kümmern, dass die Mails aus dessen Queue an die Server zugestellt werden. Dazu müssen Sie die entweder die Konfiguration anpassen oder die Queue freigeben. Das hängt natürlich vom Produkt ab.

Weitere Links