Felsök 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
För att kunna ö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, problem med autentiseringsuppgifter eller privilegier 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 återkallelse. Servern som används för att söka efter återkallning kan inte nås.
SSL-certifikatet innehåller ett gemensamt namn (CN) som inte matchar värdnamnet.
Det är möjligt att:
- Målcertifikatet signeras av en annan certifikatutfärdare som inte är betrodd av hanteringsservern.
- Målet har ett ogiltigt certifikat, t.ex. att dess egna namn (CN) inte matchar 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.
- 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 GMTAnvä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 skapades 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 av växlarna
-h
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 en IP-adress på 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 fel
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 verifiera 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"}
Kommentar
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 decimalvärden för antingen 1
(aktiverad) eller 0
(inaktiverad).
Certifikatsigneringsåtgärden misslyckades
Möjliga orsaker
- Det användarkonto som angetts 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 identifiering 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 med matchning av nätverksnamn
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 se till att det finns en IP-adress till namnmappning för den berörda värden.
Felbeskrivning
Det gick inte att matcha namnet server.contoso.com till IP-adressen
Orsak
Det här felet uppstår om ett FQDN för värden angavs för identifiering men namnet inte kan matchas med IP-adressen i DNS (framåtsökning).
Lösning
Åtgärda problemet genom att korrigera dns-konfigurationen (name resolution) för framåtblickande sökning och kontrollera att värdnamnet till IP-adressmappningen finns för värden.
DNS-konfiguration: Vidarebefordra 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. Verifiera DNS-konfigurationen och försök med begäran igen.
Orsak
Den vanligaste orsaken är att posterna för värden i de framåtriktade och omvända DNS-uppslagszonerna 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-adresserna 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 samt att 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.
- Ett nätverk eller en värdbaserad brandvägg blockerar TCP-port 1270-anslutning till målvärden.
Lösning
Du kan åtgärda problemet genom att kontrollera att hanteringsservern kan pinga agentvärden med hjälp av dess FQDN. Kontrollera också att inga nätverksbrandväggar eller värdbrandvägg blockerar TCP-port 1270.
Oväntad discoveryResult.ErrorData-typ. Rapportera filfel – Parameternamn: s
Felbeskrivning
Oväntad DiscoveryResult.ErrorData-typ. Skicka buggrapport.
ErrorData: System.ArgumentNullException
Värdet kan 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örbikoppling 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 det fullständiga domännamnet 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.
Kommentar
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 buggrapport.
ErrorData: System.ArgumentNullException
Värdet kan 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 paketmappen.
Lösning
Gå till följande katalog i Utforskaren:
C:\Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits
Om det finns omsagent-filer 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.
Kommentar
Identifieringen kan misslyckas med ett annat fel. Felet anger att mer felsökning krävs, till exempel sudoers, anslutning och så vidare.
SSH-anslutningsfel
Fel vid SSH-identifiering. 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-daemonen körs inte i målsystemet.
- Ett nätverk eller en värdbaserad brandvägg förhindrar SSH-anslutningar på TCP-port 22.
Upplösningar
- Kontrollera att SSH-daemonen körs.
- Kontrollera att inga nätverksbrandväggar eller värdbrandvägg blockerar TCP-port 22.
Fel vid SSH-identifiering. Slutkod: -1073479118
Felbeskrivning
Fel vid SSH-identifiering. Slutkod: -1073479118
Standardutdata:
Standardfel:
Undantagsmeddelande:Ett undantag (-1073479118) gjorde att SSH-kommandot misslyckades – servern skickade frånkopplingsmeddelande: typ 2 (protokollfel: För många autentiseringsfel för roten)
Möjliga orsaker
- Det användarkonto 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
Upplösningar
- Kontrollera att användaren har behörighet att logga in via SSH.
- Kontrollera indataautentiseringsuppgifterna och att användaren har definierats på målvärden.
Fel vid SSH-identifiering. Slutkod: 1
Felbeskrivning
Fel vid SSH-identifiering. 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 valdes i användarens indata för autentiseringsuppgifter, men requiretty
alternativet inaktiverades inte 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:
Standardvärden: <username>!requiretty
Mer information finns i Konfigurera 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:
exit
su: felaktigt lösenord
opsuser@lx1:~> avsluta
logout
Möjlig orsak
Su-höjning valdes 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.
Fel vid SSH-identifiering. Slutkod: -2147221248
Felbeskrivning
Fel vid SSH-identifiering. Slutkod: -2147221248
Standardutdata:
Standardfel: Det gick inte att chdir till hemkatalogen /home/username: Ingen sådan fil eller katalogOrsak
Användarkontot som angetts för identifiering 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
Fel vid SSH-identifiering. Slutkod: -2147221248
Standardutdata:
Standardfel: rotens lösenord:
Undantagsmeddelande:Tidsgränsen för åtgärden har överskriditsOrsak
Sudo-höjning valdes i användarens indata för autentiseringsuppgifter. Användarkontot som angetts för identifiering är dock inte korrekt konfigurerat för att använda lösenordslös sudo-höjning, eller så beviljades inte de nödvändiga sudo-utökade behörigheterna för det användarkonto som användes i identifieringen.
Lösning
Granska dokumentationen för 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 är installerad och agentcertifikatet har signerats. Användarautentiseringsuppgifterna som anges 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 anges för agentverifiering är ogiltiga.
- Det finns ett behörighetsproblem eller felaktig PAM-konfiguration på UNIX-sidan.
Lösning
Du löser problemet genom att följa dessa steg:
Kontrollera att användarnamnet och lösenordet för agentverifieringen har angetts korrekt och att användaren är en giltig användare på målvärden.
Om problemet kvarstår kontrollerar du att sudo-höjningen har konfigurerats korrekt.
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:
3 sep 14:49:07 server auth|security:debug /opt/microsoft/scx/bin/omiserver PAM: pam_authenticate: felet Autentiseringen misslyckades.
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 rör OMI från en fungerande dator till den icke-fungerande datorn.
WSMan-identifieringen misslyckades endast 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 ett 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, ett nätverk eller en värdbaserad brandvägg förhindrar anslutningen eller UNIX/Linux-agenten är för närvarande inte tillgänglig.
Upplösningar
- Signera certifikatet manuellt.
- Kontrollera att UNIX/Linux-agenten har installerats.
- Ändra alternativet till 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 System Center 2012 Operations Manager-hanteringsgrupp kan detta inträffa om UNIX/Linux-hanteringspaketen som importeras är Operations Manager 2007 R2-versioner.
Lösning
Importera System Center 2012-versionerna av UNIX/Linux-hanteringspaketen för operativsystem.
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 vyn UNIX-/Linux-servrar 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. Du måste importera hanteringspaketet/-paketen för den här plattformen innan den här datorn kan identifieras.
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 helt.
Upplösningar
- 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 kan fortfarande initieras
Felbeskrivning
Det går inte att räkna upp installationsbara agenttyper. Den associerade resurspoolen initieras kanske fortfarande. Om du har valt en nyligen skapad resurspool bör du vänta 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. I annat fall 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
Information:
Det gick inte att kopiera satsen. Slutkod: -1073479144
Standardutdata:
Standardfel:
Undantagsmeddelande: Ett undantag (-1073479144) gjorde att SSH-kommandot misslyckades
Orsak
Filagentversioner matchar inte databasen och agentlagringsplatsen.
Upplösningar
- Kontrollera att de misslyckade agenterna 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 uppdatering iteration.
- Starta om Hälsotjänst 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.