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 Management-servern 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änst

När du får anslutningsproblem i Operations Manager kontrollerar du först att Hälsotjänst 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 .

    Kommentar

    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änstens status. Annars klickar du på Start.

Kontrollera antivirusundantag

Om Hälsotjänst ä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 har slutförts via nätverket. Problem med RPC-kommunikation visas vanligtvis när en agent skickas från hanteringsservern. RPC-kommunikationsproblem orsakar vanligtvis att klient-push misslyckas med ett fel som liknar följande:

Operation Manager-servern 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 standard används eller när de tillfälliga portarna blockeras av en brandvägg. Om till exempel 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 utgö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

I det här exemplet, eftersom portundantaget för det här icke-standardintervallet inte har konfigurerats i brandväggen, 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 leta efter. Kontrollera om det här är ditt problem 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 vara 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 Konfigurera dynamisk RPC-portallokering så att den fungerar med brandväggar.

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

  1. DCOM har begränsats till en viss port. Kontrollera genom att köra dcomcnfg.exe, gå till Standardprotokoll 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 du dcomcnfg.exe, går till Min dator DCOM Config Windows Management and Instrumentation Properties Endpoints (Min dator>DCOM Config>Windows Management and Instrumentation>Properties Endpoints>) och kontrollerar att det inte finns någon anpassad inställning.

  3. Agentdatorn kör serverrollen Exchange Server 2010 Client Access. Exchange Server 2010 Client Access-tjänsten ä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ödvändiga nätverksanslutningshastigheten i samma artikel.

Kommentar

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 utbytas mellan dem. 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 upprättat 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 finns en brandvägg mellan agenterna och hanteringsservrarna måste dessutom flera auktoriserade slutpunkter definieras och underhållas i brandväggsreglerna för att tillåta kommunikation mellan dem.

För att minska de administrativa kostnaderna har Operations Manager en valfri serverroll som kallas gatewayservern. Gatewayservrar finns inom förtroendegränsen för klientagenterna 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 den obligatoriska säkra ömsesidiga autentiseringen 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 viktiga här är att om klientagenterna och hanteringsservrarna inte ligger inom samma förtroendegräns, eller om en gatewayserver 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 i personliga>certifikat för lokal dator>på hanteringsservern som gatewayen eller agenten ansluter till.

  • Bekräfta att rotcertifikatet finns i Certifikat för betrodda>rotcertifikatutfärdare>på den hanteringsserver som gatewayen eller agenten ansluter till.

  • Bekräfta att rotcertifikatet finns i Certifikat>för betrodda rotcertifikatutfärdare> på gatewayservern.

  • Bekräfta att gatewaycertifikatet finns i personliga>certifikat för lokal dator>på gatewayservern. Bekräfta att gatewaycertifikatet finns i Operations 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 har värdet för certifikatet (från mappen Lokal dator/Personlig/Certifikat i informationen i fältet Serienummer ) omvänt på gatewayservern.

  • Bekräfta att registervärdet HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber finns och har värdet för certifikatet (från mappen Lokal dator/Personlig/Certifikat i fältet Serienummer ) i den 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 för hur du hämtar och konfigurerar rätt certifikat finns i Autentisering och datakryptering för Windows-datorer.

Kontrollera om det finns ett osammanhängande namnområde på klientagenten

Ett disjoint 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 ett disjoint namnområde.

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). Uppdatera DnsHostName ä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 domänen 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 Övergång från ett disjoint namnområde till ett sammanhängande namnområde.

Kontrollera om nätverksanslutningen är långsam

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 finns i System Center 2012 R2 Operations Manager) och sedan ändra timeout-värdet manuellt.

UR8-uppdateringen ökar tidsgränsen för servern 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.

Kommentar

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

Kontrollera om det finns problem med OpsMgr Connector

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 upprättad anslutning misslyckades eftersom den anslutna värden inte svarade.). Kontrollera att det finns en nätverksanslutning, att servern körs och har registrerat dess 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ängligt och kommunikation från den här datorn tillåts.

Vanligtvis genereras dessa händelse-ID:er 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 är godkänd.

  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änst 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 hanteringsservern 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änst kan inte ansluta till Active Directory för att hämta hanteringsgruppsprincipen. Felet är Ospecificerat fel (0x80004005)
Händelse-XML:
<Event 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>
<Ospecificerade datafel></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. Det kan bero på att inga hanteringsgrupper för närvarande är konfigurerade eller att en konfigurerad hanteringsgrupp inte kunde starta. Hälsotjänst väntar på att principen från Active Directory konfigurerar en hanteringsgrupp som ska köras.
Händelse-XML:
<Event 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 anger händelseloggarna också ett problem med att kommunicera med Active Directory.

Om du ser dessa händelseloggar kontrollerar du att klientagenten kan komma åt 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 20000 händelser som anger att agenter som inte är godkända 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 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 klientagenterna 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: Classic
Användare: Ej tillämpligt
Dator: <ComputerName>
Beskrivning:
Konfigurationstjänsten för OpsMgr Management 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 arbetsobjektet 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:
OpsMgrs konfiguration kan vara inaktuell för hanteringsgruppen <GroupName> och har begärt 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 arbetsobjektet DeltaSynchronization på grund av följande undantag

Dessa händelser kan inträffa när deltasynkroniseringsprocessen 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. För att 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

    Kommentar

    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:n 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änst att kommunicera kommer sannolikt att påverkas. 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 någon 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 på 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 händelseloggen på servern om det finns 20000 händelser. 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 att agenten väntar på godkännande.
20071 OpsMgr-anslutningsappen är ansluten till %1. Anslutningen stängdes dock omedelbart utan att autentiseringen inträffade. Den troligaste orsaken till det här felet är att det inte går att autentisera antingen den här 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. Bekräfta också att TCP- och 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ö. Det här är vanligtvis ett problem med namnmatchning. Kontrollera DNS.
21006 OpsMgr-anslutningsappen kunde inte ansluta till %1:%2. Felkoden är %3(%4). Kontrollera att det finns nätverksanslutningar, att servern körs och har registrerat sin lyssnarport 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 har inte upprättats. Bekräfta att certifikatet är på plats och har konfigurerats korrekt.
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änst kommer inte att kunna kommunicera med andra hälso- och sjukvårdstjä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änst kommer inte att kunna 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 domäner som inte är betrodda 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-autentiseringen till eller från den här Hälsotjänst 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). Det här är vanligtvis en privat nyckel som saknas eller inte associeras. Undersök certifikatet. Importera certifikatet igen eller skapa ett nytt certifikat och importera det.