26
Migration von Exchange 2016 auf Exchange 2019
Hallo zusammen,
ich will eine Exchange 2016 zu Exchange 2019 migrieren. Folgendes Szenario liegt vor:
- ESXi-Virtualisierung über 6 Hosts
- 2 Domänencontroller mit Windows Server 2019 Core DataCenter
- Exchange 2016 CU 17 Server (Windows Server 2012 R2 DataCenter), von diesem Server soll migriert werden
- Exchange 2019 CU 5 Server (Windows Server 2019 GUI DataCenter), auf diesen Server soll migriert werden
Mein Problem ist, dass ich zwar den neuen Server per SMTP ansprechen kann (alle Systeme im Netz, die SMTP sprechen, sind bereits auf den neuen Server angelegt), der Server aber keine Outlook Client MAPI-Verbindungen zum alten 2016er Server weiterleitet, hier liegen aktuell noch sämtliche Postfächer und sollen auch erst migriert werden, wenn die Konnektivität zwischen beiden Servern einwandfrei besteht. Für MAPI-Authentifizierung ist NTLM und Aushandlung aktiviert, die URLs aller virtuellen Verzeichnisse sind mit denen auf dem alten Server identisch. HTTPS-Zertifikate sind installiert und es erscheint auch keine Zertifikatsfehlermeldung im Browser beim Aufruf z.B. von ECP und OWA.
Der Client hat modifizierte Einträge in der Hosts-Datei erhalten, sodass er auf den neuen Server connected. Beim Start von Outlook erscheint die Passworteingabe, aber es werden keinerlei Anmeldedaten akzeptiert. Alle Outlook- und mobilen Clients verbinden sich problemlos mit dem alten Server. In meiner Teststellung hatte ich das Problem nicht. Als Grundlage für die Migration dient mir dieser Artikel.
Per 2019er OWA kann ich auf die Postfächer ohne Probleme zugreifen und Mails versenden/empfangen.
Hat jemand eine Idee?
Vielen Dank schonmal im Voraus.
ich will eine Exchange 2016 zu Exchange 2019 migrieren. Folgendes Szenario liegt vor:
- ESXi-Virtualisierung über 6 Hosts
- 2 Domänencontroller mit Windows Server 2019 Core DataCenter
- Exchange 2016 CU 17 Server (Windows Server 2012 R2 DataCenter), von diesem Server soll migriert werden
- Exchange 2019 CU 5 Server (Windows Server 2019 GUI DataCenter), auf diesen Server soll migriert werden
Mein Problem ist, dass ich zwar den neuen Server per SMTP ansprechen kann (alle Systeme im Netz, die SMTP sprechen, sind bereits auf den neuen Server angelegt), der Server aber keine Outlook Client MAPI-Verbindungen zum alten 2016er Server weiterleitet, hier liegen aktuell noch sämtliche Postfächer und sollen auch erst migriert werden, wenn die Konnektivität zwischen beiden Servern einwandfrei besteht. Für MAPI-Authentifizierung ist NTLM und Aushandlung aktiviert, die URLs aller virtuellen Verzeichnisse sind mit denen auf dem alten Server identisch. HTTPS-Zertifikate sind installiert und es erscheint auch keine Zertifikatsfehlermeldung im Browser beim Aufruf z.B. von ECP und OWA.
Der Client hat modifizierte Einträge in der Hosts-Datei erhalten, sodass er auf den neuen Server connected. Beim Start von Outlook erscheint die Passworteingabe, aber es werden keinerlei Anmeldedaten akzeptiert. Alle Outlook- und mobilen Clients verbinden sich problemlos mit dem alten Server. In meiner Teststellung hatte ich das Problem nicht. Als Grundlage für die Migration dient mir dieser Artikel.
Per 2019er OWA kann ich auf die Postfächer ohne Probleme zugreifen und Mails versenden/empfangen.
Hat jemand eine Idee?
Vielen Dank schonmal im Voraus.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 604629
Url: https://administrator.de/forum/migration-von-exchange-2016-auf-exchange-2019-604629.html
Ausgedruckt am: 23.12.2024 um 02:12 Uhr
26 Kommentare
Neuester Kommentar
Hi,
Welche Url‘s hast du in der Hostdatei eingetragen für den neuen Server ?
Mit freundlichen Grüßen
Welche Url‘s hast du in der Hostdatei eingetragen für den neuen Server ?
Mit freundlichen Grüßen
mail.contoso.com auf die IP Adresse des neuen Exchange Servers für Outlook
autodiscover.contoso.com auf die IP Adresse des neuen Servers für Autodiscovery.
Die URLs sind hier natürlich anonymisiert.
autodiscover.contoso.com auf die IP Adresse des neuen Servers für Autodiscovery.
Die URLs sind hier natürlich anonymisiert.
Hi,
Was ist mit EWS und OAB laufen auch auf mail.contoso.com ?
Was sagen denn die IIS log kommt die Auth dort an ?
Mit freundlichen Grüßen
Was ist mit EWS und OAB laufen auch auf mail.contoso.com ?
Was sagen denn die IIS log kommt die Auth dort an ?
Mit freundlichen Grüßen
Ja, alle Verzeichnisse haben den gleichen Link.
In den Logs sehe ich keine Authentifizierungsanfrage. Kann es sein, dass das MAPI Verzeichnis im IIS falsch konfiguriert ist ?
In den Logs sehe ich keine Authentifizierungsanfrage. Kann es sein, dass das MAPI Verzeichnis im IIS falsch konfiguriert ist ?
Auch nicht bei den autodiscover Logs ?
Wo finde ich die?
Hast du denn die Möglichkeit , temporär die externe Portfreigabe auf den Exchange 2019 zu verweisen und dann alle test hiermit https://testconnectivity.microsoft.com/tests/exchange
Zu Durchlaufen ?
Zu Durchlaufen ?
Ich kann das kurz umstellen, das ist kein Problem. Mobilgeräte per ActiveSync haben keine Probleme, nur Outlook (intern und extern).
Melde mich, sobald ich Ergebnisse habe.
Melde mich, sobald ich Ergebnisse habe.
So sieht das Ergebnis aus. Ich bin schon am Prüfen, was mit dem RPC-over-HTTPS nicht stimmt, finde den Fehler aber nicht wirklich.
Was sagt denn Get-OutlookAnywhere | Select Server,ExternalHostname,Internalhostname | fl. Auf dem Exchange 2019
Server: Exchange01
ExternalHostname: mail.contoso.com
InternalHostname: mail.contoso.com
Hat es eventuell etwas damit zu tun, dass RPC over HTTP mit Exchange 2019 offiziell nicht mehr unterstützt wird? Damit ist ja eigentlich auch Outlook Anywhere gemeint.
ExternalHostname: mail.contoso.com
InternalHostname: mail.contoso.com
Hat es eventuell etwas damit zu tun, dass RPC over HTTP mit Exchange 2019 offiziell nicht mehr unterstützt wird? Damit ist ja eigentlich auch Outlook Anywhere gemeint.
https://docs.microsoft.com/de-de/exchange/clients/mapi-over-http/mapi-ov ...
Also Outlook Anywhere wird noch unterstützt , welches Protokoll nutzt denn der Outlook Client zum Exchange 2016
Und welche AUTH ist fur Outlook Anywhere eingestellt ,
Was ist wenn die Mailbox auf dem 2019 Exchange liegt , auch immer Passwort Abfrage ? Habt ihr ein Proxy in den IE Einstellungen ?
Also Outlook Anywhere wird noch unterstützt , welches Protokoll nutzt denn der Outlook Client zum Exchange 2016
Und welche AUTH ist fur Outlook Anywhere eingestellt ,
Was ist wenn die Mailbox auf dem 2019 Exchange liegt , auch immer Passwort Abfrage ? Habt ihr ein Proxy in den IE Einstellungen ?
Laut Outlook Diagnose wird HTTP eingesetzt, also MAPI over HTTP.
Die Exchange Testbefehle in der PowerShell schlagen auch fehl, aber ich glaube, das liegt noch an einem falschen Befehlssyntax. Proxy haben wir keinen, für Outlook Anywhere ist auf dem 2019er Server NTLM eingestellt. Habe ich aber auch schon umgestellt auf Basic oder Negotiate, beides bringt keine Änderung.
Ich habe noch keine Mailbox auf dem neuen Server liegen. Das wollte ich erst dann machen, wenn die Kommunikation zwischen beiden Servern funktioniert und der 2019er Server als Proxy für den 2016er Server eingesetzt werden kann. Ich kann das morgen aber mal mit einem Testaccount ausprobieren, ob das funktioniert.
Die Exchange Testbefehle in der PowerShell schlagen auch fehl, aber ich glaube, das liegt noch an einem falschen Befehlssyntax. Proxy haben wir keinen, für Outlook Anywhere ist auf dem 2019er Server NTLM eingestellt. Habe ich aber auch schon umgestellt auf Basic oder Negotiate, beides bringt keine Änderung.
Ich habe noch keine Mailbox auf dem neuen Server liegen. Das wollte ich erst dann machen, wenn die Kommunikation zwischen beiden Servern funktioniert und der 2019er Server als Proxy für den 2016er Server eingesetzt werden kann. Ich kann das morgen aber mal mit einem Testaccount ausprobieren, ob das funktioniert.
Wenn die Mailbox auf dem 2019er Exchange liegt, kommt ebenfalls die Passwortabfrage. In den IIS-Logs sehe ich, dass der Server bei Abfragen auf das /RPC-Verzeichnis scheinbar mit HTTP 401 antwortet.
Weiterer Hinweis: Bei Ausführung des PowerShell CmdLets kommt folgende Fehlermeldung im Anhang. Bei Ausführung des Befehls auf dem 2016er Server kommt keine Fehlermeldung.
Der läuft durch ohne Probleme. Gilt auch für den Test mit -Identity Parameter.
Das habe ich schon probiert. Die Fehlermeldung dabei lautet aber nicht
sondern sie lautet
Sequence contains no elementssondern sie lautet
Sequence contains more than one elements
Mhm ,
Exchange 2019 nochmal deinstallieren und Server und nochmal von vorne anfangen ?
Mit freundlichen Grüßen
Exchange 2019 nochmal deinstallieren und Server und nochmal von vorne anfangen ?
Mit freundlichen Grüßen
Das will ich vermeiden, da der Server bereits SMTP-Verbindungen annimmt, die ich teilweise nur mit Aufwand wieder zurückmünzen kann auf das alte System. Was ich aber am Wochenende probieren will, ist eine Reparaturinstallation des Servers in der Hoffnung, dass es dann wieder geht. Unser Dienstleister war heute auch den ganzen Tag dran und wir stehen kurz davor, Microsoft einzuschalten.
Entweder das oder die virtuellen Verzeichnisse zurücksetzen .
Verzeichnisse zurücksetzen? Wie geht das?
Achso, es geht ums Löschen und Neuanlege der Verzeichnisse. Das habe ich jetzt durchgeführt, hat aber nichts gebracht.
Ich habe eine Reparaturinstallation durchgeführt, jetzt funktioniert das Test-OutlookConnection Cmdlet wieder. Jetzt scheint tatsächlich nur eine Einstellung nicht zu passen. Welche Verzeichnisse sind denn für die Outlook-Verbindung notwendig?
Ich habe eine Reparaturinstallation durchgeführt, jetzt funktioniert das Test-OutlookConnection Cmdlet wieder. Jetzt scheint tatsächlich nur eine Einstellung nicht zu passen. Welche Verzeichnisse sind denn für die Outlook-Verbindung notwendig?
Also, es sieht aktuell so aus, dass beim Exchange 2019 ein Problem und eine falsche Einstellung vorhanden sind. Ich habe statt der Reparaturinstallation am Wochenende gleich das Exchange 2019 CU7 installiert und war doch mehr als erstaunt, als mir das Setup plötzlich sagte, dass zum Einen ein Schemaupdate des ADs erforderlich sei und dass zum Anderen die RSAT-ADDS-Tools nicht installiert seien. Ich bin doch sehr verwundert, da ich eigentlich davon ausging, dass sie installiert wären. Scheinbar war hier also schon ein Fehler bei der Installation des Servers aufgetreten, den ich nicht bemerkt habe.
Ich habe also die Tools nachinstalliert und dann lief die Installation des CU7 ordnungsgemäß durch. Nach einem Neustart habe ich das Test-OutlookConnectivity Cmdlet nochmal durchlaufen lassen, es lief ohne Fehler durch.
Jetzt habe ich nur noch das Problem, dass Outlook sich nicht am Exchange anmelden kann, aber ich glaube, ich habe hierzu auch schon den Ansatz gefunden. Bei Durchsicht meiner Installationsdoku habe ich gesehen, dass ich den Exchange 2016er Server mit Kerberos eingerichtet hatte, d.h. ich habe im Computerobjekt noch weitere HTTP Service Principals eingefügt. Nehme ich die aus dem 2016er Computerobjekt raus, funktioniert auch die Authentifizierung auf dem alten Server nicht mehr. Ich muss eigentlich nur die SPNs aus dem alten Computerobjekt im AD in das des neuen Exchange-Servers übertragen, nachdem ich die DNS-Namen auf den neuen Server geändert habe und sicherheitshalber beide Exchange-Server neu starten.
Was mich daran nur stutzig macht ist, dass NTLM eigentlich als Fallback funktionieren sollte, es aber nicht tut.
Ich habe also die Tools nachinstalliert und dann lief die Installation des CU7 ordnungsgemäß durch. Nach einem Neustart habe ich das Test-OutlookConnectivity Cmdlet nochmal durchlaufen lassen, es lief ohne Fehler durch.
Jetzt habe ich nur noch das Problem, dass Outlook sich nicht am Exchange anmelden kann, aber ich glaube, ich habe hierzu auch schon den Ansatz gefunden. Bei Durchsicht meiner Installationsdoku habe ich gesehen, dass ich den Exchange 2016er Server mit Kerberos eingerichtet hatte, d.h. ich habe im Computerobjekt noch weitere HTTP Service Principals eingefügt. Nehme ich die aus dem 2016er Computerobjekt raus, funktioniert auch die Authentifizierung auf dem alten Server nicht mehr. Ich muss eigentlich nur die SPNs aus dem alten Computerobjekt im AD in das des neuen Exchange-Servers übertragen, nachdem ich die DNS-Namen auf den neuen Server geändert habe und sicherheitshalber beide Exchange-Server neu starten.
Was mich daran nur stutzig macht ist, dass NTLM eigentlich als Fallback funktionieren sollte, es aber nicht tut.
