Da ist er, der Exchange 2019. Ich habe ihn mal in meiner Umgebung Zuhause installiert und getestet 🙂

 

Vorraussetzungen:

Exchange 2019, was brauchs zum laufen? Kurzfassung, wer die letzten Jahre fleißig geupdate hat, hat kaum Probleme, alle Exchange 2010 Betreiber müssen ein bisschen was nachholen.

 

• Betriebssystem

Man beachte die Hinweise/Empfehlungen 🙂

• Active Directory

• Exchange Coexistenz

• Clients

Installation:

• .NET Framework 4.7.2
• Visual C++ Redistributable Package für Visual Studio 2013
• Unified Communications Managed API 4.0 Runtime 
• Windows Server 2019 Features (Für Desktop)

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

• Active Directory: Schema und Domänen vorbereiten

 

Da Windows Server 2019 zum aktuellen Zeitpunkt nicht mehr zum Download bereit stand, habe ich probiertExchange 2019 einfach mal auf Windows Server 2016 zu installieren.
Jedoch weigerte sich das Setup dagegen..

Zum Glück konnte ich einen Kollegen finden, der Server 2019 vor dem rückzieher von Microsoft schon heruntergeladen hatte 🙂

Also erstmal noch fix eine Windows Server 2019 VM erstellt – es hat sich zu Server 2016 nicht wirklich viel verändert – nur booten tut Server 2019 extrem schnell!

 

Danach weiter mit dem Exchange 2019 Setup:

Die weiteren Steps unterscheiden sich nicht zu den vorherigen Versionen.

 

 

Ich habe auf meinem Exchange 2013 vorher Organisationsweit “MapiHttp” deaktiviert um einmal zu schauen, was bei dem Setup von Exchange 2019 passiert. Anderst als Exchange 2013 und Exchange 2016 unterstüzt Exchange 2019 keine Outlook Anywhere (RPC/HTTP), sondern nur noch MAPI/HTTP.

Und siehe da, das Setup prüft dies ab und gibt. ggf. eine Warnung aus. Also vorher noch aktivieren 😉

 

Test:

• Anpassungen Exchange 2019

Die Anpassungen der virtuellen Verzeichnisse etc. hat ohne Probleme funktioniert. Lediglich der Exchange Server hat etwas Performance Probleme gehabt. Ich habe die VM in meiner Demo Umgebung mit 2vCPU und 6GB am laufen gehabt. Das reicht dem Exchange 2013 ohne Probleme aus. Dem Server 2019 mit Exchange 2019 ist dies auf jedenfall zu wenig, also habe ich mal auf 8GB RAM erhöht mal schauen, ob das für eine minimal Umgebung reicht 😉

• Zugriffe

Zuerst habe ich einmal die Anbindung von intern und extern  (reverse proxy Sophos UTM) von dem Exchange 2013 auf den Exchange 2019 angepasst.

Die Zugriffe von intern und extern mit Outlook und einem iOS Gerät auf das Postfach auf dem Exchange 2013 haben ohne Probleme funktioniert.

• Postfach Move Nummer 1

Der erste Postfach Move war etwas holprig. Mein Postfach hat sich bis 95% Problemlos gesynct, stand danach jedoch auf einem Fehler.

 

 

Es war jedoch nichts schlimmes ersichtlich:

 

 

 

Scheinbar wurde der Job wirklich wegen dem Fehler nicht ausgeführt:

 

Ich musste den Move dann manuell abschließen:

 

 

• Postfach Move Nummer 2

Den gleichen Fehler wie bei Move Nummer 1.

 Email migration failed for this user because the subscription was suspended externally to the Migration Service

Sehr komisch.

 

• Postfach auf Exchange 2019

Die ersten Tests haben soweit alle funktioniert. Alles weitere wird sich die nächsten Tage zeigen 🙂

Was auf jedenfall schon einmal positiv auffällt ist die verbesserte Suchfunktion – die Suche ist wirklich richtig schnell und genau.

Falls sich etwas negatives ergibt, werde ich ein kurzes Update posten.

 

 

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.

 

Bevor man mit der Installation und Migration beginnt, ist es empfehlenswert sich vorher einige Punkte anzuschauen:

• Coexistenz Vorrausetzungen überprüfen

https://technet.microsoft.com/de-de/library/aa996719(v=exchg.160).aspx

• Source Exchange Server Build Numbers überprüfen

https://technet.microsoft.com/de-de/library/hh135098(v=exchg.150).aspx

z.B. für Exchange 2010

Get-Command ExSetup | ForEach {$_.FileVersionInfo}

Output:

ProductVersion FileVersion FileName
————– ———– ——–
14.03.0266.001 14.03.0266.001 C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

• vorhandene Domänencontroller Betriebssystem Version
• vorhandenes Active Directory Gesamtstruktur Funktionsebene
• Vorhandene Outlook Client Versionen ( oder andere E-Mail Programme )
• Client Proxy ( Proxy genutzt? Ausnahmen per GPO verteilt?)
• Exchange Anbindung von extern ( reverse Proxy vorhanden ? )
• E-Mail routing ( SMTP Gateway vorhanden ?, Sende+Empfangsconnectoren )
• Vorhandenes Zertifikat(e)
• Aktueller Namespace aufbau der Exchange Verzeichnisse ( internalurl / externalurl entscheident )

get-webservicesvirtualdirectory -Server Servername

get-oabvirtualdirectory -Server Servername

get-owavirtualdirectory -Server Servername

get-ecpvirtualdirectory -Server Servername

get-activesyncvirtualdirectory -Server Servername

get-OutlookAnywhere -Server Servername

( get-MapiVirtualDirectory -Server Servername – erst ab EX 2013 interessant 🙂 )

Get-ClientAccessServer Servername   ( hier ist AutoDiscoverServiceInternalUri interessant und ggf. auch der AutoDiscoverSiteScope )

• Internes DNS Aufbau (Split DNS? PinPointed DNS?)
• Fax Anbindung
• Drittanbieter Anwendungen Anbindung
• E-Mail Archivierung
• E-Mail Signatur
• UM Funktionen
• Datenbank Anzahl und Größe, Postfächer Anzahl
• Öffentliche Ordner ( ab 2013 nicht mehr so dramatisch 🙂 )

Mir ist jetzt schon seit mehreren Exchange 2016 Versionen ( CU 4 bis CU 7 ) während der Migration passiert, dass nach einem erfolgreichem Mailbox Move  Outlook nach dem neustart ( Ihr Exchange Administrator hat … 🙂 ) sich nicht zum Exchange 2016 verbindet.

Prüft man den Client mit dem Autokonfiguration Test passiert folgendes:

Die Verbindung zum SCP scheitert…

Ein XML File gibt es dadurch auch nicht…

 

Lösung:

Warten, oder im IIS den “MSExchangeAutodiscoverAppPool”  rechtsklick recyceln ( Wiederverwenden )

Danach klappts auch wieder mit dem Autodiscover und der Outlook Client kann sich verbinden.