30

MS Exchange-Problem: Servername und Name im Zertifikat stimmen nicht überein

Problembeschreibung

Nachdem ein neues Zertifikat in den Exchange-Server importiert wurde, kann es zu Fehlermeldungen beim Start von Outlook auf den Client-PCs kommen.

In diesem Fenster sehen wir in der ersten Zeile, dass sich unser Exchange mit seinem internen FQDN „servername.domäne.local“ meldet. Ebenfalls gibt uns die Meldung die Information, dass das Zertifikat ungültig ist oder die Namen nicht übereinstimmen.

Fehlermeldung beim Start von Outlook

Mit einem Klick auf „Zertifikat anzeigen“ erhalten wir zusätzliche Informationen und können nun die Namen überprüfen. Hier sehen wir direkt, dass sich diese unterscheiden.

Details zum Zertifikat

Vorgehen am Exchange

Nun haben wir im Exchange, genau genommen in der Exchange Management Shell, drei Punkte, die uns besonders interessieren. Dies sind die externen und internen Adressen für:

  • AutodiscoverService
  • AutodiscoverVirtualDirectory
  • WebServicesVirtualDirectory

Diese Informationen müssen entsprechend des Servernamens im Zertifikat angepasst werden.

AutodiscoverService

Mit dem cmdlet „Get-ClientAccessServer“ erhält man alle ClientAccessServer der Organisation. Nach dem Anpassen an unseren Exchange-Server und zuschneiden der Ausgabe auf die Adresse des AutodiscoverService, erhalten wir auch die Informationen, die wir benötigen.

Get-ClientAccessServer | ft AutodiscoverServiceInternalUri

Anstelle des lokalen FQDN „servername.domäne.local“ muss nun entsprechend des Zertifikats die neue Adresse eingegeben werden. Dies erreichen wir mit dem Set-ClientAccessServer cmdlet.

Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri „https://exchange.domain.de/Autodiscover/Autodiscover.xml“
 

AutodiscoverVirtualDirectory

Nun lesen wir die interne und externe URL des AutodiscoverVirtualDirectory aus. Nach der Standardinstallation von Exchange sind diese i.d.R. leer.

Get-AutoDiscoverService

Folgende Befehlszeile setzt beide notwendigen Einträge, damit wir der Übereinstimmung mit dem Zertifikat einen Schritt näher kommen.

Set-AutodiscoverVirtualDirectory -Identity „servername\Autodiscover (Default Web Site)“ -InternalUrl „https://exchange.domain.de/Autodiscover/Autodiscover.xml“ -ExternalUrl „https://exchange.domain.de/Autodiscover/Autodiscover.xml“
 

WebServicesVirtualDirectory

Die externe Adresse der WebServicesVirtualDirectory ist ebenfalls leer. Die interne Adresse dabei zeigt widerum auf unseren internen FQDN. Beide Einträge müssen also wieder angepasst werden.

Get-WebServicesVirtualDirectory

Set-WebServicesVirtualDirectory -Identity „servername\EWS (Default Web Site)“ -InternalUrl „https://exchange.domain.de/EWS/Exchange.asmx“ -ExternalUrl „https://exchange.domain.de/EWS/Exchange.asmx“
 

Weitere Konfigurationsmöglichkeiten

Zusätzlich kann man natürlich noch weitere Zugänge optimieren (wenn wir schon einmal dabei sind…). Darunter z.B. der OWA-Zugriff oder auch Microsoft-ActiveSync. Hier eine kleine Auflistung der notwendigen Befehlszeilen.

Set-OWAVirtualDirectory -Identity „servername\OWA (Default Web Site)“ -InternalUrl „https://exchange.domain.de/owa“ -ExternalUrl „https://exchange.domain.de/owa“
 
Set-ECPVirtualDirectory -Identity „servername\ECP (Default Web Site)“ -InternalUrl „https://exchange.domain.de/ecp“ -ExternalUrl „https://exchange.domain.de/ecp“
 
Set-ActiveSyncVirtualDirectory -Identity „servername\Microsoft-Server-ActiveSync (Default Web Site)“ -InternalUrl „https://exchange.domain.de/Microsoft-Server-Activesync“ -ExternalUrl „https://exchange.domain.de/Microsoft-Server-Activesync“
 
Set-OABVirtualDirectory -Identity „servername\OAB (Default Web Site)“ -InternalUrl „https://exchange.domain.de/OAB“ -ExternalUrl „https://exchange.domain.de/OAB“
 
Enable-OutlookAnywhere -Server servername -ExternalHostname „exchange.domain.de“ -ClientAuthenticationMethod „Basic“-SSLOffloading:$False
 

Änderungen am lokalen DNS

Damit die Clients auch etwas mit der Adresse „exchange.domain.de“ anfangen können, muss noch eine Forward-Zone im lokalen DNS eingerichtet werden. Dies ist auch schnell erledigt. Aber bitte beachten nur „exchange.domain.de“ als Forward-Zone einzutragen.

1. Öffnen der DNS-Verwaltung
2. Rechtsklick auf Forward-Lookupzonen und im Kontextmenu „Neue Zone…“ wählen

Erstellen einer neuen DNS-Forward-Lookupzone 1

3. Der Assistent startet
4. „Primäre Zone“ wählen
Erstellen einer neuen DNS-Forward-Lookupzone 2

5. Den Namen der Zone angeben. Hier den Namen aus dem Zertifikat verwenden. In unserem Beispiel „exchange.domain.de“

Erstellen einer neuen DNS-Forward-Lookupzone 3

6. Den Assistenten durchlaufen und „Fertig stellen“
7. Anschließend die Zone öffnen.
8. Via Rechtsklick im rechten Bereich das Kontextmenu öffnen „Neuer Host (A oder AAAA)…“ auswählen
9. Das Feld „Name“ leer lassen, damit der übergeordnete Name „exchange.domain.de“ verwendet wird.
10. IP-Adresse des lokalen Exchange-Servers eintragen im Feld „IP-Adress“ eintragen

Erstellen einer neuen DNS-Forward-Lookupzone 4

Bei all diesen Änderungen sollten zumindest die Exchange-Dienste neugestartet und ein IIS-Reset durchgeführt werden. Am besten einmal sowohl Server als auch Clients neustarten.

Die Benutzer sollten ihr Outlook nun ohne Fehlermeldung nutzen können. Viel Erfolg.

Abgelegt unter: Exchange, Exchange 2010, Tutorial Tags: , ,

Ähnliche Artikel

Bookmarke uns!

30 Kommentare zu "MS Exchange-Problem: Servername und Name im Zertifikat stimmen nicht überein"

  1. Schlord sagt:

    Hi da ist ein kleine Schreibfehler im Befehl für Autodiscover :

    das „n“ bei
    AutoDiscoverServiceInternal und nicht
    AutoDiscoverServiceInteral

    Set-ClientAccessServer -Identity SERVER -AutoDiscoverServiceInternalUri „https://SERVER.physio.local/Autodiscover/Autodiscover.xml“

    ansonsten 1000Dank für die Anleitung und Arbeit

    • Sebastian Pjede sagt:

      Vielen Dank für den Hinweis. Die Stelle habe ich mittlerweile entsprechend korrigiert. Auch bei Ihnen möchte ich mich für Ihr Feedback bedanken.

  2. Marc sagt:

    Hallo,

    habe deinen Beitrag gerade aufgrund des Zertifikats Fehlers durchgearbeitet.

    Erstmal, funktioniert nun alles, hat mir sehr geholfen, vielen Dank!

    Allerdings hast Du einen Fehler in dieser Anleitung, wo ich selber 5 Minuten gebraucht habe um den Fehler zu finden.

    In dem Abschnitt – AutodiscoverService – ist ein Fehler in deinem Beispiel cmdlet:

    Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInteralUri “https://exchange.domain.de/Autodiscover/Autodiscover.xml”

    Hier fehlt das „n“ bei -AutoDiscoverServiceInter(n)alUri

    Ohne dieses „n“ geht’s natürlich nicht 🙂

    Lieben Gruß
    Marc

    • Sebastian Pjede sagt:

      Hallo Marc, auch dir vielen Dank für den Hinweis und mittlerweile habe ich den Fehler auch korrigiert. Hoffe du musstest dir den Kopf nicht allzu sehr den Kopf zerbrechen, dafür war die Anleitung jedenfalls nicht gedacht 🙂
      Und natürlich auch Danke für das positive Feedback!

      • Sager Christophe sagt:

        Hallo Sebastian

        Vielen Dank für deinen Beitrag !

        Funktionieren die Powershell Befehle auch bei einem Exchange 2013 ?

        Grüsse aus der Schweiz

        Christophe

  3. Helge sagt:

    Wirklich ne tolle Anleitung.
    Ein Kunde von uns hat nämlich dieses Problem.
    Allerdings bekomme ich nach dem Get-ClientAccessServer-Befehl den Fehler
    „Der Vorgang konnte nicht ausgeführt werden, weil das Objekt ‚xxxx.de‘, nicht auf „SRV-SBS.xxx.local‘ gefunden wurde.
    Hast Du da einen Tip für mich?

  4. Joar sagt:

    Vielen Dank für die Anleitung.
    Funktioniert so wie es soll 🙂

  5. donkey sagt:

    Die Anleitung klappt einwandfrei, suchte nach einer alternative zu Active Directory Certificate Services, (AD CS), dies ist eine, DANKE

  6. jens sagt:

    Hallo Herr Pjede,

    ist die Vorgehensweise die selbe wenn man ein internes Zertifikat verlängert?
    Ich habe das interne Zertifikat meines SBS 2011 Servers über die SBS Console verlängert.
    Dem neuen Zertifikat habe ich bereits die Dienste des abgelaufenen Zertifikats zugeordnet.

    Im neuen Zertifikat habe ich folgende Informationen:

    Ausgestellt für „Walter-Walter-SBS-CA“
    Ausgestellt von „Walter-Walter-SBS-CA“
    Gültig ab „06.10.2014 bis 06.10.2017“

    der Name auf dem Sicherheitshinweis lautet:
    Walter-SBS.walter.intern

    Muss ich nun die Einträge so anpassen dass diese beispielsweise:

    Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri “https://Walter-Walter-SBS-CA/Autodiscover/Autodiscover.xml”

    lauten? Für eine Antwort ihrerseits wäre ich sehr dankbar!

    Grüße

    • Sebastian Pjede sagt:

      Hallo Herr Schreiber,

      soweit ich es richtig sehe, müsste die Zeile bei Ihnen wie folgt lauten:
      Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri „https://walter-sbs.walter.intern/Autodiscover/Autodiscover.xml“

      Hier geben Sie den FQDN an, auf den das Zertifikat ausgestellt wurde.

      Freundliche Grüße
      Sebastian Pjede

      • jens sagt:

        Hallo Herr Pjede,

        genau hier liegt mein Problem. Das neue Zertifikat wurde nicht für „walter-sbs.walter.intern“ sondern „Walter-Walter-SBS-CA“ ausgestellt.

        Der FQDN „Walter-SBS.walter.intern“ taucht in der Outlook Fehlermeldung auf. Das ist der Name den er auf dem Zertifikat nicht findet.

        Um es auf ihre Vorgehensweise zu übertragen:

        Outlook Fehlermeldung
        “servername.domäne.local” = „Walter-SBS.walter.intern“

        Zertifikat
        „exchange.domain.de“ = “Walter-Walter-SBS-CA”
        „Thawte DV SSL CA“ = „“Walter-Walter-SBS-CA”

        Vielen Dank.

  7. Andy sagt:

    Hallo,

    ich habe gerade das selbe Problem nachdem sich ein Zertifikat anscheinend automatisch verlängert hat. Der Namensunterschied ist bei mir folgender: Im Sicherheitshinweis wird der lokale Name angezeigt:

    XXX.domain.local

    Zertifizierungspfad und Aussteller ist aber xxx.xxx.xxx.xxx (unsere öffentliche IP Adresse).

    SBS2008 mit Ex07 SP3 RU14.

    Bin für jeden Tipp dankbar!

    • Andy sagt:

      Ups, Korrektur: es wird auf dem Sicherheitshinweis nicht der lokale Servername, sondern der DNS Name für die öffentliche IP Adresse angezeigt.

  8. Gregor sagt:

    Super Übersicht für die deutschen User! Es fehlen allerdings die UnifiedMessaging Services (ob man sie nutzt oder nicht – gleiche Befehle wie sonst auch mit Set-UMVirtualDirectory). Zur Überprüfung ist übrigens die „EMail AutoKonfiguration“ aus Outlook zu empfehlen 🙂

  9. Hendrik sagt:

    Hallo! Zunächst ein herzliches Dankeschön für diese wirklich vorbildliche Anleitung! Leider komme ich am Punkt „WebServicesVirtualDirectory“ nicht weiter. Ich habe die angezeigte Befehlszeile (natürlich angepasst an meine Umgebung) so eingegeben und bekomme als Ausgabe nur zwei Pfeile die nach rechts zeigen („>>“) und dahinter einen blinkenden Cursor. Keine Fehlermeldung, kein gar nichts. Was hat das zu bedeuten? Muss ich einfach warten, oder irgendeinen Dienst neustarten?

    • Hendrik sagt:

      Ich nochmal… sorry, war mein Fehler! Ich habe gleich zwei Schreibfehler bei mir drin gehabt. Einmal aber ich „InternalUrl“ auseinandergeschrieben und der zweite Fehler bestand darin, dass ich am Ende des gesamten Befehls die Anführungszeichen vergessen habe.

  10. Thomas sagt:

    Super Artikel!

    Ich habe nur leider ein Problem mit dem folgenden Befehl:

    „Set-WebServicesVirtualDirectory -Identity “servername\EWS (Default Web Site)” -InternalUrl “https://exchange.domain.de/EWS/Exchange.asmx” -ExternalUrl “https://exchange.domain.de/EWS/Exchange.asmx”“

    Bei mir hat das Cmdlet Set-WebServicesVirtualDirectory keinen Parameter -InternalUrl bzw. -ExternalUrl.

    Im Einsatz ist ein Exchange 2013 und ein Outlook 2013 Client. Die oben genannte Zertfikatswarnung erhalte ich nur Outlook 2013 Clients.

    Schon mal vielen Dank!

    • Sebastian Pjede sagt:

      Hallo,
      gerade habe ich im Exchange 2013 noch einmal nachgeschaut. Das CMDlet unterscheidet sich hier nicht zum 2010er, beide Parameter funktionieren hier einwandfrei. Die installierte Version ist bei uns dezeit „Version 15.0 ‎(Build 847.32)‎“. Im „schlechtesten“ Fall den Befehl per Hand eintragen und CMDlet und Parameter mit [TAB]-Taste vervollständigen. Vielleicht klappt es so. Beim Kopieren von Anführungszeichen kann es ebenfalls manchmal zu Fehlern kommen. Viel Erfolg weiterhin!

  11. Thomas sagt:

    Hallo,

    vielen Dank für die Tipps. wir hatten seit heute auch diese Probleme. Hauptsächlich deswegen, weil keine lokalen Namen mehr in Zertifikaten verwendet werden dürfen. Nun standen wir da vor diesem Problem. Dank der Anleitung läuft aber alles wieder tadellos.

    VIELEN DANK

    Gruß
    Thomas

  12. Frank sagt:

    Hallo,
    vielen Dank! Nach langer Suche endlich die Lösung!!
    Beste Grüße
    Frank

  13. Butch sagt:

    Erste Kajüte!
    Meinen herzlichen Dank für diesen Artikel.
    Diese Zertifikatsmeldung, genau 60 Sekunden nach dem Start eines Outlook 2007 Clients, hat mich locker 2 Tage Recherche im Netz gekostet. Die Migration von Exchange 2007 nach 2013 läuft somit rund.
    Danke,
    Butch

  14. Vielen Dank! Ich war schon am verzweifeln und wusste nicht mehr, wie ich das bei Exchange 2013 hinbekommen hatte …. nun läuft der 2013 Server sauber!

  15. Michael Isen sagt:

    Hallo,

    vielen Dank für diese Anleitung.
    Ich habe alles akribisch abgearbeitet und mehrmals kontrolliert, jedoch kommt beim Sicherheitshinweis immer noch der lokale FQDN der natürlich nicht mit dem Zertifikat übereinstimmt.
    Inzwischen habe ich nahezu jede Einstellung im Exchange überprüft, jedoch finde ich nirgends ein Problem…

  16. Thomas G sagt:

    Hat bisher super funktioniert, aber bei Exchange 2016 steh ich an, weiss jemand wie das mit Exchange 2016 funktioniert?

  17. Stephan Schiegg sagt:

    Herzlichen Dank, funktioniert wunderbar!

  18. Jens sagt:

    Super endlich den Fehler gefunden 🙂 Jetzt klappt alles ohne Fehlermeldung.
    Vielen Dank.

  19. Patrik sagt:

    Hallo Sebastian

    Vielen herzlichen Dank für die ausführliche und gute Beschreibung.

    Hat mein Problem gelöst 🙂

    Gruss

    Patrik

  20. Joe sagt:

    Hallo Sebastian,

    danke für die ausführliche Beschreibung. Leider habe ich immernoch folgendes Problem..
    Server = Exchange 2010
    Clients = Outlook 2010

    Zertifikatshinweis der Fehlermeldung: testserver.domäne.local
    Zertifikat:
    Ausgetellst für: testserver
    Ausgestellt von: testserver

    Get-ClientAccessServer:
    Testserver

    AutoDiscoverServiceInternalUri:
    https://testserver.domäne.local/autodiscover/autodiscover.xml

    AutoDiscoverVirtualDirectory:
    Int: https://testserver.domäne.local/autodiscover/autodiscover.xml
    ext: https://testserver.domäne.local/autodiscover/autodiscover.xml

    WebServicesVirtualDirectory:
    Int: https://testserver.domäne.local/EWS/Exchange.asmx
    ext: https://testserver.domäne.local/EWS/Exchange.asmx

    So sollte das doch auch aussehen, um das Zertifikatsproblem zu beheben, oder verstehe ich einen Part falsch?

    LG
    Joe

  21. Thomas sagt:

    Hallo Sebastian,

    vielen Dank für das Tutorial. Nach Umstellung sämtlicher Punkte, habe ich leider das Problem, dass weder Mails mehr rein noch rausgehen und diese in der Regel nach dem Versenden im Ordner Entwürfe landen.

    Hast du eine Idee, woran das liegen könnte? Verzweifle hier so langsam.

    Danke vorab!

    Viele Grüße
    Thomas

  22. dognose sagt:

    Hallo,

    sehr hilfreich und detailiert. Allerdings hätte ich eine Frage, die noch unklar ist:

    Aktuell laufen unsere Email-Clienten alle auf den internen FQDN mit selbst signiertem Zertifikat. Da dieses Abläuft möchte ich es gerne durch ein vernünftiges Zertifikat ersetzen.

    Wie in vorliegendem Beispiel müsste ich hierfür die interne Adresse auf „exchange.extern.com“ ändern, ebenfalls die Autodiscovery einträge etc.

    Doch aktuell zeigen alle Outlook-Clienten auf den internen FQDN. Muss das Profil in jedem Outlook anschließend angepasst werden, oder „klappt“ folgende Einstellung ebenfalls:

    Server: s1.company.local
    Autodiscovery: exchange.extern.com
    Zertifikat für exchange.extern.com

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© 2017 IT-Dienstleistungen. All rights reserved. XHTML / CSS Valid.