Exchange Let´s Encrypt Outlook Meldung

[Andreas83 11]

Hallo zusammen, 

 

habe für ein Exchange 2010 auf einem 2008 R2 ein Let´S Encrypt Zertifikat eingebunden. 

Funktioniert soweit mit OWA & Co. einwandfrei.

 

Outlook meldet beim Start aber dass der Name nicht auf dem Zertifikat existiert.

 

Outlook wurde mit dem internen Namen exchange.domain.local verbunden.

 

Wie kann ich dies lösen? 

 

Vielen Dank für eure Rückmeldungen.

 

Grüße Andreas

[NilsK 2.937]

Moin,

 

auf welchen Namen lautet denn das Zertifikat?

 

Mit Let's Encrypt kannst du auch SAN-Zertifikate bauen, die mehr als einen Namen enthalten. Ob das für Exchange geeignet ist, hab ich noch nicht geprüft.

 

Gruß, Nils

[testperson 1.680]

Hi,

 

Let's encrypt stellt doch sicherlich keine Zertifikate für .local und Co aus. Außer du registrierst dir evtl. .local ;)

Du wirst deinen Exchange wohl passend zum Zertifikat oder andersrum konfigurieren, sprich SplitDNS.

 

Gruß

Jan

 

P.S.: Der Exchange ist aktuell gepatched?

[Andreas83 11]

ich habe die internen der externen URLs gleich gesetzt und bei Let´s Encrypt zwei Aliase hinterlegt, autodiscover.domain.de sowie mail.domain.de.

Intern SplitDNS konfiguriert. Aber irgendwo muss ich eine Einstellung am Exchange vergessen oder übersehen haben. 

 

Selbst wenn ich ein neues Exchange Profil anlege und als Server mail.domain.de verwende, kommt die Meldung nach dem Outlook start.

 

Irgendwoher zieht es sich weiterhin den internen Servernamen exchange.domain.local

 

Windows Updates sind Stand Mitte Dezember

Exchange ist Version 14.3 (Build 123.4)

[testperson 1.680]

Der Exchange hat schonmal SP3. Wäre jetzt die Frage, ob die neusten RUs drauf sind: http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

 

Ohne die Info was du denn alles angepasst hast, kann man schlecht sagen was du vergessen hast ;) Ich tippe aber mal drauf, dass "Get-ClientAccessServer | fl Name, AutoDiscoverServiceInternalUri" hefen könnte.

[Andreas83 11]

sorry, habe unter Serverkonfiguration, Clientzugriff die interne der externen URL für alle Reiter wie OWA usw. gleichgesetzt.

 

Mit Get-ClientAccessServer | fl Name, AutoDiscoverServiceInternalUri

erhalte ich die interne URL

 

https://obr-srv-ex.domain.local/Autodiscover/Autodiscover.xml

 

Konnte es mit 

Set-ClientAccessServer name -AutoDiscoverServiceInternalUri https://autodiscover.yourdomain.com/Autodiscover/Autodiscover.xml

ändern.

 

Server Neustart wurde zur Sicherheit durchgeführt aber die Meldung erscheint weiterhin. 

 

Noch eine Idee?

 

SP3 Update Rollup 15 ist ist installiert. 

 

 

 

Vielen Dank

[Sanches 22]

Hallo Andreas,

 

schau doch mal in die Eigenschaften des Zertifikats rein. Dort werden die URLs aufgelistet, welche im Zertifikat hinterlegt wurden.

Sind dort beide (bzw. alle) URLs aufgeführt?

Sprich:

 - <mail-oder-was-auch-immer>.deinedomäne.de

 - autodiscover.deinedomäne.de

 

und deine Clients können diese URLs auch intern korrekt auflösen (Stichwort von Jan - SplitDNS)?

 

Gruß Sebastian

[Andreas83 11]

Beide URLs sind vorhanden und intern funktioniert einwandfrei. https://mail.meinedomain.de/owa zeigt OWA ohne Zertifikatsfehler. 

 

Service Connection Point (SCP) habe ich auch geprüft, zeigt auch auf die mail.meinedomain.de

[testperson 1.680]

Erstelle jetz mal ein neues Outlook Profl und teste.

[Andreas83 11]

neues Profil hat nicht geholfen. In einem anderen Forum habe ich nochmal von den internen und externen URLs gelesen und entsprechend die Abfragen in der Shell gemacht. hier das Ergebnis. Denke da passt was noch nicht. 

 

[PS] C:\Windows\system32>get-AutodiscoverVirtualDirectory

Name                            Server     InternalUrl
----                            ------     -----------
Autodiscover (Default Web Site) OBR-SRV-EX

[PS] C:\Windows\system32>get-ClientAccessServer

Name
----
OBR-SRV-EX

[PS] C:\Windows\system32>get-webservicesvirtualdirectory

Name                   Server     InternalUrl
----                   ------     -----------
EWS (Default Web Site) OBR-SRV-EX https://obr-srv-ex.intern.local/EWS/Exchange.asmx

[PS] C:\Windows\system32>get-oabvirtualdirectory

Server     Name                   Internal Url                              External Url
------     ----                   ------------                              ------------
OBR-SRV-EX OAB (Default Web Site) https://mail.externdomain.de/OAB https://mail.externdomain.de/OAB

[PS] C:\Windows\system32>get-owavirtualdirectory

Name                   Server     OwaVersion
----                   ------     ----------
owa (Default Web Site) OBR-SRV-EX Exchange2010

[PS] C:\Windows\system32>get-ecpvirtualdirectory

Name                   Server
----                   ------
ecp (Default Web Site) OBR-SRV-EX

[PS] C:\Windows\system32>get-ActiveSyncVirtualDirectory

Name                                           Server     InternalUrl
----                                           ------     -----------
Microsoft-Server-ActiveSync (Default Web Site) OBR-SRV-EX https://mail.externdomain.de/Microsoft-Server-Act...

 

 

Soll ich wie im MS Technet Forum beschrieben alle so anpassen?

 

To set the URL's for all directories at once, run the following powershell commands (save it as a .ps1 extension and run it in EMS)

 

For internal URLs:

 

$urlpath = Read-Host "Type internal Client Access FQDN starting with http:// or https://"

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceInternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * –internalurl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –internalurl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –internalurl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –internalurl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"

 

External URLs:

 

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceExternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * -ExternalUrl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –ExternalUrl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –ExternalUrl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –ExternalUrl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl "$urlpath/Microsoft-Server-ActiveSync"

[testperson 1.680]

Wenn du dann wirklich mal _alle_ virtuellen Verzeichnisse angepasst hast, sollte das auch klappen (Außer es wird ein Proxyserver eingesetzt und die Ausnahmen passen nicht).

 

"Einfacher" dürfte es mit "Get-OWAVirtualDirectory -Server <Servername> | Set-OWAVirtualDirectory -InternalURL <URL> -ExternalURL <URL>" etc. gehen.

 

Des Weiteren gibt es keinen "AutodiscoverServiceExternalUri".

[Andreas83 11]

hatte die Info aus dem Technet Forum. Script läuft durch und meckert, wie du es auch geschrieben hast, dass es kein AutodiscoverServiceExternalUri gibt.

 

An sich ja aber kein Fehler es so zu machen um die ps1 Datei auch an einem anderen Exchange nutzen zu können. Sollte so korrekt sein. Oder?

 

 

$urlpath = Read-Host "Bitte URL eingeben"

Get-ClientAccessServer –Identity * | Set-ClientAccessServer –AutodiscoverServiceInternalUri "$urlpath/autodiscover/autodiscover.xml"
Set-webservicesvirtualdirectory –Identity * –internalurl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –internalurl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –internalurl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –internalurl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"

 

Get-ClientAccessServer –Identity * | Set-webservicesvirtualdirectory –Identity * -ExternalUrl "$urlpath/ews/exchange.asmx"
Set-oabvirtualdirectory –Identity * –ExternalUrl "$urlpath/oab"
Set-owavirtualdirectory –Identity * –ExternalUrl "$urlpath/owa"
Set-ecpvirtualdirectory –Identity * –ExternalUrl "$urlpath/ecp"
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl "$urlpath/Microsoft-Server-ActiveSync"

[testperson 1.680]

Ich wäre mit dem -Identity * und einem allgemein nutzbaren Script eher vorsichtig. Aber es spricht nichts dagegen so ein "Kraut und Rüben" Script überall zu nutzen.

 

Es dürfte aber mehr bringen, das Script einmal aufzuräumen, anzupassen, ggfs. zu verstehen was man / was es da tut und dann erst beim Kunden bzw. auf anderen Exchange Servern zu nutzen.

[NorbertFe 2.035]

Nein, bloß nicht. ;)

[Andreas83 11]

sieht nun gut aus, Meldung erscheint bisher nicht mehr. 

 

Vielen Dank euch!