– Jan's Cloud – online Gedankenstütze ;)

1. August 2018

Exchange Server 2019 Preview verfügbar

Filed under: Exchange,PowerShell,Windows Server — Schlagwörter: , , , — Jan Mischo @ 14:37

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
halo i bims exchange server 2019 preview

halo i bims exchange server 2019 preview

 

2 Comments »

  1. Meines Erachtens hat die Anleitung einen Fehler, die Arbitration Mailboxen (gerade die für Migration) muss vor der Postfachmigration erfolgen, sonst kommt kein Benutzerpostfach am Exchange Server 2019 an.
    Der Testuser dürfte sich eigentlich nicht verschieben lassen.

    Auch müsste der Befehl meiner Meinung nach anders lauten:

    Get-ClientAccessService -Identity $Exch2019.Name | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://$vDirHost/autodiscover/autodiscover.xml
    –>
    Get-ClientAccessService -Identity $Exch2019.Name | Set-ClientAccessService -AutodiscoverServiceInternalUri https://$vDirHost/autodiscover/autodiscover.xml

    Kommentar by Sebastian Röhner — 6. August 2018 @ 18:56

  2. Hi,

    ich habe grade mal nachgesehen und https://technet.microsoft.com/en-us/library/mt441791(v=exchg.150).aspx gefunden. Da steht in der Tat, dass zumindest die Migration-Mailbox zuerst verschoben werden muss. Bislang habe ich immer erst eine Test-Mailbox verschoben, dann die Arbitration und dann den Rest. Ich erstelle grade eine neue Umgebung und teste das nochmal durch.

    Mit dem ClientAccessService hast du vollkommen recht. Habe bis vor dem Post an beiden Stellen mit dem *-ClientAccessServer „gearbeitet“. Aber der ist ja mittlerweile deprecated. Da habe ich vergessen den „Set-“ Befehl anzupassen.

    Danke für die Hinweise!

    Gruß
    Jan

    Kommentar by Jan Mischo — 7. August 2018 @ 06:57

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress