Freigeben über

Behandeln von Problemen mit der Agentkonnektivität in Operations Manager

  • Artikel

Diese Anleitung hilft Ihnen bei der Behebung von Problemen, die Operations Manager-Agenten bei der Verbindung mit dem Verwaltungsserver in System Center 2012 Operations Manager (OpsMgr 2012) und späteren Versionen haben.

Weitere Informationen zum Operations Manager-Agent und zur Kommunikation mit Verwaltungsservern finden Sie unter Agents und Communication Between Agents and Management Servers.

Ursprüngliche Produktversion: System Center 2012 Operations Manager
Ursprüngliche KB-Nummer: 10066

Überprüfen des Integritätsdiensts

Stellen Sie beim Auftreten von Konnektivitätsproblemen in Operations Manager zuerst sicher, dass die Integritätsdienst ohne Fehler sowohl auf dem Client-Agent als auch auf dem Verwaltungsserver ausgeführt wird. Führen Sie die folgenden Schritte aus, um festzustellen, ob der Dienst ausgeführt wird:

  1. Drücken Sie die WINDOWS-TASTE+R.

  2. Geben Sie services.msc im Feld "Ausführen" die EINGABETASTE ein, und drücken Sie die EINGABETASTE.

  3. Suchen Sie den Microsoft Monitoring Agent-Dienst , und doppelklicken Sie dann darauf, um die Seite "Eigenschaften" zu öffnen.

    Notiz

    In System Center 2012 Operations Manager lautet der Dienstname System Center Management.

  4. Stellen Sie sicher, dass der Starttyp auf "Automatisch" festgelegt ist.

  5. Überprüfen Sie, ob "Gestartet" im Dienststatus angezeigt wird. Klicken Sie andernfalls auf "Start".

Überprüfen auf Antivirenausschlüsse

Wenn die Integritätsdienst ausgeführt wird, müssen Sie als Nächstes bestätigen, dass Antivirenausschlüsse ordnungsgemäß konfiguriert sind. Die neuesten Informationen zu empfohlenen Antivirenausschlüssen für Operations Manager finden Sie unter Empfehlungen für Antivirenausschlüsse, die sich auf Operations Manager beziehen.

Überprüfen auf Netzwerkprobleme

In Operations Manager muss der Agentcomputer erfolgreich eine Verbindung mit TCP-Port 5723 auf dem Verwaltungsserver herstellen können. Wenn dies fehlschlägt, erhalten Sie wahrscheinlich die Ereignis-ID 21016 und 21006 für den Client-Agent.

Zusätzlich zu TCP-Port 5723 müssen die folgenden Ports aktiviert sein:

  • TCP- und UDP-Port 389 für LDAP
  • TCP- und UDP-Port 88 für kerberos-Authentifizierung
  • TCP- und UDP-Port 53 für Domain Name Service (DNS)

Darüber hinaus müssen Sie sicherstellen, dass die RPC-Kommunikation erfolgreich über das Netzwerk abgeschlossen wurde. Probleme mit der RPC-Kommunikation manifestieren sich in der Regel selbst, wenn ein Agent vom Verwaltungsserver übertragen wird. RPC-Kommunikationsprobleme verursachen in der Regel einen Fehler, der dem Client-Push ähnelt:

Der Operation Manager-Server konnte den angegebenen Vorgang auf dem Computer agent1.contoso.com nicht ausführen.

Vorgang: Agent-Installation
Installationskonto: contoso\Agent_action
Fehlercode: 800706BA
Fehlerbeschreibung: Der RPC-Server ist nicht verfügbar.

Dieser Fehler tritt in der Regel auf, wenn entweder nicht standardmäßige ephemerale Ports verwendet werden oder wenn die kurzlebigen Ports von einer Firewall blockiert werden. Wenn beispielsweise nicht standardmäßige RPC-Ports mit hohem Bereich konfiguriert wurden, zeigt eine Netzwerkablaufverfolgung eine erfolgreiche Verbindung mit RPC-Port 135 gefolgt von einem Verbindungsversuch mit einem nicht standardmäßigen RPC-Port wie 15595 an. Es folgt ein Beispiel:

18748 MS Agent TCP TCP: Flags=CE.... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192
18750 MS Agent TCP:[SynReTransmit #18748] Flags=CE.... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0,
18751 MS Agent TCP TCP:[SynReTransmit #18748] Flags=...... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192

Da in diesem Beispiel die Portausnahme für diesen nicht standardmäßigen Bereich nicht für die Firewall konfiguriert wurde, werden die Pakete verworfen, und die Verbindung schlägt fehl.

In Windows Vista und höheren Versionen sind die RPC High Range Ports 49152-65535, sodass wir suchen möchten. Um zu überprüfen, ob dies Ihr Problem ist, führen Sie den folgenden Befehl aus, um zu sehen, welche rpc high port range konfiguriert ist:

netsh int ipv4 show dynamicportrange tcp

Nach IANA-Standards sollte die Ausgabe wie folgt aussehen:

Dynamischer Tcp-Portbereich des Protokolls
---------------------------------
Startport : 49152
Anzahl der Ports : 16384

Wenn ein anderer Startport angezeigt wird, liegt das Problem möglicherweise darin, dass die Firewall nicht ordnungsgemäß konfiguriert ist, um Datenverkehr über diese Ports zuzulassen. Sie können die Konfiguration in der Firewall ändern oder den folgenden Befehl ausführen, um die Ports mit hohem Bereich wieder auf ihre Standardwerte festzulegen:

netsh int ipv4 set dynamicport tcp start=49152 num=16384

Sie können den dynamischen RPC-Portbereich auch über die Registrierung konfigurieren. Weitere Informationen finden Sie unterKonfigurieren der dynamischen RPC-Portzuweisung für den Firewall-Einsatz.

Wenn alles ordnungsgemäß konfiguriert ist und der Fehler weiterhin auftritt, kann dies durch eine der folgenden Bedingungen verursacht werden:

  1. DCOM wurde auf einen bestimmten Port beschränkt. Um zu überprüfen, führen Sie die Standardprotokolle für "Meine Computereigenschaften>>" aus, stellen Sie sicher, dass keine benutzerdefinierte Einstellung vorhanden ist.dcomcnfg.exe

  2. WMI ist für die Verwendung eines benutzerdefinierten Endpunkts konfiguriert. Um zu überprüfen, ob ein statischer Endpunkt für WMI konfiguriert ist, führen Sie die dcomcnfg.exeOption "Mein Computer>DCOM Config>Windows Management and Instrumentation>Properties Endpoints>" aus, stellen Sie sicher, dass keine benutzerdefinierte Einstellung vorhanden ist.

  3. Auf dem Agentcomputer wird die Exchange Server 2010-Clientzugriffsserverrolle ausgeführt. Der Exchange Server 2010-Clientzugriffsdienst ändert den Portbereich in 6005 bis 65535. Der Bereich wurde erweitert, um eine ausreichende Skalierung für große Bereitstellungen bereitzustellen. Ändern Sie diese Portwerte nicht, ohne die Konsequenzen vollständig zu verstehen.

Weitere Informationen zu Port- und Firewallanforderungen finden Sie unter Firewalls. Sie können auch die mindest erforderlichen Netzwerkkonnektivitätsgeschwindigkeiten im selben Artikel finden.

Notiz

Die Problembehandlung bei Netzwerkproblemen ist ein extrem großes Problem, daher empfiehlt es sich, einen Netzwerktechniker zu konsultieren, wenn Sie vermuten, dass ein zugrunde liegendes Netzwerkproblem Probleme mit der Agentkonnektivität in Operations Manager verursacht. Darüber hinaus haben wir einige grundlegende, generalisierte Informationen zur Problembehandlung im Netzwerk, die über unser Windows Directory Services-Supportteam zur Problembehandlung bei Netzwerken ohne NetMon verfügbar sind.

Überprüfen auf Zertifikatprobleme auf dem Gatewayserver

Operations Manager erfordert, dass die gegenseitige Authentifizierung zwischen Client-Agents und Verwaltungsservern vor dem Austausch von Informationen zwischen diesen ausgeführt wird. Um den Authentifizierungsprozess zu sichern, wird der Prozess verschlüsselt. Wenn sich der Agent und der Verwaltungsserver in derselben Active Directory-Domäne oder in Active Directory-Domänen befinden, die Vertrauensstellungen eingerichtet haben, verwenden sie die von Active Directory bereitgestellten Kerberos v5-Authentifizierungsmechanismen. Wenn die Agents und Verwaltungsserver nicht innerhalb derselben Vertrauensgrenze liegen, müssen andere Mechanismen verwendet werden, um die anforderung der sicheren gegenseitigen Authentifizierung zu erfüllen.

In Operations Manager erfolgt dies durch die Verwendung von X.509-Zertifikaten, die für jeden Computer ausgestellt wurden. Wenn viele von Agent überwachte Computer vorhanden sind, kann dies zu einem hohen Verwaltungsaufwand für die Verwaltung all dieser Zertifikate führen. Wenn es eine Firewall zwischen den Agents und Verwaltungsservern gibt, müssen darüber hinaus mehrere autorisierte Endpunkte definiert und in den Firewallregeln verwaltet werden, um die Kommunikation zwischen ihnen zu ermöglichen.

Um den Verwaltungsaufwand zu verringern, verfügt Operations Manager über eine optionale Serverrolle namens GatewayServer. Gatewayserver befinden sich innerhalb der Vertrauensgrenze der Client-Agents und können an der obligatorischen gegenseitigen Authentifizierung teilnehmen. Da Gateways innerhalb der gleichen Vertrauensgrenze wie die Agents liegen, wird das Kerberos v5-Protokoll für Active Directory zwischen den Agents und dem Gatewayserver verwendet, und jeder Agent kommuniziert dann nur mit den Gatewayservern, die es kennt.

Die Gatewayserver kommunizieren dann im Auftrag der Clients mit den Verwaltungsservern. Um die obligatorische sichere gegenseitige Authentifizierung zwischen dem Gatewayserver und den Verwaltungsservern zu unterstützen, müssen Zertifikate ausgestellt und installiert werden, jedoch nur für die Gateway- und Verwaltungsserver. Dadurch wird die Anzahl der erforderlichen Zertifikate reduziert. Im Falle einer dazwischen liegenden Firewall wird auch die Anzahl der autorisierten Endpunkte reduziert, die in den Firewallregeln definiert werden müssen.

Dies ist der Grund: Wenn die Client-Agents und Verwaltungsserver nicht innerhalb derselben Vertrauensgrenze liegen oder wenn ein Gatewayserver verwendet wird, müssen die erforderlichen Zertifikate installiert und ordnungsgemäß konfiguriert werden, damit die Agentkonnektivität ordnungsgemäß funktioniert. Im Folgenden finden Sie einige wichtige Punkte, die Sie überprüfen sollten:

  • Vergewissern Sie sich, dass das Gatewayzertifikat in persönlichen>Lokalen Computerzertifikaten> auf dem Verwaltungsserver vorhanden ist, mit dem das Gateway oder agent eine Verbindung herstellt.

  • Vergewissern Sie sich, dass das Stammzertifikat in >Zertifikaten für vertrauenswürdige Stammzertifizierungsstellen>auf dem Verwaltungsserver vorhanden ist, mit dem das Gateway oder agent eine Verbindung herstellt.

  • Vergewissern Sie sich, dass das Stammzertifikat in >Zertifikaten für vertrauenswürdige Stammzertifizierungsstellen>auf dem Gatewayserver vorhanden ist.

  • Vergewissern Sie sich, dass das Gatewayzertifikat in persönlichen>Lokalen Computerzertifikaten> auf dem Gatewayserver vorhanden ist. Vergewissern Sie sich, dass das Gatewayzertifikat in lokalen Computer>Operations Manager-Zertifikaten> auf dem Gatewayserver vorhanden ist.

  • Vergewissern Sie sich, dass der Registrierungswert HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber vorhanden ist und dass der Wert des Zertifikats (aus dem Ordner "Lokaler Computer/Personal/Zertifikate" innerhalb der Details im Feld "Seriennummer ") innerhalb des Zertifikats auf dem Gatewayserver umgekehrt wurde.

  • Vergewissern Sie sich, dass der Registrierungswert HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber vorhanden ist und den Wert des Zertifikats hat (aus dem Ordner "Lokaler Computer/Personal/Zertifikate" innerhalb der Details im Feld "Seriennummer ") auf dem Verwaltungsserver, mit dem das Gateway oder agent eine Verbindung herstellt.

Möglicherweise erhalten Sie die folgenden Ereignis-IDs im Operations Manager-Ereignisprotokoll, wenn ein Problem mit Zertifikaten besteht:

  • 20050
  • 20057
  • 20066
  • 20068
  • 20069
  • 20072
  • 20077
  • 21007
  • 21021
  • 21002
  • 21036

Ausführliche Informationen dazu, wie zertifikatbasierte Authentifizierungsfunktionen in Operations Manager funktionieren, sowie Anweisungen zum Abrufen und Konfigurieren der richtigen Zertifikate finden Sie unter Authentifizierung und Datenverschlüsselung für Windows-Computer.

Überprüfen auf einen nicht zusammenhängenden Namespace im Client-Agent

Ein nicht zusammenhängender Namespace tritt auf, wenn der Clientcomputer über ein primäres DNS-Suffix verfügt, das nicht mit dem DNS-Namen der Active Directory-Domäne übereinstimmt, zu der der Client gehört. Beispielsweise verwendet ein Client, der ein primäres DNS-Suffix von corp.contoso.com in einer Active Directory-Domäne verwendet, die mit dem Namen na.corp.contoso.com einen nicht zusammenhängenden Namespace verwendet.

Wenn der Client-Agent oder der Verwaltungsserver über einen nicht zusammenhängenden Namespace verfügt, kann die Kerberos-Authentifizierung fehlschlagen. Dies ist zwar ein Active Directory-Problem und kein Operations Manager-Problem, wirkt sich jedoch auf die Agentkonnektivität aus.

Weitere Informationen finden Sie unter Nicht zusammenhängender Namespace.

Verwenden Sie eine der folgenden Methoden, um das Problem zu beheben:

Methode 1

Erstellen Sie manuell die entsprechenden Dienstprinzipalnamen (SERVICE Principal Names, SPNs) für die betroffenen Computerkonten, und schließen Sie den Host-SPN für den vollqualifizierten Domänennamen (FQDN) zusammen mit dem nicht zusammenhängenden Namenssuffix (HOST/machine.disjointed_name_suffix.local) ein. Aktualisieren Sie außerdem das DnsHostName Attribut für den Computer, um den nicht zusammenhängenden Namen (machine.disjointed_name_suffix.local) widerzuspiegeln und die Registrierung für das Attribut in einer gültigen DNS-Zone auf den VON Active Directory verwendeten DNS-Servern zu aktivieren.

Methode 2

Korrigieren Sie den nicht zusammenhängenden Namespace. Ändern Sie dazu den Namespace in den Eigenschaften des betroffenen Computers so, dass er den FQDN der Domäne widerspiegelt, zu der der Computer gehört. Stellen Sie sicher, dass Sie sich der Konsequenzen bewusst sind, die dies tun, bevor Sie Änderungen in Ihrer Umgebung vornehmen. Weitere Informationen finden Sie unter Transition from a Disjoint Namespace to a Contiguous Namespace.

Überprüfen auf langsame Netzwerkverbindung

Wenn der Client-Agent über eine langsame Netzwerkverbindung ausgeführt wird, kann es zu Verbindungsproblemen kommen, da es ein hartcodiertes Timeout für die Authentifizierung gibt. Um dieses Problem zu beheben, installieren Sie System Center 2012 Operations Manager SP1 UpdateRollup 8 (vorausgesetzt, Sie befinden sich nicht bereits auf System Center 2012 R2 Operations Manager), und ändern Sie dann den Timeoutwert manuell.

Das UR8-Update erhöht das Servertimeout auf 20 Sekunden und das Clienttimeout auf 5 Minuten.

Weitere Informationen finden Sie unter UpdateRollup 8 für System Center 2012 Operations Manager Service Pack 1.

Notiz

Dieses Problem kann auch auftreten, wenn Zeitsynchronisierungsprobleme zwischen dem Client-Agent und dem Verwaltungsserver auftreten.

Überprüfen auf OpsMgr-Verbindungsprobleme

Wenn alles andere auscheckt, überprüfen Sie das Operations Manager-Ereignisprotokoll auf Fehlerereignisse, die vom OpsMgr Connector generiert wurden. Häufige Ursachen und Auflösungen für verschiedene OpsMgr Connector-Ereignisse sind unten aufgeführt.

Ereignis-ID 21006 und 21016 werden im Client-Agent angezeigt

Beispiele für diese Ereignisse:

Quelle: OpsMgr Connector
Datum: Uhrzeit
Ereignis-ID: 21006
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung: Der OpsMgr-Connector konnte keine Verbindung mit <ManagementServer>:5723 herstellen. Der Fehlercode ist 10060L (Ein Verbindungsversuch ist fehlgeschlagen, da die verbundene Partei nach einem bestimmten Zeitraum nicht ordnungsgemäß reagiert hat oder die Verbindung fehlgeschlagen ist, weil der verbundene Host nicht reagiert hat.) Überprüfen Sie, ob netzwerkkonnektivität vorhanden ist, der Server ausgeführt wird und den Überwachungsport registriert hat, und es gibt keine Firewalls, die den Datenverkehr an das Ziel blockieren.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: Uhrzeit
Ereignis-ID: 21016
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung: OpsMgr konnte keinen Kommunikationskanal für <ManagementServer> einrichten, und es gibt keine Failoverhosts. Die Kommunikation wird fortgesetzt, wenn <ManagementServer> verfügbar ist und die Kommunikation von diesem Computer zulässig ist.

In der Regel werden diese Ereignis-IDs generiert, da der Agent keine Konfiguration erhalten hat. Nachdem ein neuer Agent hinzugefügt wurde und bevor er konfiguriert ist, ist dieses Ereignis üblich. Ereignis 1210 im Operations Manager-Ereignisprotokoll des Agents gibt an, dass der Agent die Konfiguration empfangen und angewendet hat. Sie erhalten dieses Ereignis, nachdem die Kommunikation eingerichtet wurde.

Sie können die folgenden Schritte verwenden, um dieses Problem zu beheben:

  1. Wenn die automatische Genehmigung für manuell installierte Agents nicht aktiviert ist, bestätigen Sie, dass der Agent genehmigt wurde.

  2. Stellen Sie sicher, dass die folgenden Ports für die Kommunikation aktiviert sind:

    • 5723 und TCP- und UDP-Port 389 für LDAP.
    • TCP- und UDP-Port 88 für die Kerberos-Authentifizierung.
    • TCP- und UDP-Port 53 für DNS-Server.

  3. Dieses Ereignis kann potenziell darauf hinweisen, dass die Kerberos-Authentifizierung fehlschlägt. Überprüfen Sie in den Ereignisprotokollen und bei der Problembehandlung auf Kerberos-Fehler.

  4. Überprüfen Sie, ob das DNS-Suffix über eine falsche Domäne verfügt. Beispielsweise wird der Computer mit contoso1.com verbunden, aber das primäre DNS-Suffix ist auf contoso2.com festgelegt.

  5. Stellen Sie sicher, dass die Standardmäßigen Registrierungsschlüssel für Domänennamen korrekt sind. Stellen Sie sicher, dass die folgenden Registrierungsschlüssel ihrem Domänennamen entsprechen:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain

  6. Ein duplizierter SPN für die Integritätsdienst kann auch die Ereignis-ID 21016 verursachen. Führen Sie den folgenden Befehl aus, um das doppelte SPN zu finden:

    setspn -F -Q MSOMHSvc/<fully qualified name of the management server in the event>

    Wenn doppelte SPNs registriert sind, müssen Sie den SPN für das Konto entfernen, das nicht für den Verwaltungsserver Integritätsdienst verwendet wird.

Ereignis-ID 20057 wird auf dem Verwaltungsserver angezeigt

Beispiel für dieses Ereignis:

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: Zeit
Ereignis-ID: 20057
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:Fehler beim Initialisieren des Sicherheitskontexts für das Ziel MSOMHSvc/******Die zurückgegebene Fehler ist 0x80090311(Es konnte keine Autorität für die Authentifizierung kontaktiert werden.) Dieser Fehler kann entweder auf das Kerberos- oder das SChannel-Paket angewendet werden.

Ereignis-IDs 21006, 21016 und 20057 werden in der Regel durch Firewalls oder Netzwerkprobleme verursacht, die die Kommunikation über die erforderlichen Ports verhindern. Um dieses Problem zu beheben, überprüfen Sie die Firewalls zwischen dem Client-Agent und dem Verwaltungsserver. Die folgenden Ports müssen geöffnet sein, um die richtige Authentifizierung und Kommunikation zu aktivieren:

  • TCP- und UDP-Port 389 für LDAP.
  • TCP- und UDP-Port 88 für die Kerberos-Authentifizierung.

Ereignis-ID 2010 und 2003 werden im Client-Agent angezeigt

Beispiele für diese Ereignisse:

Protokollname: Operations Manager
Quelle: HealthService
Datum: Daten
Ereignis-ID: 2010
Aufgabenkategorie: Integritätsdienst
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung: Die Integritätsdienst kann keine Verbindung mit Active Directory herstellen, um die Verwaltungsgruppenrichtlinie abzurufen. Der Fehler ist nicht angegebener Fehler (0x80004005)
Event Xml:
<Ereignis xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="HealthService" />
<EventID Qualifiers="49152">2010/<EventID>
<Ebene>2</Ebene>
<Vorgang>1</Vorgang>
<Schlüsselwörter>0x80000000000000</Schlüsselwörter>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z" />
<EventRecordID>84143</EventRecordID>
<Channel>Operations Manager</Channel>
<Computer ComputerName></Computer>
<Sicherheit/>
</System>
<EventData>
<Daten>nicht angegebener Fehler</Daten>
<Daten>0x80004005</Daten>
</EventData>
</Ereignis>

Protokollname: Operations Manager
Quelle: HealthService
Datum: Zeit
Ereignis-ID: 2003
Aufgabenkategorie: Integritätsdienst
Ebene: Information
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung: Es wurden keine Verwaltungsgruppen gestartet. Dies kann entweder darauf zurückzuführen sein, dass derzeit keine Verwaltungsgruppen konfiguriert sind oder eine konfigurierte Verwaltungsgruppe nicht gestartet werden konnte. Die Integritätsdienst wartet auf die Richtlinie aus Active Directory, die eine Verwaltungsgruppe für die Ausführung konfiguriert.
Event Xml:
<Ereignis xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="HealthService" />
<EventID Qualifiers="16384">2003/<EventID>
<Ebene>4</Ebene>
<Vorgang>1</Vorgang>
<Schlüsselwörter>0x80000000000000</Schlüsselwörter>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z" />
<EventRecordID>84156</EventRecordID>
<Channel>Operations Manager</Channel>
<Computer ComputerName></Computer>
<Sicherheit/>
</System>
<EventData>
</EventData>
</Ereignis>

Wenn der Agent die Active Directory-Zuweisung verwendet, weisen die Ereignisprotokolle auch auf ein Problem bei der Kommunikation mit Active Directory hin.

Wenn diese Ereignisprotokolle angezeigt werden, vergewissern Sie sich, dass der Client-Agent auf Active Directory zugreifen kann. Überprüfen Sie Firewalls, Namensauflösung und allgemeine Netzwerkkonnektivität.

Ereignis-ID 20070 in Kombination mit Ereignis-ID 21016

Beispiele für diese Ereignisse:

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: 13.06.2014 10:13:39 Uhr
Ereignis-ID: 21016
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
OpsMgr konnte keinen Kommunikationskanal für <ComputerName> einrichten, und es gibt keine Failoverhosts. Die Kommunikation wird fortgesetzt, wenn <ComputerName> verfügbar ist und die Kommunikation von diesem Computer zulässig ist.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: 13.06.2014 10:13:37 Uhr
Ereignis-ID: 20070
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
Der OpsMgr-Connector ist mit ComputerName> verbunden<, die Verbindung wurde jedoch unmittelbar nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht berechtigt ist, mit dem Server zu kommunizieren, oder der Server hat keine Konfiguration erhalten. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000-Ereignissen, was angibt, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen.

Wenn diese Ereignisse angezeigt werden, gibt sie an, dass die Authentifizierung aufgetreten ist, die Verbindung aber geschlossen wurde. Dies tritt in der Regel auf, da der Agent nicht konfiguriert wurde. Um dies zu überprüfen, überprüfen Sie, ob die Ereignis-ID 20000 Ein Gerät, das nicht Teil dieser Verwaltungsgruppe ist, versucht hat, auf diesen Integritätsdienst zuzugreifen, auf dem Verwaltungsserver empfangen wird.

Diese Ereignisprotokolle können auch auftreten, wenn Client-Agents in einem Status "Ausstehend" hängen bleiben und nicht in der Konsole sichtbar sind.

Führen Sie zum Überprüfen den folgenden Befehl aus, um zu überprüfen, ob die Agents zur manuellen Genehmigung aufgeführt sind:

Get-SCOMPendingManagement

In diesem Fall können Sie dies beheben, indem Sie den folgenden Befehl ausführen, um die Agents manuell zu genehmigen:

Get-SCOMPendingManagement| Approve-SCOMPendingManagement

Ereignis-ID 21023 wird auf dem Client-Agent angezeigt, während die Ereignis-ID 29120, 29181 und 21024 auf dem Verwaltungsserver angezeigt wird.

Nachfolgend finden Sie einige Beispiele für diese Ereignisse.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 21023
Aufgabenkategorie: Keine
Ebene: Information
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
OpsMgr hat keine Konfiguration für die Verwaltungsgruppe <GroupName> und fordert eine neue Konfiguration vom Konfigurationsdienst an.

Protokollname: Operations Manager
Quelle: OpsMgr Management Configuration
Ereignis-ID: 29120
Aufgabenkategorie: Keine
Ebene: Warnung
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
Der Verwaltungskonfigurationsdienst von OpsMgr konnte die Konfigurationsanforderung (XML-Konfigurationsdatei oder Management Pack-Anforderung) aufgrund der folgenden Ausnahme nicht verarbeiten

Protokollname: Operations Manager
Quelle: OpsMgr Management Configuration
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
OpsMgr Management Configuration Service konnte die Arbeitsaufgabe des Moduls "GetNextWorkItem" aufgrund der folgenden Ausnahme nicht ausführen.

Protokollname: Operations Manager
Quelle: OpsMgr Management Configuration
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
OpsMgr Management Configuration Service konnte die Arbeitsaufgabe des Moduls "LocalHealthServiceDirtyNotification" aufgrund der folgenden Ausnahme nicht ausführen.

Protokollname: Operations Manager
Quelle: OpsMgr Management Configuration
Ereignis-ID 21024:
Aufgabenkategorie: Keine
Ebene: Information
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
Die Konfiguration von OpsMgr kann für die Verwaltungsgruppe <"GroupName>" veraltet sein und die aktualisierte Konfiguration vom Konfigurationsdienst angefordert haben. Das aktuelle(veraltete) Statuscookies ist "5dae4442500c9d3f8f7a883e83e83851994,906af60d48ed417fb1860b23ed67dd71:001662A3"

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <ComputerName>
Beschreibung:
OpsMgr Management Configuration Service konnte die Arbeitsaufgabe des Moduls "DeltaSynchronization" aufgrund der folgenden Ausnahme nicht ausführen.

Diese Ereignisse können auftreten, wenn der Delta-Synchronisierungsprozess keine Konfiguration innerhalb des konfigurierten Timeoutfensters von 30 Sekunden erstellen kann. Dies kann auftreten, wenn ein großer Instanzenbereich vorhanden ist.

Um dieses Problem zu beheben, erhöhen Sie das Timeout auf allen Verwaltungsservern. Verwenden Sie dazu eine der folgenden Methoden:

Methode 1

  1. Erstellen Sie eine Sicherungskopie der folgenden Datei:

    Laufwerk:\Programme\System Center 2012\Operations Manager\Server\ConfigService.Config

  2. Erhöhen Sie die Timeoutwerte ConfigService.config mit den folgenden Änderungen:

    Suchen , ändern Sie <OperationTimeout DefaultTimeoutSeconds="30">30 bis 300.
    Suchen , ändern Sie <Operation Name="GetEntityChangeDeltaList" TimeoutSeconds="180" />180 in 300.

  3. Starten Sie den Konfigurationsdienst neu.

In den meisten Fällen sollte dies genügend Zeit für den Abschluss des Synchronisierungsprozesses ermöglichen.

Methode 2

  1. Installieren Sie das Updaterollup 3 oder höher für System Center 2012 R2 Operations Manager.

  2. Fügen Sie den folgenden Registrierungswert auf dem Server hinzu, auf dem System Center 2012 R2 Operations Manager ausgeführt wird, um das Timeout zu konfigurieren:

    • Registrierungsunterschlüssel: HKEY_LOCAL_MACHINE\Software\Microsoft Operations Manager\3.0\Config Service
    • DWORD-Name: CommandTimeoutSeconds
    • DWORD-Wert: nn

    Notiz

    Der Standardwert für den Platzhalter nn beträgt 30 Sekunden. Sie können diesen Wert ändern, um das Timeout für die Deltasynchronisierung zu steuern.

Sonstige OpsMgr Connector Ereignis-IDs

Weitere OpsMgr Connector-Fehlerereignisse und die entsprechenden Problembehandlungsvorschläge sind unten aufgeführt:

Ereignis Beschreibung Weitere Informationen
20050 Das angegebene Zertifikat konnte nicht geladen werden, da die angegebene erweiterte Schlüsselverwendung nicht den Anforderungen von OpsMgr entspricht. Das Zertifikat muss über die folgenden Verwendungstypen verfügen: %n %n Serverauthentifizierung (1.3.6.1.5.5.7.3.1)%n Clientauthentifizierung (1.3.6.1.5.5.7.3.2)%n Bestätigen Sie den Objektbezeichner für das Zertifikat.
20057 Fehler beim Initialisieren des Sicherheitskontexts für ziel "%1". Der zurückgegebene Fehler ist %2(%3). Dieser Fehler kann entweder auf das Kerberos-Paket oder das SChannel-Paket angewendet werden. Suchen Sie nach doppelten oder falschen SPNs.
20066 Es wurde ein Zertifikat für die Verwendung mit der gegenseitigen Authentifizierung angegeben. Dieses Zertifikat konnte jedoch nicht gefunden werden. Die Fähigkeit für diese Integritätsdienst zu kommunizieren, wird wahrscheinlich beeinträchtigt. Er überprüft das Zertifikat.
20068 Das zertifikat, das in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings angegeben ist, kann nicht für die Authentifizierung verwendet werden, da das Zertifikat keinen verwendbaren privaten Schlüssel enthält oder weil der private Schlüssel nicht vorhanden ist. Der Fehler ist %1(%2). Suchen Sie nach einem fehlenden oder nicht zugeordneten privaten Schlüssel. Untersuchen Sie das Zertifikat. Importieren Sie das Zertifikat erneut, oder erstellen Sie ein neues Zertifikat und importieren Sie es.
20069 Das angegebene Zertifikat konnte nicht geladen werden, da die KeySpec AT_KEYEXCHANGE Er überprüft das Zertifikat. Überprüfen Sie den Objektbezeichner für das Zertifikat.
20070 Der opsMgr Connector ist mit %1 verbunden. Die Verbindung wurde jedoch unmittelbar nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht berechtigt ist, mit dem Server zu kommunizieren oder dass der Server keine Konfiguration empfangen hat. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000-Ereignissen. Diese geben an, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen. Die Authentifizierung ist aufgetreten, die Verbindung wurde jedoch geschlossen. Vergewissern Sie sich, dass Ports geöffnet sind, und überprüfen Sie, ob der Agent die Genehmigung aussteht.
20071 Der opsMgr Connector ist mit %1 verbunden. Die Verbindung wurde jedoch sofort ohne Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist ein Fehler beim Authentifizieren dieses Agents oder des Servers. Überprüfen Sie das Ereignisprotokoll auf dem Server und im Agent auf Ereignisse, die auf einen Fehler bei der Authentifizierung hinweisen. Authentication has failed. (Fehler bei der Authentifizierung.) Überprüfen Sie Firewalls und Port 5723. Der Agentcomputer muss port 5723 auf dem Verwaltungsserver erreichen können. Vergewissern Sie sich außerdem, dass TCP & UDP-Port 389 für LDAP, Port 88 für Kerberos und Port 53 für DNS verfügbar sind.
20072 Das Remotezertifikat "%1" war nicht vertrauenswürdig. Der Fehler ist %2(%3). Überprüfen Sie, ob sich das Zertifikat im vertrauenswürdigen Speicher befindet.
20077 Das in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings angegebene Zertifikat kann nicht für die Authentifizierung verwendet werden, da das Zertifikat nicht nach Eigenschafteninformationen abgefragt werden kann. Der spezifische Fehler ist %2(%3).%n %n. Dies bedeutet in der Regel, dass kein privater Schlüssel im Zertifikat enthalten war. Überprüfen Sie bitte, ob das Zertifikat einen privaten Schlüssel enthält. Ein fehlender oder nicht zugeordneter privater Schlüssel ist vorhanden. Untersuchen Sie das Zertifikat. Importieren Sie das Zertifikat erneut, oder erstellen Sie ein neues Zertifikat und importieren Sie es.
21001 Der OpsMgr-Connector konnte keine Verbindung mit %1 herstellen, da bei der gegenseitigen Authentifizierung ein Fehler aufgetreten ist. Stellen Sie sicher, dass der SPN ordnungsgemäß auf dem Server registriert ist und dass, wenn sich der Server in einer separaten Domäne befindet, eine voll vertrauenswürdige Beziehung zwischen den beiden Domänen besteht. Überprüfen Sie die SPN-Registrierung.
21005 Der OpsMgr-Connector konnte die IP für %1 nicht auflösen. Der Fehlercode ist %2(%3). Stellen Sie sicher, dass DNS in Ihrer Umgebung ordnungsgemäß funktioniert. Dies ist in der Regel ein Namensauflösungsproblem. Überprüfen Sie DNS.
21006 Der OpsMgr Connector konnte keine Verbindung mit %1:%2 herstellen. Der Fehlercode ist %3(%4). Vergewissern Sie sich, dass eine Netzwerkkonnektivität vorhanden ist, dass der Server ausgeführt wird und den Überwachungsport registriert hat und dass keine Firewalls vorhanden sind, die den Datenverkehr an das Ziel blockieren. Dies ist wahrscheinlich ein allgemeines Verbindungsproblem. Überprüfen Sie die Firewalls, und vergewissern Sie sich, dass Port 5723 geöffnet ist.
21007 Der OpsMgr-Connector kann keine sich gegenseitig authentifizierte Verbindung mit %1 erstellen, da er sich nicht in einer vertrauenswürdigen Domäne befindet. Es wird keine Vertrauensstellung eingerichtet. Vergewissern Sie sich, dass das Zertifikat vorhanden ist und ordnungsgemäß konfiguriert ist.
21016 OpsMgr konnte keinen Kommunikationskanal für %1 einrichten, und es gibt keine Failoverhosts. Die Kommunikation wird fortgesetzt, wenn %1 verfügbar ist und die Kommunikation von diesem Computer aktiviert ist. Dies weist in der Regel auf einen Authentifizierungsfehler hin. Vergewissern Sie sich, dass der Agent für die Überwachung genehmigt wurde und dass alle Ports geöffnet sind.
21021 Es konnte kein Zertifikat geladen oder erstellt werden. Diese Integritätsdienst kann nicht mit anderen Gesundheitsdiensten kommunizieren. Suchen Sie nach vorherigen Ereignissen im Ereignisprotokoll, um weitere Details zu erfahren. Er überprüft das Zertifikat.
21022 Es wurde kein Zertifikat angegeben. Diese Integritätsdienst kann nicht mit anderen Gesundheitsdiensten kommunizieren, es sei denn, diese Gesundheitsdienste befinden sich in einer Domäne, die eine Vertrauensstellung mit dieser Domäne hat. Wenn dieser Integritätsdienst mit Integritätsdiensten in nicht vertrauenswürdigen Domänen kommunizieren muss, konfigurieren Sie bitte ein Zertifikat. Er überprüft das Zertifikat.
21035 Fehler bei der Registrierung eines SPN für diesen Computer mit der Dienstklasse "%1" mit dem Fehler "%2". Dies kann dazu führen, dass die Kerberos-Authentifizierung zu oder von diesem Integritätsdienst fehlschlägt. Dies weist auf ein Problem mit der SPN-Registrierung hin. Untersuchen sie SPNs für die Kerberos-Authentifizierung.
21036 Das zertifikat, das in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings angegeben ist, kann nicht für die Authentifizierung verwendet werden. Der Fehler ist %1(%2). Dies ist in der Regel ein fehlender oder nicht zugeordneter privater Schlüssel. Untersuchen Sie das Zertifikat. Importieren Sie das Zertifikat erneut, oder erstellen Sie ein neues Zertifikat, und importieren Sie es.