Ich befinde mich gerade in der Migration auf einen Exchange Server 2016. Nach der Erweiterung der Active Directory und der Installation des neuen Servers erfolgte die Grundeinrichtung, hier kann ich die Blog-Reihe von Frank Zöchling absolut empfehlen:
Frankys Web: Migration von Exchange 2010 zu Exchange 2016 (Teil 1)
Frankys Web: Migration von Exchange 2010 zu Exchange 2016 (Teil 2)
Frankys Web: Migration von Exchange 2010 zu Exchange 2016 (Teil 3)
Die Testszenarien
An einem gewissen Punkt war es dann soweit, dass wir die ersten Testkonten verschieben konnten. Zu diesem Zweck stehen ca. 20 Konten bereit, die für genau solche Tests, Demos, Schulungen usw. genutzt werden. Da diese Konten bereits seit einiger Zeit bestehen, sind bereits Emails, Kalendereinträge usw. vorhanden. Um den Test möglichst umfassend und realistisch zu halten, haben wir die unterschiedlichsten Szenarien getestet:
- User benutzt Outlook intern im Domänennetzwerk
- Mit Cache-Modus
- Ohne Cache-Modus
- Die Nutzung von Outlook Web Access (OWA)
- Die Arbeit von extern per Outlook Anywhere
- Die Nutzung von mobilen Endgeräten
- Test mit einem iPhone
- Test mit einem Android-Gerät
- …
Das Problem
Bei einem Demo-Account, der ausschließlich per Outlook Anywhere verbunden ist, kam es zu folgendem Verhalten:
Situation vor der Migration
Outlook ist per Outlook Anywhere verbunden, dies lässt sich sehr gut erkennen im Verbindungsstatus von Outlook.
Diesen Status kann man einsehen, wenn man mit gedrückter „STRG“-Taste einen Rechtsklick auf das Outlook-Symbol in der Taskleiste macht.
Die Migration
Nun wurde auf dem Exchange Server das Postfach von diesem Demo-Benutzer migriert. Die Migration dauerte einige Minuten, danach erschien auf dem Client (wie gewohnt) eine Meldung, dass der Administrator eine Änderung vorgenommen hat und das man das Outlook bitte neu starten soll. Dies wurde gemacht, danach blieb das Outlook offline und zeigte unten im Exchange-Verbindungsstatus „getrennt“ an.
Ich habe mir an dieser Stelle erneut den Outlook-Verbindungsstatus angeschaut, hier war nur noch eine einzige Verbindung offen, und zwar zum alten Exchange-Server.
Da ich im Vorfeld schon dafür gesorgt habe, dass der autodiscover-Eintrag auf den korrekten Server (also den neuen Exchange 2016) zeigt, schien hier ein anderes Problem vorzuliegen. Die Nutzung von TCPView und ein Trace mit Wireshark zeigte, dass der korrekte Server angesprochen wird und das Verbindungen zur korrekten IP sichtbar waren. Trotzdem hat der Client keine erfolgreiche Verbindung aufgebaut und blieb offline.
Die Lösung
Nach einer kurzen Suche nach dem Problem bin ich auf verschiedene Foren- und Blogeinträge gestoßen, bei denen als Ursache der IIS auf dem Exchange Server genannt wurde. Besonders geholfen hat mir der folgende Beitrag:
Notes from the field: Don’t Forget to Bounce the Autodiscover Application Pool
In diesem Beitrag wird beschrieben, dass nach der Migration von einem Client das Outlook (genau wie in meinem Fall) offline verbleibt und sich nicht verbinden kann. Microsoft selbst hat hier auch einen eigenen Beitrag zu dem Problem:
Outlook logon fails after mailbox moves from Exchange 2010 to Exchange 2013 or Exchange 2016
Ursache für das Problem ist, dass der Exchange Server nach der Migration des Postfachs immer noch denkt, dass das Postfach auf dem alten Server ist und daher den Client zum alten Server schickt. Dies kann umgangen werden, indem man entweder bis zu 12 Stunden wartet (doof 🙁 ) oder einmalig per Hand den IIS Autodiscover Application Pool neustartet. Dies geht am einfachsten per Windows PowerShell:
Restart-WebAppPool MSExchangeAutodiscoverAppPool
Nachdem der Befehl (auf dem neuen Exchange Server 2016) einmal erfolgreich abgesetzt wurde, dauerte es in meinem Fall weniger als eine Minute, bis sich der Outlook-Client wieder erfolgreich mit dem neuen Exchange Server verbinden konnte. Dies lies sich danach mit einem zweiten Client bestätigen, hier passierte exakt der gleiche Vorgang:
Client wird migriert, verbleibt offline nach einem Outlook-Neustart, IIS-Pool neugestartet, Client geht wieder online mit einer Verbindung zum neuen Server.
Das Problem durch einen Automatismus (temporär) umgehen
Steht eine Migration von sehr vielen Clients an, besteht auch die Möglichkeit, dass der Restart-Vorgang im IIS selbst automatisiert alle XX Minuten passiert. Dies lässt sich wie folgt einrichten:
An dieser Stelle kann ein Neustart in einem gewissen Intervall konfiguriert werden
Falls diese Option eingestellt wird, denkt auf jeden Fall daran, dass sie nach der erfolgreichen Migration wieder entfernt wird, sonst startet der Autodiscover-Anwendungspool fröhlich alle XX Minuten neu.
Pingback:Exchange 2016 - Nach Migration keine Frei-/Gebucht-Informationen verfügbar - Jans Blog