Behandeln von Agent-Konnektivitätsproblemen in Operations Manager

  • Artikel

Dieser Leitfaden hilft Ihnen bei der Behandlung von Problemen, bei denen Operations Manager-Agents Probleme beim Herstellen einer Verbindung mit dem Verwaltungsserver in System Center 2012 Operations Manager (OpsMgr 2012) und höheren Versionen haben.

Weitere Informationen zum Operations Manager-Agent und seiner Kommunikation mit Verwaltungsservern finden Sie unter Agents und Kommunikation zwischen Agents und Verwaltungsservern.

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

Überprüfen des Integritätsdiensts

Stellen Sie bei Verbindungsproblemen in Operations Manager zunächst sicher, dass der Integritätsdienst sowohl auf dem Client-Agent als auch auf dem Verwaltungsserver fehlerfrei ausgeführt wird. Führen Sie die folgenden Schritte aus, um zu ermitteln, ob der Dienst ausgeführt wird:

  1. Drücken Sie die Windows-Taste+R.

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

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

    Hinweis

    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 Dienst status angezeigt wird. Klicken Sie andernfalls auf Start.

Überprüfen von Antivirenausschlüssen

Wenn der Integritätsdienst aktiv ist und 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 von Netzwerkproblemen

In Operations Manager muss der Agent-Computer 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 auf dem 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 die Kerberos-Authentifizierung
  • TCP und UDP-Port 53 für Domain Name Service (DNS)

Darüber hinaus müssen Sie sicherstellen, dass die RPC-Kommunikation über das Netzwerk erfolgreich abgeschlossen wird. Probleme mit der RPC-Kommunikation treten in der Regel auf, wenn ein Agent vom Verwaltungsserver gepusht wird. RPC-Kommunikationsprobleme führen in der Regel dazu, dass der Clientpush mit einem Fehler ähnlich dem folgenden fehlschlägt:

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 kurzlebige Ports verwendet werden oder wenn die kurzlebigen Ports von einer Firewall blockiert werden. Wenn beispielsweise nicht standardmäßige RPC-Ports für hohe Reichweite konfiguriert wurden, zeigt eine Netzwerkablaufverfolgung eine erfolgreiche Verbindung mit RPC-Port 135 an, gefolgt von einem Verbindungsversuch mit einem nicht standardmäßigen RPC-Port wie 15595. 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 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 in der Firewall konfiguriert wurde, werden die Pakete gelöscht, und die Verbindung schlägt fehl.

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

netsh int ipv4 show dynamicportrange tcp

Gemäß den IANA-Standards sollte die Ausgabe wie folgt aussehen:

Protokoll tcp Dynamic Port Range
---------------------------------
Startport : 49152
Anzahl der Ports: 16384

Wenn ein anderer Startport angezeigt wird, besteht 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 für den hohen 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 unter Konfigurieren der dynamischen RPC-Portzuordnung für die Verwendung mit Firewalls.

Wenn anscheinend 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 dies zu überprüfen, führen Sie ausdcomcnfg.exe, wechseln Sie zuStandardprotokolle derEigenschaften> von "Mein Computer>", und stellen Sie sicher, dass keine benutzerdefinierte Einstellung vorhanden ist.

  2. WMI ist für die Verwendung eines benutzerdefinierten Endpunkts konfiguriert. Um zu überprüfen, ob Sie einen statischen Endpunkt für WMI konfiguriert haben, führen Sie ausdcomcnfg.exe, und wechseln Sie zu Arbeitsplatz>DCOM Konfiguration>Windows-Verwaltungs- und Instrumentierungseigenschaften>>Endpunkte. Stellen Sie sicher, dass keine benutzerdefinierte Einstellung vorhanden ist.

  3. Auf dem Agent-Computer wird die Serverrolle Exchange Server 2010-Clientzugriff 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 finden auch die mindestens erforderlichen Netzwerkkonnektivitätsgeschwindigkeiten in demselben Artikel.

Hinweis

Die Behandlung von Netzwerkproblemen ist ein extrem großes Problem. Daher sollten Sie sich am besten an einen Netzwerktechniker wenden, wenn Sie vermuten, dass ein zugrunde liegendes Netzwerkproblem Zu Problemen mit der Agent-Konnektivität in Operations Manager führt. Darüber hinaus finden Sie einige grundlegende, generalisierte Informationen zur Netzwerkproblembehandlung von unserem Supportteam für Windows-Verzeichnisdienste unter Problembehandlung von Netzwerken ohne NetMon.

Überprüfen von Zertifikatproblemen auf dem Gatewayserver

Operations Manager erfordert, dass die gegenseitige Authentifizierung zwischen Client-Agents und Verwaltungsservern vor dem Austausch von Informationen zwischen ihnen durchgeführt wird. Um den Authentifizierungsprozess zu schützen, 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, nutzen sie die kerberos v5-Authentifizierungsmechanismen, die von Active Directory bereitgestellt werden. 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 wird dies durch die Verwendung von X.509-Zertifikaten erreicht, die für jeden Computer ausgestellt werden. Wenn viele Computer mit Agent-Überwachung vorhanden sind, kann dies zu einem hohen Verwaltungsaufwand für die Verwaltung all dieser Zertifikate führen. Wenn eine Firewall zwischen den Agents und Verwaltungsservern vorhanden ist, müssen außerdem mehrere autorisierte Endpunkte in den Firewallregeln definiert und verwaltet werden, um die Kommunikation zwischen ihnen zu ermöglichen.

Um den Verwaltungsaufwand zu reduzieren, 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 derselben 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 er kennt.

Die Gatewayserver kommunizieren dann im Namen 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 das Gateway und die Verwaltungsserver. Dadurch wird die Anzahl der erforderlichen Zertifikate reduziert. Im Fall einer dazwischen liegenden Firewall wird auch die Anzahl der autorisierten Endpunkte reduziert, die in den Firewallregeln definiert werden müssen.

Wenn sich die Client-Agents und Verwaltungsserver nicht innerhalb derselben Vertrauensgrenze befinden oder ein Gatewayserver verwendet wird, müssen die erforderlichen Zertifikate installiert und konfiguriert werden, damit die Agent-Konnektivität ordnungsgemäß funktioniert. Hier sind einige wichtige Punkte, die Sie überprüfen sollten:

  • Vergewissern Sie sich, dass das Gatewayzertifikat unterPersönliche>Zertifikate für den lokalen Computer> auf dem Verwaltungsserver vorhanden ist, mit dem das Gateway oder der Agent eine Verbindung herstellt.

  • Vergewissern Sie sich, dass das Stammzertifikat unter Lokale Computer>vertrauenswürdige Stammzertifizierungsstellen>Zertifikate auf dem Verwaltungsserver vorhanden ist, mit dem das Gateway oder der Agent eine Verbindung herstellt.

  • Vergewissern Sie sich, dass das Stammzertifikat unterZertifikate dervertrauenswürdigen Stammzertifizierungsstellen> des lokalen Computers> auf dem Gatewayserver vorhanden ist.

  • Vergewissern Sie sich, dass das Gatewayzertifikat unter Local Computer>Personal>Certificates auf dem Gatewayserver vorhanden ist. Vergewissern Sie sich, dass das Gatewayzertifikat unter Lokale Computer>OperationsManager-Zertifikate> 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 in den Details im Feld Seriennummer ) 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 dass der Wert des Zertifikats (aus dem Ordner Lokaler Computer/Personal/Zertifikate in den Details im Feld Seriennummer ) darin auf dem Verwaltungsserver, mit dem das Gateway oder der Agent eine Verbindung herstellt, umgekehrt wurde.

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

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

Ausführliche Informationen zur Funktionsweise der zertifikatbasierten Authentifizierung in Operations Manager sowie Anweisungen zum Abrufen und Konfigurieren der richtigen Zertifikate finden Sie unter Authentifizierung und Datenverschlüsselung für Windows-Computer.

Suchen nach einem nicht zusammenhängenden Namespace auf dem 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 das primäre DNS-Suffix corp.contoso.com in einer Active Directory-Domäne mit dem Namen na.corp.contoso.com verwendet, einen nicht zusammenhängenden Namespace.

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

Weitere Informationen finden Sie unter Disjoint 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 aktivieren Sie die Registrierung für das Attribut in einer gültigen DNS-Zone auf den VON Active Directory verwendeten DNS-Servern.

Methode 2

Korrigieren Sie den nicht zusammenhängenden Namespace. Ändern Sie hierzu den Namespace in den Eigenschaften des betroffenen Computers, um den FQDN der Domäne widerzuspiegeln, zu der der Computer gehört. Stellen Sie sicher, dass Sie sich der Konsequenzen dieser Vorgehensweise vollständig bewusst sind, bevor Sie Änderungen an Ihrer Umgebung vornehmen. Weitere Informationen finden Sie unter Übergang von einem disjoint-Namespace zu einem zusammenhängenden Namespace.

Überprüfen auf langsame Netzwerkverbindung

Wenn der Client-Agent über eine langsame Netzwerkverbindung ausgeführt wird, kann es aufgrund eines hartcodierten Timeouts für die Authentifizierung zu Konnektivitätsproblemen kommen. Um dieses Problem zu beheben, installieren Sie System Center 2012 Operations Manager SP1 Update Rollup 8 (vorausgesetzt, Sie sind noch nicht in System Center 2012 R2 Operations Manager) und ändern sie dann manuell den Timeoutwert.

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.

Hinweis

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

Suchen nach OpsMgr Connector-Problemen

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

Ereignis-ID 21006 und 21016 werden auf dem 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: Nicht zutreffend
Computer: <ComputerName>
Beschreibung: Der OpsMgr-Connector konnte keine Verbindung mit ManagementServer>:5723 herstellen<. Der Fehlercode ist 10060L (Ein Verbindungsversuch ist fehlgeschlagen, weil die verbundene Partei nach einem bestimmten Zeitraum nicht ordnungsgemäß reagiert hat oder die hergestellte Verbindung fehlgeschlagen ist, weil der verbundene Host nicht reagiert hat.) Vergewissern Sie sich, dass netzwerkkonnektivität vorhanden ist, der Server ausgeführt wird und seinen Lauschport registriert hat und keine Firewalls den Datenverkehr zum Ziel blockieren.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: Uhrzeit
Ereignis-ID: 21016
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
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 aus zulässig ist.

In der Regel werden diese Ereignis-IDs generiert, weil der Agent keine Konfiguration empfangen hat. Nachdem ein neuer Agent hinzugefügt wurde und bevor er konfiguriert wird, kommt dieses Ereignis häufig vor. 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 ausführen, um dieses Problem zu beheben:

  1. Wenn die automatische Genehmigung für manuell installierte Agents nicht aktiviert ist, vergewissern Sie sich, 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 möglicherweise darauf hinweisen, dass die Kerberos-Authentifizierung fehlschlägt. Suchen Sie in den Ereignisprotokollen nach Kerberos-Fehlern, und beheben Sie die Problembehandlung.

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

  5. Stellen Sie sicher, dass die Registrierungsschlüssel für standarddomänennamen richtig sind. Stellen Sie zur Überprüfung 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 doppelter SPN für den Integritätsdienst kann auch die Ereignis-ID 21016 verursachen. Führen Sie den folgenden Befehl aus, um den doppelten 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 Integritätsdienst des Verwaltungsservers verwendet wird.

Ereignis-ID 20057 wird auf dem Verwaltungsserver angezeigt

Ein Beispiel für dieses Ereignis:

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: Uhrzeit
Ereignis-ID: 20057
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:Fehler beim Initialisieren des Sicherheitskontexts für das ZIEL MSOMHSvc/******Der zurückgegebene Fehler ist 0x80090311(Für die Authentifizierung konnte keine Autorität kontaktiert werden.) Dieser Fehler kann für das Kerberos- oder das SChannel-Paket gelten.

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 ermöglichen:

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

Ereignis-ID 2010 und 2003 werden auf dem 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: Nicht zutreffend
Computer: <ComputerName>
Beschreibung: Der Integritätsdienst kann keine Verbindung mit Active Directory herstellen, um die Verwaltungsgruppenrichtlinie abzurufen. Der Fehler ist Nicht angegeben (0x80004005).
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Anbietername="HealthService" />
<EventID Qualifiers="49152">2010/<EventID>
<Ebene>2</Ebene>
<Aufgabe>1</Aufgabe>
<Schlüsselwörter>0x80000000000000</Schlüsselwörter>
<TimeCreated SystemTime="2015-02-21T21:06:04.00000000000Z" />
<EventRecordID>84143</EventRecordID>
<Channel>Operations Manager</Channel>
<Computer>ComputerName</Computer>
<Sicherheit/>
</System>
<EventData>
<Daten>nicht angegebener Fehler</Daten>
<0x80004005></Daten>
</Eventdata>
</Ereignis>

Protokollname: Operations Manager
Quelle: HealthService
Datum: Uhrzeit
Ereignis-ID: 2003
Aufgabenkategorie: Integritätsdienst
Ebene: Informationen
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung: Es wurden keine Verwaltungsgruppen gestartet. Dies kann entweder daran liegen, dass derzeit keine Verwaltungsgruppen konfiguriert sind oder eine konfigurierte Verwaltungsgruppe nicht gestartet werden konnte. Der Integritätsdienst wartet auf die Ausführung einer Active Directory-Richtlinie, die eine Verwaltungsgruppe konfiguriert.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Anbietername="HealthService" />
<EventID Qualifiers="16384">2003/<EventID>
<Ebene>4</Ebene>
<Aufgabe>1</Aufgabe>
<Schlüsselwörter>0x80000000000000</Schlüsselwörter>
<TimeCreated SystemTime="2015-02-21T21:06:04.00000000000Z" />
<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 22:13:39 Uhr
Ereignis-ID: 21016
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
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 aus zulässig ist.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Datum: 13.06.2014 22:13:37 Uhr
Ereignis-ID: 20070
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
Der OpsMgr-Connector ist mit ComputerName> verbunden<, aber die Verbindung wurde sofort nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht zur Kommunikation mit dem Server autorisiert ist oder dass der Server keine Konfiguration empfangen hat. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000 Ereignissen, was darauf hinweist, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen.

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

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

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

Get-SCOMPendingManagement

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

Get-SCOMPendingManagement| Approve-SCOMPendingManagement

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

Einige Beispiele für diese Ereignisse sind unten aufgeführt.

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 21023
Aufgabenkategorie: Keine
Ebene: Informationen
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
OpsMgr verfügt über keine Konfiguration für die Verwaltungsgruppe <GroupName> und fordert eine neue Konfiguration vom Konfigurationsdienst an.

Protokollname: Operations Manager
Quelle: OpsMgr-Verwaltungskonfiguration
Ereignis-ID: 29120
Aufgabenkategorie: Keine
Stufe: Warnung
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
Fehler beim Verarbeiten der Konfigurationsanforderung (XML-Konfigurationsdatei oder Management Pack-Anforderung) des OpsMgr-Verwaltungskonfigurationsdiensts aufgrund der folgenden Ausnahme

Protokollname: Operations Manager
Quelle: OpsMgr-Verwaltungskonfiguration
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
Fehler beim Ausführen des Arbeitselements "GetNextWorkItem" für den OpsMgr-Verwaltungskonfigurationsdienst aufgrund der folgenden Ausnahme

Protokollname: Operations Manager
Quelle: OpsMgr-Verwaltungskonfiguration
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
Fehler beim Ausführen des Arbeitselements "LocalHealthServiceDirtyNotification" für den OpsMgr-Verwaltungskonfigurationsdienst aufgrund der folgenden Ausnahme

Protokollname: Operations Manager
Quelle: OpsMgr-Verwaltungskonfiguration
Ereignis-ID: 21024
Aufgabenkategorie: Keine
Ebene: Informationen
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
Die Konfiguration von OpsMgr ist für die Verwaltungsgruppe <GroupName> möglicherweise veraltet und hat eine aktualisierte Konfiguration vom Konfigurationsdienst angefordert. Das aktuelle (veraltete) Statuscookies ist "5dae4442500c9d3f8f7a883e83851994,906af60d48ed417fb1860b23ed67dd71:001662A3"

Protokollname: Operations Manager
Quelle: OpsMgr Connector
Ereignis-ID: 29181
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend
Computer: <ComputerName>
Beschreibung:
OpsMgr Management Configuration Service konnte das Arbeitselement "DeltaSynchronization"-Engine aufgrund der folgenden Ausnahme nicht ausführen

Diese Ereignisse können auftreten, wenn der Deltasynchronisierungsprozess die Konfiguration nicht innerhalb des konfigurierten Timeoutfensters von 30 Sekunden erstellen kann. Dies kann auftreten, wenn ein großer instance Speicherplatz 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 in ConfigService.config mit den folgenden Änderungen:

    Suchen Sie nach <OperationTimeout DefaultTimeoutSeconds="30">, ändern Sie 30 in 300.
    Suchen Sie nach <Operation Name="GetEntityChangeDeltaList" TimeoutSeconds="180" />, ändern Sie 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 bieten.

Methode 2

  1. Installieren Sie 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

    Hinweis

    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.

Andere Ereignis-IDs des OpsMgr-Connectors

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

Ereignis Beschreibung Weitere Informationen
20050 Das angegebene Zertifikat konnte nicht geladen werden, da die angegebene erweiterte Schlüsselverwendung die OpsMgr-Anforderungen nicht erfüllt. Das Zertifikat muss die folgenden Verwendungstypen aufweisen: %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 für das Kerberos-Paket oder das SChannel-Paket gelten. 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 Kommunikationsfähigkeit dieses Integritätsdiensts wird wahrscheinlich beeinträchtigt. Überprüfen Sie das Zertifikat.
20068 Das in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings unter angegebene Zertifikat 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 keySpec AT_KEYEXCHANGE Überprüfen Sie das Zertifikat. Überprüfen Sie den Objektbezeichner für das Zertifikat.
20070 Der OpsMgr-Connector ist mit %1 verbunden. Die Verbindung wurde jedoch sofort nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht zur Kommunikation mit dem Server autorisiert ist oder dass der Server keine Konfiguration erhalten hat. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000 Ereignissen. Diese weisen darauf hin, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen. Die Authentifizierung wurde durchgeführt, aber die Verbindung wurde geschlossen. Vergewissern Sie sich, dass Ports geöffnet sind, und überprüfen Sie den Agent, der 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 bei der Authentifizierung dieses Agents oder des Servers. Überprüfen Sie das Ereignisprotokoll auf dem Server und auf dem Agent auf Ereignisse, die auf einen Fehler bei der Authentifizierung hinweisen. Fehler bei der Authentifizierung. Überprüfen Sie Firewalls und Port 5723. Der Agent-Computer 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 unter 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 im Zertifikat kein privater Schlüssel enthalten war. Überprüfen Sie, ob das Zertifikat einen privaten Schlüssel enthält. Es fehlt ein oder kein zugeordneter privater Schlüssel. 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 die gegenseitige Authentifizierung fehlgeschlagen ist. Vergewissern Sie sich, dass der SPN ordnungsgemäß auf dem Server registriert ist und dass eine voll vertrauenswürdige Beziehung zwischen den beiden Domänen besteht, wenn sich der Server in einer separaten Domäne befindet. Überprüfen Sie die SPN-Registrierung.
21005 Der OpsMgr-Connector konnte die IP-Adresse für %1 nicht auflösen. Der Fehlercode lautet %2(%3). Überprüfen Sie, ob DNS in Ihrer Umgebung ordnungsgemäß funktioniert. Dies ist in der Regel ein Problem bei der Namensauflösung. Überprüfen Sie DNS.
21006 Der OpsMgr-Connector konnte keine Verbindung mit %1:%2 herstellen. Der Fehlercode ist %3(%4). Vergewissern Sie sich, dass netzwerkkonnektivität vorhanden ist, dass der Server ausgeführt wird und seinen Überwachungsport registriert hat und dass keine Firewalls vorhanden sind, die den Datenverkehr zum Ziel blockieren. Dies ist wahrscheinlich ein allgemeines Konnektivitätsproblem. Ü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. Eine Vertrauensstellung ist nicht eingerichtet. Vergewissern Sie sich, dass das Zertifikat vorhanden 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 aus aktiviert ist. Dies deutet 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. Dieser Integritätsdienst kann nicht mit anderen Integritätsdiensten kommunizieren. Suchen Sie im Ereignisprotokoll nach vorherigen Ereignissen, um weitere Details zu finden. Überprüfen Sie das Zertifikat.
21022 Es wurde kein Zertifikat angegeben. Dieser Integritätsdienst kann nicht mit anderen Integritätsdiensten kommunizieren, es sei denn, diese Integritätsdienste befinden sich in einer Domäne, die über eine Vertrauensstellung zu dieser Domäne verfügt. Wenn dieser Integritätsdienst mit Integritätsdiensten in nicht vertrauenswürdigen Domänen kommunizieren muss, konfigurieren Sie ein Zertifikat. Überprüfen Sie das Zertifikat.
21035 Bei der Registrierung eines SPN für diesen Computer mit der Dienstklasse "%1" ist der Fehler "%2" fehlgeschlagen. Dies kann dazu führen, dass die Kerberos-Authentifizierung bei oder von diesem Integritätsdienst fehlschlägt. Dies deutet auf ein Problem mit der SPN-Registrierung hin. Untersuchen Sie SPNs für die Kerberos-Authentifizierung.
21036 Das in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings unter angegebene Zertifikat 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.