14
Migration Exchange 2016 nach 2019 - Glitches
Moin Kollegen.
Ich hoffe auf Antworten von Admins, die diese Migration (2016->2019, beides on premises) möglichst schon mehrfach gemacht haben.
Unsere Migration war erfolgreich und laut Logs gab es keine Probleme, Exchange 2016 ist deinstalliert und der Autokonfig Test läuft überall in einer Sekunde durch und zeigt auch keine Verweise mehr auf den alten Server.
Ich habe jedoch seit der Migration 2 Dinge beobachtet, die ich mir noch versuche, zu erkären:
1 Beim ersten Start von Outlook (2016) nach der Migration kam es bei ca. 1/3 der Mitarbeiter dazu, dass Outlook behauptete, es könnte die Ordnerstruktur nicht öffnen.
Abhilfe war, dann ein neues Outlookprofil zu erstellen ->öffnete sofort. Dann wieder zum alten Profil zurück ->keine Probleme mehr!
Frage 1: was will mir das sagen? Warum ist das Verhalten dermaßen inkonsistent, dass es bei den meisten (2/3) einfach so läuft, während bei den anderen dieser lustige Workaround nötig war?
2 Bei einem kleinen Nutzerkreis, die einen freigegebenen Abteilungsurlaubskalender gemeinsam verwenden, kam es beim Wechsel zu diesem manchmal zu Hängern (ca. 2 Minuten). Procmon förderte zu Tage, dass Outlook tatsächlich versuchte, hier den alten Server zu kontaktieren.
Frage 2: warum nur bei diesem einen Kalender, warum nur manchmal? Wie gesagt: alle Postfächer und Kalender wurden laut Logs einwandfrei migriert.
Ich habe vor, diesen Kalender einfach zu exportieren, zu löschen, neu zu importieren und wieder freizugeben, vermutlich ist auch das dann Geschichte.
Ich hoffe auf Antworten von Admins, die diese Migration (2016->2019, beides on premises) möglichst schon mehrfach gemacht haben.
Unsere Migration war erfolgreich und laut Logs gab es keine Probleme, Exchange 2016 ist deinstalliert und der Autokonfig Test läuft überall in einer Sekunde durch und zeigt auch keine Verweise mehr auf den alten Server.
Ich habe jedoch seit der Migration 2 Dinge beobachtet, die ich mir noch versuche, zu erkären:
1 Beim ersten Start von Outlook (2016) nach der Migration kam es bei ca. 1/3 der Mitarbeiter dazu, dass Outlook behauptete, es könnte die Ordnerstruktur nicht öffnen.
Abhilfe war, dann ein neues Outlookprofil zu erstellen ->öffnete sofort. Dann wieder zum alten Profil zurück ->keine Probleme mehr!
Frage 1: was will mir das sagen? Warum ist das Verhalten dermaßen inkonsistent, dass es bei den meisten (2/3) einfach so läuft, während bei den anderen dieser lustige Workaround nötig war?
2 Bei einem kleinen Nutzerkreis, die einen freigegebenen Abteilungsurlaubskalender gemeinsam verwenden, kam es beim Wechsel zu diesem manchmal zu Hängern (ca. 2 Minuten). Procmon förderte zu Tage, dass Outlook tatsächlich versuchte, hier den alten Server zu kontaktieren.
Frage 2: warum nur bei diesem einen Kalender, warum nur manchmal? Wie gesagt: alle Postfächer und Kalender wurden laut Logs einwandfrei migriert.
Ich habe vor, diesen Kalender einfach zu exportieren, zu löschen, neu zu importieren und wieder freizugeben, vermutlich ist auch das dann Geschichte.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1986078357
Url: https://administrator.de/forum/migration-exchange-2016-nach-2019-glitches-1986078357.html
Ausgedruckt am: 01.04.2025 um 19:04 Uhr
14 Kommentare
Neuester Kommentar
Bei sowas leere ich im Vorfeld immer den Autodiscover-Cache von Outlook auf den Clients. Outlook braucht halt immer Stützräder damit es nicht gleich umfällt 
.
.
1
Zitat von @1915348599:
Outlook braucht halt immer Stützräder damit es nicht gleich umfällt.
Outlook braucht halt immer Stützräder damit es nicht gleich umfällt
.Der Spruch ist gut!
@1915348599
Moin.
Du meinst, unter %localappdata%\Microsoft\Outlook die lalala - autodiscover.xml entsorgen?
Oder wie leerst Du den Cache?
Das hat hier nichts gebracht, obwohl in einer der Dateien in der Tat der alte Servername drin steht.
Auch bringt es nichts, diese Datei(en) dort zu belassen aber den Namen manuell zu ändern.
Moin.
Du meinst, unter %localappdata%\Microsoft\Outlook die lalala - autodiscover.xml entsorgen?
Oder wie leerst Du den Cache?
Das hat hier nichts gebracht, obwohl in einer der Dateien in der Tat der alte Servername drin steht.
Auch bringt es nichts, diese Datei(en) dort zu belassen aber den Namen manuell zu ändern.
Zitat von @DerWoWusste:
@1915348599
Moin.
Du meinst, unter %localappdata%\Microsoft\Outlook die lalala - autodiscover.xml entsorgen?
Ja.@1915348599
Moin.
Du meinst, unter %localappdata%\Microsoft\Outlook die lalala - autodiscover.xml entsorgen?
Das hat hier nichts gebracht, obwohl in einer der Dateien in der Tat der alte Servername drin steht.
Auch bringt es nichts, diese Datei(en) dort zu belassen aber den Namen manuell zu ändern.
Cached mode ist nirgendwo an, untersagt per GPO.
Auch das Erstellen von OSTs wenn Online Mode aktiviert ist?
https://www.slipstick.com/exchange/outlook-online-mode-creates-ost-file/
https://www.slipstick.com/exchange/outlook-online-mode-creates-ost-file/
Hm, ob NoOST nötig ist? Ich finde hier keine OST, aber vielleicht versucht er, eine anzulegen, wenn's hängt.
Ich brauche nun einen neuen Problemfall, um dies zu testen. Wird sich bald finden (auf den Konferenz-PCs zum Beispiel). Melde mich.
Ich brauche nun einen neuen Problemfall, um dies zu testen. Wird sich bald finden (auf den Konferenz-PCs zum Beispiel). Melde mich.
Zitat von @DerWoWusste:
Ich hoffe auf Antworten von Admins, die diese Migration (2016->2019, beides on premises) möglichst schon mehrfach gemacht haben.
Unsere Migration war erfolgreich und laut Logs gab es keine Probleme, Exchange 2016 ist deinstalliert und der Autokonfig Test läuft überall in einer Sekunde durch und zeigt auch keine Verweise mehr auf den alten Server.
Ich habe jedoch seit der Migration 2 Dinge beobachtet, die ich mir noch versuche, zu erkären:
1 Beim ersten Start von Outlook (2016) nach der Migration kam es bei ca. 1/3 der Mitarbeiter dazu, dass Outlook behauptete, es könnte die Ordnerstruktur nicht öffnen.
Abhilfe war, dann ein neues Outlookprofil zu erstellen ->öffnete sofort. Dann wieder zum alten Profil zurück ->keine Probleme mehr!
Frage 1: was will mir das sagen? Warum ist das Verhalten dermaßen inkonsistent, dass es bei den meisten (2/3) einfach so läuft, während bei den anderen dieser lustige Workaround nötig war?
Unsere Migration war erfolgreich und laut Logs gab es keine Probleme, Exchange 2016 ist deinstalliert und der Autokonfig Test läuft überall in einer Sekunde durch und zeigt auch keine Verweise mehr auf den alten Server.
Ich habe jedoch seit der Migration 2 Dinge beobachtet, die ich mir noch versuche, zu erkären:
1 Beim ersten Start von Outlook (2016) nach der Migration kam es bei ca. 1/3 der Mitarbeiter dazu, dass Outlook behauptete, es könnte die Ordnerstruktur nicht öffnen.
Abhilfe war, dann ein neues Outlookprofil zu erstellen ->öffnete sofort. Dann wieder zum alten Profil zurück ->keine Probleme mehr!
Frage 1: was will mir das sagen? Warum ist das Verhalten dermaßen inkonsistent, dass es bei den meisten (2/3) einfach so läuft, während bei den anderen dieser lustige Workaround nötig war?
War denn das alte Exchange System zu diesem Zeitpunkt noch verfügbar?
Nein, der alte Exchange war zum Zeitpunkt dieser Fehlstarts nicht mehr aktiv und auch deinstalliert. Aber auch wenn er hochgefahren und pingbar ist, läuft natürlich kein Webserver mehr, da deinstalliert.
So, mir scheint jetzt hab ich's.
Nicht nur direkt unter %localappdata%\Microsoft\Outlook liegen anppassbare blablubb - autodiscover.xml, sondern auch unter %localappdata%\Microsoft\Outlook\16 und nachdem ich die angepasst habe, ist der Fehler weg.
Besten Dank für den Tipp!
Nicht nur direkt unter %localappdata%\Microsoft\Outlook liegen anppassbare blablubb - autodiscover.xml, sondern auch unter %localappdata%\Microsoft\Outlook\16 und nachdem ich die angepasst habe, ist der Fehler weg.
Besten Dank für den Tipp!
Zitat von @DerWoWusste:
Nein, der alte Exchange war zum Zeitpunkt dieser Fehlstarts nicht mehr aktiv und auch deinstalliert. Aber auch wenn er hochgefahren und pingbar ist, läuft natürlich kein Webserver mehr, da deinstalliert.
Nein, der alte Exchange war zum Zeitpunkt dieser Fehlstarts nicht mehr aktiv und auch deinstalliert. Aber auch wenn er hochgefahren und pingbar ist, läuft natürlich kein Webserver mehr, da deinstalliert.
Meiner Meinung nach schickt doch der alte Exchange dem Client ein Redirect für den neunen Server.
Ok, wie soll das technisch funktionieren? Wo findet man das dokumentiert?
Schon drei mal gemacht, 2007 auf 10, dann auf 13 inkl. Hybrid mit Online Protection, dann auf 16.
Dein Autodiscover ist vom DNS abhängig. Dein Active Directory Server der vermutlich auch den DNS hält, sollte eure Mail Domäne bereitstellen und dort einen CNAME Eintrag für autodiscover.deinedomäne.de auf deinen bereitstellenden Mailserver enthalten oder wahlweise oder zusätzlich einen SRV eintrag auf _autodiscover._tcp 443 auf deinen Mailserver.
Der Exchange Transport Server läuft zwar auf der gleichen Kiste, ist aber technisch gesehen ein externer Dienst, der das Active Directory nach der Adressliste befragt und anhand der Ergebnisse mit dem zuständigen CAS bzw. Postfachdatenbank-Server kommuniziert.
Die autodiscover.xml kommt aus dem virtuellen Directory im IIS, wenn da was lokal liegt, gehört es da nicht hin.
Neu erstellen geht so.
https://www.frankysweb.de/exchange-2016-virtuelle-verzeichnisse-im-iis-n ...
SSL muss dazu zwangsläufig funktionieren, die Config wird nur dann abgerufen wenn es keine Zertifikatsfehler gibt, eventuell haben manche eurer Clients nicht die erforderliche CA.
Eine Migration ist eigentlich Pillepalle, Sysprep ausführen, Server Installieren, alles worüber er motzt beheben, Zertifikate anpassen, Postfächer inkl. Public Folders nach und nach migrieren. Ggf. noch zusätzliche Connectors erstellen.
NAT oder Reverse Proxy auf neue Adresse umbiegen, alten Server dekommissionieren, fertig.
2016 und 2019 sind so ähnlich das sie sogar in einer DAG miteinander koexistieren können, nimmt sich nix.
Dokumentationen dazu gibt es tausende. Google Bildsuche nach Exchange, Active Directory und Routing fördert alles zutage was man so braucht.
Frage ist nur, warum du das machen möchtest. End of Life ist für alle On-Premises Produkte der 13. Okt. 2025.
Eine Migration bringt nicht wirklich einen Vorteil.
Dein Autodiscover ist vom DNS abhängig. Dein Active Directory Server der vermutlich auch den DNS hält, sollte eure Mail Domäne bereitstellen und dort einen CNAME Eintrag für autodiscover.deinedomäne.de auf deinen bereitstellenden Mailserver enthalten oder wahlweise oder zusätzlich einen SRV eintrag auf _autodiscover._tcp 443 auf deinen Mailserver.
Der Exchange Transport Server läuft zwar auf der gleichen Kiste, ist aber technisch gesehen ein externer Dienst, der das Active Directory nach der Adressliste befragt und anhand der Ergebnisse mit dem zuständigen CAS bzw. Postfachdatenbank-Server kommuniziert.
Die autodiscover.xml kommt aus dem virtuellen Directory im IIS, wenn da was lokal liegt, gehört es da nicht hin.
Neu erstellen geht so.
https://www.frankysweb.de/exchange-2016-virtuelle-verzeichnisse-im-iis-n ...
SSL muss dazu zwangsläufig funktionieren, die Config wird nur dann abgerufen wenn es keine Zertifikatsfehler gibt, eventuell haben manche eurer Clients nicht die erforderliche CA.
Eine Migration ist eigentlich Pillepalle, Sysprep ausführen, Server Installieren, alles worüber er motzt beheben, Zertifikate anpassen, Postfächer inkl. Public Folders nach und nach migrieren. Ggf. noch zusätzliche Connectors erstellen.
NAT oder Reverse Proxy auf neue Adresse umbiegen, alten Server dekommissionieren, fertig.
2016 und 2019 sind so ähnlich das sie sogar in einer DAG miteinander koexistieren können, nimmt sich nix.
Dokumentationen dazu gibt es tausende. Google Bildsuche nach Exchange, Active Directory und Routing fördert alles zutage was man so braucht.
Frage ist nur, warum du das machen möchtest. End of Life ist für alle On-Premises Produkte der 13. Okt. 2025.
Eine Migration bringt nicht wirklich einen Vorteil.
Moin.
Warum man 16 auf 19 migriert? Weil 19 noch im Mainstream Lifecycle ist und Verbesserungen erhält, 2016 nicht. Zudem war die Upgradelizenz bei Beschaffung von 16 inklusive. Auch kann 19 auf 22 upgegradet werden (in place), 16 nicht - ja, es wird 2022 on premises geben.
Ich habe zu meinem Problem die Lösung gefunden. Es mangelte nicht an DNS-Einträgen oder Serverkonfigs, sondern lediglich am Autodiscover-Cache, der gestört hat.
Warum man 16 auf 19 migriert? Weil 19 noch im Mainstream Lifecycle ist und Verbesserungen erhält, 2016 nicht. Zudem war die Upgradelizenz bei Beschaffung von 16 inklusive. Auch kann 19 auf 22 upgegradet werden (in place), 16 nicht - ja, es wird 2022 on premises geben.
Ich habe zu meinem Problem die Lösung gefunden. Es mangelte nicht an DNS-Einträgen oder Serverkonfigs, sondern lediglich am Autodiscover-Cache, der gestört hat.
Die autodiscover.xml kommt aus dem virtuellen Directory im IIS, wenn da was lokal liegt, gehört es da nicht hin.
Nein, es ist nicht die Rede davon, der Cache ist etwas anderes, Schau rein unter %localappdata%\Microsoft\Outlook bzw. %localappdata%\Microsoft\Outlook\16
