Bei der Installation neuer Exchange 2016 Server, etwa für die Migration, muss etwas behutsam vorgegangen werden. Exchange Server fühlen sich dazu berufen direkt nach der Installation auf Client Anfragen zu reagieren.
Hintergrund ist folgender:
Sobald ein neuer Exchange Server installiert wurde, werden auch SCP (Service Connection Point) Einträge im Active Directory erzeugt. Die SCP Einträge werden wiederrum von den Clients verwendet um Autodiscover zu finden und aufzurufen. Sobald ein Client den frisch installierten Exchange Server anspricht, bekommt er Zertifikatswarnung und versucht mit dem noch nicht fertig konfiguriertem Exchange Server zu sprechen. Dieses Verhalten resultiert daraus, dass sich bestehende und neue Exchange Server innerhalb des gleichen Active Directory Standortes befinden. In diesem Beispiel ist es der Standort „Default-First-Site-Name“:
Um dieses Problem zu umgehen gibt es mehrere Möglichkeiten, die sich allerdings im Aufwand und in den Anforderungen unterscheiden.
Lösung 1: Deployment Site für häufige Exchange Installationen
Diese Lösung eignet sich für alle die viele Exchange Server installieren müssen, also große Firmen, oder Firmen mit vielen verteilten Standorten. Diese Lösung erfordert einiges an Vorbereitung, ist aber sehr zuverlässig.
Nach dem Anlegen des neuen Standort sieht es in etwa so aus:
In diesem Subnetz sind nun die IPs 172.16.100.129 bis 172.16.100.134 zulässig (Dran denken: Netzadresse .128 und Broadcast Adresse ,135 nicht für Hosts verwenden)
Aber: Im neuen Standort gibt es, wie man auf dem Screenshot oben erkennen kann, keinen Domain Controller. Für die Exchange Installation wird allerdings ein Domain Controller im Standort vorausgesetzt. Exchange überprüft bei der Bereitschaftsprüfung vor der Installation ob an dem Standort ein Domain Controller zur Verfügung steht, ist das nicht der Fall kommt es zur folgenden Fehlermeldung:
Fehler:
Problem beim Überprüfen des Status von Active Directory: Für die Domäne ‚frankysweb‘ und den Standort ‚ExchangeInstall‘ sind keine Domänencontroller verfügbar. Im Exchange-Setupprotokoll finden Sie weitere Informationen zu diesem Fehler.
Weitere Informationen finden Sie unter: http://technet.microsoft.com/library(EXCHG.160)/ms.exch.setupreadiness.AdInitErrorRule.aspxFehler:
Active Directory ist nicht vorhanden, oder es kann keine Verbindung damit hergestellt werden.
Weitere Informationen finden Sie unter: http://technet.microsoft.com/library(EXCHG.160)/ms.exch.setupreadiness.CannotAccessAD.aspx
Wer häufiger Exchange Server installiert, muss also noch einen Domain Controller innerhalb des Standortes „ExchangeInstall“ installieren. Diese Lösungsmöglichkeit lohnt sich also nur, wenn häufig neue Exchange Server installiert werden.
Die IP Adresse des Exchange Servers muss dann auf eine IP Adresse innerhalb des Standorts „ExchangeInstall“ gesetzt werden:
Mit dem folgenden Befehl lässt sich prüfen in welchem Standort sich der Exchange Server befindet
nltest /dsgetsite
Jetzt kann Exchange 2016 wie gewohnt installiert und konfiguriert werden, ohne das Clients den Server für Anfragen benutzen.
Sobald die Konfiguration abgeschlossen ist und der Server in die Produktion soll, muss die IP-Adresse wieder geändert werden. Ebenfalls sollten die DNS Einträge (Forward und Reverse) kontrolliert werden.
Abschließend muss noch der folgende Befehl in der Exchange Management Shell ausgeführt werden:
Set-ClientAccessService SERVERNAME –AutoDiscoverSiteScope "Name des endgültigen AD-Standorts"
Wenn der Server FWEX1 also wieder im Standort „Default-First-Site-Name“ ist, lautet der Befehl:
Set-ClientAccessService FWEX1 –AutoDiscoverSiteScope "Default-First-Site-Name"
Lösung 2: SCP (Service Connection Points) anpassen
Eine weitere Lösung, ist das Anpassen der SCP Einträge selbst. Diese Vorgehensweise eignet sich besonders, wenn nur wenige Server oder nur ein einzelner Server installiert werden sollen.
Exchange Server wird hier ganz normal installiert, ohne das vorher Vorbereitungen getroffen werden müssen (siehe Lösung 1). Es kommt hier nur ein bisschen auf das Timing an.
Während die Installation läuft, kann schon die Konsole „Active Directory Standorte und –Dienste“ geöffnet werden. In den Ansichtseinstellungen muss „Dienstknoten anzeigen“ ausgewählt werden:
Während der Exchange Installation kann man sich dann bis zum Objekt „Protocols“ durchhangeln:
Noch während der Exchange Installation, ab Schritt 14 von 15, wird der SCP Eintrag für Autodiscover erzeugt:
Sobald der Eintrag sichtbar ist (F5 drücken nicht vergessen), kann das SCP Objekt bearbeitet werden:
Hier können die Werte für „serviceBindingInformation“ und der Standort unter „keywords“ entfernt werden:
Jetzt kann Exchange Server konfiguriert werden, aber bitte nicht vergessen die entsprechenden Einträge nach der Konfiguration wieder hinzuzufügen.
Diese Möglichkeit löst zwar nicht alle Probleme, aber zumindest, die
Lösung 3: Schnell konfigurieren
Bei kleinen Organisationen oder nur einem Exchange Server der migriert werden soll, kann auch einfach auf die Methode „Schnell das nötigste konfigurieren“ zurückgegriffen werden. Zwar löst das schnelle Konfigurieren nicht alle Probleme (zum Beispiel OAB Download, wenn noch kein OAB generiert wurde), aber es bewahrt die Benutzer davor, Zertifikatswarnungen zu erhalten.
Es muss also ein gültiges Zertifikat her, das lässt sich vorbereiten. Direkt nach der Installation kann das Zertifikat dann den Exchange Diensten zugewiesen werden. Das Zertifikat lässt sich entweder vorab von einer CA kaufen, oder es wird ein Zertifikat von einer internen PKI ausgestellt.
Hier sind die entsprechenden HowTos für die Zertifikate (gilt auch für Exchange 2016):
Ausserdem müssen direkt nach der Installation die URLs entsprechend konfiguriert werden, auch hier lassen sich bereits die entsprechenden Befehle vorbereiten:
$servername = "EX2016" $internalhostname = "outlook.frankysweb.de" $externalhostname = "outlook.frankysweb.de" $autodiscoverhostname = "autodiscover.frankysweb.de" $owainturl = "https://" + "$internalhostname" + "/owa" $owaexturl = "https://" + "$externalhostname" + "/owa" $ecpinturl = "https://" + "$internalhostname" + "/ecp" $ecpexturl = "https://" + "$externalhostname" + "/ecp" $ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx" $ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx" $easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync" $easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync" $oabinturl = "https://" + "$internalhostname" + "/OAB" $oabexturl = "https://" + "$externalhostname" + "/OAB" $mapiinturl = "https://" + "$internalhostname" + "/mapi" $mapiexturl = "https://" + "$externalhostname" + "/mapi" $aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml" Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl Get-ActiveSyncVirtualDirectory -Server $servername | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate' Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri
Jetzt kann die Konfiguration wie gewohnt abgeschlossen werden. Welcher Weg gewählt wird, hängt also von der Umgebung ab.
Hallo Frank,
Frage: Benötigt der weitere Exchange Server bei der Installation direkte Verbindung zum Schema Master?
Ich versuche einen neuen Server in einer neuen Site mit 2 neuen vorhandenen DCs zu installieren, jedoch schlägt die Installation mit obigen Fehlermeldung fehl (AD nicht vorhanden, fehlende Berechtigungen etc.).
Der Benutzer ist OrgAdmin, SchemaAdmin etc.
In unserem Fall ist der direkte Zugriff auf die Schema Master firewalltechnisch abgeriegelt.
Ist das temporäre Verschieben des Schema Masters in die neue Site ein Lösungsansatz, oder gibt es einen anderen Weg?
Hallo,
ich kann die AutoDiscoverServiceInternalUri per Sehll nich setzen. Setze ich den Befehl ab, bleibt die Uri trotzdem leer? Kann ich die Uri anderweitig setzen? Alles andere hat reibungslos funktioniert.
Danke für die Auskunft.
Super Artikel, vielen Dank.
Die Lösung zwei finde ich am charmantesten und mann kann sie während der Installation noch etwas „tunen“. Zwischendruch funktioniert ab und an schon die PowerShell auf dem neuen Server.
D.h. vorher die AutoDsicvoerServiceInternalURi am alten Server abfragen:
Get-ClientAccessServer alterServer | fl
Und dann bei der Installation (im Schritt 14 geht das ganz gut) via
Set-ClientAccessServer neuerServer -AutoDiscoverServiceInternalUri https://meineURI.domain.com/Autodiscover/autodiscover.xml
Ich persönlich mag es lieber einen gepflegtes PowerShell Commando abzusetzen, anstatt via Active Direcotry Sites and Services Attribute zu verändern.
Hallo Franky,
super Artikel, vielen Dank :)
hast du Erfahrungen bezüglich dem Ändern der IP Adresse eines laufenden Exchange 2016 Servers? Gibt es noch mehr zu beachten als die Anpassung der DNS-Einträge?
Grüße
Hagen
Hi,
Die Änderung der IP ist aus Exchange Sicht eher unkritisch, neben den DNS Einträgen sollten auch Geräte wie Drucker / MFCs und andere Server und Rechner im Auge behalten werden, damit diese nicht versuchen Mails an die alte IP zuzustellen.
Gruß, Frank