Bevor ihr den Beitrag hier lest, empfehle ich euch die Beiträge aus der Kategorie “Microsoft Exchange Server Basics“.

Vor der Migration

Die Zeichnung zeigt den internen Verbindungsaufbau bei einer Exchange 2010 Umgebung mit einem Exchange Server ( HUB, Mailbox und CAS Rolle ) vor dem Migrations beginn.

 

Es gibt einen Exchange 2010 Server ( Name “jr-legacy-ex01” mit der IP 172.16.20.11 ). Der Exchange 2010 Server muss für eine Co Existenz mit Exchange 2016 mindestens SP3 Updaterollup 11 installiert haben.

Der Exchange Server nutzt für die virtuellen Verzeichnisse als -internalurl und -externalurl den gleichen DNS Namen. Im SCP ( -internaluri ist “autodiscover.rehbergerold.de” hinterlegt )

Als RpcClientAccessServer ist der FQDN vom Exchange Server hinterlegt. Ein ClientAccessArray ist nicht definiert.

Achtung! Dieser Name darf extern im DNS nicht auflösbar sein. Mehr Infos dazu hier: https://blogs.technet.microsoft.com/exchange/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations/

Auf dem DNS Server ist ein Split DNS angelegt. Die URL “mail.rehbergerold.de” und “autodiscover.rehbergerold.de” zeigen auf den Exchange 2010 ( jr-legacy-ex01)

 

Auf den Exchange ist ein Zertifikat von der internen Zertfizierungsstelle hinterlegt.

Der CAS Server ist der internen Active Directory Site zugwiesen.

 

Installation Exchange 2016

Nachdem das Schema und Domäne für den Exchange 2016 vorbereitet wurde, kann man mit der Installation beginnen.

Was passiert nun?

Der Exchange Server wird der Exchange Organisation hinzugefügt und direkt wie ein Familien Mitglied behandelt, es wird also fleißig untereinander kommuniziert.

Die Installation erstellt einen SCP für den Exchange 2016, definiert die virtuellen Verzeichnisse mit den FQDN des Exchange 2016 und hinterlegt ein selbstsigniertes Zertifikat.

Nun kann es passieren, dass der Outlook Client in ein Autodiscover Update Interval läuft, oder gerade jemand Outlook startet und dadurch der SCP von dem Exchange 2016 genutzt wird – “graue Striche”, anstelle dem des Exchange 2010 ( eigentlich soll der Outlook Client den ältestens SCP nutzen – sprich der von dem Exchange 2010 – aber so wirklich 100%tig bestätigen konnte ich das noch nicht 🙂 ).

Das ist blöd, da der User dann eine Zertifikats Warnung bekommt, da er dem Selbstsignierten Zertifikat nicht traut.

Dies lässt sich aber verhindern. Ich habe schon Blog Einträge gelesen, die empfohlen haben währen der Installation den erstellen SCP händisch im Active Directory zu löschen. Das würde ich jetzt nicht bevorzugen scheint aber wohl zu funktionieren..

Man könnte auch eine eigene Site im Active Directory definieren, aber am einfachsten finde ich immer noch -> vorbereitet sein und direkt nachdem die installation fertig ist den SCP abzuändern, sodass er die gleiche URL nutzt wie der Exchange 2010 – siehe Bild unten “graue Striche”.

So frägt der Client zwar den SCP von dem Exchange 2016 an, aber dieser hat nun “autodiscover.rehbergerold.de” hinterlegt, sodass der Client diesen Namen auflöst und dieser hat ja noch als Ziel den Exchange 2010 im DNS hinterlegt.

Man kann nun also in Ruhe auf dem Exchange 2016 die -internalUrl´s und -externalUrl´s definieren und ein neues Zertifikat einspielen ohne das die User etwas davon mitbekommen.

 

Test Verbindung zu Exchange 2016

Nun kann man die Verbindungen von einem Test Client einmal zu dem Exchange 2016 lenken.

Dazu einfach die Host Datei anpassen und die Adressen umleiten – in diesem Beispiel “mail.rehbergerold.de” und “autodiscover.rehbergerold.de” auf die 172.16.20.12 abändern.

Autodisocover etc. sollte keine Zertifikatswarnungen geben und EX2016 OWA Zugriff sollte auf das Postfach welches noch auf dem EX2010 liegt funktionieren.

Solange das Postfach noch auf dem Exchange 2010 liegt wird weiterhin die RPC/TCP Verbindung direkt zum RpcClientAccessServer / CasArray aufgebaut.

RPC/HTTP ( Outlook Anywhere ) wird also noch nicht genutzt.

Desweiteren kann man auf dem Exchange 2016 ein Postfach erstellen, das direkt in der neuen EX2016 Datenbank platziert wird. Mit dem Testclient kann man dann testen, ob RPC/HTTP ( Outlook Anywhere ) funktioniert.

Funktioniert soweit alles wie gewohnt, kann das DNS für alle angepasst werden.

Zudem kann die Verbindung von extern auch auf den Exchange 2016 geleitet werden.

 

Erster Mailbox Move

Exchange 2016 ( oder auch 2013 ) können keine RPC/TCP Verbindungen mehr aufbauen. Daher wird der Outlook Client, wenn das Postfach verschoben ist RPC/HTTP ( Outlook Anywhere ) nutzen. Outlook Client Voraussetzungen / Update Anforderungen beachten!!

Was passiert nun bei dem Move?
Der Outlook Client merkt, das sich etwas verändert hat und bringt eine Meldung, das er neugestartet werden muss.

Nach dem Neustart ist in dem Outlook Profil nicht mehr der Exchange 2010 “RpcClientAccessServer” oder “ClientAccessArray” in den Einstellungen hinterlegt, sondern die Benutzer Postfach GUID ( Benutzer die PostfachGUID@domaine.com )

Wichtig! Es können nur Postfächer verschoben werden, wenn die DNS Einträge auf den EX2016 verweisen! Intern und Extern!

Danach mit dieser Mailbox Email Empfang und Email Versand testen, sowie ggf. Email Signatur o.ä. Anbindungen.

Allgemeiner Move

Ist der Test in Ordnung können alle weiteren Postfächer verschoben werden.