Freigeben über

Problembehandlung bei der UNIX-/Linux-Agent-Ermittlung in Operations Manager

  • Artikel

Dieser Artikel hilft Ihnen bei der Problembehandlung häufiger Fehler, 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

Um UNIX- oder Linux-Computer in System Center Operations Manager (OpsMgr) zu überwachen, müssen die Computer zuerst ermittelt werden, und der OpsMgr-Agent muss 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 Netzwerk- und Namensauflösungsproblemen fehlschlagen.

Zertifikatfehler oder Zertifikatsignierungsfehler

Der Signierte Zertifikatüberprüfungsvorgang war nicht erfolgreich.

Wenn die Zertifikatüberprüfung fehlschlägt, erhalten Sie in der Regel einen Fehler, der wie folgt aussieht:

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 Server, der zum Überprüfen auf den Sperrungsstatus verwendet wird, ist möglicherweise nicht erreichbar.
Das SSL-Zertifikat enthält einen gemeinsamen Namen (CN), der nicht mit dem Hostnamen übereinstimmt.
Es ist möglich, dass:

  1. Das Zielzertifikat ist von einer anderen Zertifizierungsstelle signiert, die für den Verwaltungsserver nicht vertrauenswürdig ist.
  2. Das Ziel besitzt 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 dafür konfiguriert, von anderen Servern im Pool signierten Zertifikaten zu vertrauen.

  • Eine häufige Ursache ist, dass der gemeinsame Name (CN)-Wert des Agentzertifikats nicht mit dem bereitgestellten oder aufgelösten vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) übereinstimmt.

    Um dies zu überprüfen, vergewissern Sie sich, dass der Hostname und der Domänenname des Agenthosts mit dem durch 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

    In diesem Fall sehen Sie die Ausgabe, die den 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 korrekt ist, der Operations Manager-Verwaltungsserver sie jedoch falsch auflösen kann, ä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 das richtige, und erstellen Sie ein neues Zertifikat.
      • Erstellen Sie ein neues Zertifikat mit dem gewünschten Hostnamen.

    So ändern Sie den Namen des Zertifikats:

    Wenn das Zertifikat mit einem falschen Namen erstellt wurde, können Sie den Hostnamen ändern und das Zertifikat und den privaten Schlüssel erneut 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 im Zertifikat ändern, indem Sie die -h Folgenden verwenden und -d wechseln, 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, die sich auf dem Verwaltungsserver befindet, einen Eintrag hinzufügen, um die Namensauflösung bereitzustellen. Die Hostdatei befindet sich im \Windows\System32\Drivers\etc Ordner. Ein Eintrag in der Hostsdatei ist eine Kombination aus der IP-Adresse und dem FQDN.

    Wenn Sie beispielsweise einen Eintrag für den Host namens newhostname.newdomain.name mit einer IP-Adresse von 192.168.1.1 hinzufügen möchten, fügen Sie Folgendes am Ende der Hostsdatei 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 die Zertifikatvertrauensstellung nicht 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 beim Versuch, UNIX/Linux-Agents zu ermitteln, der Fehler angezeigt. Der Fehler kann während des Zertifikatüberprüfungsschritts auftreten, während ein UNIX/Linux-Computer erkannt wird.

Mögliche Ursachen

  • Die Standardauthentifizierung ist auf einen oder mehrere Verwaltungsserver im UNIX/Linux-Ressourcenpool festgelegt false , wenn der UNIX/Linux-Agent nicht in die Domäne eingebunden ist und die Kerberos-Authentifizierung nicht verwendet werden 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 Gruppenrichtlinien festlegen:

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

Notiz

Der obige Befehl legt einen DWORD-Registrierungswert (32-Bit) (AllowBasic) im folgenden Registrierungsschlüssel fest:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WinRM\Client

AllowBasic lässt dezimale 1 Werte (Aktiviert) oder 0 (Deaktiviert) zu.

Die Zertifikatsignierung 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 bei der Anmeldung beteiligt sind.
  • Sudo elevation privileges for the user account specified for discovery wasn't 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 identifizieren. Überprüfen Sie außerdem die Sudo-Berechtigungskonfiguration für das Konto, das für die Zertifikatsignierung verwendet wird.

Fehler bei der Netzwerknamensauflö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-Adressen-IP-Adresse <> zum 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-Nachschlagezone, stellen Sie sicher, dass eine IP-Adresse zur Namenszuordnung für den betroffenen Host 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, aber der Name in DNS nicht aufgelöst werden kann (Forward Lookup).

    Lösung

    Um dieses Problem zu beheben, korrigieren Sie die DNS-Konfiguration (Name Resolution) für forward lookup, stellen Sie sicher, dass ein Hostname zur IP-Adresszuordnung für den Host vorhanden ist.

DNS-Konfiguration: Die Weiterleitungs-DNS-Auflösung stimmt nicht mit umgekehrter DNS-Auflösung überein.

Fehlerbeschreibung

In diesem Fall erhalten Sie in der Regel einen Fehler, der etwa wie folgt aussieht:

Der bereitgestellte Hostname ServerName wurde in die IP-Adresse von 10.137.216.x aufgelöst. Der Hostname ServerName.contoso.com durch umgekehrte Suche der IP-Adresse 192.168.x.x nicht mit dem bereitgestellten Hostnamen zurückgegeben. Ü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 Vorwärts- und Reverse-DNS-Lookupzonen nicht übereinstimmen.

Lösung

Korrigieren Sie zum Beheben dieses Problems die Einträge in den Forward- und Reverse-Lookupzonen in DNS, damit die Hostnamen und die IP-Adresse übereinstimmen.

Die Zieladresse ist nicht erreichbar.

Fehlerbeschreibung

In diesem Fall erhalten Sie in der Regel einen Fehler, der etwa wie folgt aussieht:

Der WinRM-Client kann den Vorgang nicht innerhalb der angegebenen Zeit abschließen. Überprüfen Sie, ob der Computername gültig ist und über die Netzwerk- und Firewall-Ausnahme für Windows Remoteverwaltungsdienst aktiviert 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 mithilfe seines FQDN anpingen kann. Stellen Sie außerdem sicher, dass keine Netzwerkfirewalls oder Hostfirewall TCP-Port 1270 blockieren.

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

Fehlerbeschreibung

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

Ursache

Dieser Fehler tritt auf, da 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 hinzu, den Sie zur Umgehungsliste ermitteln möchten, indem Sie den folgenden Befehl ausführen:

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

Überprüfen Sie nach der Konfiguration der Umgehungsliste, ob die Agentermittlung erfolgreich ist.

Notiz

Sie können den netsh winhttp reset proxy Befehl ausführen, um den WinHTTP-Proxy zu deaktivieren. Mit diesem Befehl wird der Proxyserver entfernt und der direkte Zugriff konfiguriert.

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

Fehlerbeschreibung

Ermittlung nicht erfolgreich
Meldung: Nicht angegebener Fehler
Details: Unerwarteter DiscoveryResult.ErrorData-Typ. Bitte Dateifehlerbericht.
ErrorData: System.ArgumentNullException
Wert darf nicht NULL sein.
Parametername: lhs
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 input, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 input, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
at 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 aufgelistet sind, verschieben Sie sie in ein temporäres Verzeichnis außerhalb der System Center Operations Manager (SCOM)-Dateien.

Ein Beispiel finden Sie im folgenden Screenshot:

Screenshot der Omsagent-Dateien im Ordner

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

Notiz

Die Ermittlung schlägt möglicherweise mit einem anderen Fehler fehl. Der Fehler gibt an, dass eine weitere Problembehandlung erforderlich ist, z. B. sudoers, Konnektivität usw.

SSH-Konnektivitätsfehler

Fehler bei der SSH-Ermittlung. Exitcode: -1073479162

Fehlerbeschreibung

Standardausgabe:
Standardfehler:
Ausnahmemeldung: Eine Ausnahme (-1073479162) führte dazu, dass der SSH-Befehl fehlschlug – Es konnte keine Verbindung hergestellt werden, da der Zielcomputer sie aktiv abgelehnt hat.

Mögliche Ursachen

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

Resolutionen

  • Überprüfen Sie, ob 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 gesendete Disconnect-Nachricht: Typ 2 (Protokollfehler: Zu viele Authentifizierungsfehler für stamm)

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.

Resolutionen

  • Stellen Sie sicher, dass der Benutzer sich über SSH anmelden darf.
  • Überprüfen Sie die Eingabeanmeldeinformationen und legen Sie fest, dass 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: Leider müssen Sie einen tty haben, um sudo auszuführen.
Ausnahmemeldung:

Ursache

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

Lösung

Bearbeiten Sie die Datei "sudoers " auf dem Zielhost mithilfe des visudo Befehls, und fügen Sie die folgende Zeile hinzu:

Standardwerte: <username>!requiretty

Weitere Informationen finden Sie unter Konfigurieren von sudo Elevation- 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'
Password (Kennwort):
exit
su: falsches Kennwort
opsuser@lx1:~> exit
logout

Mögliche Ursache

Su-Rechte wurde in der Benutzeranmeldeinformationseingabe ausgewählt, für die Erhöhung wurde jedoch ein ungültiges Stammkennwort bereitgestellt.

Lösung

Überprüfen Sie die Kennworteingabe für den Stamm im Dialogfeld "Erhöhungskonfiguration".

Fehler bei der SSH-Ermittlung. Exitcode: -2147221248

  • Fehlerbeschreibung

    Fehler bei der SSH-Ermittlung. Exitcode: -2147221248
    Standardausgabe:
    Standardfehler: Das Verzeichnis "/home/home/username" konnte nicht verwendet werden: Keine solche Datei oder ein solches Verzeichnis

    Ursache

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

    Lösung

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

  • Fehlerbeschreibung

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

    Ursache

    Die Erhöhung von Sudo wurde in der Benutzeranmeldeinformationseingabe 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 wurden für das in der Ermittlung verwendete Benutzerkonto nicht gewährt.

    Lösung

    Überprüfen Sie die Sudo-Konfigurationsdokumentation zur Erhöhung 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 die WSMan-Verbindung ist fehlgeschlagen, weil der Zugriff verweigert wurde.

Mögliche Ursachen

  • Der Agent ist installiert, und das Agentzertifikat 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, die für die Agentüberprüfung bereitgestellten Benutzeranmeldeinformationen sind jedoch ungültig.
  • Es gibt ein Berechtigungsproblem oder eine falsche PAM-Konfiguration auf UNIX-Seite.

Lösung

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

  1. Überprüfen Sie, ob der Benutzername und das Kennwort für die Agentüberprüfung korrekt 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 sudo-Rechteerweiterung ordnungsgemäß konfiguriert wurde.

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

    Suchen Sie nach Zeilen wie den folgenden:

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

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

    Die einfachste Möglichkeit, die Informationen zu OMIServer zurück zur PAM-Konfigurationsdatei hinzuzufügen, besteht darin, den SCX-Agent von Grund auf 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 arbeitsfreien Computer kopieren.

Fehler bei der WSMan-Erkennung für 192.168.x.x

Mögliche Ursachen

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

Resolutionen

  • Manuelles Signieren des Zertifikats.
  • Überprüfen Sie, ob der UNIX/Linux-Agent installiert wurde.
  • Ändern Sie die Option " Alle Computer ermitteln", damit der Ermittlungs-Assistent die Zertifikatsignierung durchführen kann.
  • Überprüfen Sie, ob der UNIX/Linux-Agent ausgeführt wird und ob der Zielhost erreichbar ist.
  • Stellen Sie sicher, dass keine Netzwerkfirewalls oder Hostfirewall den Zugriff auf TCP-Port 1270 verhindern.

Sonstige Fehler

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

Ursache

In einer System Center 2012 Operations Manager-Verwaltungsgruppe kann dies auftreten, wenn die importierten UNIX/Linux-Management Packs Operations Manager 2007 R2-Versionen sind.

Lösung

Importieren Sie die System Center 2012-Versionen der UNIX/Linux-Betriebssystem-Management Packs.

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. Das Agentupgrade oder die Migration zu einem alternativen Ressourcenpool kann über die Ansicht UNIX/Linux-Server im Verwaltungsbereich der Operations-Konsole ausgeführt werden.

Fehler beim Auffinden einer übereinstimmenden unterstützten Agent-Instanz in den importierten Management Packs

Fehlerbeschreibung

Eine passende unterstützte Agentinstanz wurde in den importierten Management Packs nicht gefunden. Importieren Sie die Management Packs für diese Plattform, um den 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.

Resolutionen

  • Vergewissern Sie sich, dass der Zielhost ein unterstütztes Betriebssystem ausführt.
  • Importieren Sie das Management Pack für das Betriebssystem und die Version des Zielhosts.
  • Wenn das Management Pack importiert wurde, kann es weiterhin geladen werden. Warten Sie einige Minuten, und führen Sie die Ermittlung erneut aus.

Aufzählung der installierbaren Agententypen nicht möglich. Der zugeordnete Ressourcenpool kann weiterhin initialisiert werden.

Fehlerbeschreibung

Aufzählung der installierbaren Agententypen nicht möglich. Der zugeordnete Ressourcenpool kann weiterhin initialisiert werden. Wenn Sie einen neu erstellten Ressourcenpool ausgewählt haben, warten Sie bitte einige Minuten, bevor Sie es verwenden.

Mögliche Ursachen

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

Lösung

Wenn der in der Ermittlung verwendete Ressourcenpool kürzlich erstellt wurde, versuchen Sie die Ermittlung nach mehreren Minuten erneut, 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 Quelle des Problems zu erhalten.

Neuer Agent kann nicht auf diesen Computer kopiert werden.

Fehlerbeschreibung

Meldung: Der neue Agent kann nicht auf diesen Computer kopiert werden.
Details:
Fehler beim Kopieren. Exitcode: -1073479144
Standardausgabe:
Standardfehler:
Ausnahmemeldung: Eine Ausnahme (-1073479144) führte zu einem Fehler des SSH-Befehls.

Ursache

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

Resolutionen

  • Stellen Sie sicher, dass die fehlgeschlagenen Agents alle aufgrund eines Versionskonflikts fehlschlagen. Wenden Sie andernfalls weitere Schritte zur Problembehandlung an.
  • Versuchen Sie erneut, die fehlgeschlagenen Agents zu aktualisieren. In der Regel wird die Liste der fehlgeschlagenen Agents bei jeder Aktualisierungsiteration kürzer und kürzer.
  • Starten Sie die Integritätsdienst auf allen Mitgliedern Ihres Linux-Ressourcenpools oder eines anderen Pools für die Verwaltung von Unix- oder Linux-Computern neu. Überprüfen Sie den %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits Ordner, wenn Dateinamen korrekt sind. Denken Sie daran, den Discovery-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.