diemilz
Goto Top

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.

Content-Key: 604629

Url: https://administrator.de/contentid/604629

Ausgedruckt am: 06.10.2022 um 23:10 Uhr

Mitglied: 7Gizmo7
7Gizmo7 15.09.2020 aktualisiert um 20:56:06 Uhr
Goto Top
Hi,

Welche Url‘s hast du in der Hostdatei eingetragen für den neuen Server ?

Mit freundlichen Grüßen
Mitglied: diemilz
diemilz 15.09.2020 um 20:59:58 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 15.09.2020 um 21:05:19 Uhr
Goto Top
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
Mitglied: diemilz
diemilz 15.09.2020 um 21:08:08 Uhr
Goto Top
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 ?
Mitglied: 7Gizmo7
7Gizmo7 15.09.2020 um 21:10:21 Uhr
Goto Top
Auch nicht bei den autodiscover Logs ?
Mitglied: diemilz
diemilz 15.09.2020 um 21:10:47 Uhr
Goto Top
Wo finde ich die?
Mitglied: 7Gizmo7
7Gizmo7 15.09.2020 um 21:16:59 Uhr
Goto Top
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 ?
Mitglied: diemilz
diemilz 16.09.2020 um 07:19:40 Uhr
Goto Top
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.
Mitglied: diemilz
diemilz 16.09.2020 um 11:55:19 Uhr
Goto Top
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.
screenshot 2020-09-16 115425
Mitglied: 7Gizmo7
7Gizmo7 16.09.2020 um 18:35:41 Uhr
Goto Top
Was sagt denn Get-OutlookAnywhere | Select Server,ExternalHostname,Internalhostname | fl. Auf dem Exchange 2019
Mitglied: diemilz
diemilz 16.09.2020 um 18:42:30 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 16.09.2020 aktualisiert um 18:52:52 Uhr
Goto Top
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 ?
Mitglied: diemilz
diemilz 16.09.2020 um 19:01:43 Uhr
Goto Top
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.
Mitglied: diemilz
diemilz 17.09.2020 um 15:46:23 Uhr
Goto Top
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.
Mitglied: diemilz
diemilz 18.09.2020 aktualisiert um 08:25:40 Uhr
Goto Top
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.
screenshot 2020-09-18 082418
Mitglied: 7Gizmo7
7Gizmo7 18.09.2020 um 09:34:53 Uhr
Goto Top
Mitglied: diemilz
diemilz 18.09.2020 aktualisiert um 09:44:44 Uhr
Goto Top
Der läuft durch ohne Probleme. Gilt auch für den Test mit -Identity Parameter.
screenshot 2020-09-18 094329
Mitglied: 7Gizmo7
7Gizmo7 18.09.2020 um 20:07:04 Uhr
Goto Top
Mitglied: diemilz
diemilz 18.09.2020 aktualisiert um 20:16:18 Uhr
Goto Top
Das habe ich schon probiert. Die Fehlermeldung dabei lautet aber nicht


sondern sie lautet

Mitglied: 7Gizmo7
7Gizmo7 18.09.2020 um 20:19:27 Uhr
Goto Top
Mhm ,

Exchange 2019 nochmal deinstallieren und Server und nochmal von vorne anfangen ?

Mit freundlichen Grüßen
Mitglied: diemilz
diemilz 18.09.2020 um 20:21:43 Uhr
Goto Top
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.
Mitglied: 7Gizmo7
7Gizmo7 19.09.2020 um 09:24:38 Uhr
Goto Top
Entweder das oder die virtuellen Verzeichnisse zurücksetzen .
Mitglied: diemilz
diemilz 19.09.2020 um 09:28:34 Uhr
Goto Top
Verzeichnisse zurücksetzen? Wie geht das?
Mitglied: 7Gizmo7
7Gizmo7 19.09.2020 um 14:52:01 Uhr
Goto Top
Mitglied: diemilz
diemilz 19.09.2020 um 23:30:20 Uhr
Goto Top
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?
Mitglied: diemilz
diemilz 21.09.2020 um 07:45:16 Uhr
Goto Top
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.