Im letzten Teil der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” wird die Deinstallation von Exchange 2016 vorbereitet und die Migration abgeschlossen.
Der kleine Abschnitt Troubleshooting widmet sich der häufigsten Ursache für fehlgeschlagene oder angehaltene MoveRequests. Bei Migrationen kann es immer wieder zu Problemen kommen, welche man vorher nicht ausschließen konnte. Die Ursachen können vielfältig sein, daher kann ich hier nicht auf alle Eventualitäten eingehen.
Troubleshooting
Bevor Exchange 2016 deinstalliert werden kann, müssen alle Postfächer aus der Exchange 2016 Datenbank in die Exchange 2019 Datenbank verschoben werden. In Teil 3 dieser Artikelserie wurden dazu MoveRequests verwendet.
Es kommt aber durchaus häufig vor, dass manche MoveRequests den Status “Suspended” oder “Failed” aufweisen und dadurch das Postfach nicht verschoben wird.
Der Status der MoveRequests lässt sich mit dem folgenden Befehl prüfen:
Get-MoveRequest
In den meisten Fällen werden die MoveRequests nicht abgeschlossen, da es defekte Elemente innerhalb der Postfächer gibt. Hier hilft es meist schon das entsprechende Limit der tolerierbaren Fehler anzuheben. Mit dem folgenden Befehl, können für vorhandene MoveRequests 50 fehlerhafte Elemente zugelassen werden:
Get-MoveRequest | Set-MoveRequest -BadItemLimit 50
Die MoveRequests lassen sich dann fortführen:
Get-MoveRequest | Resume-MoveRequest
Wie bereits erwähnt kann es auch andere Ursachen für fehlerhafte Verschiebungsanforderungen geben. Mit dem folgenden Befehl erhält man weitere Informationen für das Troubleshooting:
Get-MoveRequest | Get-MoveRequestStatistics | fl
Hier gibt es auch einen weiteren Artikel der fehlgeschlagenen MoveRequests helfen kann:
Wie schon eingangs erwähnt, gibt es viele Ursachen für fehlgeschlagene MoveRequests. Weitere Ursachen und Lösungen können gerne als Kommentar hinterlassen werden. Falls genügend Tipps zusammenkommen, kann ich diese gerne als separaten Artikel aufnehmen.
Wenn alle MoveRequests erfolgreich abgeschlossen wurden und den Status “Completed” aufweisen, können die MoveRequests gelöscht werden:
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
Damit bei der Deinstallation möglichst keine Probleme auftreten, sollte noch etwas aufgeräumt werden.
Aufräumen und Deinstallation vorbereiten
Damit die Deinstallation von Exchange 2016 möglichst ohne Probleme verläuft, sollten vor der Deinstallation noch ein paar Aufräumarbeiten erledigt werden.
Bei meinen Aufräumarbeiten ist mir zum Beispiel noch aufgefallen, dass ich vergessen hatte die AuditLog Mailbox zu verschieben. Dies hatte ich in Teil 3 nicht durchgeführt, daher reiche ich es jetzt nach. Hier die schon bekannten Befehle zum Anzeigen und Verschieben:
get-mailbox -Database DB2016 -AuditLog
get-mailbox -Database DB2016 -AuditLog | New-MoveRequest -TargetDatabase DB2019
Get-MoveRequest
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
Nachdem auch das AuditLog Postfach verschoben wurde, sollten nun keine Postfächer mehr in der alten Exchange 2016 Datenbank gespeichert sein. Mit den folgenden Befehlen lassen sich die gängigen Postfachtypen abfragen:
get-mailbox -Database DB2016 get-mailbox -Database DB2016 -Arbitration get-mailbox -Database DB2016 -Archive get-mailbox -Database DB2016 -PublicFolder get-mailbox -Database DB2016 -AuditLog
Ebenfalls sollte es nun keine MoveRequests mehr geben. Sollte es an dieser Stelle noch MoveRequests geben, müssen diese zunächst abgeschlossen und gelöscht werden (Siehe Abschnitt Troubleshooting). Mit dem folgenden Befehl lässt sich prüfen, ob es noch Moverequests existieren:
Get-MoveRequest
Wenn keine Postfächer mehr in der Exchange 2016 Datenbank vorhanden sind und auch keine MoveRequests mehr angezeigt werden, kann der Exchange 2016 Server aus der Bereichsdefinition des Sendeconnectors entfernt werden:
Bei der Deinstallation sollte es nun zu keinen Problemen kommen.
Deinstallation
Die Deinstallation von Exchange 2016 kann über die Systemsteuerung via “Programme und Features” gestartet werden:
Hinweis: Bevor Exchange 2016 deinstalliert wird, sollte möglicherweise vorhandene AntiViren/AntiSPAM Software für Exchange deinstalliert werden. Oft verhindern diese Programme eine erfolgreiche Deinstallation von Exchange.
Die Deinstallationsroutine überprüft nach dem Klick auf “Weiter” noch einmal ob die Deinstallation durchgeführt werden kann:
In diesem Fall ist alles in Ordnung und die Deinstallation kann gestartet werden:
Die Deinstallation dauert ein paar Minuten:
Exchange 2016 wurde erfolgreich deinstalliert und es wird ein letzter Neustart angefordert:
Somit ist die Migration zu Exchange 2019 abgeschlossen. Optional gibt es noch zwei weitere Steps die nun ausgeführt werden können.
Optional: Server aus Domain entfernen
Sofern der Exchange 2016 Server keine weiteren Dienste mehr ausführt, kann nun der Server aus dem AD entfernt und runtergefahren werden. Die Windows Installation sollte nicht für andere Dienste weiter verwendet werden. Auch das Computerkonto des alten Exchange 2016 Server sollte gelöscht werden (wenn noch vorhanden).
Hinweis: Die Deinstallationsroutine entfernt nicht die alten Datenbank Dateien und Logs, falls das Betriebssystem des alten Exchange Servers also noch etwas in Betrieb bleibt (möglicherweise aufgrund anderer Dienste), dann sollten Datenbank und Logs manuell gelöscht werden:
Wenn die Serverhardware weiter verwendet werden soll, dann bietet sich hier eine saubere Neuinstallation des Betriebssystems an.
Optional: Client Access Rules (Exchange Admin Center einschränken)
Die “Client Access Rules” sind ein neues Exchange 2019 Feature, welches unter anderem dazu benutzt werden kann, den Zugriff auf das Exchange Admin Center (EAC) einzuschränken.
In der hier beschriebenen Testumgebung gibt es einen NAT Eintrag welcher Port 443 auf den Exchange 2019 Server weiterleitet:
Dieser NAT Eintrag veröffentlicht Exchange 2019 im Internet, somit sind Protokolle wie ActiveSync und MAPIoverHTTP aus dem Internet nutzbar. Gleichzeitig wird damit aber auch das Exchange Admin Center (EAC) aus dem Internet erreichbar gemacht. Administrative Oberflächen, wie EAC, die direkt im Internet erreichbar sind, stellen immer ein potenzielles Sicherheitsrisiko dar. Gerade wenn, wie hier in dieser Testumgebung, keine Web Application Firewall oder andere Schutzmaßnahmen zum Einsatz kommen.
Damit administrative Oberflächen wie das EAC nicht direkt aus dem Internet aufgerufen werden können, lässt sich der Zugriff eingrenzen, beispielsweise auf das interne Netzwerk oder ein dediziertes Management Netz.
Mit den folgenden Befehlen lässt sich beispielsweise der Zugriff auf die RemotePowerShell und EAC auf das interne Netzwerk 192.168.200.0/24 einschränken:
New-ClientAccessRule -Name "Block Remote PowerShell" -Action DenyAccess -AnyOfProtocols RemotePowerShell -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24 New-ClientAccessRule -Name "Block Remote ExchangeAdminCenter" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24
Der Zugriff von Rechnern außerhalb des Subnetzes 192.168.200.0/24 auf EAC und PowerShell ist somit nicht mehr möglich. Hier muss natürlich etwas aufgepasst werden, damit man sich nicht selbst aussperrt.
Ein ausführlicher Beitrag zu den Client Access Rules folgt noch.