Exchange Server Deinstallation

Freischaltung

In der Regel ist eine Migration erst dann zu Ende, wenn alle Informationen von alten Server auf den neuen Server verschoben wurden. Aber auch hier bleiben gerne und oft einige Aspekte unberücksichtigt, weswegen ich hier einige Punkte aufführe, die vor der Abschaltung erfüllt sein sollten:

• Postfächer und Public Folder
  Es versteht sich von selbst, dass Sie als erstes alle "Inhalte" des alten Exchange Servers auf neue Server verlagern müssen. Vergessen Sie dabei auch nicht die Benutzer, die zwar ein Postfach haben aber noch nicht angemeldet waren. Sie erscheinen nicht immer in den Statistiken. Ein "Get-Recipient" mit einem Filter auf die Datenbanken des alten Servers hilft hier weiter.
• Connectoren
  Damit der alte Server keine Mails mehr versendet, sollten Sie bei allen SEND-Connectoren prüfen, dass diese andere Server als "Local Bridgehead" verwenden. Nach einiger Zeit sollte der alte Server dann zumindest keine Mails mehr versenden. Auf den Empfang hat das aber direkt keinen Einfluss und ich würde die Receive-Connectoren auch noch nicht löschen. Dies passiert besser erst kurz vor der Abschaltung der Server.
• OABGen
  Exchange generiert immer noch "Offline Adressbücher", die von Clients herunter geladen werden können. Oft wird vergessen diesen Prozess auf die neuen Server umzustellen. Bei der Migration auf eine neue Version wird hingegen oft ein neues OAB erstellt und das alte kann stattdessen gelöscht werden.
• Autodiscover SCP -URL
  Jeder Exchange Server veröffentlicht seine Client Access URLs im lokalen Active Directory. Hierzu zählt insbesondere die "Autodiscover-URL" die ich in der Regel ändere. Ich lasse den alten Server auf den gleichen Namen verweisen, den die neuen Server nutzen. Das ist meist sogar autodiscover.<maildomain> und so werden die Clients gar nicht mehr zum alten Server geleitet.
• Datenbanken
  Das Exchange Setup entfernt eigentlich keine Datenbanken. Sie haben zusätzliche Datenbanken damals ja auch angelegt und sollten sie auch genauso wieder entfernen. Die Commandlets prüfen dabei schon, ob die Datenbanken wirklich "ungenutzt" sind. Nebenbei ist dies ein weiterer Check, dass Sie keine Postfächer vergessen haben. Allerdings wird sich die letzte Datenbank eines Servers nicht immer entfernen lassen, da hier noch Systempostfächer liegen, die aber nur für den Server relevant sind. Das wird dann später beim Setup selbständig entfernt.

So sollte ihre Server nun fast "Lastfrei" sein und zumindest keine produktiven Daten mehr halten.

Karenzzeit / Cleanup

Wenn die Migration der letzten Postfächer und Connectoren erst einige Stunden oder Tage her ist, dann sollten Sie den alten Server noch einige Tage weiter laufen lassen. Wir erwarte, dass idealerweise keine Mails mehr über diesen Server geroutet werden und keine Clients darauf zugreifen. Um das aber sicher von früherem produktiven Verkehr zu unterscheiden, sind einige Tage Abstand ratsam.

Für können und sollten die Zeit dazu nutzen, möglichst viele Protokollierungsfunktionen zu aktivieren, um weitere Zugriffe zu erkennen. Die meisten Protokolle sind schon aktiv

• IISLogs
  Hier erscheinen zumindest alles Zugriff per Autodiscover, EWS, ActiveSync, OWA und PowerShell, so dass solche Dienste sich verraten. Selbst ein Outlook über MAPI/TCP nutzt seit Outlook 2007 auch EWS/Autodiscover und wird so sichtbar.
• Messagetracking
  Diese Datenquelle ist verlässlich, um jegliches Mailrouting auf diesem Server zu erkennen. So finden wie z.B. ausgehende Mails über vergessene "Send-Connectoren" aber auch Clients, die immer noch per SMTP an den alten Server einliefern.

Dennoch kann es ratsam sein, z.B. auch IMAP und POP-Logging zu aktivieren, wenn dies vorher noch nicht erfolgt ist. Auch eine Überwachung der Netzwerkkommunikation (Stichwort NetFlow, SFlow, IPFix) ist hilfreich um vergessene Clients und Prozesse zu erkennen.

Wir sollten also in den Tagen nach der Migration und vor der Abschaltung immer mal wieder diese Logs prüfen und solche Prozesse anpassen.

Allerdings können Sie nicht "ewig" warten und irgendwann fällt die Entscheidung den Server zurück zu bauen..

Letzte Kontrolle

Schon in der vorherigen Phase "Karenzzeit / Cleanup" sollten durch Kontrollen noch Systeme aufgefallen sein, die den alten Server nutzten. Irgendwann ist aber auch die Geduld eines Exchange Administrators am Ende und die Abschaltung steht kurz bevor.

• Meldung an alle IT-Beteiligten
  Der Spruch "Melden mach frei" ist zwar eher im militärischen Umfeld bekannt aber auch in der Wirtschaft sollten Sie informieren, welche Veränderungen anstehen. Diesmal ist es aber kein "wir würden gerne" sondern eine klare Ansage, dass der Server ab einem Zeitpunkt nicht mehr zur Verfügung stehen wird. Diese Information ist vor allem für den Helpdesk wichtig, bei denen Probleme zuerst auflaufen.
• Kontrolle der IISLogs
  Welche Dienste und Services greifen noch auf den alten Server zu. Sollte eigentlich niemand mehr nutzen, wenn Sie die CAS-Namen auf die neuen Server umgestellt und die Postfächer verschoben haben. Es könnte maximal ein Client sein, der den FQDN oder die IP des Servers direkt anspricht. In den meisten Fällen wir er aber eh nicht mehr an ein Postfach auf einer „neueren Version“ kommen.
• Kontrolle IMP4/POP3 Logs
  Sollte eigentlich niemand mehr nutzen, wenn Sie die CAS-Namen auf die neuen Server umgestellt und die Postfächer verschoben haben/li>
• Kontrolle MessageTracking für SMTP Versand
  Die alten Server sollten nichts mehr senden, wenn Sie diese „korrekt“ aus den Send Connectoren im Rahmen der Migration als „Local Bridgehead“ entfernt haben.
• Kontrolle MessageTracking für SMTP-Empfang
  Hier wird es meist kniffliger, da auch ein Server, der quasi kurz vor der Deinstallation steht“, weiter Mails annimmt. Wenn also im Feld irgendwelche Skripte, Drucker, Scanner etc. sind, die statt des bereits umgestellten DNS-Alias oder die virtuelle IP des Loadbalancers doch den Server direkt ansprechen, dann muss man die abklappern.

Eine 100% Sicherheit wird man nie erhalten. Ich hatte schon Fälle, wo ein Prozess eben nur einmal vor Weihnachten eine „Massenmail“ versendet hat. (Die Chefsekretärin mit einem Seriendruck-Tool per SMTP) und das ist eben erst später aufgefallen. Schlimmer sind Prozesse, die keine Rückmeldung über einen anderen Weg eskalieren. Wenn Sie also z.B. ein SAN-System haben, welches bei einem Fehler eben „nur“ eine Mail sendet und diese dann nicht mehr senden kann, dass ist das aus meiner Sicht trotzdem eher ein Problem des Monitoring. Aus meiner Sicht sollte ein System, welches Mails versendet immer über einen anderen Weg auch noch eine Meldung über den Fehler beim Mailversand generieren können.

Deinstallation

Vermeiden Sie es bitte den Server einfach hart zu entfernen. Der einzige offizielle Weg ist die Deinstallation mittelst Exchange Setup. Nebenbei prüft das Setup dabei auch die Voraussetzungen für einen erfolgreiche Installation. Allzu oft werden z.B. die "Arbitration"-Postfächer vergessen. Die Reihenfolge ist:

• Anpassen Monitoring
  Nicht dass ihre Überwachung den gleich "fehlenden" Server eskaliert
• Anpassen Backup
  Ihre Sicherung braucht den Server nicht weiter sichern.
• Anpassung Loadbalancer
• Entfernen aus der DAG
• Neustart
  Ich habe mir angewöhnt, vorher den Server einmal durchzustarten. Oft reduziert dies die Wahrscheinlichkeit, dass die Deinstallation aufgrund blockierter Dateien oder Dienste hängen bleibt oder abbricht. Meistens hänge es am Windows Management Interface-Dienst (WMIMGMT). Das können Sie gut im ExchangeServersetup.log sehen

#Anzeige des Setup-Prozess
Get-Content C:\ExchangeSetupLogs\ExchangeSetup.log -tail 100 -wait

[08/09/2021 21:45:46.0445] [2] Will wait '120000' milliseconds for the service 'WinMgmt' to reach status 'Stopped'.
[08/09/2021 21:47:46.0526] [2] Service 'WinMgmt' failed to reach status 'Stopped' on this server after waiting for '120000' milliseconds.


# ggfls stoppen der Blockade des WMIMGMT, wenn das Setup an dem Dienst hängt.
Get-Process wmi* | Stop-Process -Force

• Deinstallation Exchange
  Über die Systemsteuerung lässt sich Exchange sauber deinstallieren. Sollte Exchange sie hindern, dann lesen Sie bitte genau die Fehlermeldung und beseitigen Sie das Hindernis. Wenn die Deinstallation dann abbricht, dann können Sie nach dem Neustart einfach von den Installationsquellen die Deinstallation starten:

Setup.exe /mode:Uninstall

• Server aus der Domäne entfernen und abschalten.
  Zuletzt habe ich mir es angewöhnt, den Server auch sauber aus der Domäne zu entfernen. So gibt es keine alten Computerkonten als Leichen. Vergessen Sie nicht vorher das Kennwort des lokalen Administrators zu setzen.
• Hardware verwerten
  Die Windows Installation selbst habe ich nie für andere Zwecke weiter verwendet, sondern immer zerstört. Das gilt umso mehr, wenn Sie die Hardware ausmustern. Auf den Festplatten liegen immer noch Dateien, die per Undelete oder Schattenkopien sogar eine Wiederherstellung der früheren EDB-Datei und mit Recovery-Tools auch ein Zugriff auf die Inhalten erlauben könnten. Sorgen Sie daher für eine ordnungsgemäße Datenvernichtung, ehe Sie die Datenträger anderweitig verwenden.