Koexistenz Probleme mit Exchange 2010 und 2013 bis 2016

Verschiedene Konstellationen die zu Problemen beim Clientzugriff während der Koexistenz von Exchange 2010 und 2013 bis 2016 führen können.

Da ein Großteil unserer (Neu) Kunden jetzt so langsam anfängt Ihre Exchange Server 2010 in den wohlverdienten Ruhestand zu schicken stolpern diese, oder auch ich, immer mal wieder über entsprechende Konfigurationsfehler. Hier mal ein Überblick, was wie zu Problemen führt und wie diese beseitigt werden:

Client Access Array zeigt auf OWA, ECP, EWS URLs und / oder Outlook Anywhere Host (https://blogs.technet.microsoft.com/exchange/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations/):

  1. Den Link bitte aufmerksam lesen! Wer möchte darf auch noch das und das lesen. 🙂
  2. Die Lösung umsetzen und intern sowie extern per Outlook Anywhere mit dem Exchange verbinden
Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

Sollte das, warum auch immer, nicht möglich sein, wäre ein anderer Schritt eine weitere Datenbank anzulegen und dort den RpcClientAccessServer auf den Exchange selber zeigen zu lassen sowie im Anschluss die Postfächer in die neue Datenbank zu verschieben. Sobald die User sich mit Outlook in der neuen DB verbunden haben, können diese weiter auf den neuen Exchange Server verschoben werden.

New-MailboxDatabase "Name_der_Datenbank"
Set-MailboxDatabase "Name_der_Datenbank" -RpcClientAccessServer Name_des_Exchange_2010
Get-Mailbox -Server Exchange_2010 | New-MoveRequest -TargetDatabase "Name_der_Datenbank"

Achtung: Speicherplatz beachten! Bzw. vorher gründlich planen. 😉

Die nächste Alternative wäre das ClientAccessArray aus den bestehenden Datenbanken zu entfernen und zu löschen. Sollte Autodiscover nicht funktionieren, müssen alle Outlook Profile von Hand neu eingerichtet werden. Aber Achtung: Auch wenn Autodiscover funktioniert, ist die Chance sehr hoch, dass viele Outlook Profile von Hand neu konfiguriert werden müssen!

Outlook Web App (OWA) Proxy von Exchange Server 2016 / 2013 zu Exchange 2010 ohne Funktion (:-( Da hat etwas nicht geklappt.):

Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.
Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.

Hier ist mir eben grade noch eine HTTP -> HTTPS Weiterleitung bzw. eine Umleitung auf /owa auf die Füße gefallen. Entsprechende Umleitungen können an diversen Stellen konfiguriert sein:

  1. In C:\inetpub\wwwroot\ die „iisstart.htm“ macht ein <META> Redirect.
    Lösung: Am besten die Standard iisstart.htm wieder bereitstellen oder eine leere.
  2. Eine „web.config“ mit entsprechende Umleitung / entsprechenden Umleitungen in C:\inetpub\wwwroot
    Lösung: web.config aus dem Verzeichnis verschieben. Bzw. Backup erstellen und löschen.
  3. HTTP-Umleitung im Internetinformationsdienste (IIS)-Manager (inetmgr)
    Lösung: HTTP-Umleitung im „inetmgr“ deaktivieren

Neben dem Umleitungs-Problem kann es ebenfalls noch ein Berechtigugnsproblem auf dem virtullen Verzeichnis für ECP und / oder OWA sein:

  1. Internetinformationsdienste (IIS)-Manager (inetmgr) starten und unter der „Default Web Site“ im „ecp“ und „owa“ Verzeichnis prüfen, ob die Windows-Authentifizierung aktiviert ist. Falls nicht, diese aktivieren und im rechten Teil in den „Aktionen“ unter „Anbieter…“ sicherstellen, dass „NTLM“ und „Negotiate“ ausgewählt sind. Siehe Bilder:

Kein Zugriff auf Verschobene Mailboxen (Der Informationsspeicher steht zurzeit nicht zur Verfügung) :

Die beschriebenen OWA (Outlook Web App) Probleme können ebenfalls die Ursache dafür sein, dass ein Zugriff mit Outlook auf ein bereits verschobenes Postfach per MAPI over HTTP bzw. Outlook Anywhere nicht möglich ist. Sollte es hier zu einem „komischen“ und „unerklärlichem“ Verhalten kommen, ggfs. die o.g. Schritte prüfen und durchführen. 🙂

Eine Weitere potenzielle Fehlerquelle könnten komplett vergessene öffentliche Ordner (Public Folders) oder eine nicht erstellte PFProxyMailbox sein (Siehe dazu: https://jans.cloud/2018/07/migration-von-exchange-2010-zu-2016/).

Kein Zugriff auf die öffentlichen Ordner auf dem Exchange 2010 (legacy Public Folder) mit Postfach auf einem Exchange Server 2016:

  1. Autodiscover für die Proxy Mailbox funktioniert nicht -> Der Proxy Mailbox eine SMTP Adresse konfigurieren, für die die passenden Autodiscover Records existieren. Aus PFProxyMailbox@domain.local würde dann PFProxyMailbox@jans.cloud werden.
  2. Bei Postfächern mit Problemen die DefaultPublicFolderMailbox konfigurieren:  
Set-Mailbox Ali.Gator -DefaultPublicFolderMailbox PFProxyMailbox

Bei weiteren Problemen / Fehler, die mir über den Weg laufen, werde ich den Beitrag updaten. Generell kann es natürlich nie schaden -> RTFM! 🙂

Neues vom Exchange Server

Exchange Server 2016 CU11 veröffentlicht, neues zum .Net Framework 4.7.2 sowie ein paar Infos zu Exchange 2019

Exchange Server 2019:

  • Nur auf Windows Server 2019 (Core oder GUI) freigegeben / Mangament Tools ebenfalls auf Windows 10 64 Bit
  • Mindestens den Active Directory Forest Functional Level „Windows Server 2012 R2“ (oder eben höher)
    Daraus ergibt sich, dass die Domain Controller zwangsweise mindestens Windows Server 2012 R2 oder neuer sein müssen
  • .Net Framework 4.7.2:
  • Visual C++ 2012 Runtime für alle Server-Rollen: https://www.microsoft.com/de-DE/download/details.aspx?id=30679
  • Visual C++ 2013 Runtime für die Mailbox-Server-Rolle: https://www.microsoft.com/de-DE/download/details.aspx?id=40784
  • Outlook Clients von 2013 bis 2019
  • Koexistenz mit nur mit Exchange Server 2013 CU21 sowie Exchange 2016 CU11 oder neuer

Exchange Server 2016:

  • Download des Kumulativen Update 11 für Exchange Server 2016: https://www.microsoft.com/de-DE/download/details.aspx?id=57388
  • Alle Exchange Server 2016 CU11 Rollen benötigen jetzt die Visual C++ 2012 Runtime (Link siehe oben)
    Der Exchange Team Blog rät dringendst dazu, die Visual C++ 2012 Runtime vor einem Update auf CU11 oder neuer von Hand zu installieren:

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 11 or later for the first time on an existing server. The setup pre-requisite rule works as expected when using Cumulative Update 11 or later to install a new server using the Cumulative Update 11 or later package.

https://blogs.technet.microsoft.com/exchange/2018/10/16/released-october-2018-quarterly-exchange-updates/
  • Server mit dem CU11 und installierter Mailbox Rolle benötigen ebenfalls die Visual C++ 2013 Runtime (Link siehe oben)
  • Ebenfalls unterstützt Exchange 2016 CU11 jetzt auch das .Net Framework 4.7.2. Ebenfalls wird das .Net Framework 4.7.2 ab dem CU13 im Juni 2019 zur Vorraussetzung.

Exchange 2013:

  • Exchange Server 2013 CU21 hat im Nachgang ebenfalls Support für das .Net Framework 4.7.2 erhalten!

Für den fleißigen Exchange Admin, der zeitnah auf Exchange 2016 CU11 oder Exchange 2019 RTM geht, heißt es dann auch schon „Frohe Weihnachten“. Die nächsten geplanten Kumulativen Updates (CU12 für Exchange Server 2016) sowie das Exchange Server 2019 CU1 erscheinen erst im März 2019.

Exchange Server 2019 Preview verfügbar

Am 24.07.2018 wurde die Exchange Server 2019 Preview für die Allgemeinheit veröffentlicht.

Da es grade sehr heiß ist und in der Ferienzeit scheinbar alle im Urlaub sind, habe ich meine riesige Exchange Demoumgebung doch direkt einmal auf die Exchange Server 2019 Preview upgedatet. 🙂

Bei der Installation in die bestehende Exchange Organisation hat sich im Vergleich zu den letzten beiden Exchange Versionen eigentlich wenig getan. Die Vorraussetzungen sind ebenfalls nahezu geich geblieben und wären namentlich:

Eine kleine (ggfs. wichtige) Änderung betrifft das Forest Functional Level der Gesamtstruktur. Dieses muss mindestens auf das Forest Functionality Level Server 2012 R2 angehoben werden!

Getreu dem Dinner for one Motto „The same procedure as every year“ sieht das GUI Setup dem der alten Versionen ziemlich ähnlich. Damit alle beruhigt sind, bei der Installation per Commandline hat sich auch nichts getan.

Nach der Installation geht es ebenfalls ziemlich genau so weiter wie bei einer Migration von Exchange 2013 auf 2016:

#Auslesen der Exchange Server
$Exch2016 = Get-ExchangeServer | ? AdminDisplayVersion -match "Version 15.1"
$Exch2019 = Get-ExchangeServer | ? AdminDisplayVersion -match "Version 15.2"
#Auslesen des konfigurierten SplitDNS FQDNs
$vDirHost = $(Get-OwaVirtualDirectory -Server $Exch2016).InternalURL.Host
 
#Mailboxdatenbanken auf dem Exchange 2019 trennen
Get-MailboxDatabase -Server $Exch2019 | Dismount-Database -Confirm:$false
#Mailboxdatenbanken umbenennen, verschieben und einbinden
foreach ($DB in $(Get-MailboxDatabase -Server $Exch2019)) { $i = $i + 1; Set-MailboxDatabase -Identity $DB -Name Exch2019DB0$i; Move-Databasepath -Identity $DB -edbfilepath "D:\ExchangeDB\Exch2019DB0$i\Exch2019DB0$i.edb" -logfolderpath "D:\ExchangeLOG\Exch2019DB0$i" -confirm:$false; Mount-Database -Identity Exch2019DB0$i -confirm:$false }
 
#Neuen Receiveconnector "Internet" erstellen und in meinem Fall der Firewall erlauben anonym Mails einzuliefern
New-ReceiveConnector -Name "Internet" -Usage Custom  -TransportRole FrontendTransport -PermissionGroups AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIpRanges $((Get-NetRoute -ifIndex $(Get-NetIPAddress -InterfaceAlias "LAN" -AddressFamily "IPv4").ifIndex | ? DestinationPrefix -eq "0.0.0.0/0").NextHop)
#Dem Sendeconnector "Internet" den neuen Exchange hinzufügen
Get-SendConnector -Identity "Internet" | Set-SendConnector -SourceTransportServers $Exch2016, $Exch2019
 
#IMAP und POP Zertifikats CN anpassen, da ich ein Wildcard Zertifikat nutze
Set-ImapSettings -Server $Exch2019 -X509CertificateName $vDirHost
Set-PopSettings -Server $Exch2019 -X509CertificateName $vDirHost
 
# IMAP und POP Dienste neu starten
Restart-Service MSExchangeIMAP4BE
Restart-Service MSExchangeImap4
Restart-Service MSExchangeIMAP4BE
Restart-Service MSExchangePop3
 
#Virtuelle Verzeichnisse konfigurieren
Get-OwaVirtualDirectory -Server $Exch2019 | Set-OwaVirtualDirectory -InternalUrl "https://$vDirHost/owa" -ExternalUrl "https://$vDirHost/owa"
Get-EcpVirtualDirectory -Server $Exch2019 | Set-EcpVirtualDirectory -InternalUrl "https://$vDirHost/ecp" -ExternalUrl "https://$vDirHost/ecp"
Get-OABVirtualDirectory -Server $Exch2019 | Set-OABVirtualDirectory -InternalURL "https://$vDirHost/OAB" -ExternalURL "https://$vDirHost/OAB"
Get-ActiveSyncVirtualDirectory -Server $Exch2019 | Set-ActiveSyncVirtualDirectory -InternalURL "https://$vDirHost/Microsoft-Server-ActiveSync" -ExternalURL "https://$vDirHost/Microsoft-Server-ActiveSync"
Get-WEbServicesVirtualDirectory -Server $Exch2019 | Set-WEbServicesVirtualDirectory -InternalURL "https://$vDirHost/EWS/Exchange.asmx" -ExternalURL "https://$vDirHost/EWS/Exchange.asmx"
Get-MapiVirtualDirectory -Server $Exch2019 | Set-MapiVirtualDirectory -InternalURL "https://$vDirHost/mapi" -ExternalURL "https://$vDirHost/mapi"
Get-ClientAccessService -Identity $Exch2019.Name | Set-ClientAccessService -AutodiscoverServiceInternalUri https://$vDirHost/autodiscover/autodiscover.xml
Get-OutlookAnywhere -Server $Exch2019 | Set-OutlookAnywhere -ExternalHostname $vDirHost -InternalHostname $vDirHost -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod "Ntlm"
 
#Zertifikatskette und eigentliches Wildcard Zertifikat aus C:\Install\Zertifikate einlesen
$Zertifikat = (Get-ChildItem -Path C:\Install\Zertifikate\1Comodo_RootCA.crt)
$Zertifikat | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root | Out-Null
$Zertifikat = (Get-ChildItem -Path C:\Install\Zertifikate\2Comodo_Intermediate_1.crt)
$Zertifikat | Import-Certificate -CertStoreLocation Cert:\LocalMachine\CA | Out-Null
$Zertifikat = (Get-ChildItem -Path C:\Install\Zertifikate\3Comodo_Intermediate_2.crt)
$Zertifikat | Import-Certificate -CertStoreLocation Cert:\LocalMachine\CA | Out-Null
$Zertifikat = Import-pfxCertificate -FilePath "C:\Install\Zertifikate\04Wildcard.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password $(ConvertTo-SecureString "Kennwort1" -AsPlainText -Force)
Enable-ExchangeCertificate -Thumbprint $Zertifikat.Thumbprint -Services IIS, IMAP, POP, SMTP -Force -Confirm:$false
 
#An dieser Stelle wäre es Zeit die IP Adresse im DNS von $vDirHost auf den neuen Exchange Server zu schwenken
#Sowie den DNS Cache am Server sowie Client zu löschen
#Sowie einen heißen, schwarzen Kaffee zu trinken!
 
#Migrations Mailbox verschieben
#https://technet.microsoft.com/en-us/library/mt441791(v=exchg.150)
Get-Mailbox -Identity Migration* -Arbitration | New-MoveRequest -TargetDatabase Exch2019DB01
 
#Test User verschieben
New-MoveRequest Toni.Test -TargetDatabase Exch2019DB01
 
#Outlook testen... Outlook kann während dem gesamten Verschiebevorgang offen sein. Nach Abschluss ist ebenfalls kein Neustart mehr notwendig
 
#Arbitration Postfächer, alle anderen Postfächer und die öffentlichen Ordner Postfächer verschieben
Get-Mailbox -Server $Exch2016 -Arbitration | New-MoveRequest -TargetDatabase Exch2019DB01
Get-Mailbox -Server $Exch2016 | New-MoveRequest -TargetDatabase Exch2019DB01
Get-Mailbox -PublicFolder | New-MoveRequest -TargetDatabase Exch2019DB01
Get-Mailbox -AuditLog | New-MoveRequest -TargetDatabase Exch2019DB01
 
#Aufräumen
Get-MoveRequest | Remove-MoveRequest -Confirm:$false
 
#Exchange 2016 deinstallieren

Aufgrund des Hinweises von Sebastian Röhner im Kommentar, habe ich die Umgebung noch einmal neu aufgebaut und die Mailbox eines Testusers direkt verschoben ohne vorher das Migrationspostfach (Migration Mailbox) zu verschieben. Was soll ich sagen, es hat erneut ohne Probleme funktionert. Dennoch werde ich in Zukunft wohl den Microsoft-Weg, wie in https://technet.microsoft.com/en-us/library/mt441791(v=exchg.150) beschrieben gehen. Daher ist das Script auch ein wenig ergänzt worden.

Nochmals ein „Danke“ an Sebastian Röhner für den Hinweis!

MoveRequest MigrationMailbox
MoveRequest MigrationMailbox

Da bleibt ja eigenltich nur die Frage nach den Änderungen oder Neuerungen… Auf den ersten Blick wären da:

  • Support von Windows Server 2016 (2019 vermutlich auch?) Core
  • Einem in der Preview nicht funktionierenden SSD Cache
  • Indexierung nicht mehr im Dateisystem sondern in der Datenbnak
  • Unterstützung von 48 Prozessoren und 256GB RAM
  • Es gibt keine UM (Unified Messaging) Rolle mehr mit Exchange 2019