Direkt zum Hauptbereich

Sicherheitswarnung beim Starten von Outlook 2007 und Verbinden mit einem Postfach auf einem Server mit Exchange Server 2007 oder 2010: "Der auf dem Sicherheitszertifikat angegebene Name ist ungültig oder stimmt nicht mit dem Namen der Site überein"

Problembeschreibung:


Sie starten Microsoft Office Outlook 2007 und stellen dann eine Verbindung mit einem Postfach her, das auf einem Postfachserver gespeichert ist, auf dem Microsoft Exchange Server 2007 oder Microsoft Exchange Server 2010 ausgeführt wird. In diesem Szenario wird die folgende Sicherheitswarnung angezeigt:
Der auf dem Sicherheitszertifikat angegebene Name ist ungültig oder stimmt nicht mit dem Namen der Site überein.
Hinweis Dieses Szenario betrifft nur Outlook-Clients, die aus dem lokalen Netzwerk heraus eine Verbindung mit Exchange herstellen. Es betrifft keine Outlook-Remoteclients, die die Verbindung mit Exchange über Outlook Anywhere herstellen.


Ursache:


Das Problem tritt auf, wenn die folgenden Bedingungen vorliegen:
  • Sie ersetzen das standardmäßige selbstsignierte Exchange Server 2007- oder Exchange Server 2010-Zertifikat durch ein anderes Zertifikat. 

    Hinweis Bei der Installation von Exchange Server 2007 oder Exchange Server 2010 erstellt das Setupprogramm ein standardmäßiges selbstsigniertes Zertifikat.
  • Der allgemeine Name des Ersatzzertifikats entspricht nicht dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) der URL, die in den folgenden Objekten gespeichert ist:
    • Dienstverbindungspunkt-Objekt für den AutoErmittlungsdienst
    • InternalUrl-Attribut des Exchange 2007-Webdiensts (EWS)
    • InternalUrl-Attribut des Offlineadressbuch-Webdiensts
    • InternalUrl-Attribut des Exchange Unified Messaging-Webdiensts (UM)
Standardmäßig verweist die in diesen Objekten gespeicherte URL auf den NetBIOS-Namen des Servers. Beispielsweise wird eine URL gespeichert, die wie folgt aussieht:
https://NetBIOS-Name.contoso.com/autodiscover/autodiscover.xml
Diese kann von dem im FQDN des Ersatzzertifikats verwendeten Hostnamen abweichen. Das Ersatzzertifikat kann z. B. einen FQDN ähnlich dem folgenden FQDN aufweisen:
mail.contoso.com
Dieses Problem führt zu einem Namenskonflikt. Daher wird die Sicherheitswarnung angezeigt, wenn Sie versuchen, eine Verbindung von Outlook 2007 zum Postfach herzustellen.


Lösung:


Um das Problem zu beheben, ändern Sie die URLs der entsprechenden Exchange 2007-Komponenten. Gehen Sie hierzu folgendermaßen vor:
  1. Starten Sie die Exchange-Verwaltungsshell.
  2. Ändern Sie die AutoErmittlungs-URL im Dienstverbindungspunkt. Der Dienstverbindungspunkt ist im Active Directory-Verzeichnisdienst gespeichert. Um diese URL zu ändern, geben Sie den folgenden Befehl ein, und drücken Sie anschließend die EINGABETASTE:
    Set-ClientAccessServer -Identity CAS-Servername -AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml
  3. Ändern Sie das Attribut InternalUrl des EWS. Geben Sie hierzu den folgenden Befehl ein, und drücken Sie die EINGABETASTE:
    Set-WebServicesVirtualDirectory -Identity "CAS-Servername\EWS (Standardwebsite)" -InternalUrl https://mail.contoso.com/ews/exchange.asmx
  4. Ändern Sie das Attribut InternalUrl für die Verteilung des webbasierten Offlineadressbuchs. Geben Sie hierzu den folgenden Befehl ein, und drücken Sie die EINGABETASTE:
    Set-OABVirtualDirectory -Identity "CAS-Servername\oab (Standardwebsite)" -InternalUrl https://mail.contoso.com/oab
  5. Ändern Sie das Attribut InternalUrl des UM-Webdiensts. Geben Sie hierzu den folgenden Befehl ein, und drücken Sie die EINGABETASTE:
    Set-UMVirtualDirectory -Identity "CAS-Servername\unifiedmessaging (Standardwebsite)" -InternalUrl https://mail.contoso.com/unifiedmessaging/service.asmx
    Hinweis Dieser Befehl ist nur in einer Exchange 2007-Umgebung erforderlich. In Exchange 2010-Umgebungen existiert der Befehl nicht mehr. Stattdessen wird die WebServices-URL zu diesem Zweck verwendet.
  6. Öffnen Sie IIS-Manager.
  7. Erweitern Sie den lokalen Computer und dann Anwendungspools.
  8. Klicken Sie mit der rechten Maustaste auf MSExchangeAutodiscoverAppPool, und klicken Sie dann auf Wieder verwenden.
Wichtig Bei diesen Schritten wird davon ausgegangen, dass ein Hostdatensatz im DNS existiert, um den angegebenen FQDN der IP-Adresse des CAS-Servers zuzuordnen. Stellen Sie sich beispielsweise das folgende Szenario vor:
  • Die ursprünglichen internen URLs für die Exchange-Komponenten zeigen auf den internen FQDN des Servers. Eine dieser URLs zeigt beispielsweise auf folgendes Ziel:
    https://Servername.contoso.com/ews/exchange.asmx
  • Der auf dem Zertifikat angegebene FQDN zeigt auf den für den externen Zugriff verwendeten Hostnamen des Servers. Im Zertifikat wird z. B. ein FQDN wie "mail.contoso.com" angegeben.
In diesem Szenario müssen Sie einen Hostdatensatz für den Mailhostnamen hinzufügen, der der intern für den Zugriff verwendeten IP-Adresse des CAS-Servers zugeordnet ist, um internen Clients den Zugriff auf den Server zu ermöglichen.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Office 2013 aktivieren via Kommandozeile

Wie man das neue Microsoft Office 2013 aktiviert via Kommandozeile, das werde ich euch in dem folgenden Beitrag Schritt für Schritt erklären. Gerade in grösseren Systemumgebungen in welchen die Clients und Standard Software automatisiert installiert werden, kann das sehr hilfreich sein und erspart einem viel Arbeit nach der Installation des Clients. Das Ziel sollte sein, möglichst viel zu automatisieren und soweit möglich, wenig noch händisch zu konfigurieren. Da kommt dieser Beitrag sicherlich nicht ungelegen. Die folgenden Befehle könnte man beispielsweise ganz einfach in eine MDT (Microsoft Development Toolkit) Umgebung mit einbeziehen oder auch mit anderer Software benutzen. Wichtig zu wissen ist, dass dies nur dann funktioniert, wenn Microsoft Office 2013 über das Internet aktiviert wird. Hat man einen eigenständigen Aktivierungsserver (KMS), funktioniert dies nicht. Zudem müssen die Befehle alle mit Administrator Rechte ausgeführt werden. Normale Benutzerberechtigungen genügen …

Windows Domain Controller: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar

Zurzeit häuft sich (warum auch immer) das Problem dass nach einem Neustart eines Windows Domain Controllers bei der Anmeldung die Fehlermeldung „Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar“ kommt und eine Anmeldung so nicht möglich ist Das Problem ist hierbei das der Domain Controller im Active Directory Reperatur Modus (Abgesicherter Modus) startet. Am einfachsten lässt sich dieses Problem folgendermaßen beheben: 1) Anmeldung mit dem DSRM (Directory Services Restore Mode) / Verzeichnisdienstwiederherstellungskennwort Falls die Anmeldung nicht funktioniert kann man einen Workaround wie hier beschrieben durchführen. 2) Systemkonfiguration mittels msconfig.exe aufrufen

WSUS won’t uninstall or re-install

Hat heute ein Problem mit WSUS unter Windows Server 2008 R2 bei einem Kunden. Das Problem - die Clients konnten keinen Verbindung zum WSUS Server herstellen. Die Deinstallation wurde unerwartet beenden mit folgender Fehlermeldung: Attempt to un-install Windows Server Update Services failed with error code 0x80070643. Fatal error during installation  Die Lösung: I don’t like Windows Server Update Services (WSUS), but it’s the free alternative many companies select over the higher cost alternatives like Intune or Systems Center. So, today I had to repair a damaged WSUS installation. Turns out someone uninstalled SQL Server 2005 Express not realizing WSUS was using it. Now firing up the WSUS console just yielded an error complaining about the missing SQL database. So like any good troubleshootin IT guy the first thing I tried was to uninstall WSUS…sadly, however the product would not uninstall or re-install. Here’s how I finally got rid of it: [the problem] WSUS 3.0 SP2 is missing SQL serv…