Problembehandlung beim DataProtection-Integritätssatz
Gilt für: Exchange Server 2013
Mit dem DataProtection-Integritätssatz wird die Redundanz von Datenbanken in einer Database Availability Group (DAG) überwacht.
Wenn Sie eine Warnung erhalten, die angibt, dass DataProtection fehlerhaft ist, weist dies auf ein Problem hin, das sich auf die Replikations- oder Clusterkomponenten auswirken kann und den Zugriff auf die Exchange-Datenbanken verhindern kann.
Erklärung
Der DataProtection-Integritätsdienst wird mithilfe der folgenden Tests und Monitore überwacht.
Sonde | Integritätssatz | Abhängigkeiten | Zugehörige Monitore |
---|---|---|---|
ClusterEndpointProbe | Datenschutz | Active Directory | ClusterEndpointMonitor |
ClusterGroupProbe | Datenschutz | Active Directory | ClusterGroupMonitor |
ClusterNetworkProbe | Datenschutz | Active Directory | ClusterNetworkMonitor |
ClusterServiceCrashProbe | Datenschutz | Active Directory | ClusterServiceCrashMonitor |
ServerOneCopyProbe | Datenschutz | Active Directory | ServerOneCopyMonitor |
ServerOneCopyInternalMonitorProbe | Datenschutz | Active Directory | ServerOneCopyInternalMonitorMonitor |
ServiceHealthMSExchangeReplEndpointProbe | Datenschutz | Active Directory | ServiceHealthMSExchangeReplEndpointMonitor |
ServiceHealthMSExchangeReplCrashProbe | Datenschutz | Active Directory | ServiceHealthMSExchangeReplCrashMonitor |
ServerSiteFailureProbe | Datenschutz | Active Directory | ServerSiteFailureMonitor |
StorageApparentControllerIssuesProbe | Datenschutz | Active Directory | StorageApparentControllerIssuesMonitor |
DatabaseHealthTooManyMountedDatabaseProbe | Datenschutz | Active Directory | DatabaseHealthTooManyMountedDatabaseMonitor |
Weitere Informationen zu Tests und Monitoren finden Sie unter Serverintegrität und -leistung.
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 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 Autodiscover.Protocol-Integritätssatzes zu "server1.contoso.com" abzurufen, führen Sie den folgenden Befehl aus:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover.Protocol"}
Ü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
.Identifizieren Sie den Test, auf dem der Monitor basiert. Beachten Sie, dass die meisten Tests dasselbe Namenspräfix besitzen. Suchen Sie im vorherigen Beispiel nach "ClusterNetwork*":
Get-MonitoringItemIdentity -Identity DataProtection -Server server1.contoso.com | ?{$_.Name -like "ClusterNet ItemType work*"}
Die zurückgegebenen Ergebnisse sollten ähnlich wie folgt aussehen.
ItemType HealthSetName Name TargetResource Probe
DataProtection
ClusterNetworkProbe
MSExchangeRepl
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 AutodiscoverSelfTestMonitor als fehlgeschlagenen Monitor an. Der diesem Monitor zugeordnete Test ist AutodiscoverSelfTestProbe. Um diesen Test auf "server1.contoso.com" auszuführen, führen Sie den folgenden Befehl aus:
Invoke-MonitoringProbe Autodiscover.Protocol\AutodiscoverSelfTestProbe -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.
Schritte zur Problembehandlung
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
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.
Bei den meisten Problemen, die in Umgebungen mit hoher Verfügbarkeit auftreten, können Sie das Cmdlet Test-ReplicationHealth ausführen, um die Problembehandlung von Cluster/Netzwerk/ActiveManager/Diensten zu unterstützen. Für andere Integritätssätze/Komponenten sind andere "Test-*"-Cmdlets vorhanden.
Beispiel:
Test-ReplicationHealth <ServerName>
Die zurückgegebenen Ergebnisse ähneln der folgenden Tabelle:
Server | Scheck | Result |
---|---|---|
<Servername> | ClusterService |
Passed |
<Servername> | ReplayService |
Passed |
<Servername> | ActiveManager |
Passed |
<Servername> | TasksRpcListener |
Passed |
<Servername> | TcpListener |
Passed |
<Servername> | ServerLocatorService |
Passed |
<Servername> | DagMembersUp |
Passed |
<Servername> | ClusterNetwork |
Passed |
<Servername> | QuorumGroup |
Passed |
<Servername> | FileShareQuorum |
Passed |
<Servername> | DatabaseRedundancyCheck |
Passed |
<Servername> | DatabaseAvailabilityCheck |
Passed |
<Servername> | DBCopySuspended |
Passed |
<Servername> | DBCopyFailed |
Übergeben |
<Servername> | DBInitializing |
Passed |
<Servername> | DBDisconnected |
Passed |
<Servername> | DBLogCopyKeepingUp |
Passed |
<Servername> | DBLogReplayKeepingUp |
Passed |
Wenn für alle Komponenten in der Spalte Ergebnis der Wert Erfüllt angezeigt wird, versuchen Sie, den zugeordneten Test, wie im Abschnitt Verifying the issue still exists in Schritt 2c gezeigt, erneut auszuführen.
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.