Problembehandlung beim Autodiscover-Integritätssatz
Gilt für: Exchange Server 2013
Mit dem Autodiscover-Integritätssatz wird die Gesamtintegrität des AutoErmittlungsdiensts für Clients überwacht.
Wenn Sie eine Warnung erhalten, dass Autodiscover-Integritätsfehler vorliegen, weist dies auf ein Problem hin, das Benutzer eventuell am Zugriff auf ihre Postfächer mithilfe des AutoErmittlungsprozesses hindert.
Erklärung
Der AutoErmittlungsdienst wird mithilfe der folgenden Tests und Monitore überwacht.
| Sonde | Integritätssatz | Abhängigkeiten | Zugehörige Monitore |
|---|---|---|---|
| AutoDiscoverCtpProbe | AutoErmittlung | Active Directory | AutoDiscoverCtpMonitor |
Weitere Informationen zu Tests und Monitoren finden Sie unter Serverintegrität und -leistung.
Häufig auftretende Probleme
Bei diesem Test kann aus einer der folgenden häufigen Ursachen ein Fehler auftreten:
- Der AutoErmittlungs-Anwendungspool (MSExchangeAutodiscoverAppPool), der auf dem überwachten Clientzugriffsserver gehostet wird, reagiert nicht. Oder der AutoErmittlungs-Anwendungspool, der auf mindestens einem Postfachserver gehostet wird, reagiert nicht.
- Der Clientzugriffsserver hat Netzwerkprobleme und kann keine Verbindung mit dem Postfachserver oder dem Domänencontroller herstellen.
- Die Anmeldeinformationen des Überwachungskontos sind fehlerhaft.
- Die Domänencontroller reagieren nicht.
Benutzeraktion
Es ist möglich, dass der Dienst wiederhergestellt wurde, nachdem er die Warnung ausgegeben hat. Wenn Sie also eine Warnung erhalten, dass Integritätsfehler im Integritätssatz vorliegen, überprüfen Sie zuerst, ob das Problem noch besteht. Besteht das Problem noch, führen Sie die geeigneten Wiederherstellungsaktionen aus, die in den folgenden Abschnitten beschrieben sind.
Überprüfen des Vorhandenseins des Problems
Identifizieren des Namens des Integritätssatzes sowie des Servernamens in der Warnung.
Die Nachrichtendetails enthalten Informationen zur genauen Ursache für die Warnung. In den meisten Fällen bieten die Nachrichtendetails ausreichende Problembehandlungsinformationen, um die Fehlerursache zu identifizieren. Wenn die Nachrichtendetails nicht klar sind, gehen Sie wie folgt vor:
Öffnen Sie die Exchange-Verwaltungsshell, und führen Sie den folgenden Befehl aus, um die Details des Integritätssatzes abzurufen, der die Warnung ausgegeben hat:
Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}Um beispielsweise die Details des Autodiscover-Integritätssatzes zu "server1.contoso.com" abzurufen, führen Sie den folgenden Befehl aus:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover"}Überprüfen Sie die Ausgabe des Befehls, um zu bestimmen, von welchem Monitor der Fehler gemeldet wurde. Der AlertValue-Wert für den Monitor, der die Warnung ausgegeben hat, ist
Unhealthy.Führen Sie den zugeordneten Test für den Monitor erneut aus, der sich in einem fehlerhaften Zustand befindet. Den zugeordneten Test können Sie mithilfe der Tabelle im Abschnitt Explanation ermitteln. Führen Sie dazu den folgenden Befehl aus:
Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> | Format-ListNehmen wir beispielsweise AutodiscoverCtpMonitor als fehlgeschlagenen Monitor an. Der diesem Monitor zugeordnete Test ist AutodiscoverCtpProbe. Um diesen Test auf "server1.contoso.com" auszuführen, führen Sie den folgenden Befehl aus:
Invoke-MonitoringProbe Autodiscover\AutodiscoverCtpProbe -Server server1.contoso.com | Format-ListÜberprüfen Sie in der Ausgabe des Befehls den Wert von Ergebnis für den Test. Wenn der Wert Erfolgreich ist, hat es sich bei dem Problem um einen vorübergehenden Fehler gehandelt, der nicht mehr besteht. Andernfalls finden Sie Informationen in den Schritten zur Wiederherstellung, die in den folgenden Abschnitten beschrieben sind.
AutodiscoverCtpMonitor-Wiederherstellungsaktionen
Wenn Sie eine Warnung von einem Integritätssatz erhalten, enthält die E-Mail folgende Informationen:
- Name des Servers, von dem die Warnung gesendet wurde
- Name des Postfachservers, der von dem Test überwacht wurde
- Uhrzeit und Datum des Auftretens der Warnung
- Verwendeter Authentifizierungsmechanismus und Anmeldeinformationen
- Vollständige Ausnahmeablaufverfolgung des letzten Fehlers, einschließlich Diagnosedaten und spezifischer HTTP-Headerinformationen
Die in der vollständigen Ausnahmeablaufverfolgung enthaltenen Informationen können bei der Behandlung des Problems hilfreich sein. Die von dem Test generierte Ausnahme enthält eine Fehlerursache, die den Grund für das Fehlschlagen des Tests beschreibt. Beispielsweise kann die Fehlerursache eine der folgenden sein:
- X-FEServer: Gibt an, auf welchem CAS der Test ausgeführt wurde.
- X-CalculatedBETarget: Gibt den Postfachserver an, an den die Anforderung weitergeleitet wird.
- X-DiagInfo: Gibt den Postfachserver an, der die Anforderung empfangen hat.
Führen Sie zum Behandeln dieses Problems die folgenden Schritte aus:
Überprüfen Sie die Protokolle auf den Clientzugriffs- und Postfachservern. Protokollprotokolle auf dem CAS befinden sich standardmäßig im Ordner %ExchangeInstallPath%Logging\HttpProxy\Autoermittlung . Protokollprotokolldateien auf dem Postfachserver befinden sich standardmäßig im Ordner %ExchangeInstallPath%Logging\AutoErmittlung .
Erstellen Sie ein Testbenutzerkonto, und melden Sie sich dann beim Clientzugriffsserver an, indem Sie das Testbenutzerkonto verwenden. Melden Sie sich beispielsweise mit an:
https://<servername>/autodiscover/autodiscover.xml.Wenn der Testbenutzerkontoname erfolgreich ist, kann sich ein Problem auf den Postfachserver auswirken, auf dem das überwachte Postfach gehostet wird.
Versuchen Sie, die vorherigen Schritte zu wiederholen, indem Sie ein Testkonto auf dem Postfachserver verwenden. Sollte dieser Versuch fehlschlagen, versuchen Sie, den Test mit einem anderen Clientzugriffsserver erneut auszuführen, um zu überprüfen, ob das Problem auf einem bestimmten Clientzugriffsserver auftritt und nicht auf dem Postfachserver.
Überprüfen Sie die Netzwerkkonnektivität zwischen den Clientzugriffs- und Postfachservern. Verwenden Sie "ping.exe", um zu überprüfen, ob jeder Server antwortet.
Überprüfen Sie den Autodiscover.Proxy-Integritätssatz auf Warnungen, die auf ein Problem hinweisen können, das einen bestimmten Postfachserver betrifft. Weitere Informationen finden Sie unter Troubleshooting Autodiscover.Proxy Health Set.
Überprüfen Sie den Autodiscover.Protocol-Integritätssatz auf Warnungen, die auf ein Problem hinweisen können, das bestimmte Postfachserver betrifft. Weitere Informationen finden Sie unter Troubleshooting Autodiscover.Protocol Health Set.
Starten Sie den IIS-Manager, und stellen Sie eine Verbindung mit dem Server her, von dem das Problem gemeldet wird. Überprüfen Sie, ob der Anwendungspool MSExchangeAutodiscoverAppPool sowohl auf dem Clientzugriffsserver als auch auf den Postfachservern ausgeführt wird.
Klicken Sie im IIS-Manager auf Anwendungspools, und verwenden Sie dann den Anwendungspool MSExchangeAutodiscoverAppPool , indem Sie den folgenden Befehl ausführen:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutodiscoverAppPoolFühren Sie den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut aus.
Wenn das Problem weiterhin besteht, starten Sie den IIS-Dienst neu, indem Sie das Hilfsprogramm "IISReset" verwenden oder den folgenden Befehl ausführen:
Iisreset /noforceFühren Sie den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut aus.
Wenn das Problem weiterhin besteht, starten Sie den Server neu.
Führen Sie nach dem Neustart des Servers den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut aus.
Tritt weiterhin ein Fehler bei diesem Test auf, benötigen Sie eventuell Unterstützung zur Behebung dieses Problems. Wenden Sie sich zur Lösung des Problems an einen Microsoft-Supportspezialisten. Um einen Microsoft-Support Fachmann zu kontaktieren, besuchen Sie Support für Unternehmen, und wählen Sie dann Server>Exchange Server aus. Da es in Ihrer Organisation ein bestimmtes Verfahren für den direkten Kontakt mit dem Microsoft-Produktsupport geben kann, sollten Sie zuerst die Richtlinien Ihrer Organisation prüfen.