Referenz zur Problembehandlung für Clientzugriffsserver

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Nachdem Sie die Clientzugriffs-Serverrolle auf einem Computer mit MicrosoftExchange Server 2010 installiert haben, kann es notwendig sein, die Funktionalität des Servers zu testen oder Probleme mit Clientverbindungen zu beheben. Die folgenden Informationen unterstützen Sie bei der Problembehandlung für häufige Fehler und beim Testen, um sicherzustellen, dass Ihr Clientzugriffsserver ordnungsgemäß konfiguriert ist. Dieses Thema wird regelmäßig aktualisiert.

Testen der Clientzugriffsserver-Konnektivität

Mithilfe der Microsoft Exchange-Remoteverbindungsuntersuchung (ExRCA) kann die ordnungsgemäße Konfiguration der Konnektivität für Ihre Exchange-Server sichergestellt und eine Diagnose von Konnektivitätsproblemen durchgeführt werden. Auf der Website der Remoteverbindungsuntersuchung werden Tests für MicrosoftExchange ActiveSync, Exchange-Webdienste, Outlook und Internet-E-Mail bereitgestellt.

Weitere Informationen finden Sie unter Grundlegendes zur Remoteverbindungsuntersuchung.

Outlook-Clientkonnektivität

Die folgenden Links und Informationen helfen Ihnen bei der Problembehandlung für die Outlook-Clientkonnektivität.

Postfach kann in Outlook 2007 nicht geöffnet werden

Wenn Sie das Postfach eines Benutzers in MicrosoftOffice Outlook 2007 nicht öffnen können, es aber in MicrosoftOfficeOutlook Web App geöffnet werden kann, überprüfen Sie die Serverinformationen, indem Sie den folgenden Befehl ausführen:

Get-MailboxDatabase | fl RPCClientAccessServer

Wenn die Ausgabe dieses Befehls den Namen des Exchange 2010-Postfachservers ergibt, wurden die Clientzugriffs-Serverrolle und die Postfachserverrolle wahrscheinlich in der falschen Reihenfolge installiert. Der Wert des Parameters RPCClientAccessServer wird auf den Postfachserver und nicht auf den Clientzugriffsserver festgelegt. Führen Sie zum Beheben des Problems den folgenden Befehl aus:

Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer <FQDN of the Client Access Server>

Postfach kann in Outlook 2003 und Exchange 2010 RTM nicht geöffnet werden

Wenn Sie versuchen, auf ein Postfach auf einem Exchange 2010-Postfachserver mit OfficeOutlook 2003 zuzugreifen, erhalten Sie möglicherweise eine der folgenden Fehlermeldungen:

  • Microsoft Office Outlook kann nicht gestartet werden. Das Office-Fenster kann nicht geöffnet werden. Die Ordnergruppe konnte nicht geöffnet werden.

  • Die Standard-E-Mail-Ordner können nicht geöffnet werden. Der Informationsspeicher konnte nicht geöffnet werden.

Der RPC-Endpunkt ist in Exchange 2010 standardmäßig verschlüsselt. Allerdings erzwingt Outlook 2003 keine verschlüsselten MAPI-Verbindungen. Wenn Sie ein Upgrade Ihrer Organisation auf Exchange 2010 ausführen, sind Ihre Clients, die Outlook 2007 oder höhere Versionen ausführen, automatisch mit dem Wechsel zum RPC-Clientzugriff kompatibel, da sie die RPC-Verschlüsselung standardmäßig unterstützen. Outlook 2003 verwendet jedoch keine RPC-Verschlüsselung, die standardmäßig für den RPC-Clientzugriff erforderlich ist.

Hinweis

Standardmäßig ist die Verschlüsselung von Exchange 2010 Service Pack 1 (SP1) auf dem RPC-Endpunkt nicht aktiviert. Daher sollte dieser Fehler nicht auftreten.

Gehen Sie folgendermaßen vor, um Outlook 2003 für die Verwendung der RPC-Verschlüsselung zu konfigurieren:

  1. Klicken Sie auf Extras > E-Mail-Konten > Vorhandene E-Mail Konten anzeigen oder ändern.

  2. Wählen Sie das Konto aus, und klicken Sie auf Weitere Einstellungen.

  3. Klicken Sie auf die Registerkarte Sicherheit.

  4. Aktivieren Sie das Kontrollkästchen Daten zwischen Microsoft Office Outlook und Microsoft Exchange verschlüsseln.

  5. Klicken Sie auf OK.

Das Laden von E-Mail-Nachrichten dauert für Outlook 2003-Clients sehr lange

Die Unterstützung der UDP-Benachrichtigung wurde in Exchange 2010 entfernt. Daher können in Outlook 2003 Abrufbenachrichtigungen nur im Onlinemodus verwendet werden. Dies führt zu einer leichten Verzögerung bei Updates des Elementstatus (von durchschnittlich 30 Sekunden bis zu einer Minute), wenn an einem Postfach, auf das Outlook 2003 zugreift, Änderungen an Elementen vorgenommen werden. Für dieses Problem gibt es zwei Problemumgehungen:

  • Verwenden Sie Outlook 2003 im Exchange-Cachemodus.

  • Passen Sie das Abrufintervall auf dem Clientzugriffsserver an. Dies wirkt sich auf die Leistung des Clientzugriffsservers aus.

Weitere Informationen zu diesem Problem finden Sie unter Das Senden und Empfangen von E-Mail-Nachrichten dauert lange (möglicherweise in englischer Sprache).

Beim Start des RPC-Clientzugriffsdiensts wird Ereignis-ID 106 protokolliert

Wenn der Microsoft Exchange-RPC-Clientzugriffsdienst auf einem Exchange 2010-Postfachserver gestartet wird, auf dem nicht die Clientzugriffs-Serverrolle installiert ist, wird Ereignis-ID 106 im Anwendungsprotokoll protokolliert. Dieser Fehler tritt auf, da die Leistungsindikatoren des RPC-Clientzugriffsdiensts nicht installiert werden, wenn die Postfachserverrolle ohne Clientzugriffs-Serverrolle installiert wird. Installieren Sie die Clientzugriffs-Serverrolle auf dem Exchange 2010-Server, um diesen Fehler zu beheben.

DNS-Änderung hindert einen Benutzer an der Outlook Web App-Anmeldung

Wenn ein Benutzer versucht, sich bei Outlook Web App anzumelden, wird möglicherweise die folgende Fehlermeldung angezeigt:

  • Der Zugriff auf Ihr Konto wird durch eine Änderung an der Serverkonfiguration vorübergehend verhindert. Schließen Sie alle Internet Explorer-Fenster, und versuchen Sie es in ein paar Minuten erneut. Wenden Sie sich an den Helpdesk, wenn das Problem weiterhin auftritt.

Dies kann passieren, wenn der DNS-Datensatz des Clientzugriffsservers geändert wird und ein Benutzer versucht, sich bei Outlook Web App anzumelden, bevor der DNS-Cache in Internet Explorer aktualisiert wurde. Dies kann dadurch behoben werden, indem der Benutzer alle Browserfenster schließt, um die Aktualisierung des DNS-Caches durch Internet Explorer zu erzwingen. Weitere Informationen zum DNS-Cache in Internet Explorer finden Sie unter Verwendung des Cache für DNS-Hosteinträge in Internet Explorer.

Um dies zu vermeiden, erstellen Sie einen zweiten DNS-Eintrag für den Clientzugriffsserver und verwenden dann das Cmdlet Set-OwaVirtualDirectory, um den Parameter FailbackUrl passend zu konfigurieren. Der Parameter FailbackUrl gibt den Hostnamen an, den Outlook Web App zum Herstellen einer Verbindung mit dem Clientzugriffsserver nach einem Failback in einem Vorgang zur Ausfallsicherheit von Standorten verwendet, und erfordert einen separaten DNS-Eintrag, der auf die IP-Adresse des ursprünglichen Clientzugriffsservers verweist. Der Parameter FailbackUrl muss sich vom Parameter ExternalUrl unterscheiden.

In diesem Beispiel wird der Parameter FailbackUrl konfiguriert.

Set-owavirtualdirectory -identity "owa (default web site)" -FailbackUrl "<failback URL>"

Weitere Informationen zu Syntax und Parametern finden Sie unter Set-OwaVirtualDirectory.

Problembehandlung bei Fehlern mit dem Zertifikat-Assistenten

Exchange 2010 verwendet Microsoft Windows HTTP-Dienste (WinHTTP) zur Verwaltung des gesamten HTTP/HTTPS-Datenverkehrs. Daher verwendet Exchange 2010 nicht die Proxyservereinstellungen, die möglicherweise im Webbrowser konfiguriert sind. WinHTTP verwendet das Web Proxy Autodiscovery Protocol (WPAD). Dafür muss eine PAC-Datei (Proxy Access Control) über DHCP oder DNS angegeben sein.

Wenn die WinHTTP-Proxyeinstellungen nicht korrekt konfiguriert sind, können die folgenden Probleme auftreten:

  1. Nach dem Import eines gültigen Zertifikats eines Drittanbieters in einen Exchange 2010-Clientzugriffsserver gibt die Exchange-Verwaltungskonsole möglicherweise den folgenden Status aus: Der Zertifikatstatus konnte nicht ermittelt werden, da die Sperrungsüberprüfung keinen Erfolg hatte

  2. Wenn Sie das Cmdlet Get-ExchangeCertificate in der Exchange-Verwaltungsshell ausführen, wird der folgende Status für das importierte Zertifikat angezeigt: Status: RevocationCheckFailure

Gehen Sie wie folgt vor, um diese Probleme zu beheben:

  1. Geben Sie den folgenden Befehl an der Eingabeaufforderung ein, und drücken Sie die EINGABETASTE, um die WinHTTP-Proxyeinstellungen aufzulisten: netsh winhttp show proxy. In der Antwort werden die aktuellen Proxyinformationen angezeigt, die von Exchange verwendet werden. Sie erhalten typischerweise die folgende oder eine ähnliche Antwort:

    C:\>netsh winhttp show proxy 
    
    Current WinHTTP proxy settings: 
    
    Direct access (no proxy server)
    
  2. Wenn der korrekte Server nicht in der Antwort identifiziert wird, können Sie die Proxyeinstellungen für WinHTTP mithilfe des Befehls "netsh" konfigurieren. Konfigurieren Sie den FQDN des Servers in der Umgehungsliste, sodass die Exchange-Verwaltungsshell und die Exchange-Verwaltungskonsole die Remote-PowerShell kontaktieren können.

  3. Geben Sie dazu an der Eingabeaufforderung folgenden Befehl ein, und drücken Sie dann die EINGABETASTE: netsh winhttp set proxy proxy-server="http=<Proxy_Server_Name>" bypass-list="*.<Exchange_Server_Hostname_Domain>"

    Hinweis

    Ersetzen Sie den Platzhalter <Proxy_Server_Name> durch den Namen des Proxyservers. Ersetzen Sie auch den Platzhalter <Exchange_Server_Hostname_Domain> mithilfe des Domänennamens der zweiten Ebene und dem Domänennamen der ersten Ebene von Exchange Server (z. B. microsoft.com)

  4. Schließen und öffnen Sie die Exchange-Verwaltungskonsole. Überprüfen Sie den Status des Zertifikats. Wenn die Proxyeinstellungen korrekt sind, der Zertifikatstatus jedoch noch immer nicht, können Sie die folgenden Befehle an der Eingabeaufforderung ausführen, um den OCSP/CRL-Cache zu löschen:

    certutil -urlcache ocsp delete

    certutil -urlcache crl delete

  5. Starten Sie den Server neu. und öffnen die Exchange-Verwaltungskonsole, um den Status des Zertifikats zu überprüfen.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.