Exchange Server Deinstallation

Auf den Seite E2000 deinstallieren, Ex5.5 deinstallieren und Org Deinstallation habe ich in der Vergangenheit schon Seiten zur Deinstallation von Exchange erstellt. Auf Mig 200x->2013 ist das Entfernen eines vorherigen Servers ein teil der Checkliste. Ich möchte auf dieser Seite etwas ausführlicher auf die Deinstallation von Exchange 2007 und höher, also die 64bit Versionen von Exchange eingehen..

Letzter Server entfernen

Diese Seite beschäftigt sich nicht ausführlich mit der Deinstallation des letzten Servers in einem lokalen Forest. Dieser Fall ist aus meiner Sicht aktuell sehr selten und auch nicht sonderlich schwer. Der Fall trifft nur zu, wenn Sie wirklich kein Exchange mehr OnPremise nutzen wollen, weil Sie z.B. auf Mail komplett verzichten oder eine Cloud-Lösung eines anderen Herstellers gewechselt sind.

Die Migration nach Office 365 / Exchange Online erfordert auch heute noch einen lokalen Exchange Server für das Provisioning der Anwender. Siehe auch ADSync mit Exchange Online Only

Wenn Sie immer noch überzeugt sind, dass sie lokal überhaupt kein Exchange mehr benötigen, dann können Sie den Server sauber deinstallieren und die Spuren der Organisation entfernen. Allerdings werden Sie über den Weg die Schema-Erweiterungen nicht rückgängig machen können.

  • Deaktivieren aller Postfächer, Shared Mailboxes, Räume etc
    Bitte verwechseln sie hier nicht "Löschen der Mailbox" mit "Löschen des AD-Kontos"
  • Deaktivieren aller Verteiler
  • Deaktivieren als "Mailenabled Public Folder"
  • Kontrolle mit "GET-RECIPIENT"
    Es sollten keine Empfänger mehr sichtbar sein

Diese Schritte sollten Sie vorab machen, solange Sie noch eine Exchange PowerShell haben. Eine direkte Änderung der Felder bei den Benutzern mit ADMOFITY oder ADSIEDIT ist mühselig und fehleranfällig.

Früheren Server entfernen

Sie viel häufiger ist es der Fall, dass Sie im Rahmen einer Migration schon alle Daten und Inhalte von früheren Servern auf neue Server verlagert haben und nun der alte Server nur noch ordentlich deinstalliert werden soll.

Sie dürfen den bisherigen Server bitte nicht einfach "abschalten" oder die VM löschen. In dem Fall bleiben Einstellungen im Active Directory zurück, die man offiziell nicht mit ADSIEDIT o.ä. löschen darf. In dem Fall müssen Sie sogar den Server mit "/RecoverServer" wieder installieren um ihn dann sauber zu deinstallieren.

Das Exchange Setup ist seit Exchange 2007 das einzige unterstützte Werkzeug, um einen Exchange Server sauber aus einer bestehenden Organisation zu entfernen. Dazu prüft das Setup vorab, ob der zu deinstallierende Server auch wirklich "frei" ist und gefahrlos deinstalliert werden kann. Allerdings beziehen sich diese Checks nur auf die Bestandsdaten des Servers, z.B. ob es noch Postfächer oder aktive Rollen auf dem Server gibt aber nicht, ob der Server wirklich nicht mehr genutzt wird. Daher habe ich mir eine eigene zusätzliche Liste gemacht:

Tätigkeit Status

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.
  • Deinstallation Exchange 2007/2010/2013
    Ü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.
  • 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.

Wenn Sie hier angekommen sind, dann sollte der Server sauber und ohne Probleme aus ihrer Umgebung entfern worden sein.

Weitere Links