14
Testumgegung - Migration Exchange 2010 zu 16 zu 19 - Outlook 2010 zu 2013 Verhalten
Hallo zusammen,
ich weiß, der Betreff ist absolut besch... aber ich habe echt kein Plan, wie ich das anders formulieren sollte.
Ziel: Test der Migration von Exchange 2010 zu Exchange 2016, damit wir dann auf 2019 können.
Anleitung: Sehr gute gefunden bei Franky, sollte also kein Problem sein, aber dazu kommen wir erst gar nicht x_X
Wie sieht die Produktivumgebung aus:
- Alles DCs sind schon auf Server 2019 (zwei in einer Site... einer in einer anderen (andere Lokation))
- Exchange ist noch ein Server 2008R2 mit Exchange 2010 SP3 und aktuellestem Patchstand davor liegt ein NginX als Proxy (läuft schon seit knapp 2 Jahren so)
- Clients alle auf Win10 (aktuellester Patchstand) mit verschiedenen Officeversionen von 2010 bis 2019 alles dabei (ja auch 2019... funktioniert obwohl nicht offiziell freigegeben)
Wie ist unser Vorgehen:
- eine Kopie von EINEM DC (der sowohl alle FSMO hat sowie die Zertifizierungsstelle)
- alle anderen DC rausgekratzt mit NTDSUTIL
- Exchangekopie
- frisch installierter Client mit Win10 und Office 2013
- alle Maschinen laufen auf einem ESXi, die nur intern kommunizieren können
Problem:
- frisch installierter Client wird in die Domäne genomme... = funktioniert... Outlook 2013 installiert und gestartet... weiter weiter fertig stellen scheitert daran, dass im letzten Step dann die Meldung kommt:
bestätigt man diese Meldung erscheint das hier:
Was wir bisher getan haben:
- Office Reparatur haben wir schon durchgeführt (hat einer mal online gepostet)
- Regeintrag gemacht zwecks globalen Katalog (findet man in diesem Zusammenhang extrem oft)
- DNS rauf und runter geprüft und getestet, kein Fehler ersichtlich
- die externe URL im DNS eingetragen, damit diese weiter funktioniert, da in der Testumgebung weder ein NginX vorangestellt ist noch Internet besteht.
Aus Verzeiflung einen Client in der Produktdomäne installiert mit gleichem Office ... = geht!
Aus weiterer Verzeiflung erneut einen Win10 Client aufgesetzt mit Office 2010 = funktioniert!!!! (in also in der Testumgebung)
Vor Frust dann einmal ALLE Officeversionen (2010, 2013, 2016 und 2019) gestestet... in der Testumgebung funktioniert NUR Office 2010
Wo zur Hölle ist denn hier die Unterscheidung... wir kommen einfach nicht drauf, da es in der Produktivumgebung funktioniert aber als Kopie in einem gesonderten Netz nicht.
Kennst jemand das Problem bzw. kann uns wer hier unterstützen?
Wir wolle die Migration von Exchange 2010 auf 2016 und dann 2019 definitiv erst in der Testumgebung machen und dann erst im Produktivbetrieb... dafür wollten wir Office 2013 als Testclient nutzen, damit wir eben alle Exchange Versionen damit abfrühstücken können, denn Office 2010 ist eben nicht freigegeben für Exchange 2019, scheitern jedoch daran Outlook 2013 an den Start zu bekommen, obwohl die Umgebung fast 1:1 kopiert wurde.
Sorry... aber wir wissen echt nicht weiter.
Gruß
ich weiß, der Betreff ist absolut besch... aber ich habe echt kein Plan, wie ich das anders formulieren sollte.
Ziel: Test der Migration von Exchange 2010 zu Exchange 2016, damit wir dann auf 2019 können.
Anleitung: Sehr gute gefunden bei Franky, sollte also kein Problem sein, aber dazu kommen wir erst gar nicht x_X
Wie sieht die Produktivumgebung aus:
- Alles DCs sind schon auf Server 2019 (zwei in einer Site... einer in einer anderen (andere Lokation))
- Exchange ist noch ein Server 2008R2 mit Exchange 2010 SP3 und aktuellestem Patchstand davor liegt ein NginX als Proxy (läuft schon seit knapp 2 Jahren so)
- Clients alle auf Win10 (aktuellester Patchstand) mit verschiedenen Officeversionen von 2010 bis 2019 alles dabei (ja auch 2019... funktioniert obwohl nicht offiziell freigegeben)
Wie ist unser Vorgehen:
- eine Kopie von EINEM DC (der sowohl alle FSMO hat sowie die Zertifizierungsstelle)
- alle anderen DC rausgekratzt mit NTDSUTIL
- Exchangekopie
- frisch installierter Client mit Win10 und Office 2013
- alle Maschinen laufen auf einem ESXi, die nur intern kommunizieren können
Problem:
- frisch installierter Client wird in die Domäne genomme... = funktioniert... Outlook 2013 installiert und gestartet... weiter weiter fertig stellen scheitert daran, dass im letzten Step dann die Meldung kommt:
bestätigt man diese Meldung erscheint das hier:
Was wir bisher getan haben:
- Office Reparatur haben wir schon durchgeführt (hat einer mal online gepostet)
- Regeintrag gemacht zwecks globalen Katalog (findet man in diesem Zusammenhang extrem oft)
- DNS rauf und runter geprüft und getestet, kein Fehler ersichtlich
- die externe URL im DNS eingetragen, damit diese weiter funktioniert, da in der Testumgebung weder ein NginX vorangestellt ist noch Internet besteht.
Aus Verzeiflung einen Client in der Produktdomäne installiert mit gleichem Office ... = geht!
Aus weiterer Verzeiflung erneut einen Win10 Client aufgesetzt mit Office 2010 = funktioniert!!!! (in also in der Testumgebung)
Vor Frust dann einmal ALLE Officeversionen (2010, 2013, 2016 und 2019) gestestet... in der Testumgebung funktioniert NUR Office 2010
Wo zur Hölle ist denn hier die Unterscheidung... wir kommen einfach nicht drauf, da es in der Produktivumgebung funktioniert aber als Kopie in einem gesonderten Netz nicht.
Kennst jemand das Problem bzw. kann uns wer hier unterstützen?
Wir wolle die Migration von Exchange 2010 auf 2016 und dann 2019 definitiv erst in der Testumgebung machen und dann erst im Produktivbetrieb... dafür wollten wir Office 2013 als Testclient nutzen, damit wir eben alle Exchange Versionen damit abfrühstücken können, denn Office 2010 ist eben nicht freigegeben für Exchange 2019, scheitern jedoch daran Outlook 2013 an den Start zu bekommen, obwohl die Umgebung fast 1:1 kopiert wurde.
Sorry... aber wir wissen echt nicht weiter.
Gruß
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: 505301
Url: https://administrator.de/contentid/505301
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
14 Kommentare
Neuester Kommentar
Funktionieren die DNS-Auflösungen alle? Geht ansonsten mal mit Wireshark dazwischen und guckt euch den traffic an wo es hakt...
Hi,
sind in der Testumgebung alle IP-Adressen gleich? Falls nein, in der DNS-Kopie bei allen Records die IP-Adressen angepasst?
E.
sind in der Testumgebung alle IP-Adressen gleich? Falls nein, in der DNS-Kopie bei allen Records die IP-Adressen angepasst?
E.
Hallo Ihr zwei,
danke schon einmal für die schnelle Reaktion.
Zu den IPs: wir haben im ESXi einen virtuellen Switch ohne physikalischen Adapter, damit gewährleistet ist, dass die Testumgebung zum einen genau so betrieben werden kann wie zuvor und somit auch gleichzeitig die Produktivumgebung nicht stört. An den IPs von DC und Exchangen hat sich also absolut nichts geändert.
Zum Thema DNS: also zumindest das, was wir geprüft haben, hat funktioniert. Die Frage ist jetzt, haben wir auch wirklich alles getestet? Um auszuschließen, dass wir keinen DNS Check vergessen haben, was gehört definitiv alles geprüft? Interne URL und Externe? Was noch?
Wireshark haben wir schon installiert, aber zugegeben, ich bin in Wireshark jetzt nicht 100% der Profi, aber zusammen mit meinem Kollegen schien da nichts wirklich auffälliges zu sein.
Was macht Outlook 2010 denn anders als Outlook 2013?
Gruß und danke!
Mike
danke schon einmal für die schnelle Reaktion.
Zu den IPs: wir haben im ESXi einen virtuellen Switch ohne physikalischen Adapter, damit gewährleistet ist, dass die Testumgebung zum einen genau so betrieben werden kann wie zuvor und somit auch gleichzeitig die Produktivumgebung nicht stört. An den IPs von DC und Exchangen hat sich also absolut nichts geändert.
Zum Thema DNS: also zumindest das, was wir geprüft haben, hat funktioniert. Die Frage ist jetzt, haben wir auch wirklich alles getestet? Um auszuschließen, dass wir keinen DNS Check vergessen haben, was gehört definitiv alles geprüft? Interne URL und Externe? Was noch?
Wireshark haben wir schon installiert, aber zugegeben, ich bin in Wireshark jetzt nicht 100% der Profi, aber zusammen mit meinem Kollegen schien da nichts wirklich auffälliges zu sein.
Was macht Outlook 2010 denn anders als Outlook 2013?
Gruß und danke!
Mike
O2010 arbeitet noch rein über MAPI.
Ok... damit wüssten wir jetzt aber nur, dass es über Mapi funktioniert :D sollte mich das jetzt auf eine Idee bringen, warum es in der Produktivumgebung funktioniert aber nicht in der Testumgebung? Dann habe ich den Wink nicht verstanden :D
Du wolltest wissen, was O2010 anders macht.
Moin zusammen,
ich hatte das gleiche Problem.
Bei mir lag es an einem zunächst falsch konfigurierten
Autodiscover.
Mir half folgender Link:
https://www.msxfaq.de/exchange/autodiscover/autodiscover_scp.htm
Im besagten Attribut stand ein nicht existierendes Verzeichnis,
wie auch immer das da hin gekommen ist. Ich hab den Eintrag
auf die richtige DAtei gestzt und alles läuft problemlos...
Gruß
Kay
ich hatte das gleiche Problem.
Bei mir lag es an einem zunächst falsch konfigurierten
Autodiscover.
Mir half folgender Link:
https://www.msxfaq.de/exchange/autodiscover/autodiscover_scp.htm
Im besagten Attribut stand ein nicht existierendes Verzeichnis,
wie auch immer das da hin gekommen ist. Ich hab den Eintrag
auf die richtige DAtei gestzt und alles läuft problemlos...
Gruß
Kay
Nachtrag: Wichtig war der Abschnitt "Autodiscover und SCP"...
Hallo Pampersjoe,
Wenn ihr auch die Verwendung von einem Drittanbieter-Tool für diese Aufgabe überlegt, dann dieser Artikel beschreibt, wie man dies mit CodeTwo Exchange Migration erledigt: https://www.codetwo.de/blog/wie-migriert-man-exchange-2010-direkt-zu-exc .... Keine Double-Hop-Migration nötig, man führt eine direkte Cross-Forest-Migration von Exchange 2010 zu 2019 durch und hat dabei technischen Support, der im Preis inbegriffen ist. Das Programm ist auch 30 Tage kostenlos zum Testen verfügbar.
Gruß,
Adam
Wenn ihr auch die Verwendung von einem Drittanbieter-Tool für diese Aufgabe überlegt, dann dieser Artikel beschreibt, wie man dies mit CodeTwo Exchange Migration erledigt: https://www.codetwo.de/blog/wie-migriert-man-exchange-2010-direkt-zu-exc .... Keine Double-Hop-Migration nötig, man führt eine direkte Cross-Forest-Migration von Exchange 2010 zu 2019 durch und hat dabei technischen Support, der im Preis inbegriffen ist. Das Programm ist auch 30 Tage kostenlos zum Testen verfügbar.
Gruß,
Adam
Das mit dem "Verzeichnis" ist es leider auch nicht... sieht alles eigentlich grün aus... das ist doch echt die Nadel im Heuhaufen 
wieder ein Tag rum.
wieder ein Tag rum.
Moin zusammen,
naja, mit Verzeichnis habe ich mich vielleicht nicht richtig ausgedrückt.
Bei mir stand da der Wert "autodiscover.meinefirma.tld".
Ich habe aber alle virtuellen Verzeichnisse konfiguriert
auf "meinefirma.tld".
Der Eintrag "autodiscover.meinefirma.tld" konnte per DNS
nicht erreicht werden, was in meine Fall ja auch richtig ist.
Also habe ich den Eintrag auf "meinefirma.tld" geändert,
dieser Eintrag zeigt auf meinen Mailserver, DNS funktioniert.
Somit findet nun ein Interner Client den Server und Autodiscover
funktionert.....
Zumindest bei mir....
Schöne Restwoche
Kay
naja, mit Verzeichnis habe ich mich vielleicht nicht richtig ausgedrückt.
Bei mir stand da der Wert "autodiscover.meinefirma.tld".
Ich habe aber alle virtuellen Verzeichnisse konfiguriert
auf "meinefirma.tld".
Der Eintrag "autodiscover.meinefirma.tld" konnte per DNS
nicht erreicht werden, was in meine Fall ja auch richtig ist.
Also habe ich den Eintrag auf "meinefirma.tld" geändert,
dieser Eintrag zeigt auf meinen Mailserver, DNS funktioniert.
Somit findet nun ein Interner Client den Server und Autodiscover
funktionert.....
Zumindest bei mir....
Schöne Restwoche
Kay
schon verstanden... war ja keine Kritik oder sonst etwas... wollte damit auch nur sagen, dass ich die URL geprüft habe und die nach wie vor stimmt... glaub mir ... ich hätte mich gefreut, wenn es damit behoben wäre.Echt extrem komisch -.- Office 2010 frisst es ohne Problem... klar ich könnte damit die Migration zumindest auf Exchange 2016 machen und würde vermutlich sogar funktionieren... was aber, wenn ich danach das Office gegen eine höhere Variante tauschen muss, weil Exchange 2019 eben nicht mit Office 2010 kann... dann stehe ich vermutlich vor dem gleichen Problem und dann ist das eben kein Vergleich mehr...
Hallo zusammen,
ich habe jetzt neue Erkenntnisse, mit denen ich allerdings wenig anfangen kann und langsam verzweifel, aber vielleicht könnt Ihr mir hier auf die Sprünge helfen.
Ich habe jetzt x-Versuche und Varianten probiert, wie ich es zum Laufen bekommen habe und zwar scheint EIN einziger DC verantwortlich zu sein. Und wie immer... der letzte DC, den ich dazu genommen habe war schuld.
Noch einmal zusammenfassend:
Aufgabe: Migration Exchange 2010 erst einmal auf 2016 und später 2019... ist aus meiner Sicht normal kein Problem
Vorgehen: den DC in der gleichen Site mit allen FSMO und GC in eine Testumgebung gepackt und den Exchange 2010 dazu
Client ebenfalls installiert einmal mit Office 2010 und der andere mit Office 2013. Office 2010 funktioniert problemlos... 2013 eben nicht.
Für meinen Test habe ich "ursprünglich" den DC genommen, der alle FSMO Rollen hatte inkl. Zertifizierungsstelle, das hatte eben zu dem negativen Ergebnis geführt. Dieser ist wie der Exchange in der gleichen Site! Er ist ebenfalls (wie alle DCs) GlobalCatalog, ergo hätte es aus meiner Sicht zu 100% funktionieren müssen.
Danach habe ich den zweiten DC in der gleichen Site hinzu genommen, ebenfalls erfolglos. Abschließend habe ich meine Testumgebung mit ein weiteren Subnet (Site in der der andere DC in der anderen Lokation steht) mit aufgenommen und danach ging es.
repadmin /kcc und syncall ist immer sauber durchgelaufen. DNS sieht für mich auch zu 100% identisch und funktionierend aus... meinem Kenntnisstand nimmt der Exchange auch den GC aus seiner Site... aber irgendwie scheint es doch einen Grund zu geben, warum er unbedingt DIESEN DC aus der anderen Site haben möchte.
Vielleicht noch als Hintergrund... alle DCs wurden vor knapp einem Monat von Server 2016 auf Server 2019 umgezogen wobei der DC, der anscheinend zwingend benötigt wird der erste DC war, der auf 2019 umgezogen wurde. Unser vorgehen hierbei war: Rollen, sofern vorhanden umziehen, wobei dieser KEINE hatte und nur GC hatte, Herunterstufen, AD-Dienste deinstallieren... aus der Domäne nehmen. Frisch installieren... AD Dienste installieren und eben hochstufen. Hat alles auch sauber geklappt, nur dass wir am Anfang übersehen hatten, dass er sich selbst als DNS mit der 127.0.0.1 drin hatte, ergo haben wir das ausgetauscht zu seiner IP.
Jetzt ist die Frage... WAS zur Hölle hat der DC, was die anderen nicht haben? Ich verzweifel noch... weil ohne, dass ich Gewissheit habe, was hier los ist... obwohl alles grün ist... will ich eigentlich keine Migration machen vor allem kommt noch ein Problem auf uns zu... der Standort wird definitiv in 2 Jahren abgebaut... ergo... dann wäre auch dieser DC NICHT mehr existent... und dann hätten wir ein richtiges Problem, wenn eben das eine jene welche fehlt, was anscheinend dringend benötigt wird.
Ich bin echt um jeden Rat dankbar.
Gruß Mike
ich habe jetzt neue Erkenntnisse, mit denen ich allerdings wenig anfangen kann und langsam verzweifel, aber vielleicht könnt Ihr mir hier auf die Sprünge helfen.
Ich habe jetzt x-Versuche und Varianten probiert, wie ich es zum Laufen bekommen habe und zwar scheint EIN einziger DC verantwortlich zu sein. Und wie immer... der letzte DC, den ich dazu genommen habe war schuld.
Noch einmal zusammenfassend:
Aufgabe: Migration Exchange 2010 erst einmal auf 2016 und später 2019... ist aus meiner Sicht normal kein Problem
Vorgehen: den DC in der gleichen Site mit allen FSMO und GC in eine Testumgebung gepackt und den Exchange 2010 dazu
Client ebenfalls installiert einmal mit Office 2010 und der andere mit Office 2013. Office 2010 funktioniert problemlos... 2013 eben nicht.
Für meinen Test habe ich "ursprünglich" den DC genommen, der alle FSMO Rollen hatte inkl. Zertifizierungsstelle, das hatte eben zu dem negativen Ergebnis geführt. Dieser ist wie der Exchange in der gleichen Site! Er ist ebenfalls (wie alle DCs) GlobalCatalog, ergo hätte es aus meiner Sicht zu 100% funktionieren müssen.
Danach habe ich den zweiten DC in der gleichen Site hinzu genommen, ebenfalls erfolglos. Abschließend habe ich meine Testumgebung mit ein weiteren Subnet (Site in der der andere DC in der anderen Lokation steht) mit aufgenommen und danach ging es.
repadmin /kcc und syncall ist immer sauber durchgelaufen. DNS sieht für mich auch zu 100% identisch und funktionierend aus... meinem Kenntnisstand nimmt der Exchange auch den GC aus seiner Site... aber irgendwie scheint es doch einen Grund zu geben, warum er unbedingt DIESEN DC aus der anderen Site haben möchte.
Vielleicht noch als Hintergrund... alle DCs wurden vor knapp einem Monat von Server 2016 auf Server 2019 umgezogen wobei der DC, der anscheinend zwingend benötigt wird der erste DC war, der auf 2019 umgezogen wurde. Unser vorgehen hierbei war: Rollen, sofern vorhanden umziehen, wobei dieser KEINE hatte und nur GC hatte, Herunterstufen, AD-Dienste deinstallieren... aus der Domäne nehmen. Frisch installieren... AD Dienste installieren und eben hochstufen. Hat alles auch sauber geklappt, nur dass wir am Anfang übersehen hatten, dass er sich selbst als DNS mit der 127.0.0.1 drin hatte, ergo haben wir das ausgetauscht zu seiner IP.
Jetzt ist die Frage... WAS zur Hölle hat der DC, was die anderen nicht haben? Ich verzweifel noch... weil ohne, dass ich Gewissheit habe, was hier los ist... obwohl alles grün ist... will ich eigentlich keine Migration machen vor allem kommt noch ein Problem auf uns zu... der Standort wird definitiv in 2 Jahren abgebaut... ergo... dann wäre auch dieser DC NICHT mehr existent... und dann hätten wir ein richtiges Problem, wenn eben das eine jene welche fehlt, was anscheinend dringend benötigt wird.
Ich bin echt um jeden Rat dankbar.
Gruß Mike
Hallo zusammen,
scheint gelöst zu sein.
Falls wer mal in eine gleiche Situation kommt... warum auch immer keine Fehler kamen bei repadmin /syncall und kcc so lag es wohl doch an der Synchronisierung der DCs...
Nachdem ich ja wusste, dass ein DC wohl etwas hat, was die anderen nicht haben, so habe ich unter AD Standort und Dienste --> Standort ---> Server --> NTDS die Verbindungen alle einmal gelöscht bei allen DCs (Testumgebung), wurden mal manuell eingerichtet und habe sie "automatisch" neu anlegen lassen.
Nachdem eine Nacht durch war, habe ich bei allen Server kontrolliert, ob alle Verbindungen automatisch wieder hergestellt waren, was auch der Fall war... Danach wollte ich wissen, ob alles wieder funktionieren würde, auch ohne DIESEN jene welchen DC, also habe ich diesen heruntergestuft... komplett aus der Domäne genommen und komplett ausgeschalten, sodass nur noch zwei DCs übrigen sind, mit denen es vorher NICHT ging... und siehe da... GEHT!
Danke trotzdem für die Unterstützung... fragt sich nur, warum die Synchronisierung angeblich funktioniert, obwohl es nicht komplett der Fall war... sei es drum... bin froh, dass es nun geht und ich die Testmigration durchführen kann.
scheint gelöst zu sein.
Falls wer mal in eine gleiche Situation kommt... warum auch immer keine Fehler kamen bei repadmin /syncall und kcc so lag es wohl doch an der Synchronisierung der DCs...
Nachdem ich ja wusste, dass ein DC wohl etwas hat, was die anderen nicht haben, so habe ich unter AD Standort und Dienste --> Standort ---> Server --> NTDS die Verbindungen alle einmal gelöscht bei allen DCs (Testumgebung), wurden mal manuell eingerichtet und habe sie "automatisch" neu anlegen lassen.
Nachdem eine Nacht durch war, habe ich bei allen Server kontrolliert, ob alle Verbindungen automatisch wieder hergestellt waren, was auch der Fall war... Danach wollte ich wissen, ob alles wieder funktionieren würde, auch ohne DIESEN jene welchen DC, also habe ich diesen heruntergestuft... komplett aus der Domäne genommen und komplett ausgeschalten, sodass nur noch zwei DCs übrigen sind, mit denen es vorher NICHT ging... und siehe da... GEHT!
Danke trotzdem für die Unterstützung... fragt sich nur, warum die Synchronisierung angeblich funktioniert, obwohl es nicht komplett der Fall war... sei es drum... bin froh, dass es nun geht und ich die Testmigration durchführen kann.
