Migration zu Exchange SE

Migration 2016- >2019 und dann Inplace

Macht keinen Sinn, denn auch Exchange 2019 bekommt keine Updates mehr.

Migration Exchange 2013 -> SE

Exchange 2013 kann nicht mit Exchange SE parallel genutzt werden. Sie könnten Exchange 2019 CU14 (nicht CU15) installieren, nach dem hier beschriebenen Verfahren migrieren und danach von Exchange 2019 CU14 auf Exchange SE mittels Inplace Updates.

Exchange 2019 -> SE 

Ich würde umgehend ein Inplace-Update auf SE machen. Wenn Sie die Hardware ändern wollen, dann können Sie das danach immer noch über die hier beschriebene Swing-Migration machen.

IST-Aufnahme

Die Installation eines weiteren Exchange Servers in ihre Umgebung sollte nie ohne eine kurze Aufnahme der aktuellen Umgebung erfolgen. Das Setup addiert Einstellungen, die direkt von Clients gesehen und genutzt werden und z.B. zu Zertifikatswarnungen führen. Auch kann es Abhängigkeiten anderer Produkte geben, die dann Probleme verursachen. Hier ein paar Punkte:

• Unter welchen DNS-Namen ist der aktuelle Server erreichbar?
  Schlecht ist, wenn die Clients den Server unter ihrem FQDN erreichen oder gleich die IP-Adresse verwenden. Hier sind die Internal/External-URLs der Server interessant, da der neue Server die am besten mit übernimmt. Wenn noch nicht passiert, dann wäre nun auch mal die Change über generische CNAMEs statt Server-FQDNs nachzudenken, z.B. mail.<firmendomain>, imap.<firmendomain>, smtp.<firmendomain>
  Siehe auch "Namespace Planning in Exchange 2016" https://techcommunity.microsoft.com/blog/exchange/namespace-planning-in-exchange-2016/604072
• Welche Zertifikate nutzt aktuell der Server?
  Sie müssen zu den URLs und Servernamen passen. Die Zielserver sollen die Funktion der alten System übernehmen
• Wie ist er aus dem Internet erreichbar (HTTP, SMTP)?
  Durch die Koexistenz muss der neue Server eine eigene IP-Adresse haben und Firewalls, DNS und Routing muss ggfls. angepasst werden
• Welche 3rd Party-Produkte müssen für Exchange SE angepasst werden?
  Denken Sie an Fax-Server, Disclaimer-Software, ERP-Zugriffe per EWS/IMAP4, Telefonanlage, lokale GIT-Server
• Clients
  Outlook und ActiveSync sind problemlos. Aber SMTP-Sender oder IMAP/POP-Clients machen selten Autodiscover und nutzen oft IP-Adressen oder den FQDN, was eine Umstellung erschwert. Sie müssen ihre SMTP-Clients klassifizieren in:
  a) Authentifiziert: Können nach intern und Extern nur mit ihrer eigenen Adresse senden
  b) Anonym an interne Empfänger: Funktioniert von Hause aus ohne Konfiguration
  c) Anonym an wenige Empfänger: Vielleicht könnten Kontakte als Weiterleitung eine Lösung sein
  d) Anonym (Source-IP) ins Internet: Klassisches Open Relay. Hierzu hätte ich gerne eine Liste der Sender und den Grund
  Sie glauben gar nicht, wie viele Firmen ganze Subnetze als Openrelay zulassen und dann bei Missbrauch erschrocken sind.
  Beachten Sie dazu auch die Seite "SMTP-Clients ermitteln - Wie finde ich vor der Migration heraus, wer meinen Exchange Server per SMTP anspricht"
• NDRs/FAIL
  Ich nutze gerne die Anzahl der "FAIL" im Messagetracking als Qualitätsmerkmal. Ein hoher Wert verrät mir, dass Sie einige Fehler in der Konfiguration haben, die man genauer untersuchen sollte, z.B. automatisierte interne Mails an ungültige Empfänger o.ä. In einer guten Umgebung gibt es fat keine NDRs, weil der Spamfilter ungültige Empfänger schon draußen ablehnt und die eigenen Benutzer das Exchange Adressbuch nutzen sollten. Den Wert können Sie z.B. aus den Performance Countern lesen oder wie folgt ermitteln mit Details

(Get-MessageTrackingLog -EventId fail -Start (get-date).adddays(-1)).count

• Volumen
  Wissen sie, wie viel Speicherplatz ihr Exchange Server gerade verwendet und was ihr geplantes Wachstum beträgt? Sie müssen kein High End Sizing machen aber ein paar Eckdaten zu CPU, RAM und vor allem Disks sollten Sie schon für den nächsten Schritt zusammenstellen.
• Authentication
  Viele alten Exchange Server sind immer noch direkt per NAT ohne Preauthentication aus dem Internet erreichbar. Das sind quasi die 30.000 unsichere Exchange Server, die das BSI gefunden hat. Vielleicht ist jetzt die Zeit sich für einen Reverse Proxy mit Preauthentication und Kerberos - Constraint Delegation oder eine Veröffentlichung über Azure AD Application Proxy zu entscheiden.

Das sind ein paar Beispiele, die in letzter Zeit bei Migrationen ausgebremst und damit den Aufwand erhöht haben.

Plattform bereitstellen

Ich erspare mir ein eigenes Kapitel für Sizing, da Exchange SE und 2019/2016 die gleichen Anforderungen haben. Neue Server oder VMs sind meist eh schneller, haben mehr RAM und oft SSDs, wovon alte Server nur träumen konnten. Bedenken Sie aber, dass ihr neue Server vielleicht wieder ein paar Jahre aktiv sein wird und zumindest erweiterbar sein muss.

• Active Directory Mode
  Auch wenn Exchange SE quasi wie Exchange 2019/2016 tickt, sollten Sie sicherstellen, dass ihr AD in Topform ist, d.h. mindestens zwei DCs, auf denen natürlich kein Exchange installiert wird,  eine funktionierende Namensauflösung, korrekte Zeitsynchronisation (vor allem auf VMs)
• Windows Server OS
  Ob sie den zukünftigen Server aus einer Vorlage oder neu erstellen, überlasse ich ihnen. Er muss natürlich "Domainmitglied" sein. Vorsicht bei "Clones von Templates". Ich hatte schon Probleme, da die DeviceID der VMs nicht eindeutig war und strenger Prüfungen nach MS Security Updates die Domainmitgliedschaft gebrochen haben. Im Zweifel lieber neu installieren. Wer einen Loadbalancer als "Dual-Arm"-Konfiguration betreiben will, sollte Exchange in ein eigenes Subnetz/VLAN installieren, was mit Access-Listen auf dem Router die Sicherheit zusätzlich erhöhen kann. Bitte lassen Sie auch die Windows Firewall aktiv. Zusätzliche Festplatten für Datenbanken sollten mit 64k-Blöcken und sehr große Disks mit ReFS formatiert werden. Wer viele Festplatten nutzt, für den sind Mountpoints anstatt "Buchstaben" eine flexiblere Option.
• Integration
  Ein Server steht nie allein. Er muss über ein Backup zuverlässig gesichert werden und eine Integration eine Serverüberwachung ist wichtig. Vielleicht konsolidieren Sie Protokolle (Eventlog, Transport, IIS) in einem zentralen Logging-System. Das kann alles schon vor der eigentliche Installation von Exchange erfolgen. Vergessen Sie auch nicht den Virenscanner, gerne mit AMSI-Schnittstelle und entsprechenden Ausschlüssen für die Datenbanken und einige andere Exchange-Dateien, bei denen eine übereifrige Endpoint Protection Lösung mehr Schaden als Nutzen anrichtet.
• Firewall
  In dem Zuge sollten Sie auch die Kommunikation der Exchange ins Internet zu den erlaubten Zielen sicherstellen z.B. für das spätere Hybrid-SMTP-Routing zu Exchange oder Internet. Eingehende Verbindungen können sie schon konfigurieren aber noch nicht aktivieren, d.h. Loadbalancer und DNS bleiben noch unangetastet, denn noch sind die neuen Server nicht installiert und konfiguriert.

Installation Exchange

• Prerequsites
  Die fordert das Exchange Setup ja schon alleine an. Im Wesentlichen sind es VC2013Runtime, UCMA und IIS-URLRewrite. Früher haben wir per Skripte diese Komponenten als auch die erforderlichen Windows Rollen installiert. Mittlerweile überlasse ich das dem Exchange Setup.
• Exchange Installation + Anpassen Autodiscover/CAS-URL
  Das Setup addiert im Active Directory entsprechende Einträge, die Clients stören könnten. Diese sollten umgehend auf passende Werte gesetzt werden, z.B. den Namen des alten Servers.
  Auf Copy-CASUrls finden Sie ein PowerShell-Script, mit dem Sie die URLs schnell von einem bestehenden Server übertragen können. Ich starte das Skripte während des Setups.
  Setup 7 von 13: Das Autodiscover-ECP wurde angelegt und kann aktualisiert werden
  Setup 9 von 13: Postfachrolle: Die IIS Verzeichnisse kommen nach einander in die Konfiguration
  Die URLs sind nur für die Autodiscover-Ermittlung relevant. Intern nutzen die Exchange Server immer den FQDN des Zielservers.
• Zertifikate einspielen
  Wenn der neue Server später unter dem gleichen DNS-Namen wie der bisherige Server erreichbar sein soll, dann sollten Sie die erforderlichen Zertifikate des bisherigen Servers mit installieren. Bitte nutzen Sie nicht die MMC (Exchange Zertifikat Insights) sondern die Exchange PowerShell.

Import-ExchangeCertificate `
   -FileData ([System.IO.File]::ReadAllBytes('c:\install\exchange.pfx')) `
   -Password (Read-Host "Enter password" -AsSecureString) `
   -PrivateKeyExportable $true

• Exchange Updates
  Sowohl für Windows als auch Exchange und nachinstallierte Komponenten sind Updates zu installieren. (Exchange Server SE Updates)
• Lizenz einspielen
  Wenn der Server nicht nur ein Hybrid Connector Server ist, sondern SMTP-Dienste oder Postfächer betreibt, dann ist jetzt der Zeitpunkt zum Einspielen der Lizenz. Details zur Lizenzierung finden Sie auf Exchange SE Licensing
• Exchange HealthCheck
  Prüfen Sie mit dem CSS-Exchange Healthcheck das installierte System. Meist sind noch Anpassungen bei Pagefile, Energieeinstellungen, TCP-Settings, TLS-Einstellungen, etc. erforderlich.

Danach läuft der neue Server erst einmal fast unbemerkt neben dem Bestandssystem. Allerdings werden die anderen Exchange Server ihn z.B.: in die Transport-HA-Funktion integrieren. Die neuen Server sind also nicht untätig". Ein Blicks ins Messagetracking zeigt das aber es sollte kein Client geben, der die neuen Server anspricht und auch keine SMTP-Verbindungen zu sonstsigen Systemen.

• Exchange 2016 Installationscheckliste

Exchange Mailbox-Rolle vorbereiten

In diesem Schritt wird die Postfach-Rolle für die spätere Migration von Postfächern konfiguriert

• Konfiguration DAG und Cluster
  Wenn die neue Umgebung für länger geplant ist dann wäre eine DAG vielleicht eine gute Idee. Das sind dann mindestens zwei Server und ein Quorum auf einem dritten Server erforderlich, auf dem "Exchange Trusted Subsystem" in die Administratoren-Gruppe addiert sein muss.
  Tipp: Solange sie noch keinen Cluster haben, können Sie die automatisch mit eingerichteten Datenbank noch einfach umbenennen und verschieben.
• Weitere Datenbanken anlegen und konfigurieren
  Legen Sie erforderliche weitere Datenbanken an und konfigurieren Sie diese, z.B. hinsichtlich Quotas, ExcludeFromProvisioning etc.
• Backup integrieren
  Hochverfügbarkeit im Cluster ist kein Ersatz für ein Backup. Jetzt ist es an der Zeit das Backup zu prüfen. Es wird bei der späteren Migration der Postfächer gebraucht, um die Transaktionsprotokolle im Zaum zu halten.

Exchange Transport umstellen

Eine Umstellung des Mailroutings läuft meist von Anwendern kaum bemerkt ab, aber bringt erste Last auf den Server und entlastet den alten Server. Vor allem können wir bis zur Abschaltung einfacher sehen, wer noch die alten Server verwendet.

• Globale Einstellungen
  z.B. Messagtrackinggröße, Nachrichtengröße etc. Es ist gut, wenn damals bei der Installation von Exchange 2016 die Änderungen protokolliert wurden.
• Receive Connectoren
  Auf dem bisherigen Server hinterlegte Connectoren, z.B. für Relay-Versand müssen auch auf dem neuen Server nachgehalten werden. Dabei sollten Sie prüfen, ob diese "unsicheren" Funktionen überhaupt noch erforderlich sind. Vielleicht hilft ihnen Copy-ReceiveConnector beim Übertragen der Konfiguration.
  Bei einem Hybrid-Setup sollten Sie beim Receive Connector für eingehende Mails aus dem Tenant die TLSSettings prüfen.
• Send-Connectoren
  Nach Installation der Zertifikat können wir den neuen Server einfach in die SendConnectoren als "Local Bridgehead" aufnehmen. Den Hybrid-Connector zu einem Tenant sollten Sie mittel HCW umstellen, wenn Sie nicht wissen, wie Sie per PowerShell das Zertifikat zum Versand setzen
• Firewall/Relay-Anpassungen
  Denken Sie bei allen Änderungen, dass auch eine Firewall oder SMTP-Relays und externe Spamfilter mit angepasst werden müssen.

Das Ziel dieser Phase ist eine Plattform für die Einlieferung durch SMTP-Clients und Routing für alle anderen Gegenstellen bereitzustellen, die nicht Exchange Online betreffen. Das Hybrid Setup kommt im nächsten Schritt.

Hybrid Setup

Wenn Sie bereits ein Hybrid Setup mit Exchange 2016 haben, dann muss dieses auf Exchange SE umgestellt werden. Das sind einmal die Einstellungen auf dem Transport, die MRS-Endpunkte und EWS-Zugriffe. Der einfachste Weg ist die Konfiguration per HCW mit dem neuen Server und nachfolgend dann die Umstellung der Erreichbarkeit über das Netzwerk. Details finden Sie auf  Hybrid Mail Routing.

• Hybrid Routing Ausgehend
  Die neuen Server müssen sich ebenfalls bei Exchange Online mit einem Zertifikat (oder der IP-Adresse) authentifizieren. Dazu muss HCW im Connector zum Tenant auch die neuen Server aufnehmen und das zu verwendende Zertifikat konfigurieren. Prüfen Sie vorher, ob die neuen Exchange Server auch Exchange Online per DNS auflösen und per 25/TCP erreichen können.
• Hybrid Routing Eingehend
  Eingehend benötigen Sie den HCW zuallererst, dass er auf dem Default Receive Connector die TLSSettings für das Zertifikat und bei "TlsDomainCapabilities:{mail.protection.outlook.com:AcceptCloudServicesMail}" steht. Das Exchange Online dann wirklich die neuen Server anspricht, müssen Sie meist in der Firewall (Reverse NAT) noch anpassen.
• MRSProxy bei Bedarf aktivieren
  Der MRSProxy ist normalerweise deaktiviert, aber wird vom HCW für Migrationen in die Cloud aktiviert. Wenn der alte Server eine Gegenstelle für Migrationen war und Sie mit der Migration noch nicht fertig sind, dann sollten Sie auf dem neuen Server die Funktion auch per ECP, PowerShell oder HCW wieder aktivieren, ehe Sie in der Firewall dann die Zugriffe von Exchange Online auf die neuen Server umstellen. Das Skript Copy-CASUrls kopiert die Einstellung des Quellservers.
• Dedicated Hybrid App
  Die "Dedicated Hybrid App" haben Sie hoffentlich schon vor dem Okt 2025 konfiguriert. Ansonsten wird es nun höchste Zeit dies mit dem HCW und PowerShell nachzuholen. (Siehe Dedicated Hybrid Application). Der Wechsel der Erreichbarkeit von Exchange Online können Sie hier jetzt oder im nächsten Schritt mit der Umstellung des Client Zugriffs durchführen.
• Gggfls. Modern Hybrid Agent installieren
  Falls Sie "Modern Hybrid" nutzen und der Agent auf dem alten Server installiert war, dann ist es nun an der Zeit den neuen Server wieder mit einem Agenten auszustatten. Der HCW übernimmt dies für Sie.

Exchange Client Zugriff umstellen

Die Clients können über Exchange 2016 auch auf ein Exchange SE Postfach zu greifen und umgekehrt. Insofern ist die Umstellung des Client-Zugriffs auf die neuen Server meist problemlos. Wir müssen aber den IIS der neuen Server natürlich entsprechend vorbereiten

• Einspielen und Binden der IIS-Zertifikate
• MAPI/HTTP konfigurieren, wenn es noch nicht passiert sein sollte
  
• ggfls. Konfiguration der IIS-Seiten (Authentifizierung, Kerberos)
• Verifizieren der Clients
  Wenn ihr Setup es zulässt, können Sie auf einigen Clients über einen HOST-Eintrag die neuen Server nutzen und so die Funktion testen
• Zugriffe umstellen (DNS oder HLB)
  Irgendwann kommt dann aber der Moment, dass Sie alle Clients nur noch über den neuen Server routen. Wer einen Loadbalancer nutzt, kann einfach die neuen Server mit als RealServer addieren und die Zugriffe gezielt umstellen. Wer DNS nutzt, sollte rechtzeitig vorher den TTL auf vielleicht 60 Sekunden reduzieren, damit bei Problemen schnell eine Korrektur aktiv wird. Nur im Notfall würde ich dem alten Exchange Server eine neue IP-Adresse geben, um seine alte Adresse zum neune Server zu übertragen. Das entspannt zwar die Probleme mit Scanner, die IP statt DNS nutzen, aber manifestiert weiter solche Fehlkonfigurationen
• Exchange PowerShell
  Vielleicht haben Sie ein Identity Management oder andere Skripte, die ihre Benutzer anlegen und verwalten oder Reports erstellen. Sollte dort ein Exchange Server als FQDN hinterlegt sein, dann müssen Sie diese Skripte ebenfalls umstellen

Idealerweise greift nach der Umstellung kein Client mehr auf den bisherigen Server direkt zu. Clients nutzen den neuen Server als Frontend, der seinerseits dann auf die Postfächer auf dem alten Server zugreift, bis diese migriert sind

Umstellen von SMTP-Clients

Ich wünsche ihnen ja, dass alle Clients über einen virtuellen DNS-Namen (z.B. mail.<firmendomain>) auf den alten Exchange Server zugegriffen haben und allein eine Änderung im DNS oder Loadbalancer schon die Umstellung auf den neuen Server bewirkt hat. Wenn Sie aber Clients haben, die den FQDN des alten Server oder gar dessen IP-Adresse genutzt haben, dann finden Sie diese Clients im Messagetrackinglog des alten Servers und dürfen die Produkte und Geräte nun umstellen.

• SMTP-Clients ermitteln

Umstellen von Connectoren/Gateways

Das gleiche gilt für Systeme, die von Exchange per Connector erreicht werden, z.B. andere Hosts, ERP/CRM-Systeme, Faxserver, Archivprodukte, die beim Umstellen der Hub/Transport-Rolle übersehen wurden. Auch hier hilft ein Blick ins Messagetracking nach Mails, die nicht von anderen Exchange Servern kommen.

Verschieben der Postfächer von 2016->SE

Schön langsam mit Backup der Logfiles, Denken Sie auch an die Systempostfächer, DiscoveryMailbox, Arbitration Postfächer, Public Folder etc. Sie gehen einfach auf den Zielserver und starten die Migration per ECP oder PowerShell an.

New-MoveRequest `
   -Identity 'userq@msxfaq.de' `
   -TargetDatabase "DB1"

Natürlich können Sie auch einfach einen Target-Server angeben. Mit "Get-Mailbox" und filtern können Sie auch mehrere Postfächer übergeben, z.B.

Get-Mailbox -Database DB1 `
 | New-MoveRequest -TargetDatabase "DB2"

Den aktuellen Status können Sie z.B. wie folgt in einer Exchange PowerShell immer wieder ausgeben lassen:

while ($true) {
   Get-MoveRequest -MoveStatus InProgress `
   | Get-MoveRequestStatistics `
   | Sort Percent* `
   | Format-Table DisplayName, StatusDetail, TotalMailboxSize, SourceServer, SourceDatabase, TargetServer, TargetDatabase, PercentComplete
   Start-Sleep -Seconds 60
}

Achten Sie immer auf den freien Festplattenplatz auf dem Zielsystem. Transaktionsprotokolle können sehr schnell ein Volume füllen, was dann zum Dismount der Datenbank führt.

• MoveRequest und MigrationBatch

Statusmeetings

Wenn Sie als Kunde diesen Teil der Migration selbst durchführen, können regelmäßige Statusmeetings durch den Dienstleister den Vorgang beschleunigen.

Lastfreiheit feststellen

Ehe wir den alten Exchange Server deinstallieren, kontrollieren wir, dass er nicht mehr verwendet wird:

• Client Zugriffe verlagert
  Haben Sie den Server schon im Loadbalancer deaktiviert/entfernt oder zusätzliche A-Records im DNS entfernt, so dass kein Client mehr über DNS oder Loadbalancing den Server anspricht? Sie werden nie alle Clients erwischen. Dies gilt insbesondere die Systeme, welche nur sporadisch ihren Server kontaktieren. Hier gilt es dann abzuwägen, wie lange sie ihren alten Server noch "irgendwie" laufen lassen. Sie könnten natürlich auch nach der Abschaltung des alten Servers einfach dessen IP-Adresse dem neuen Server zusätzlich geben.

Dann müssen sie mir aber versprechen, dass sie solche Altlasten überwachen und zeitnah die IP-Adresse wieder entfernen.

• IISLogs
  Ob der Server noch von Clients genutzt wird, sehen wir am einfachsten im IIS/POP/IMAP-Log. Einige Firmen können dies auch im Netzwerkmanagement (SFlow, IPFix, NetFlow) nachprüfen. Wir erwarten keine Zugriffe mehr. Ansonsten haben Sie in der vorherigen Phase nicht sorgfältig gearbeitet.
• SMTP-Logs/Messagetracking
  Hier sollten keine unerklärlichen "SMTP RECEIVE", "SMTP SEND" und insbesondere keine "SMTP SENDEXTERNAL" erscheinen. Eine paar "SMTP HAREDIRECT", SMTP HARECEIVE" oder "SMTP HADISCARD" sind aber normal. Siehe Message Tracking Exchange 2016 und Exchange Transport Cache". Wir werden sicher einige HAREDIRECT-Messages von anderen Exchange Servern sehen aber es sollten keine eingehende Verbindungen von anderen IP-Adressen mehr erscheinen. SMTP-Clients ermitteln

Get-Messagetracking -start (get-date).adddays(-1) | Group-Object OriginalClientIP

• Sind die Datenbanken wirklich frei"
  Ein "Get-Mailbox -Server <servername>" liefert zumindest die Postföcher aber rufen Sie den Befehl auch noch mal mit "-archive" und "-arbitration" auf. Bis auf einige Monitoring-Mailboxen sollte kein Postfach mehr aufgeführt werden. Sie können vorab schon Datenbanken löschen. Dabei prüft Exchange auch noch einmal, dass wirklich kein Postfach mehr in der jeweiligen Datenbank liegt.

Get-Mailbox -Server <servername>
Get-Mailbox -Server <servername> -arbitration
Get-Mailbox -Server <servername> -Archiv
Get-Mailbox -Server <servername> -Migration
Get-Mailbox -Server <servername> -Monitoring
Get-Mailbox -Server <servername> -PublicFolder

Je gewissenhafter sie diese Prüfungen durchführen, desto weniger Fehler werden Sie nach der Abschaltung haben.

Exchange "Ruhezeit"

Die "vorsichtigen Administratoren" könnten nu erst einmal den alten Exchange Server in den Wartungsmode versetzen und für einige Tage "Offline" nehmen. Ich mache das in der Regel nicht, sondern wenn der Server seit Beginn der Migration nur noch Zugriffe über die neuen Server protokolliert hat, dann finden Sie die seltenen Verbindungen auch nicht. Klassische ist der "Massenmailversand von Weihnachtsgrußkarten" mit einer 3rd Party Software. Das fällt dann wirklich erst dann auf. Jede Komponente, die Mails senden, sollte auch mit einem Fehler umgehen und diese über eine Monitoring sichtbar machen.

Exchange Deinstallation

Irgendwann ist aber der Moment gekommen, dass Sie auf dem alten Server das Exchange Setup starten und Exchange deinstallieren. Falls das Setup sich über noch auf dem Server verbliebene Reste beschwert, sollten die Hinweise ihnen bei der Beseitigung helfen. Auf jeden Fall werden am Schluss alle Dienste von Exchange deinstalliert sein. Auf Port 25, 586, 110, 143, 993, 995 etc. lauscht gar nichts mehr und Clients bekommen einen TCP-Reset. Allerdings ist z.B. der IIS immer noch drauf aber ohne die virtuellen Exchange Verzeichnisse. Sie könnten nun alle Exchange Prerequsites nacheinander deinstallieren aber wenn der Server sonst keine weiteren Funktionen hat, würde den Server keine Minute länger mehr laufen lassen. Also wird er heruntergefahren, gegen wiedereinschalten gesichert und das Computerkonto im AD deaktiviert. Mit dem Herunterfahren hat er sich auch im DNS deregistriert.

Nun kommt die Zeit der Fehler, d.h. Clients, die sie bei der Inventarisierung am Anfang und der Auswertung nach der Migration übersehen oder sich in der ganzen Zeit nicht gemeldet haben. Hoffentlich fällt jemand auf, wenn so ein Prozess keine Mail mehr senden kann und sie dessen Konfiguration anpassen müssen. Das sollte aber nur passieren, wenn ein System den FQDN des Server oder sogar dessen IP-Adresse verwendet hat, denn die generischen DNS-Namen haben wir ja auf die neuen Server umgestellt.

Wer hier aber mehr Sicherheit haben will, kann gerne die IP-Adressen und DNS-Namen der alten Server weiter überwachen, da gibt es eine Menge Optionen, z.B.:

• "Honeypot"
  Es gibt fertige Distributionen, die auf eingehende Verbindungen warten um diese zu melden. Bessere Systeme simulieren sogar die entsprechenden Dienste und beobachten, was Angreifer tun. Für SMTP und IMAP wäre es schon interessant, so etwas mehr über den Prozess zu erfahren
• Windows Firewall
  Sie können aber auch einfach einen Server nutzen, auf dem die Firewall die Verbindungen blockiert und in ein Protokoll schreibt. Dieses Protokoll können Sie dann weiter auswerten.
• PowerShell
  Wenn sie mögen, können Sie natürlich auch einfach z.B. per PowerShell einen Port-Listener schreiben, der ebenfalls solche Verbindungen bemerkt, mit einer hilfreichen Meldung quittiert und alarmiert.
• Netzwerk-Firewall/Loadbalancer
  Wenn im gleichen Netzwerk wir ihre alten Exchange Server auch eine Firewall steht, dann können Sie die alte IP-Adresse auch dort addieren und deren Nutzung protokollieren und alarmieren bzw. sogar per NAT auf einen verbliebenen Server weitergeben. Für Letzteres eignet sich auch ein Loadbalancer im gleichen Subnetz.
• DNS-Logging
  Um Anfragen auf früheren Namen zu ermitteln, können Sie die Protokolle ihres DNS-Servers aktivieren und auswerten oder mittels CNAME auf einen anderen Server auch weiterhin Zugriffe ermöglichen.

Letztlich ist es eine Risikoabschätzung und wenn Sie ihre Systeme vorher gut erfasst haben und kennen, dann benötigen Sie das nicht. 

Besenwagen

Ihre alten Exchange Server sind deinstalliert und im DNS nicht mehr