Problembehandlung bei der Ermittlung des UNIX/Linux-Agents in Operations Manager

In diesem Artikel erfahren Sie, wie Sie häufige Fehler beheben, die während des Ermittlungsprozesses von UNIX- oder Linux-Computern auftreten können.

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

Zum Überwachen von UNIX- oder Linux-Computern in System Center Operations Manager (OpsMgr) müssen die Computer zuerst ermittelt und der OpsMgr-Agent installiert werden. Der Computer- und Geräteverwaltung-Assistent wird verwendet, um Agents auf UNIX- und Linux-Computern zu ermitteln und zu installieren. Der Ermittlungsprozess kann jedoch aufgrund von Konfigurationsproblemen, Problemen mit Anmeldeinformationen oder Berechtigungen oder Aufgrund von Problemen bei der Netzwerk- und Namensauflösung fehlschlagen.

Zertifikatfehler oder Zertifikatsignaturfehler

Die Überprüfung des signierten Zertifikats war nicht erfolgreich.

Wenn die Zertifikatüberprüfung fehlschlägt, erhalten Sie in der Regel einen Fehler, der dem folgenden ähnelt:

Fehler bei der Agent-Überprüfung. Fehlerdetails: Das Serverzertifikat auf dem Zielcomputer (lx1.contoso.com:1270) weist die folgenden Fehler auf:
Das SSL-Zertifikat konnte nicht auf Sperrung überprüft werden. Der Zur Überprüfung auf Sperrung verwendete Server ist möglicherweise nicht erreichbar.
Das SSL-Zertifikat enthält einen allgemeinen Namen (Common Name, CN), der nicht mit dem Hostnamen übereinstimmt.
Es ist möglich, dass:

1. Das Zielzertifikat wird von einer anderen Zertifizierungsstelle signiert, die vom Verwaltungsserver nicht als vertrauenswürdig eingestuft wird.
2. Das Ziel verfügt über ein ungültiges Zertifikat, z. B. stimmt sein allgemeiner Name (Common Name, CN) nicht mit dem vollqualifizierten Domänennamen (FQDN) überein, der für die Verbindung verwendet wird. Der für die Verbindung verwendete FQDN lautet: lx1.contoso.com.
3. Die Server im Ressourcenpool wurden nicht so konfiguriert, dass sie Zertifikaten vertrauen, die von anderen Servern im Pool signiert wurden.

• Eine häufige Ursache ist, dass der Wert des allgemeinen Namens (Common Name, CN) des Agent-Zertifikats nicht mit dem angegebenen oder aufgelösten vollqualifizierten Domänennamen (FQDN) übereinstimmt.

  Um dies zu überprüfen, vergewissern Sie sich, dass hostname und Domänenname des Agenthosts mit dem über DNS aufgelösten FQDN übereinstimmen.

  Sie können die grundlegenden Details des Zertifikats auf dem UNIX- oder Linux-Computer anzeigen, indem Sie den folgenden Befehl ausführen:

  openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates
  

  Wenn Sie dies tun, wird eine Ausgabe angezeigt, die der folgenden ähnelt:

  subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
  issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
  notBefore=Mar 25 05:21:18 2008 GMT
  notAfter=Mar 20 05:21:18 2029 GMT

  Verwenden Sie diese Informationen, um die Hostnamen und Datumsangaben zu überprüfen. Stellen Sie sicher, dass sie mit dem Namen übereinstimmen, der vom Operations Manager-Verwaltungsserver aufgelöst wird.

  Wenn die Hostnamen nicht übereinstimmen, verwenden Sie eine der folgenden Aktionen, um das Problem zu beheben:

  • Wenn der UNIX- oder Linux-Hostname richtig ist, der Operations Manager-Verwaltungsserver ihn jedoch falsch auflöst, ändern Sie entweder den DNS-Eintrag so, dass er dem richtigen FQDN entspricht, oder fügen Sie der Hostdatei auf dem Operations Manager-Server einen Eintrag hinzu.
  • Wenn der UNIX- oder Linux-Hostname falsch ist, führen Sie eine der folgenden Aktionen aus:
    • Ändern Sie den Hostnamen auf dem UNIX- oder Linux-Host in den richtigen, und erstellen Sie ein neues Zertifikat.
    • Erstellen Sie ein neues Zertifikat mit dem gewünschten Hostnamen.

  So ändern Sie den Namen für das Zertifikat:

  Wenn das Zertifikat mit einem falschen Namen erstellt wurde, können Sie den Hostnamen ändern und das Zertifikat und den privaten Schlüssel neu erstellen. Führen Sie dazu den folgenden Befehl auf dem UNIX- oder Linux-Computer aus:

  /opt/microsoft/scx/bin/tools/scxsslconfig -f -v
  

  Die -f Option erzwingt, dass die Dateien in /etc/opt/microsoft/scx/ssl überschrieben werden.

  Sie können auch den Hostnamen und den Domänennamen für das Zertifikat ändern, indem Sie die -Option und -d die -h -Option verwenden, wie im folgenden Beispiel gezeigt:

  /opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>
  

  Starten Sie den Agent neu, indem Sie den folgenden Befehl ausführen:

  /opt/microsoft/scx/bin/tools/scxadmin -restart
  

  So fügen Sie der Hostdatei einen Eintrag hinzu:

  Wenn sich der FQDN nicht im Reverse-DNS befindet, können Sie der Hostdatei auf dem Verwaltungsserver einen Eintrag hinzufügen, um die Namensauflösung bereitzustellen. Die Hostdatei befindet sich im \Windows\System32\Drivers\etc Ordner. Ein Eintrag in der Hostdatei ist eine Kombination aus der IP-Adresse und dem FQDN.

  Wenn Sie beispielsweise einen Eintrag für den Host namens newhostname.newdomain.name mit der IP-Adresse 192.168.1.1 hinzufügen möchten, fügen Sie Am Ende der Datei hosts Folgendes hinzu:

  192.168.1.1 newhostname.newdomain.name

• Eine weitere häufige Ursache für diesen Fehler ist, dass das Zertifikat von einer nicht vertrauenswürdigen Autorität signiert wurde, z. B. wenn mehrere Verwaltungsserver Mitglieder des ressourcenpools sind, der für die Ermittlung verwendet wird, aber keine Zertifikatvertrauensstellung zwischen den Verwaltungsservern konfiguriert wurde.

  Um dies zu überprüfen, vergewissern Sie sich, dass alle Verwaltungsserver im Ressourcenpool, die für die Ermittlung verwendet werden, dem Zertifikat des anderen Servers vertrauen.

  Weitere Informationen zum Verwalten von Ressourcenpools für UNIX- und Linux-Computer finden Sie unter Verwalten von Ressourcenpools für UNIX- und Linux-Computer.

Der Benutzername oder das Kennwort ist falsch.

Möglicherweise wird der Fehler angezeigt, wenn Sie versuchen, UNIX/Linux-Agents zu ermitteln. Der Fehler kann während des Zertifikatüberprüfungsschritts beim Ermitteln eines UNIX/Linux-Computers auftreten.

Mögliche Ursachen

• Die Standardauthentifizierung ist auf mindestens einem Verwaltungsserver im UNIX/Linux-Ressourcenpool auf false festgelegt, wenn der UNIX/Linux-Agent nicht in die Domäne eingebunden ist und die Kerberos-Authentifizierung nicht verwenden kann. Sie können die aktuellen WinRM-Einstellungen überprüfen, indem Sie den folgenden Befehl ausführen: winrm get winrm/config/client.
• Der Benutzername oder das Kennwort ist falsch.

Lösung

Sie können die WinRM-Konfiguration auf den Verwaltungsservern im UNIX/Linux-Ressourcenpool aktualisieren, um die Standardauthentifizierung zuzulassen, indem Sie den folgenden Befehl ausführen, oder Sie können die Konfiguration über Gruppenrichtlinie festlegen:

winrm set winrm/config/client/auth @{Basic="true"}

Der Zertifikatsignaturvorgang war nicht erfolgreich.

Mögliche Ursachen

• Das für die Ermittlung angegebene Benutzerkonto verfügt über unzureichende Berechtigungen zum Ausführen von Dateivorgängen, die an der Signatur beteiligt sind.
• Sudo-Rechte zur Erhöhung des Benutzerkontos, das für die Ermittlung angegeben wurde, wurden nicht ordnungsgemäß konfiguriert.

Lösung

Um das Problem zu beheben, überprüfen Sie das Benutzerkonto, indem Sie die StdErr-Ausgabe in den Fehlerdetails überprüfen, um die Ursache des Fehlers zu ermitteln. Überprüfen Sie außerdem die sudo-Berechtigungskonfiguration für das Konto, das für die Zertifikatsignatur verwendet wird.

Fehler bei der Netzwerknamenauflösung

Die Zieladresse kann nicht aufgelöst werden.

Diese Probleme fallen in der Regel in eine der folgenden Kategorien:

• Fehlerbeschreibung

  Fehler beim Auflösen der IP-Adress-IP-Adresse <> in den Namen

  Ursache

  Dieser Fehler tritt auf, wenn eine IP-Adresse für den Host für die Ermittlung eingegeben wurde, die IP-Adresse aber nicht in einen Namen in DNS aufgelöst werden kann (Reverse-Lookup).

  Lösung

  Um dieses Problem zu beheben, korrigieren Sie die DNS-Konfiguration (Name Resolution) für die Reverse-Lookupzone, und stellen Sie sicher, dass für den betroffenen Host eine IP-Adresse zu Namenszuordnung vorhanden ist.

• Fehlerbeschreibung

  Fehler beim Auflösen des Namens server.contoso.com in die IP-Adresse

  Ursache

  Dieser Fehler tritt auf, wenn ein FQDN für den Host für die Ermittlung eingegeben wurde, der Name aber nicht in die IP-Adresse im DNS aufgelöst werden kann (Forward-Lookup).

  Lösung

  Um dieses Problem zu beheben, korrigieren Sie die DNS-Konfiguration (Name Resolution, Namensauflösung) für den Forward-Lookup, und stellen Sie sicher, dass für den Host eine Zuordnung von Hostnamen zu IP-Adressen vorhanden ist.

DNS-Konfiguration: Weiterleitungs-DNS-Auflösung stimmt nicht mit reverser DNS-Auflösung überein

Fehlerbeschreibung

In dieser Situation erhalten Sie in der Regel einen Fehler, der dem folgenden ähnelt:

Der angegebene Hostname ServerName wurde in die IP-Adresse 10.137.216.x aufgelöst. Der Hostname ServerName.contoso.com, der durch reverse lookup der IP-Adresse 192.168.x.x zurückgegeben wird, stimmte nicht mit dem angegebenen Hostnamen überein. Überprüfen Sie die DNS-Konfiguration, und versuchen Sie es erneut.

Ursache

Die häufigste Ursache ist, dass die Einträge für den Host in den Forward- und Reverse-DNS-Lookupzonen nicht übereinstimmen.

Lösung

Um dieses Problem zu beheben, korrigieren Sie die Einträge in den Forward- und Reverse-Lookupzonen im DNS, sodass die Hostnamen und die IP-Adresse übereinstimmen.

Die Zieladresse ist nicht erreichbar.

Fehlerbeschreibung

In dieser Situation erhalten Sie in der Regel einen Fehler, der dem folgenden ähnelt:

Der WinRM-Client kann den Vorgang nicht innerhalb der angegebenen Zeit abschließen. Überprüfen Sie, ob der Computername gültig und über die Netzwerk- und Firewall-Ausnahme für den Windows-Remoteverwaltungsdienst erreichbar ist.

Mögliche Ursachen

• Der Host ist aufgrund einer falschen Namensauflösung, eines Netzwerkausfalls oder eines Hostausfalls nicht erreichbar.
• Eine netzwerk- oder hostbasierte Firewall blockiert die TCP-Port 1270-Konnektivität mit dem Zielhost.

Lösung

Um dieses Problem zu beheben, überprüfen Sie, ob der Verwaltungsserver den Agenthost mit seinem FQDN pingen kann. Vergewissern Sie sich außerdem, dass tcp-Port 1270 durch keine Netzwerkfirewalls oder Hostfirewall blockiert wird.

Unerwarteter discoveryResult.ErrorData-Typ. Dateifehlerbericht – Parametername: s

Fehlerbeschreibung

Unerwarteter DiscoveryResult.ErrorData-Typ. Erstellen Sie einen Fehlerbericht.
ErrorData: System.ArgumentNullException
Wert darf nicht NULL sein.
Parametername: s
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
unter Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Ursache

Dieser Fehler tritt auf, weil winHTTP-Proxyeinstellungen auf den Verwaltungsservern im UNIX- oder Linux-Ressourcenpool konfiguriert wurden und der FQDN des UNIX- oder Linux-Agents, den Sie ermitteln möchten, nicht in der WinHTTP-Proxyumgehungsliste enthalten ist.

Lösung

Um dieses Problem zu beheben, fügen Sie den UNIX- oder Linux-FQDN zur WinHTTP-Proxyumgehungsliste hinzu.

Führen Sie auf den Verwaltungsservern im UNIX- oder Linux-Ressourcenpool den folgenden Befehl an einer Eingabeaufforderung mit erhöhten Rechten aus, um die aktuelle Proxykonfiguration zu überprüfen:

netsh winhttp show proxy

Wenn ein WinHTTP-Proxyserver konfiguriert ist, fügen Sie den FQDN des Servers, den Sie ermitteln möchten, der Umgehungsliste hinzu, indem Sie den folgenden Befehl ausführen:

netsh winhttp set proxy proxy-server="<proxyserver:port>" bypass-list="*.ourdomain.com;*.yourdomain.com*;<serverFQDN>"

Nachdem die Umgehungsliste konfiguriert wurde, überprüfen Sie, ob die Agent-Ermittlung erfolgreich war.

Unerwarteter discoveryResult.ErrorData-Typ. Dateifehlerbericht – Parametername: lhs

Fehlerbeschreibung

Ermittlung nicht erfolgreich
Meldung: Nicht angegebener Fehler
Details: Unerwarteter DiscoveryResult.ErrorData-Typ. Erstellen Sie einen Fehlerbericht.
ErrorData: System.ArgumentNullException
Wert darf nicht NULL sein.
Parametername: lhs
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
unter Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Ursache

Dieser Fehler tritt aufgrund von omsagent-Shelldateien im Ordner installierte Kits auf.

Lösung

Navigieren Sie in Explorer zum folgenden Verzeichnis:

C:\Programme\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits

Wenn omsagent-Dateien aufgeführt sind, verschieben Sie sie in ein temporäres Verzeichnis außerhalb der SCOM-Dateien (System Center Operations Manager).

Ein Beispiel finden Sie im folgenden Screenshot:

Nachdem sie aus dem Ordner DownloadedKits verschoben wurden, wiederholen Sie die Ermittlung. Die Ermittlung sollte jetzt erfolgreich sein.

SSH-Konnektivitätsfehler

Fehler bei der SSH-Ermittlung. Exitcode: -1073479162

Fehlerbeschreibung

Standardausgabe:
Standardfehler:
Ausnahmemeldung: Eine Ausnahme (-1073479162) hat dazu geführt, dass der SSH-Befehl fehlschlägt. Es konnte keine Verbindung hergestellt werden, da der Zielcomputer dies aktiv abgelehnt hat.

Mögliche Ursachen

• Der SSH-Daemon wird nicht auf dem Zielsystem ausgeführt.
• Eine netzwerk- oder hostbasierte Firewall verhindert SSH-Verbindungen über TCP-Port 22.

Lösungen

• Vergewissern Sie sich, dass der SSH-Daemon ausgeführt wird.
• Stellen Sie sicher, dass keine Netzwerkfirewalls oder Hostfirewall tcp-Port 22 blockieren.

Fehler bei der SSH-Ermittlung. Exitcode: -1073479118

Fehlerbeschreibung

Fehler bei der SSH-Ermittlung. Exitcode: -1073479118
Standardausgabe:
Standardfehler:
Ausnahmemeldung: Eine Ausnahme (-1073479118) hat dazu geführt, dass der SSH-Befehl fehlschlägt– Server hat die Trennungsmeldung gesendet: Typ 2 (Protokollfehler: Zu viele Authentifizierungsfehler für root)

Mögliche Ursachen

• Das für die Ermittlung angegebene Benutzerkonto darf sich nicht über SSH anmelden.
• Das für die Ermittlung angegebene Benutzerkonto wurde mit einem ungültigen Benutzernamen oder Kennwort eingegeben.

Lösungen

• Vergewissern Sie sich, dass sich der Benutzer über SSH anmelden darf.
• Überprüfen Sie die Eingabeanmeldeinformationen und ob der Benutzer auf dem Zielhost definiert ist.

Fehler bei der SSH-Ermittlung. Exitcode: 1

Fehlerbeschreibung

Fehler bei der SSH-Ermittlung. Exitcode: 1
Standardausgabe: Sudo-Pfad: /usr/bin/
Standardfehler: sudo: sorry, Sie müssen über ein tty verfügen, um sudo auszuführen.
Ausnahmemeldung:

Ursache

Die Erhöhung von Sudo wurde in der Eingabe der Benutzeranmeldeinformationen ausgewählt, die requiretty Option wurde jedoch für den Benutzer in sudoers nicht deaktiviert.

Lösung

Bearbeiten Sie die sudoers-Datei auf dem Zielhost mit dem visudo Befehl, und fügen Sie die folgende Zeile hinzu:

Standardwerte: <benutzername>!requiretty

Weitere Informationen finden Sie unter Konfigurieren von sudo-Erhöhungen und SSH-Schlüsseln.

Ungültiges SU-Kennwort

Fehlerbeschreibung

. [?1034hopsuser@lx1:~> su - root -c 'sh /tmp/scx-opsuser/GetOSVersion.sh; EC=$?; rm -rf /tmp/scx-opsuser; exit $EC'
Passwort:
Ausfahrt
su: falsches Kennwort
opsuser@lx1:~> exit
Logout

Mögliche Ursache

Die Rechteerweiterung "Su" wurde in der Eingabe der Benutzeranmeldeinformationen ausgewählt, aber für die Rechteerweiterung wurde ein ungültiges Root-Kennwort angegeben.

Lösung

Überprüfen Sie die Kennworteingabe für root im Konfigurationsdialogfeld Erhöhte Rechte.

Fehler bei der SSH-Ermittlung. Exitcode: -2147221248

• Fehlerbeschreibung

  Fehler bei der SSH-Ermittlung. Exitcode: -2147221248
  Standardausgabe:
  Standardfehler: Chdir konnte nicht im Startverzeichnis /home/username gespeichert werden: Keine datei oder verzeichnis

  Ursache

  Das für die Ermittlung angegebene Benutzerkonto verfügt nicht über ein Basisverzeichnis.

  Lösung

  Vergewissern Sie sich, dass der Benutzer über ein Basisverzeichnis unter /home/ verfügt und dass der Benutzer in dieses Verzeichnis schreiben kann.

• Fehlerbeschreibung

  Fehler bei der SSH-Ermittlung. Exitcode: -2147221248
  Standardausgabe:
  Standardfehler: Root-Kennwort:
  Ausnahmemeldung: Timeout des Vorgangs

  Ursache

  Die Erhöhung von Sudo wurde in der Eingabe der Benutzeranmeldeinformationen ausgewählt. Das für die Ermittlung angegebene Benutzerkonto ist jedoch nicht ordnungsgemäß für die Verwendung kennwortloser sudo-Rechte konfiguriert, oder die erforderlichen sudo-Rechte zur Erhöhung wurden für das benutzerkonto, das bei der Ermittlung verwendet wird, nicht gewährt.

  Lösung

  Lesen Sie die Dokumentation zur sudo-Erhöhungskonfiguration, und überprüfen Sie die Benutzerkonfiguration für sudo. Beachten Sie, dass kennwortlose sudo konfiguriert werden muss.

WSMan-Konnektivitätsfehler

Der Agent hat auf die Anforderung geantwortet, aber bei der WSMan-Verbindung ist ein Fehler aufgrund von: Zugriff verweigert

Mögliche Ursachen

• Der Agent ist installiert, und das Agent-Zertifikat wurde signiert. Die für die Agent-Überprüfung bereitgestellten Benutzeranmeldeinformationen sind jedoch ungültig.
• Das für die Ermittlung angegebene Benutzerkonto wurde für die Authentifizierung mit einem SSH-Schlüssel konfiguriert, aber die für die Agentüberprüfung bereitgestellten Benutzeranmeldeinformationen sind ungültig.
• Auf der UNIX-Seite liegt ein Berechtigungsproblem oder eine falsche PAM-Konfiguration vor.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Vergewissern Sie sich, dass der Benutzername und das Kennwort für die Agentüberprüfung ordnungsgemäß eingegeben wurden und dass der Benutzer ein gültiger Benutzer auf dem Zielhost ist.

2. Wenn das Problem weiterhin besteht, überprüfen Sie, ob die Erhöhung von sudo ordnungsgemäß konfiguriert wurde.

3. Überprüfen Sie auch das Meldungenprotokoll auf dem UNIX/Linux-Computer. In AIX finden Sie z. B. das Protokoll unter /var/adm/messages. Bei anderen Betriebssystemen kann der Speicherort variieren.

   Suchen Sie nach Zeilen wie den folgenden:

   3. September 14:49:07 Serverauthentifizierung|security:debug /opt/microsoft/scx/bin/omiserver PAM: pam_authenticate: Fehler Authentifizierung fehlgeschlagen.

   Wenn im Nachrichtenprotokoll ähnliche Zeilen angezeigt werden, bedeutet dies, dass in der PAM-Konfigurationsdatei Informationen zu OMIServer fehlen. Die PAM-Konfigurationsdatei befindet sich im /etc/pam.d/ Verzeichnis oder in der /etc/pam.conf Datei.

   Die einfachste Möglichkeit, die Informationen zu OMIServer wieder der PAM-Konfigurationsdatei hinzuzufügen, besteht darin, den SCX-Agent von Grund auf neu auf diesem Computer neu zu installieren. Wenn dies nicht einfach möglich ist, können Sie die Zeilen, die OMI betreffen, von einem Arbeitscomputer auf den nicht funktionierenden Computer kopieren.

Fehler bei der reinen WSMan-Ermittlung für 192.168.x.x

Mögliche Ursachen

• Die Option Ermittlungstyp wurde auf Nur Computer mit einem installierten Agent und signiertem Zertifikat festgelegt, und auf dem Zielhost ist der Agent installiert. Das Zielhostzertifikat wurde jedoch nicht signiert. Um die Nur-WSMan-Ermittlungsoption verwenden zu können, muss der Agent installiert und das Zertifikat manuell signiert werden.
• Die Option Ermittlungstyp wurde auf Nur Computer mit einem installierten Agent und signiertem Zertifikat festgelegt, aber auf dem Zielhost ist der UNIX/Linux-Agent derzeit nicht installiert.
• Die Option Ermittlungstyp wurde auf Nur Computer mit einem installierten Agent und signiertem Zertifikat festgelegt, aber der UNIX/Linux-Agent wird derzeit nicht ausgeführt.
• Die Option Ermittlungstyp wurde auf Nur Computer mit einem installierten Agent und signiertem Zertifikat festgelegt, aber der Zielhost ist nicht erreichbar, eine Netzwerk- oder hostbasierte Firewall verhindert die Konnektivität, oder der UNIX/Linux-Agent ist derzeit ausgefallen.

Lösungen

• Signieren Sie das Zertifikat manuell.
• Vergewissern Sie sich, dass der UNIX/Linux-Agent installiert wurde.
• Ändern Sie die Option auf Alle Computer ermitteln , damit der Ermittlungs-Assistent die Zertifikatsignierung durchführen kann.
• Vergewissern Sie sich, dass der UNIX/Linux-Agent ausgeführt wird und dass der Zielhost erreichbar ist.
• Stellen Sie sicher, dass keine Netzwerkfirewalls oder Hostfirewalls den Zugriff auf TCP-Port 1270 verhindern.

Andere Fehler

Die Aufgabe kann nicht für die Objekte ausgeführt werden, da das Ziel des Tasks keiner der Klassen des Objekts entspricht.

Ursache

In einer System Center 2012 Operations Manager-Verwaltungsgruppe kann dies auftreten, wenn es sich bei den importierten UNIX/Linux-Management Packs um Operations Manager 2007 R2-Versionen handelt.

Lösung

Importieren Sie die System Center 2012-Versionen der Management Packs für UNIX/Linux-Betriebssysteme.

Der Agent ist installiert, und der Computer wird bereits von Operations Manager überwacht.

Ursache

Der Zielhost wurde bereits in dieser Verwaltungsgruppe ermittelt.

Lösung

Es ist keine Aktion erforderlich. Ein Agent-Upgrade oder eine Migration zu einem alternativen Ressourcenpool kann über die Ansicht UNIX/Linux-Server im Bereich Verwaltung der Betriebskonsole durchgeführt werden.

Fehler beim Finden eines übereinstimmenden unterstützten Agent-instance in den importierten Management Packs

Fehlerbeschreibung

Fehler beim Finden eines übereinstimmenden unterstützten Agent-instance in den importierten Management Packs. Importieren Sie die Management Packs für diese Plattform, um diesen Computer zu ermitteln.

Mögliche Ursachen

• Auf dem Zielhost wird ein nicht unterstütztes Betriebssystem ausgeführt.
• Das richtige Management Pack für das Betriebssystem des Zielhosts wurde nicht importiert.
• Das richtige Management Pack für das Betriebssystem wurde kürzlich importiert, aber noch nicht vollständig geladen.

Lösungen

• Vergewissern Sie sich, dass auf dem Zielhost ein unterstütztes Betriebssystem ausgeführt wird.
• Importieren Sie das Management Pack für das Betriebssystem und die Version des Zielhosts.
• Wenn das Management Pack importiert wurde, wird es möglicherweise trotzdem geladen. Warten Sie einige Minuten, und führen Sie die Ermittlung erneut aus.

Installierbare Agent-Typen können nicht aufgelistet werden. Der zugeordnete Ressourcenpool wird möglicherweise noch initialisiert.

Fehlerbeschreibung

Installierbare Agent-Typen können nicht aufgelistet werden. Der zugeordnete Ressourcenpool wird möglicherweise noch initialisiert. Wenn Sie einen neu erstellten Ressourcenpool ausgewählt haben, warten Sie einige Minuten, bevor Sie ihn verwenden.

Mögliche Ursachen

• Der bei der Ermittlung verwendete Ressourcenpool ist nicht fehlerfrei, z. B. sind die meisten Mitgliedsserver offline.
• Der bei der Ermittlung verwendete Ressourcenpool wurde kürzlich erstellt, aber noch nicht vollständig initialisiert.

Lösung

Wenn der bei der Ermittlung verwendete Ressourcenpool kürzlich erstellt wurde, wiederholen Sie die Ermittlung nach einigen Minuten, damit der Pool initialisiert werden kann. Überprüfen Sie andernfalls das Operations Manager-Ereignisprotokoll auf den Servern, die Mitglieder des Ressourcenpools sind, der für die Ermittlung verwendet wird, um Hinweise auf die Ursache des Problems zu erhalten.

Neuer Agent kann nicht auf diesen Computer kopiert werden

Fehlerbeschreibung

Meldung: Neuer Agent kann nicht auf diesen Computer kopiert werden
Details:
Fehler beim Kopieren des Kits. Exitcode: -1073479144
Standardausgabe:
Standardfehler:
Ausnahmemeldung: Eine Ausnahme (-1073479144) hat dazu geführt, dass der SSH-Befehl fehlschlägt.

Ursache

Datei-Agent-Versionen stimmen nicht zwischen Datenbank und Agent-Repository überein.

Lösungen

• Überprüfen Sie, ob alle fehlerhaften Agents aufgrund eines Versionskonflikts fehlschlagen. Wenden Sie andernfalls weitere Schritte zur Problembehandlung an.
• Versuchen Sie erneut, die fehlerhaften Agents zu aktualisieren. In der Regel wird die Liste der fehlerhaften Agents während jeder Updateiteration immer kürzer.
• Starten Sie den Integritätsdienst für alle Mitglieder Ihres Linux-Ressourcenpools oder eines anderen Pools zum Verwalten von Unix- oder Linux-Computern neu. Überprüfen Sie den %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits Ordner, ob die Dateinamen korrekt sind. Denken Sie daran, den Ermittlungs-Assistenten zu schließen und erneut zu öffnen.

Weitere Informationen

Weitere Hilfe finden Sie in unserem TechNet-Supportforum, oder wenden Sie sich an Microsoft-Support.