Dela via

Felsöka problem med agentanslutning i Operations Manager

  • Artikel

Den här guiden hjälper dig att felsöka problem med att Operations Manager-agenter har problem med att ansluta till hanteringsservern i System Center 2012 Operations Manager (OpsMgr 2012) och senare versioner.

Mer information om Operations Manager-agenten och hur de kommunicerar med hanteringsservrar finns i Agenter och kommunikation mellan agenter och hanteringsservrar.

Ursprunglig produktversion: System Center 2012 Operations Manager
Ursprungligt KB-nummer: 10066

Kontrollera hälsotjänsten

När du får anslutningsproblem i Operations Manager kontrollerar du först att hälsotjänsten körs utan fel på både klientagenten och hanteringsservern. Följ dessa steg för att avgöra om tjänsten körs:

  1. Tryck på Windows-tangenten+R.

  2. I rutan Kör skriver services.msc du och trycker på Retur.

  3. Leta upp tjänsten Microsoft Monitoring Agent och dubbelklicka sedan på den för att öppna sidan Egenskaper .

    Obs!

    I System Center 2012 Operations Manager är tjänstnamnet System Center Management.

  4. Kontrollera att starttypen är inställd på Automatisk.

  5. Kontrollera om Startad visas i Tjänststatus. Annars klickar du på Start.

Kontrollera antivirusundantag

Om hälsotjänsten är igång är nästa sak att bekräfta att antivirusundantag är korrekt konfigurerade. Den senaste informationen om rekommenderade antivirusundantag för Operations Manager finns i Rekommendationer för antivirusundantag som är relaterade till Operations Manager).

Kontrollera nätverksproblem

I Operations Manager måste agentdatorn kunna ansluta till TCP-port 5723 på hanteringsservern. Om detta misslyckas får du troligen händelse-ID 21016 och 21006 på klientagenten.

Förutom TCP-port 5723 måste följande portar vara aktiverade:

  • TCP- och UDP-port 389 för LDAP
  • TCP- och UDP-port 88 för Kerberos-autentisering
  • TCP- och UDP-port 53 för DNS (Domain Name Service)

Dessutom måste du se till att RPC-kommunikationen slutförs via nätverket. Problem med RPC-kommunikation visar sig vanligtvis när en agent skickas från hanteringsservern. RPC-kommunikationsproblem gör vanligtvis att klient-push misslyckas med ett fel som liknar följande:

Åtgärdshanterarens server kunde inte utföra den angivna åtgärden på datorn agent1.contoso.com.

Åtgärd: Agentinstallation
Installera konto: contoso\Agent_action
Felkod: 800706BA
Felbeskrivning: RPC-servern är inte tillgänglig

Det här felet uppstår vanligtvis när tillfälliga portar som inte är av standard används eller när de tillfälliga portarna blockeras av en brandvägg. Om RPC-portar som inte är standard har konfigurerats visar en nätverksspårning en lyckad anslutning till RPC-port 135 följt av ett anslutningsförsök med en RPC-port som inte är standard, till exempel 15595. Följande är ett exempel:

18748 MS Agent TCP TCP: Flags=CE.... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192
18750 MS Agent TCP TCP:[SynReTransmit #18748] Flags=CE.... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0,
18751 MS Agent TCP TCP:[SynReTransmit #18748] Flags=...... S., SrcPort=52457, DstPort=15595, PayloadLen=0, Seq=1704157139, Ack=0, Win=8192

Eftersom portundantaget för det här icke-standardintervallet inte har konfigurerats i brandväggen i det här exemplet tas paketen bort och anslutningen misslyckas.

I Windows Vista och senare versioner är RPC-portarna med hög räckvidd 49152-65535, så det är det vi vill söka efter. Kontrollera om det här är problemet genom att köra följande kommando för att se vilket RPC-hög portintervall som har konfigurerats:

netsh int ipv4 show dynamicportrange tcp

Enligt IANA-standarder bör utdata se ut så här:

Protokoll tcp dynamiskt portintervall
---------------------------------
Startport: 49152
Antal portar: 16384

Om du ser en annan startport kan problemet bero på att brandväggen inte är korrekt konfigurerad för att tillåta trafik via dessa portar. Du kan ändra konfigurationen i brandväggen eller köra följande kommando för att ställa in portarna med högt intervall tillbaka till standardvärdena:

netsh int ipv4 set dynamicport tcp start=49152 num=16384

Du kan också konfigurera det dynamiska RPC-portintervallet via registret. Mer information finns i Så här konfigurerar du dynamisk RPC-portallokering för att fungera med brandväggar.

Om allt verkar vara korrekt konfigurerat och du fortfarande upplever felet kan det bero på något av följande villkor:

  1. DCOM har begränsats till en viss port. Kontrollera genom att köra dcomcnfg.exe, gå tillStandardprotokoll för mina datoregenskaper>> och se till att det inte finns någon anpassad inställning.

  2. WMI har konfigurerats för att använda en anpassad slutpunkt. Om du vill kontrollera om du har en statisk slutpunkt konfigurerad för WMI kör dcomcnfg.exedu , gå till Min datorDCOM Config Windows Management and Instrumentation PropertiesEndpoints (Min dator >DCOM Config>Windows Management and Instrumentation>Properties Endpoints>) och kontrollera att det inte finns någon anpassad inställning.

  3. Agentdatorn kör serverrollen Exchange Server 2010 Client Access. Klientåtkomsttjänsten Exchange Server 2010 ändrar portintervallet till 6005 till 65535. Intervallet utökades för att ge tillräcklig skalning för stora distributioner. Ändra inte dessa portvärden utan att helt förstå konsekvenserna.

Mer information om port- och brandväggskrav finns i Brandväggar. Du kan också hitta den minsta nätverksanslutningshastighet som krävs i samma artikel.

Obs!

Felsökning av nätverksproblem är ett mycket stort problem, så det är bäst att kontakta en nätverkstekniker om du misstänker att ett underliggande nätverksproblem orsakar problem med agentanslutningen i Operations Manager. Vi har också viss grundläggande, generaliserad information om nätverksfelsökning som är tillgänglig från vårt supportteam för Windows Directory Services som är tillgängligt i Felsökning av nätverk utan NetMon.

Kontrollera certifikatproblem på gatewayservern

Operations Manager kräver att ömsesidig autentisering utförs mellan klientagenter och hanteringsservrar innan information mellan dem utbyts. För att skydda autentiseringsprocessen krypteras processen. När agenten och hanteringsservern finns i samma Active Directory-domän, eller i Active Directory-domäner som har etablerade förtroenderelationer, använder de de Kerberos v5-autentiseringsmekanismer som tillhandahålls av Active Directory. När agenterna och hanteringsservrarna inte ligger inom samma förtroendegräns måste andra mekanismer användas för att uppfylla kravet på säker ömsesidig autentisering.

I Operations Manager utförs detta genom användning av X.509-certifikat som utfärdats för varje dator. Om det finns många agentövervakade datorer kan det leda till höga administrativa kostnader för att hantera alla dessa certifikat. Om det dessutom finns en brandvägg mellan agenterna och hanteringsservrarna måste flera auktoriserade slutpunkter definieras och underhållas i brandväggsreglerna för att tillåta kommunikation mellan dem.

För att minska det administrativa arbetet har Operations Manager en valfri serverroll som kallas gatewayserver. Gatewayservrar finns inom klientagenternas förtroendegräns och kan delta i den obligatoriska ömsesidiga autentiseringen. Eftersom gatewayer ligger inom samma förtroendegräns som agenterna används Kerberos v5-protokollet för Active Directory mellan agenterna och gatewayservern, och varje agent kommunicerar sedan endast med de gatewayservrar som den känner till.

Gatewayservrarna kommunicerar sedan med hanteringsservrarna för klienternas räkning. För att stödja obligatorisk säker ömsesidig autentisering mellan gatewayservern och hanteringsservrarna måste certifikat utfärdas och installeras, men endast för gateway- och hanteringsservrarna. Detta minskar antalet certifikat som krävs. När det gäller en mellanliggande brandvägg minskar det också antalet auktoriserade slutpunkter som måste definieras i brandväggsreglerna.

Det viktigaste här är att om klientagenterna och hanteringsservrarna inte ligger inom samma förtroendegräns, eller om en gateway-server används, måste de nödvändiga certifikaten installeras och konfigureras korrekt för att agentanslutningen ska fungera korrekt. Här följer några viktiga saker att kontrollera:

  • Bekräfta att gatewaycertifikatet finns iPersonliga> certifikat för lokal dator> påhanteringsservern som gatewayen eller agenten ansluter till.

  • Bekräfta att rotcertifikatet finns i Certifikat> förbetrodda rotcertifikatutfärdare> på denhanteringsserver som gatewayen eller agenten ansluter till.

  • Bekräfta att rotcertifikatet finns iCertifikat förbetrodda rotcertifikatutfärdare> på gatewayservern på den lokala datorn>.

  • Bekräfta att gatewaycertifikatet finns ipersonliga>certifikat för lokal dator> på gatewayservern. Bekräfta att gatewaycertifikatet finns iOperations Manager-certifikat> för lokal dator> på gatewayservern.

  • Bekräfta att registervärdet HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber finns och att värdet för certifikatet (från mappen Lokal dator/Personlig/Certifikat i informationen i fältet Serienummer ) har återställts i det på gatewayservern.

  • Bekräfta att registervärdet HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber finns och att värdet för certifikatet (från mappen Lokal dator/Personlig/Certifikat i informationen i fältet Serienummer ) har återförts i det på hanteringsservern som gatewayen eller agenten ansluter till.

Du kan få följande händelse-ID:t i Operations Manager-händelseloggen när det finns ett problem med certifikat:

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

Mer information om hur certifikatbaserad autentisering fungerar i Operations Manager, samt instruktioner om hur du hämtar och konfigurerar rätt certifikat finns i Autentisering och datakryptering för Windows-datorer.

Sök efter ett osammanhängande namnområde på klientagenten

Ett osammanhängande namnområde inträffar när klientdatorn har ett primärt DNS-suffix som inte matchar DNS-namnet på den Active Directory-domän som klienten tillhör. En klient som till exempel använder ett primärt DNS-suffix för corp.contoso.com i en Active Directory-domän med namnet na.corp.contoso.com använder en uppdelad namnrymd.

När klientagenten eller hanteringsservern har ett osammanhängande namnområde kan Kerberos-autentiseringen misslyckas. Även om det här är ett Active Directory-problem och inte ett Operations Manager-problem, påverkar det agentanslutningen.

Mer information finns i Dela upp namnrymd.

Lös problemet genom att använda någon av följande metoder:

Metod 1

Skapa lämpliga tjänsthuvudnamn (SPN) manuellt för de berörda datorkontona och inkludera värd-SPN för det fullständigt kvalificerade domännamnet (FQDN) tillsammans med det uppdelade namnsuffixet (HOST/machine.disjointed_name_suffix.local). DnsHostName Uppdatera även attributet för datorn så att det återspeglar det uppdelade namnet (machine.disjointed_name_suffix.local) och aktivera registrering för attributet i en giltig DNS-zon på de DNS-servrar som Active Directory använder.

Metod 2

Korrigera det uppdelade namnområdet. Det gör du genom att ändra namnområdet i den berörda datorns egenskaper så att det återspeglar FQDN för den domän som datorn tillhör. Se till att du är fullt medveten om konsekvenserna av att göra detta innan du gör några ändringar i din miljö. Mer information finns i Transition from a Disjoint Namespace to a Contiguous Namespace (Övergång från ett osammanhängande namnområde till ett sammanhängande namnområde).

Sök efter en långsam nätverksanslutning

Om klientagenten körs över en långsam nätverksanslutning kan det uppstå anslutningsproblem på grund av att det finns en hårdkodad tidsgräns för autentisering. Lös problemet genom att installera System Center 2012 Operations Manager SP1 Samlad uppdatering 8 (förutsatt att du inte redan använder System Center 2012 R2 Operations Manager) och sedan ändra timeout-värdet manuellt.

UR8-uppdateringen ökar serverns tidsgräns till 20 sekunder och klientens timeout till 5 minuter.

Mer information finns i Samlad uppdatering 8 för System Center 2012 Operations Manager Service Pack 1.

Obs!

Det här problemet kan också inträffa när det finns tidssynkroniseringsproblem mellan klientagenten och hanteringsservern.

Sök efter problem med OpsMgr-anslutningsprogrammet

Om allt annat checkar ut kontrollerar du operations manager-händelseloggen för eventuella felhändelser som genereras av OpsMgr Connector. Vanliga orsaker och lösningar för olika OpsMgr Connector-händelser visas nedan.

Händelse-ID 21006 och 21016 visas på klientagenten

Exempel på dessa händelser:

Källa: OpsMgr Connector
Datum: Tid
Händelse-ID: 21006
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning: OpsMgr Connector kunde inte ansluta till <ManagementServer>:5723. Felkoden är 10060L (Ett anslutningsförsök misslyckades eftersom den anslutna parten inte svarade korrekt efter en viss tidsperiod eller att den upprättade anslutningen misslyckades eftersom den anslutna värden inte svarade.). Kontrollera att det finns en nätverksanslutning, att servern körs och att den har registrerat sin lyssningsport och att det inte finns några brandväggar som blockerar trafiken till målet.

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Datum: Tid
Händelse-ID: 21016
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning: OpsMgr kunde inte konfigurera en kommunikationskanal till <ManagementServer> och det finns inga redundansvärdar. Kommunikationen återupptas när <ManagementServer> är tillgänglig och kommunikation från den här datorn tillåts.

Vanligtvis genereras dessa händelse-ID:t eftersom agenten inte har tagit emot konfigurationen. När en ny agent har lagts till och innan den har konfigurerats är den här händelsen vanlig. Händelse 1210 i agentens Operations Manager-händelselogg anger att agenten tog emot och tillämpade konfigurationen. Du får den här händelsen när kommunikationen har upprättats.

Du kan använda följande steg för att felsöka det här problemet:

  1. Om automatiskt godkännande för manuellt installerade agenter inte är aktiverat kontrollerar du att agenten har godkänts.

  2. Kontrollera att följande portar är aktiverade för kommunikation:

    • 5723 och TCP och UDP-port 389 för LDAP.
    • TCP- och UDP-port 88 för Kerberos-autentisering.
    • TCP- och UDP-port 53 för DNS-server.

  3. Den här händelsen kan potentiellt tyda på att Kerberos-autentiseringen misslyckas. Sök efter Kerberos-fel i händelseloggarna och felsöka.

  4. Kontrollera om DNS-suffixet har en felaktig domän. Datorn är till exempel ansluten till contoso1.com men det primära DNS-suffixet är inställt på contoso2.com.

  5. Kontrollera att standardregisternycklarna för domännamn är korrekta. Kontrollera att följande registernycklar matchar domännamnet:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain

  6. Ett duplicerat SPN för hälsotjänsten kan också orsaka händelse-ID 21016. Kör följande kommando för att hitta det duplicerade SPN:et:

    setspn -F -Q MSOMHSvc/<fully qualified name of the management server in the event>

    Om dubblett-SPN registreras måste du ta bort SPN för det konto som inte används för hanteringsserverns hälsotjänst.

Händelse-ID 20057 visas på hanteringsservern

Ett exempel på den här händelsen:

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Datum: tid
Händelse-ID: 20057
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:Det gick inte att initiera säkerhetskontexten för MSOMHSvc/******Felet som returneras är 0x80090311(Ingen utfärdare kunde kontaktas för autentisering.). Det här felet kan gälla antingen Kerberos- eller SChannel-paketet.

Händelse-ID:n 21006, 21016 och 20057 orsakas vanligtvis av brandväggar eller nätverksproblem som förhindrar kommunikation via de portar som krävs. Om du vill felsöka det här problemet kontrollerar du brandväggarna mellan klientagenten och hanteringsservern. Följande portar måste vara öppna för att aktivera korrekt autentisering och kommunikation:

  • TCP- och UDP-port 389 för LDAP.
  • TCP- och UDP-port 88 för Kerberos-autentisering.

Händelse-ID 2010 och 2003 visas på klientagenten

Exempel på dessa händelser:

Loggnamn: Operations Manager
Källa: HealthService
Datum: data
Händelse-ID: 2010
Aktivitetskategori: Hälsotjänst
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning: Hälsotjänsten kan inte ansluta till Active Directory för att hämta grupprincip för hantering. Felet är Ospecificerat fel (0x80004005)
Händelse-XML:
<Händelse-xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Providernamn="HealthService" />
<EventID Qualifiers="49152">2010/<EventID>
<Nivå>2</nivå>
<Uppgift>1</aktivitet>
<Nyckelord>0x80000000000000</nyckelord>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z" />
<EventRecordID>84143</EventRecordID>
<Channel>Operations Manager</Channel>
<Datordatornamn></dator>
<Säkerhet/>
</System>
<EventData>
<Data>Ospecificerat fel</Data>
<Data>0x80004005</data>
</EventData>
</Händelse>

Loggnamn: Operations Manager
Källa: HealthService
Datum: tid
Händelse-ID: 2003
Aktivitetskategori: Hälsotjänst
Nivå: Information
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning: Inga hanteringsgrupper startades. Detta kan antingen bero på att inga hanteringsgrupper är konfigurerade för närvarande eller att en konfigurerad hanteringsgrupp inte kunde starta. Hälsotjänsten väntar på att principen från Active Directory som konfigurerar en hanteringsgrupp ska köras.
Händelse-XML:
<Händelse-xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Providernamn="HealthService" />
<EventID Qualifiers="16384">2003/<EventID>
<Nivå>4</nivå>
<Uppgift>1</aktivitet>
<Nyckelord>0x80000000000000</nyckelord>
<TimeCreated SystemTime="2015-02-21T21:06:04.000000000Z" />
<EventRecordID>84156</EventRecordID>
<Channel>Operations Manager</Channel>
<Datordatornamn></dator>
<Säkerhet/>
</System>
<EventData>
</EventData>
</Händelse>

Om agenten använder Active Directory-tilldelning visar händelseloggarna också ett problem med att kommunicera med Active Directory.

Om du ser dessa händelseloggar kontrollerar du att klientagenten har åtkomst till Active Directory. Kontrollera brandväggar, namnmatchning och allmän nätverksanslutning.

Händelse-ID 20070 kombinerat med händelse-ID 21016

Exempel på dessa händelser:

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Datum: 2014-06-13 22:13:39
Händelse-ID: 21016
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr kunde inte konfigurera en kommunikationskanal till <ComputerName> och det finns inga redundansvärdar. Kommunikationen återupptas när <ComputerName> är tillgängligt och kommunikation från den här datorn tillåts.

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Datum: 2014-06-13 22:13:37
Händelse-ID: 20070
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr-anslutningsappen är ansluten till <ComputerName>, men anslutningen stängdes omedelbart efter att autentiseringen inträffade. Den troligaste orsaken till det här felet är att agenten inte har behörighet att kommunicera med servern eller att servern inte har fått någon konfiguration. Kontrollera händelseloggen på servern om det finns 2 000 händelser, vilket anger att agenter som inte har godkänts försöker ansluta.

När du ser dessa händelser indikerar det att autentiseringen inträffade men sedan stängdes anslutningen. Detta beror vanligtvis på att agenten inte har konfigurerats. Kontrollera detta genom att kontrollera om händelse-ID 20000 En enhet som inte ingår i den här hanteringsgruppen har försökt komma åt den här hälsotjänsten tas emot på hanteringsservern.

Dessa händelseloggar kan också inträffa om klientagenter har fastnat i statusen Väntar och inte visas i konsolen.

Kontrollera genom att köra följande kommando för att kontrollera om agenterna visas för manuellt godkännande:

Get-SCOMPendingManagement

I så fall kan du lösa detta genom att köra följande kommando för att godkänna agenterna manuellt:

Get-SCOMPendingManagement| Approve-SCOMPendingManagement

Händelse-ID 21023 visas på klientagenten, medan händelse-ID 29120, 29181 och 21024 visas på hanteringsservern

Några exempel på dessa händelser ingår nedan.

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Händelse-ID: 21023
Aktivitetskategori: Ingen
Nivå: Information
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr har ingen konfiguration för hanteringsgruppen <GroupName> och begär ny konfiguration från konfigurationstjänsten.

Loggnamn: Operations Manager
Källa: OpsMgr-hanteringskonfiguration
Händelse-ID: 29120
Aktivitetskategori: Ingen
Nivå: Varning
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr Management Configuration Service kunde inte bearbeta konfigurationsbegäran (XML-konfigurationsfil eller hanteringspaketbegäran) på grund av följande undantag

Loggnamn: Operations Manager
Källa: OpsMgr-hanteringskonfiguration
Händelse-ID: 29181
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr Management Configuration Service kunde inte köra motorn GetNextWorkItem på grund av följande undantag

Loggnamn: Operations Manager
Källa: OpsMgr-hanteringskonfiguration
Händelse-ID: 29181
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr Management Configuration Service kunde inte köra motorarbetsobjektet LocalHealthServiceDirtyNotification på grund av följande undantag

Loggnamn: Operations Manager
Källa: OpsMgr-hanteringskonfiguration
Händelse-ID: 21024
Aktivitetskategori: Ingen
Nivå: Information
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr-konfigurationen kan vara inaktuell för hanteringsgruppen <GroupName> och har begärt en uppdaterad konfiguration från konfigurationstjänsten. Aktuell (inaktuell) tillståndscookie är "5dae442500c9d3f8f7a883e83851994,906af60d48ed417fb1860b23ed67dd71:001662A3"

Loggnamn: Operations Manager
Källa: OpsMgr Connector
Händelse-ID: 29181
Aktivitetskategori: Ingen
Nivå: Fel
Nyckelord: Klassisk
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
OpsMgr Management Configuration Service kunde inte köra motorarbetsobjektet DeltaSynchronization på grund av följande undantag

Dessa händelser kan inträffa när processen för deltasynkronisering inte kan skapa konfiguration inom det konfigurerade tidsgränsfönstret på 30 sekunder. Detta kan inträffa när det finns ett stort instansutrymme.

Lös problemet genom att öka tidsgränsen på alla hanteringsservrar. Om du vill göra detta använder du någon av följande metoder:

Metod 1

  1. Gör en säkerhetskopia av följande fil:

    Enhet:\Program Files\System Center 2012\Operations Manager\Server\ConfigService.Config

  2. Öka tidsgränsvärdena i ConfigService.config med följande ändringar:

    Leta upp <OperationTimeout DefaultTimeoutSeconds="30">, ändra 30 till 300.
    Leta upp <Operation Name="GetEntityChangeDeltaList" TimeoutSeconds="180" />, ändra 180 till 300.

  3. Starta om konfigurationstjänsten.

I de flesta fall bör detta ge tillräckligt med tid för att synkroniseringsprocessen ska slutföras.

Metod 2

  1. Installera Samlad uppdatering 3 eller senare för System Center 2012 R2 Operations Manager.

  2. Lägg till följande registervärde på servern som kör System Center 2012 R2 Operations Manager för att konfigurera tidsgränsen:

    • Registerundernyckel: HKEY_LOCAL_MACHINE\Software\Microsoft Operations Manager\3.0\Config Service
    • DWORD-namn: CommandTimeoutSeconds
    • DWORD-värde: nn

    Obs!

    Standardvärdet för platshållaren nn är 30 sekunder. Du kan ändra det här värdet för att styra tidsgränsen för deltasynkronisering.

Andra händelse-ID:t för OpsMgr Connector

Andra OpsMgr Connector-felhändelser och motsvarande felsökningsförslag visas nedan:

Händelse Beskrivning Mer information
20050 Det gick inte att läsa in det angivna certifikatet eftersom den utökade nyckelanvändningen som anges inte uppfyller OpsMgr-kraven. Certifikatet måste ha följande användningstyper: %n %n Serverautentisering (1.3.6.1.5.5.7.3.1)%n Klientautentisering (1.3.6.1.5.5.7.3.2)%n Bekräfta objektidentifieraren för certifikatet.
20057 Det gick inte att initiera säkerhetskontexten för målet %1 Felet som returnerades är %2(%3). Det här felet kan gälla antingen Kerberos-paketet eller SChannel-paketet. Sök efter duplicerade eller felaktiga SPN:er.
20066 Ett certifikat för användning med ömsesidig autentisering har angetts. Det gick dock inte att hitta certifikatet. Möjligheten för den här hälsotjänsten att kommunicera påverkas sannolikt. Kontrollera certifikatet.
20068 Certifikatet som anges i registret på HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings kan inte användas för autentisering eftersom certifikatet inte innehåller en användbar privat nyckel eller eftersom den privata nyckeln inte finns. Felet är %1(%2). Sök efter en privat nyckel som saknas eller inte har associerats. Undersök certifikatet. Importera certifikatet igen eller skapa ett nytt certifikat och importera.
20069 Det gick inte att läsa in det angivna certifikatet eftersom KeySpec måste vara AT_KEYEXCHANGE Kontrollera certifikatet. Kontrollera objektidentifieraren för certifikatet.
20070 OpsMgr-anslutningsappen är ansluten till %1. Anslutningen stängdes dock omedelbart efter att autentiseringen inträffade. Den troligaste orsaken till det här felet är att agenten inte har behörighet att kommunicera med servern eller att servern inte har tagit emot konfigurationen. Kontrollera om det finns 20000 händelser i händelseloggen på servern. Dessa anger att agenter som inte är godkända försöker ansluta. Autentiseringen inträffade men anslutningen stängdes. Bekräfta att portarna är öppna och kontrollera agenten som väntar på godkännande.
20071 OpsMgr-anslutningsappen är ansluten till %1. Anslutningen stängdes dock omedelbart utan att autentiseringen utfördes. Den troligaste orsaken till det här felet är att det inte går att autentisera agenten eller servern. Kontrollera händelseloggen på servern och på agenten efter händelser som indikerar att det inte gick att autentisera. Autentiseringen misslyckades. Kontrollera brandväggar och port 5723. Agentdatorn måste kunna nå port 5723 på hanteringsservern. Kontrollera också att TCP & UDP-port 389 för LDAP, port 88 för Kerberos och port 53 för DNS är tillgängliga.
20072 Fjärrcertifikatet %1 var inte betrott. Felet är %2(%3). Kontrollera om certifikatet finns i det betrodda arkivet.
20077 Certifikatet som anges i registret på HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings kan inte användas för autentisering eftersom certifikatet inte kan efterfrågas för egenskapsinformation. Det specifika felet är %2(%3).%n %n. Det innebär vanligtvis att ingen privat nyckel ingick i certifikatet. Dubbelkolla för att kontrollera att certifikatet innehåller en privat nyckel. Det finns en privat nyckel som saknas eller inte associeras. Undersök certifikatet. Importera certifikatet igen eller skapa ett nytt certifikat och importera.
21001 OpsMgr Connector kunde inte ansluta till %1 eftersom ömsesidig autentisering misslyckades. Kontrollera att SPN är korrekt registrerat på servern och att det finns en fullständig förtroenderelation mellan de två domänerna om servern finns i en separat domän. Kontrollera SPN-registreringen.
21005 OpsMgr Connector kunde inte matcha IP-adressen för %1. Felkoden är %2(%3). Kontrollera att DNS fungerar korrekt i din miljö. Detta är vanligtvis ett problem med namnmatchning. Kontrollera DNS.
21006 OpsMgr-anslutningen kunde inte ansluta till %1:%2. Felkoden är %3(%4). Kontrollera att det finns en nätverksanslutning, att servern körs och har registrerat sin lyssningsport och att det inte finns några brandväggar som blockerar trafiken till målet. Detta är sannolikt ett allmänt anslutningsproblem. Kontrollera brandväggarna och bekräfta att port 5723 är öppen.
21007 OpsMgr Connector kan inte skapa en ömsesidigt autentiserad anslutning till %1 eftersom den inte finns i en betrodd domän. Ett förtroende upprättas inte. Bekräfta att certifikatet är på plats och att det är korrekt konfigurerat.
21016 OpsMgr kunde inte konfigurera en kommunikationskanal till %1 och det finns inga redundansvärdar. Kommunikationen återupptas när %1 är tillgänglig och kommunikationen från den här datorn är aktiverad. Detta indikerar vanligtvis ett autentiseringsfel. Bekräfta att agenten har godkänts för övervakning och att alla portar är öppna.
21021 Det gick inte att läsa in eller skapa något certifikat. Den här hälsotjänsten kan inte kommunicera med andra hälsotjänster. Leta efter tidigare händelser i händelseloggen för mer information. Kontrollera certifikatet.
21022 Inget certifikat har angetts. Den här hälsotjänsten kan inte kommunicera med andra hälsotjänster om inte dessa hälsotjänster finns i en domän som har en förtroenderelation med den här domänen. Om den här hälsotjänsten måste kommunicera med hälsotjänster i ej betrodda domäner konfigurerar du ett certifikat. Kontrollera certifikatet.
21035 Registreringen av ett SPN för den här datorn med tjänstklassen %1 misslyckades med felet %2. Detta kan leda till att Kerberos-autentisering till eller från hälsotjänsten misslyckas. Detta indikerar ett problem med SPN-registrering. Undersök SPN för Kerberos-autentisering.
21036 Certifikatet som anges i registret på HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings kan inte användas för autentisering. Felet är %1(%2). Detta är vanligtvis en privat nyckel som saknas eller inte associeras. Undersök certifikatet. Importera certifikatet igen eller skapa ett nytt certifikat och importera det.