Freigeben über

Problembehandlung beim EWS-Integritätssatz

Gilt für: Exchange Server 2013

Der EwS-Integritätssatz (Exchange Web Services) überwacht die Gesamtintegrität des EWS-Diensts. Der EWS-Integritätssatz steht in enger Beziehung mit den folgenden Integritätssätzen:

Problembehandlung beim EWS.Protocol-Integritätssatz

Problembehandlung beim EWS.Proxy-Integritätssatz

Wenn Sie eine Warnung erhalten, die angibt, dass EWS fehlerhaft ist, weist dies auf ein Problem hin, das Ihre Benutzer an der Kommunikation mit dem Exchange-Server hindert.

Erklärung

EWS wird mithilfe der folgenden Tests und Monitore überwacht.

Sonde Integritätssatz Abhängigkeiten Zugehörige Monitore
EwsCtpProbe EWS Informationsspeicher

Active Directory-Domänendienste (AD DS)		 EwsCtpMonitor (EWS-Integritätssatz)
EwsSelfTestProbe EWS. Protokoll Active Directory-Domänendienste (AD DS) EWSSelfTestMonitor
EwsDeepTestProbe EWS. Protokoll Informationsspeicher EWSDeepTestMonitor

Dieser Test führt unter Verwendung eines Überwachungskontos eine vollständige EWS-Anmeldung vom Clientzugriffsserver aus bei einem Postfachserver durch. Dieser Test ruft die Methode GetFolder für EWS auf. 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:

  • Zwischen dem von dem Test verwendeten Authentifizierungsmechanismus und dem, der im virtuellen Verzeichnis des Clientzugriffsservers verwendet wird, besteht ein Konflikt.
  • Der EWS-Anwendungspool im überwachten CAS reagiert nicht.
  • Der Clientzugriffsserver hat Netzwerkprobleme beim Herstellen einer Verbindung mit dem Postfachserver.
  • Der Clientzugriffsserver hat Kommunikationsprobleme beim Herstellen einer Verbindung mit Domänencontrollern.
  • Die Domänencontroller reagieren nicht.
  • Der EWS-Anwendungspool, der sich auf mindestens einem Postfachserver befindet, reagiert nicht.
  • Die Datenbank des Benutzers ist nicht eingebunden, oder der Informationsspeicher ist für ein bestimmtes Postfach nicht verfügbar.
  • Der Informationsspeicherdienst auf mindestens einem Postfachserver hat Probleme.

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

  1. Identifizieren des Namens des Integritätssatzes sowie des Servernamens in der Warnung.

    Wenn Sie eine Warnung von diesem Integritätssatz erhalten, enthält die E-Mail folgende Informationen:

    1. Name des Clientzugriffsservers, von dem die Warnung stammt

    2. Name des Postfachservers, der von dem Test als Zielressource überwacht wurde

    3. Vollständige Ausnahmeablaufverfolgung des letzten Fehlers, einschließlich Diagnosedaten und spezifischer HTTP-Headerinformationen

    4. Uhrzeit des Auftretens des Vorfalls

    5. Verwendeter Authentifizierungsmechanismus und Anmeldeinformationen

    Die Informationen der Ausnahmeablaufverfolgung bieten den wichtigsten Hinweis auf die Ursache für das Fehlschlagen des Tests. Die Eskalationsnachricht enthält auch die folgenden HTTP-Header:

    1. X-FEServer: Gibt an, auf welchem CAS der Test ausgeführt wurde.

    2. X-TargetBEServer: Gibt an, an welchen MBX-Server die Anforderung weitergeleitet wird.

    3. X-DiagInfo: Gibt den MBX-Server an, der die Anforderung empfangen hat.

  2. 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:

    1. Öffnen Sie die Exchange-Verwaltungsshell, und führen Sie dann 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 EWS-Integritätssatzes zu "server1.contoso.com" abzurufen, führen Sie den folgenden Befehl aus:

      Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS"}

    2. Ü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.

    3. 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-List

      Nehmen wir beispielsweise für den EWS-Integritätssatz EWSCtpMonitor als fehlgeschlagenen Monitor an. Der diesem Monitor zugeordnete Test ist EWSCtpProbe. Um diesen Test auf "server1.contoso.com" auszuführen, führen Sie den folgenden Befehl aus:

      Invoke-MonitoringProbe EWS\EWSCtpProbe -Server server1.contoso.com | Format-List

    4. Ü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.

EwsCtpMonitor-Wiederherstellungsaktionen

  1. Starten Sie den IIS-Manager, und stellen Sie dann eine Verbindung mit dem Server her, der das Problem meldet, um festzustellen, ob der Anwendungspool MSExchangeServicesAppPool sowohl auf dem Zertifizierungsstellenserver als auch auf dem Postfachserver ausgeführt wird.

  2. Suchen Sie die Postfachdatenbank für fehlgeschlagene Tests. Überprüfen Sie dann, ob die Postfachdatenbank auf dem Postfachserver aktiv und ob der Postfachspeicher fehlerfrei ist.

  3. Klicken Sie auf Anwendungspools, und verwenden Sie dann den Anwendungspool MSExchangeServicesAppPool , indem Sie den folgenden Befehl ausführen:

    %SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

  4. Führen Sie den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut aus.

  5. Wenn das Problem weiterhin besteht, starten Sie den gesamten IIS-Dienst neu, indem Sie das Hilfsprogramm "IISReset" verwenden.

  6. Führen Sie den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut aus.

  7. Wenn das Problem weiterhin besteht, überprüfen Sie die Protokolldateien auf dem Clientzugriffsserver und den Postfachservern. Die Protokollprotokolle für den CAS befinden sich im Ordner %ExchangeInstallPath%Logging\HttpProxy\Ews . Auf dem Postfachserver befinden sich die Protokolle im Ordner %ExchangeInstallPath%Logging\Ews .

  8. Erstellen Sie ein Testbenutzerkonto, und melden Sie sich dann an, indem Sie das Testbenutzerkonto auf dem angegebenen Clientzugriffsserver ausführen. Melden Sie sich beispielsweise mit an: https://<servername>/ews/exchange.asmx. Wenn das Problem weiterhin besteht, versuchen Sie es mit einem anderen Clientzugriffsserver, um zu bestimmen, ob das Problem nur diesen Clientzugriffsserver betrifft und nicht auch den Postfachserver. Wenn der Testbenutzername erfolgreich ist, kann sich ein Problem auf die bestimmte Postfachdatenbank oder den Postfachserver auswirken, auf dem sich das Überwachungspostfach befindet. Versuchen Sie, diesen Schritt zu wiederholen, indem Sie ein Testkonto verwenden, das in der Postfachdatenbank vorhanden ist.

  9. Überprüfen Sie die Netzwerkkonnektivität zwischen dem Clientzugriffsserver und dem Postfachserver.

  10. Überprüfen Sie den EWS.Proxy-Integritätssatz auf Warnungen, die auf ein Problem hinweisen können, das einen bestimmten Clientzugriffsserver betrifft.

  11. Überprüfen Sie den EWS.Protocol-Integritätssatz auf Warnungen, die auf ein Problem hinweisen können, das einen bestimmten Postfachserver betrifft.

  12. Wenn das Problem weiterhin besteht, starten Sie den Server neu. Führen Sie hierzu zuerst ein Failover der Datenbanken durch, die auf dem Server gehostet sind. Führen Sie dazu den folgenden Befehl aus:

    Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $true

    Hinweis: Ersetzen Sie in diesem und allen nachfolgenden Codebeispielen server1.contoso.com durch den tatsächlichen Servernamen.

  13. Überprüfen Sie, ob alle Datenbanken von dem Server, der das Problem meldet, verschoben wurden. Führen Sie dazu den folgenden Befehl aus:

    Get-MailboxDatabaseCopyStatus -Server server1.contoso.com | Group Status

    Wenn die Ausgabe des Befehls keine aktiven Kopien mehr auf dem Server anzeigt, starten Sie den Server neu.

  14. 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.

  15. Ist der Test erfolgreich, führen Sie ein Failover der Datenbanken zurück auf den Postfachserver durch, indem Sie den folgenden Befehl ausführen:

    Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false

  16. 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.

Weitere Informationen

Exchange PowerShell

Neuerungen in Exchange 2013