Felsöka UNIX/Linux-agentidentifiering i Operations Manager

Den här artikeln hjälper dig att felsöka vanliga fel som kan uppstå under identifieringsprocessen för UNIX- eller Linux-datorer.

Ursprunglig produktversion: System Center Operations Manager
Ursprungligt KB-nummer: 4490426

Om du vill övervaka UNIX- eller Linux-datorer i System Center Operations Manager (OpsMgr) måste datorerna först identifieras och OpsMgr-agenten måste installeras. Guiden Dator och Enhetshantering används för att identifiera och installera agenter på UNIX- och Linux-datorer. Identifieringsprocessen kan dock misslyckas på grund av konfigurationsproblem, autentiseringsuppgifter eller behörighetsproblem eller problem med nätverks- och namnmatchning.

Certifikatfel eller certifikatsigneringsfel

Verifieringsåtgärden för signerat certifikat lyckades inte

När certifikatverifieringen misslyckas får du vanligtvis ett fel som liknar följande:

Agentverifieringen misslyckades. Felinformation: Servercertifikatet på måldatorn (lx1.contoso.com:1270) har följande fel:
SSL-certifikatet kunde inte kontrolleras för återkallning. Servern som används för att söka efter återkallning kan inte nås.
SSL-certifikatet innehåller ett eget namn (CN) som inte matchar värdnamnet.
Det är möjligt att:

1. Målcertifikatet signeras av en annan certifikatutfärdare som inte är betrodd av hanteringsservern.
2. Målet har ett ogiltigt certifikat, t.ex. dess eget namn (CN) matchar inte det fullständigt kvalificerade domännamnet (FQDN) som används för anslutningen. Det FQDN som används för anslutningen är: lx1.contoso.com.
3. Servrarna i resurspoolen har inte konfigurerats för att lita på certifikat som signerats av andra servrar i poolen.

• En vanlig orsak är att agentcertifikatets eget namn (CN) inte matchar det angivna eller lösta fullständigt kvalificerade domännamnet (FQDN).

  Kontrollera detta genom att bekräfta att agentvärdens värdnamn och domännamn matchar det FQDN som matchas via DNS.

  Du kan visa grundläggande information om certifikatet på UNIX- eller Linux-datorn genom att köra följande kommando:

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

  När du gör detta visas utdata som liknar följande:

  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

  Använd den här informationen för att verifiera värdnamnen och datumen och se till att de matchar namnet som matchas av Operations Manager-hanteringsservern.

  Om värdnamnen inte matchar använder du någon av följande åtgärder för att lösa problemet:

  • Om UNIX- eller Linux-värdnamnet är korrekt men Operations Manager-hanteringsservern löser det felaktigt ändrar du antingen DNS-posten så att den matchar rätt FQDN eller lägger till en post i värdfilen på Operations Manager-servern.
  • Om UNIX- eller Linux-värdnamnet är felaktigt gör du något av följande:
    • Ändra värdnamnet på UNIX- eller Linux-värden till rätt och skapa ett nytt certifikat.
    • Skapa ett nytt certifikat med önskat värdnamn.

  Så här ändrar du namnet på certifikatet:

  Om certifikatet har skapats med ett felaktigt namn kan du ändra värdnamnet och återskapa certifikatet och den privata nyckeln. Det gör du genom att köra följande kommando på UNIX- eller Linux-datorn:

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

  Alternativet -f tvingar filerna i /etc/opt/microsoft/scx/ssl att skrivas över.

  Du kan också ändra värdnamnet och domännamnet på certifikatet med hjälp -h av växlarna och -d , som i följande exempel:

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

  Starta om agenten genom att köra följande kommando:

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

  Så här lägger du till en post i värdfilen:

  Om FQDN inte finns i omvänd DNS kan du lägga till en post i värdfilen som finns på hanteringsservern för att ange namnmatchning. Värdfilen finns i \Windows\System32\Drivers\etc mappen . En post i värdfilen är en kombination av IP-adressen och det fullständiga domännamnet.

  Om du till exempel vill lägga till en post för värden med namnet newhostname.newdomain.name med IP-adressen 192.168.1.1 lägger du till följande i slutet av värdfilen:

  192.168.1.1 newhostname.newdomain.name

• En annan vanlig orsak till det här felet är att certifikatet har signerats av en ej betrodd utfärdare, till exempel när flera hanteringsservrar är medlemmar i resurspoolen som används för identifiering men certifikatförtroendet inte har konfigurerats mellan hanteringsservrarna.

  Kontrollera detta genom att bekräfta att alla hanteringsservrar i resurspoolen som används för identifiering litar på varandras servercertifikat.

  Mer information om hur du hanterar resurspooler för UNIX- och Linux-datorer finns i Hantera resurspooler för UNIX- och Linux-datorer.

Användarnamnet eller lösenordet är felaktigt

Du kan se felet när du försöker identifiera UNIX-/Linux-agenter. Felet kan inträffa under certifikatverifieringssteget när en UNIX-/Linux-dator identifieras.

Möjliga orsaker

• Grundläggande autentisering är inställt false på på en eller flera hanteringsservrar i UNIX/Linux-resurspoolen när UNIX/Linux-agenten inte är domänansluten och inte kan använda Kerberos-autentisering. Du kan kontrollera de aktuella WinRM-inställningarna genom att köra följande kommando: winrm get winrm/config/client.
• Användarnamnet eller lösenordet är felaktigt.

Lösning

Du kan uppdatera WinRM-konfigurationen på hanteringsservrarna i UNIX/Linux-resurspoolen för att tillåta grundläggande autentisering genom att köra följande kommando, eller så kan du ange konfigurationen via grupprincip:

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

Obs!

Kommandot ovan anger ett DWORD-registervärde (32-bitars) (AllowBasic) i följande registernyckel:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WinRM\Client

AllowBasic tillåter antingen 1 (aktiverade) eller 0 (inaktiverade) decimalvärden.

Certifikatsigneringsåtgärden lyckades inte

Möjliga orsaker

• Det angivna användarkontot för identifiering har inte tillräckliga behörigheter för att utföra filåtgärder som ingår i signeringen.
• Sudo-utökade privilegier för användarkontot som angetts för identifieringen har inte konfigurerats korrekt.

Lösning

Åtgärda problemet genom att kontrollera användarkontot genom att granska StdErr-utdata i felinformationen för att identifiera orsaken till felet. Kontrollera även sudo-behörighetskonfigurationen för det konto som används för certifikatsignering.

Fel vid nätverksnamnmatchning

Måladressen kan inte matchas

Dessa problem hör vanligtvis till någon av följande kategorier:

• Felbeskrivning

  Det gick inte att matcha IP-adressens <IP-adress> till namn

  Orsak

  Det här felet uppstår när en IP-adress för värden angavs för identifiering men IP-adressen inte kan matchas med ett namn i DNS (omvänd sökning).

  Lösning

  Åtgärda problemet genom att korrigera dns-konfigurationen (name resolution) för den omvända uppslagszonen och kontrollera att det finns en IP-adress till namnmappning för den berörda värden.

• Felbeskrivning

  Det gick inte att matcha namn server.contoso.com till IP-adress

  Orsak

  Det här felet uppstår om ett FQDN för värden har angetts för identifiering, men namnet inte kan matchas mot IP-adressen i DNS (framåtsökning).

  Lösning

  Åtgärda problemet genom att korrigera DNS-konfigurationen (namnmatchning) för vidare sökning och kontrollera att värdnamnet till IP-adressmappningen finns för värden.

DNS-konfiguration: Vidarebefordran av DNS-matchning matchar inte omvänd DNS-matchning

Felbeskrivning

I den här situationen får du vanligtvis ett fel som liknar följande:

Det angivna värdnamnet ServerName har matchats med IP-adressen 10.137.216.x. Värdnamnet ServerName.contoso.com som returnerades av omvänd sökning av IP-adressen 192.168.x.x matchade inte det angivna värdnamnet. Kontrollera DNS-konfigurationen och försök igen.

Orsak

Den vanligaste orsaken är att posterna för värden i zonerna för vidarebefordrande och omvänd DNS-sökning inte matchar.

Lösning

Åtgärda problemet genom att korrigera posterna i zonerna för vidarebefordran och omvänd sökning i DNS så att värdnamnen och IP-adressen matchar.

Måladressen kan inte nås

Felbeskrivning

I den här situationen får du vanligtvis ett fel som liknar följande:

WinRM-klienten kan inte slutföra åtgärden inom den angivna tiden. Kontrollera om datornamnet är giltigt och kan nås via nätverket och brandväggsfelet för Windows Remote Management-tjänsten är aktiverat.

Möjliga orsaker

• Värden kan inte nås på grund av felaktig namnmatchning, nätverksfel eller avbrott i värden.
• En nätverks- eller värdbaserad brandvägg blockerar TCP-port 1270-anslutning till målvärden.

Lösning

Åtgärda problemet genom att kontrollera att hanteringsservern kan pinga agentvärden med dess FQDN. Kontrollera också att inga nätverksbrandväggar eller värdbrandvägg blockerar TCP-port 1270.

Oväntad discoveryResult.ErrorData-typ. Felrapport – Parameternamn: s

Felbeskrivning

Oväntad DiscoveryResult.ErrorData-typ. Skicka felrapport.
ErrorData: System.ArgumentNullException
Värdet får inte vara null.
Parameternamn: s
på System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
på System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
på Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Orsak

Det här felet beror på att WinHTTP-proxyinställningarna har konfigurerats på hanteringsservrarna i UNIX- eller Linux-resurspoolen och FQDN för UNIX- eller Linux-agenten som du försöker identifiera inte ingår i listan över förbikopplingar av WinHTTP-proxy.

Lösning

Åtgärda problemet genom att lägga till UNIX- eller Linux FQDN i listan över förbikopplingar av WinHTTP-proxy.

På hanteringsservrarna i UNIX- eller Linux-resurspoolen kör du följande kommando i en upphöjd kommandotolk för att verifiera den aktuella proxykonfigurationen:

netsh winhttp show proxy

Om en WinHTTP-proxyserver har konfigurerats lägger du till FQDN för den server som du försöker identifiera i listan över förbikopplingar genom att köra följande kommando:

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

När listan över förbikopplingar har konfigurerats kontrollerar du om agentidentifieringen lyckas.

Obs!

Du kan köra netsh winhttp reset proxy kommandot för att inaktivera WinHTTP-proxyn. Det här kommandot tar bort proxyservern och konfigurerar direkt åtkomst.

Oväntad discoveryResult.ErrorData-typ. Skicka felrapport – Parameternamn: lhs

Felbeskrivning

Identifieringen lyckades inte
Meddelande: Ospecificerat fel
Information: Oväntad DiscoveryResult.ErrorData-typ. Skicka felrapport.
ErrorData: System.ArgumentNullException
Värdet får inte vara null.
Parameternamn: lhs
på System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
på System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
på Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

Orsak

Det här felet uppstår på grund av omsagent shell-filer i den installerade kits-mappen.

Lösning

Gå till följande katalog i Utforskaren:

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

Om det finns omsagentfiler i listan flyttar du dem till en tillfällig katalog utanför SCOM-filerna (System Center Operations Manager).

Se följande skärmbild för ett exempel:

När de har flyttats från mappen DownloadedKits försöker du identifiera igen. Identifieringen bör lyckas nu.

Obs!

Identifieringen kan misslyckas med ett annat fel. Felet anger att mer felsökning krävs, till exempel sudoers, anslutning och så vidare.

SSH-anslutningsfel

Misslyckades under SSH-identifieringen. Slutkod: -1073479162

Felbeskrivning

Standardutdata:
Standardfel:
Undantagsmeddelande:Ett undantag (-1073479162) gjorde att SSH-kommandot misslyckades – Det gick inte att upprätta någon anslutning eftersom måldatorn aktivt nekade det.

Möjliga orsaker

• SSH-daemon körs inte på målsystemet.
• En nätverks- eller värdbaserad brandvägg förhindrar SSH-anslutningar på TCP-port 22.

Åtgärder

• Kontrollera att SSH-daemon körs.
• Kontrollera att inga nätverksbrandväggar eller värdbrandvägg blockerar TCP-port 22.

Misslyckades under SSH-identifieringen. Slutkod: -1073479118

Felbeskrivning

Misslyckades under SSH-identifieringen. Slutkod: -1073479118
Standardutdata:
Standardfel:
Undantagsmeddelande:Ett undantag (-1073479118) orsakade att SSH-kommandot misslyckades – servern skickade frånkopplingsmeddelande: typ 2 (protokollfel: För många autentiseringsfel för roten)

Möjliga orsaker

• Användarkontot som angetts för identifiering har inte behörighet att logga in via SSH.
• Användarkontot som angavs för identifieringen angavs med ett ogiltigt användarnamn eller lösenord

Åtgärder

• Kontrollera att användaren har tillåtelse att logga in via SSH.
• Kontrollera indataautentiseringsuppgifterna och att användaren har definierats på målvärden.

Misslyckades under SSH-identifieringen. Slutkod: 1

Felbeskrivning

Misslyckades under SSH-identifieringen. Slutkod: 1
Standardutdata: Sudo-sökväg: /usr/bin/
Standardfel: sudo: du måste ha en tty för att köra sudo
Undantagsmeddelande:

Orsak

Sudo-höjning har valts i användarens indata för autentiseringsuppgifter, men requiretty alternativet har inte inaktiverats för användaren i sudoers.

Lösning

Redigera sudoers-filen på målvärden med hjälp visudo av kommandot och lägg till följande rad:

Standardinställningar: <username>!requiretty

Mer information finns i Så här konfigurerar du sudo Elevation och SSH-nycklar.

Ogiltigt SU-lösenord

Felbeskrivning

. [?1034hopsuser@lx1:~> su - root -c 'sh /tmp/scx-opsuser/GetOSVersion.sh; EC=$?; rm -rf /tmp/scx-opsuser; avsluta $EC"
Lösenord:
Avsluta
su: felaktigt lösenord
opsuser@lx1:~> avsluta
Utloggning

Möjlig orsak

Su elevation har valts i användarens indata för autentiseringsuppgifter, men ett ogiltigt rotlösenord angavs för su elevation.

Lösning

Kontrollera lösenordsindata för roten i konfigurationsdialogrutan Utökade privilegier.

Misslyckades under SSH-identifieringen. Slutkod: -2147221248

• Felbeskrivning

  Misslyckades under SSH-identifieringen. Slutkod: -2147221248
  Standardutdata:
  Standardfel: Det gick inte att chdir till hemkatalogen /home/username: Ingen sådan fil eller katalog

  Orsak

  Användarkontot som angetts för identifieringen har ingen hemkatalog.

  Lösning

  Kontrollera att användaren har en hemkatalog på: /home/ och att användaren kan skriva till den här katalogen.

• Felbeskrivning

  Misslyckades under SSH-identifieringen. Slutkod: -2147221248
  Standardutdata:
  Standardfel: rotens lösenord:
  Undantagsmeddelande:Tidsgränsen för åtgärden överst

  Orsak

  Sudo-höjning valdes i användarindata för autentiseringsuppgifter. Användarkontot som angetts för identifiering är dock inte korrekt konfigurerat för att använda lösenordsfri sudo-höjning, eller så beviljades inte de nödvändiga sudo-utökade privilegierna för användarkontot som användes vid identifieringen.

  Lösning

  Läs dokumentationen om sudo-utökade konfigurationer och verifiera användarkonfigurationen för sudo. Observera att lösenordslös sudo måste konfigureras.

WSMan-anslutningsfel

Agenten svarade på begäran men WSMan-anslutningen misslyckades på grund av: Åtkomst nekas

Möjliga orsaker

• Agenten installeras och agentcertifikatet har signerats. Användarautentiseringsuppgifterna för agentverifiering är dock ogiltiga.
• Användarkontot som angavs för identifiering konfigurerades för att autentisera med en SSH-nyckel, men användarautentiseringsuppgifterna som angavs för agentverifiering är ogiltiga.
• Det finns ett behörighetsproblem eller en felaktig PAM-konfiguration på UNIX-sidan.

Lösning

Du löser problemet genom att följa dessa steg:

1. Kontrollera att användarnamnet och lösenordet för agentverifiering har angetts korrekt och att användaren är en giltig användare på målvärden.

2. Om problemet kvarstår kontrollerar du att sudo-höjningen har konfigurerats korrekt.

3. Kontrollera även meddelandeloggen på UNIX/Linux-datorn. I AIX kan du till exempel hitta loggen under /var/adm/messages. I andra operativsystem kan platsen variera.

   Leta efter rader som följande:

   Sep 3 14:49:07 server auth|security:debug /opt/microsoft/scx/bin/omiserver PAM: pam_authenticate: error Authentication failed.

   Om du ser liknande rader i meddelandeloggen innebär det att PAM-konfigurationsfilen saknar information om OMIServer. PAM-konfigurationsfilen finns i /etc/pam.d/ katalogen eller /etc/pam.conf filen.

   Det enklaste sättet att lägga till information om OMIServer i PAM-konfigurationsfilen är att installera om SCX-agenten från grunden på datorn. Om det inte är enkelt kan du kopiera raderna som hör till OMI från en fungerande dator till den icke-fungerande datorn.

Det gick bara att identifiera WSMan för 192.168.x.x

Möjliga orsaker

• Alternativet Identifieringstyp har angetts till Endast datorer med en installerad agent och signerat certifikat och målvärden har agenten installerad. Målvärdcertifikatet har dock inte signerats. För att kunna använda identifieringsalternativet endast WSMan måste agenten installeras och certifikatet måste signeras manuellt.
• Alternativet Identifieringstyp har angetts till Endast datorer med en installerad agent och signerat certifikat, men målvärden har för närvarande inte UNIX-/Linux-agenten installerad.
• Alternativet Identifieringstyp har angetts till Endast datorer med en installerad agent och signerat certifikat, men UNIX/Linux-agenten körs inte för närvarande.
• Alternativet Identifieringstyp har angetts till Endast datorer med en installerad agent och ett signerat certifikat, men målvärden kan inte nås, en nätverks- eller värdbaserad brandvägg förhindrar anslutning eller så är UNIX/Linux-agenten för närvarande nere.

Åtgärder

• Signera certifikatet manuellt.
• Kontrollera att UNIX/Linux-agenten har installerats.
• Ändra alternativet för att identifiera alla datorer så att identifieringsguiden kan utföra certifikatsigneringen.
• Kontrollera att UNIX/Linux-agenten körs och att målvärden kan nås.
• Kontrollera att inga nätverksbrandväggar eller värdbrandvägg förhindrar åtkomst på TCP-port 1270.

Andra fel

Det går inte att köra aktiviteten mot objekten eftersom uppgiftens mål inte matchar någon av objektklasserna

Orsak

I en Hanteringsgrupp för System Center 2012 Operations Manager kan detta inträffa om unix-/Linux-hanteringspaketen som importerats är Operations Manager 2007 R2-versioner.

Lösning

Importera System Center 2012-versionerna av UNIX/Linux-operativsystemets hanteringspaket.

Agenten är installerad och datorn övervakas redan av Operations Manager

Orsak

Målvärden har redan identifierats i den här hanteringsgruppen.

Lösning

Ingen åtgärd krävs. Agentuppgradering eller migrering till en alternativ resurspool kan utföras från UNIX-/Linux-servervyn i fönstret Administration i driftkonsolen.

Det gick inte att hitta en matchande agentinstans som stöds i de importerade hanteringspaketen

Felbeskrivning

Det gick inte att hitta en matchande agentinstans som stöds i de importerade hanteringspaketen. Importera hanteringspaketen för den här plattformen för att identifiera den här datorn.

Möjliga orsaker

• Målvärden kör ett operativsystem som inte stöds.
• Rätt hanteringspaket för målvärdens operativsystem har inte importerats.
• Rätt hanteringspaket för operativsystemet har nyligen importerats men har ännu inte lästs in fullständigt.

Åtgärder

• Bekräfta att målvärden kör ett operativsystem som stöds.
• Importera hanteringspaketet för målvärdens operativsystem och version.
• Om hanteringspaketet har importerats kan det fortfarande läsas in. Vänta några minuter och kör identifieringen igen.

Det går inte att räkna upp installationsbara agenttyper. Den associerade resurspoolen kanske fortfarande initieras

Felbeskrivning

Det går inte att räkna upp installationsbara agenttyper. Den associerade resurspoolen kanske fortfarande initieras. Om du har valt en nyligen skapad resurspool väntar du några minuter innan du använder den.

Möjliga orsaker

• Resurspoolen som används i identifieringen är inte felfri, till exempel är en majoritet av medlemsservrarna offline.
• Resurspoolen som användes i identifieringen skapades nyligen, men den har inte initierats helt.

Lösning

Om resurspoolen som användes i identifieringen nyligen skapades försöker du identifiera igen efter flera minuter så att poolen kan initieras. Annars kontrollerar du Operations Manager-händelseloggen på de servrar som är medlemmar i resurspoolen som används för identifiering för att få indikationer på orsaken till problemet.

Det går inte att kopiera den nya agenten till den här datorn

Felbeskrivning

Meddelande: Det går inte att kopiera den nya agenten till den här datorn
Detaljer:
Det gick inte att kopiera paketet. Slutkod: -1073479144
Standardutdata:
Standardfel:
Undantagsmeddelande: Ett undantag (-1073479144) gjorde att SSH-kommandot misslyckades

Orsak

Filagentversioner matchar inte mellan databas- och agentlagringsplats.

Åtgärder

• Kontrollera att alla misslyckade agenter misslyckas på grund av versionsmatchningsfel. Annars kan du använda andra felsökningssteg.
• Försök att uppdatera de misslyckade agenterna igen. Vanligtvis blir listan över misslyckade agenter kortare och kortare under varje uppdateringsiteration.
• Starta om hälsotjänsten på alla medlemmar i din Linux-resurspool eller annan pool för att hantera Unix- eller Linux-datorer. Kontrollera mappen om filnamnen %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits är korrekta. Kom ihåg att stänga och öppna identifieringsguiden igen.

Mer information

Mer hjälp finns i vårt TechNet-supportforum eller kontakta Microsoft Support.