Dela via

Felsöka problem med Uppdateringshantering

  • Artikel

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som har statusen End Of Life (EOL). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

I den här artikeln beskrivs problem som du kan stöta på när du använder funktionen Uppdateringshantering för att utvärdera och hantera uppdateringar på dina datorer. Det finns en agentfelsökare för Hybrid Runbook Worker-agenten som hjälper dig att fastställa det underliggande problemet. Mer information om felsökaren finns i Felsöka problem med Windows-uppdateringsagenten och Felsöka problem med Linux-uppdateringsagenten. Andra problem med funktionsdistribution finns i Felsöka problem med funktionsdistribution.

Kommentar

Om du stöter på problem när du distribuerar uppdateringshantering på en Windows-dator öppnar du Windows-Prikazivač događaja och kontrollerar Händelseloggen för Operations Manager under Program- och tjänstloggar på den lokala datorn. Leta efter händelser med händelse-ID 4502 och händelseinformation som innehåller Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent.

Scenario: Windows Defender-uppdateringen visas alltid som saknad

Problem

Definitionsuppdatering för Windows Defender (KB2267602) visas alltid som saknad i en utvärdering när den är installerad och visas som uppdaterad när den verifieras från Windows Update-historiken.

Orsak

Definitionsuppdateringar publiceras flera gånger per dag. Därför kan du se flera versioner av KB2267602 publicerade på en enda dag, men med ett annat uppdaterings-ID och en annan version.

Uppdateringshanteringsutvärderingen körs en gång på 11 timmar. I det här exemplet kördes en utvärdering kl. 10:00 och version 1.237.316.0 var då tillgänglig. När du söker i tabellen Uppdatera på Log Analytics-arbetsytan, visas definitionsuppdatering 1.237.316.0 med UpdateState som Krävs. Om en schemalagd distribution körs några timmar senare ska vi säga att 13:00 och version 1.237.316.0 fortfarande är tillgänglig eller att en nyare version är, att den nyare versionen är installerad och detta återspeglas i posten som skrivits till tabellen UpdateRunProgress . Men i tabellen Uppdatera visas fortfarande version 1.237.316.0 som Krävs tills nästa utvärdering körs. När utvärderingen körs igen kanske det inte finns någon nyare definitionsuppdatering tillgänglig, så tabellen Update visar inte definitionsuppdateringsversionen 1.237.316.0 som saknad eller en nyare version tillgänglig efter behov. På grund av frekvensen för definitionsuppdateringar kan det finnas flera versioner som returneras i loggsökningen.

Åtgärd

Kör följande loggfråga för att bekräfta att installerade definitionsuppdateringar rapporteras korrekt. Den här frågan returnerar tidsgenererat, versions- och uppdaterings-ID för KB2267602 i tabellen Uppdateringar . Ersätt värdet för Dator med datorns fullständigt kvalificerade namn.

Update
| where TimeGenerated > ago(14h) and OSType != "Linux" and (Optional == false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((
    Heartbeat
    | where TimeGenerated > ago(12h) and OSType =~ "Windows" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, *) by Computer, SourceComputerId, UpdateID
| where UpdateState =~ "Needed" and Approved != false and Computer == "<computerName>"
| render table

Frågeresultatet bör returnera något som liknar följande:

Exempel som visar resultat av loggfråga från tabellen Uppdateringar.

Kör följande loggfråga för att hämta tidsgenererat, versions- och uppdaterings-ID för KB2267602 i tabellen UpdatesRunProgress . Den här frågan hjälper oss att förstå om den har installerats från Uppdateringshantering eller om den installerades automatiskt på datorn från Microsoft Update. Du måste ersätta värdet för CorrelationId med runbook-jobbets GUID (d.v.s . masterJOBID-egenskapsvärdet från Runbook-jobbet Patch-MicrosoftOMSComputer ) för uppdateringen och SourceComputerId med datorns GUID.

UpdateRunProgress
| where OSType!="Linux" and CorrelationId=="<master job id>" and SourceComputerId=="<source computer id>"
| summarize arg_max(TimeGenerated, Title, InstallationStatus) by UpdateId
| project TimeGenerated, id=UpdateId, displayName=Title, InstallationStatus

Frågeresultatet bör returnera något som liknar följande:

Exempel som visar resultat av loggfråga från tabellen UpdatesRunProgress.

Om värdet TimeGenerated för loggfrågans resultat från tabellen Uppdateringar är tidigare än tidsstämpeln (dvs. värdet för TimeGenerated) för uppdateringsinstallationen på datorn eller från loggfrågeresultatet från tabellen UpdateRunProgress väntar du på nästa utvärdering. Därefter kör du loggfrågan mot tabellen Uppdateringar igen. Antingen visas inte en uppdatering för KB2267602 eller så visas den med en nyare version. Men även efter den senaste utvärderingen om samma version visas som Behövs i tabellen Uppdateringar men den redan är installerad bör du öppna en Azure-supportincident.

Scenario: Linux-uppdateringar visas som väntande och de installerade varierar

Problem

För din Linux-dator visar Uppdateringshantering specifika uppdateringar som är tillgängliga under klassificeringssäkerhet och andra. Men när ett uppdateringsschema körs på datorn, till exempel för att endast installera uppdateringar som matchar säkerhetsklassificeringen, skiljer sig de installerade uppdateringarna från eller en delmängd av uppdateringarna som visades tidigare och som matchade klassificeringen.

Orsak

När en utvärdering av väntande os-uppdateringar för Linux-datorn är klar används OVAL-filer (Open Vulnerability and Assessment Language ) som tillhandahålls av Linux-distributionsleverantören av Uppdateringshantering för klassificering. Kategorisering görs för Linux-uppdateringar som Säkerhet eller Andra, baserat på OVAL-filer som anger uppdateringar som hanterar säkerhetsproblem eller sårbarheter. Men när uppdateringsschemat körs körs det på Linux-datorn med lämplig pakethanterare som YUM, APT eller ZYPPER för att installera dem. Pakethanteraren för Linux-distributionen kan ha en annan mekanism för att klassificera uppdateringar, där resultaten kan skilja sig från de som hämtas från OVAL-filer av Uppdateringshantering.

Åtgärd

Du kan kontrollera Linux-datorn manuellt, tillämpliga uppdateringar och deras klassificering enligt distributionens pakethanterare. Kör följande kommandon för att förstå vilka uppdateringar som klassificeras som Säkerhet av pakethanteraren.

För YUM returnerar följande kommando en lista över uppdateringar som inte är noll och kategoriseras som Säkerhet av Red Hat.

sudo yum -q --security check-update

För ZYPPER returnerar följande kommando en lista över uppdateringar som inte är noll och kategoriseras som Säkerhet efter SUSE.

sudo LANG=en_US.UTF8 zypper --non-interactive patch --category security --dry-run

För APT returnerar följande kommando en lista över uppdateringar som inte är noll och kategoriseras som Säkerhet av Canonical för Ubuntu Linux-distributioner.

sudo grep security /etc/apt/sources.list > /tmp/oms-update-security.list LANG=en_US.UTF8 sudo apt-get -s dist-upgrade -oDir::Etc::Sourcelist=/tmp/oms-update-security.list

I den här listan kör du sedan kommandot grep ^Inst för att hämta alla väntande säkerhetsuppdateringar.

Scenario: Du får felet "Det gick inte att aktivera uppdateringslösningen"

Problem

När du försöker aktivera Uppdateringshantering i ditt Automation-konto får du följande fel:

Error details: Failed to enable the Update solution

Orsak

Felet kan uppstå på grund av någon av följande orsaker:

  • Kraven för nätverksbrandväggen för Log Analytics-agenten kanske inte är korrekt konfigurerade. Den här situationen kan leda till att agenten misslyckas när dns-URL:erna matchas.

  • Mål för uppdateringshantering är felkonfigurerade och datorn tar inte emot uppdateringar som förväntat.

  • Du kanske också märker att datorn visar statusen Non-compliant under Efterlevnad. Samtidigt rapporterar Radna površina agenta Analytics agenten som Disconnected.

Åtgärd

Scenario: Ersatt uppdatering som anges som saknad i Uppdateringshantering

Problem

Gamla uppdateringar visas för ett Automation-konto som saknas trots att de har ersatts. En ersatt uppdatering är en uppdatering som du inte behöver installera eftersom det finns en senare uppdatering som korrigerar samma sårbarhet. Uppdateringshantering ignorerar den ersatta uppdateringen och gör den inte tillämplig till förmån för den ersatta uppdateringen. Information om ett relaterat problem finns i Uppdatera ersätts.

Orsak

Ersatta uppdateringar avvisas inte i Windows Server Update Services (WSUS) så att de inte kan anses vara tillämpliga.

Åtgärd

När en ersatt uppdatering blir 100 procent inte tillämplig bör du ändra godkännandetillståndet för uppdateringen till Declined i WSUS. Så här ändrar du godkännandetillståndet för alla dina uppdateringar:

  1. I Automation-kontot väljer du Uppdateringshantering för att visa datorstatus. Se Visa uppdateringsutvärderingar.

  2. Kontrollera den ersatta uppdateringen för att se till att den är 100 procent inte tillämplig.

  3. På WSUS-servern som datorerna rapporterar till avböjer du uppdateringen.

  4. Välj Datorer och tvinga fram en omsökning för efterlevnad i kolumnen Efterlevnad . Se Hantera uppdateringar för virtuella datorer.

  5. Upprepa stegen ovan för andra ersatta uppdateringar.

  6. För Windows Server Update Services (WSUS) rensar du alla ersatta uppdateringar för att uppdatera infrastrukturen med hjälp av rensningsguiden för WSUS Server.

  7. Upprepa den här proceduren regelbundet för att korrigera visningsproblemet och minimera mängden diskutrymme som används för uppdateringshantering.

Scenario: Datorer visas inte i portalen under Uppdateringshantering

Problem

Dina datorer har följande symtom:

  • Datorn visas Not configured från vyn Uppdateringshantering för en virtuell dator.

  • Dina datorer saknas i vyn Uppdateringshantering för ditt Azure Automation-konto.

  • Du har datorer som visas som Not assessed under Efterlevnad. Du ser dock pulsslagsdata i Azure Monitor-loggar för Hybrid Runbook Worker men inte för Uppdateringshantering.

Orsak

Det här problemet kan orsakas av lokala konfigurationsproblem eller av felaktigt konfigurerad omfångskonfiguration. Möjliga specifika orsaker är:

  • Du kan behöva registrera om och installera om Hybrid Runbook Worker.

  • Du kan ha definierat en kvot på din arbetsyta som har nåtts och som förhindrar ytterligare datalagring.

Åtgärd

  1. Kör felsökaren för Windows eller Linux, beroende på operativsystemet.

  2. Kontrollera att datorn rapporterar till rätt arbetsyta. Mer information om hur du verifierar den här aspekten finns i Verifiera agentanslutning till Azure Monitor. Kontrollera också att den här arbetsytan är länkad till ditt Azure Automation-konto. Bekräfta genom att gå till ditt Automation-konto och välja Länkad arbetsyta under Relaterade resurser.

  3. Kontrollera att datorerna visas på Log Analytics-arbetsytan som är länkad till ditt Automation-konto. Kör följande fråga på Log Analytics-arbetsytan.

    Heartbeat
| summarize by Computer, Solutions

    Om du inte ser datorn i frågeresultatet har den inte nyligen checkat in. Det finns förmodligen ett lokalt konfigurationsproblem och du bör installera om agenten.

    Om datorn visas i frågeresultatet kontrollerar du under egenskapen Lösningar att uppdateringar visas. Detta verifierar att det är registrerat med Uppdateringshantering. Om det inte är det kontrollerar du omfångskonfigurationsproblem. Omfångskonfigurationen avgör vilka datorer som har konfigurerats för uppdateringshantering. Information om hur du konfigurerar omfångskonfigurationen för måldatorn finns i Aktivera datorer på arbetsytan.

  4. Kör den här frågan på arbetsytan.

    Operation
| where OperationCategory == 'Data Collection Status'
| sort by TimeGenerated desc

    Om du får ett Data collection stopped due to daily limit of free data reached. Ingestion status = OverQuota resultat har den kvot som definierats på din arbetsyta nåtts, vilket har hindrat data från att sparas. I din arbetsyta går du till datavolymhantering under Användning och uppskattade kostnader och ändrar eller tar bort kvoten.

  5. Om problemet fortfarande är löst följer du stegen i Distribuera en Windows Hybrid Runbook Worker för att installera om Hybrid Worker för Windows. För Linux följer du stegen i Distribuera en Linux Hybrid Runbook Worker.

Scenario: Det går inte att registrera Automation-resursprovidern för prenumerationer

Problem

När du arbetar med funktionsdistributioner i ditt Automation-konto uppstår följande fel:

Error details: Unable to register Automation Resource Provider for subscriptions

Orsak

Automation-resursprovidern är inte registrerad i prenumerationen.

Åtgärd

Följ dessa steg i Azure-portalen för att registrera Automation-resursprovidern.

  1. I listan över Azure-tjänster längst ned i portalen väljer du Alla tjänster och sedan Prenumerationer i gruppen Allmän tjänst.

  2. Välj din prenumeration.

  3. Under Inställningar väljer du Resursprovidrar.

  4. Kontrollera att resursprovidern Microsoft.Automation är registrerad i listan över resursprovidrar.

  5. Om den inte visas registrerar du Microsoft.Automation-providern genom att följa stegen i Lösa fel för registrering av resursprovider.

Scenario: Schemalagd uppdatering korrigerade inte vissa datorer

Problem

Datorer som ingår i en förhandsversion av uppdateringen visas inte alla i listan över datorer som har korrigerats under en schemalagd körning, eller så visas inte virtuella datorer för valda omfång för en dynamisk grupp i listan över uppdateringsförhandsgranskningar i portalen.

Listan med uppdateringsförhandsgranskning består av alla datorer som hämtats av en Azure Resource Graph-fråga för de valda omfången. Omfången filtreras för datorer som har ett system Hybrid Runbook Worker installerat och som du har åtkomstbehörighet för.

Orsak

Det här problemet kan ha någon av följande orsaker:

  • Prenumerationerna som definieras i omfånget i en dynamisk fråga har inte konfigurerats för den registrerade Automation-resursprovidern.

  • Datorerna var inte tillgängliga eller hade inte lämpliga taggar när schemat kördes.

  • Du har inte rätt åtkomst till de valda omfången.

  • Azure Resource Graph-frågan hämtar inte de förväntade datorerna.

  • Systemet Hybrid Runbook Worker är inte installerat på datorerna.

Åtgärd

Prenumerationer som inte har konfigurerats för en registrerad Automation-resursprovider

Om din prenumeration inte har konfigurerats för Automation-resursprovidern kan du inte fråga eller hämta information på datorer i den prenumerationen. Använd följande steg för att verifiera registreringen för prenumerationen.

  1. Gå till Azure-tjänstlistan i Azure-portalen.

  2. Välj Alla tjänster och välj sedan Prenumerationer i gruppen Allmän tjänst.

  3. Hitta den prenumeration som definierats i omfånget för distributionen.

  4. Under Inställningar väljer du Resursprovidrar.

  5. Kontrollera att resursprovidern Microsoft.Automation är registrerad.

  6. Om den inte visas registrerar du Microsoft.Automation-providern genom att följa stegen i Lösa fel för registrering av resursprovider.

Datorer är inte tillgängliga eller taggas inte korrekt när schemat körs

Använd följande procedur om din prenumeration har konfigurerats för Automation-resursprovidern, men kör uppdateringsschemat med de angivna dynamiska grupperna som missade vissa datorer.

  1. Öppna Automation-kontot i Azure-portalen och välj Uppdateringshantering.

  2. Kontrollera historiken för uppdateringshantering för att fastställa den exakta tiden när uppdateringsdistributionen kördes.

  3. För datorer som du misstänker har missats av Uppdateringshantering använder du Azure Resource Graph (ARG) för att hitta datorändringar.

  4. Sök efter ändringar under en längre period, till exempel en dag, innan uppdateringsdistributionen kördes.

  5. Kontrollera sökresultaten för eventuella systemändringar, till exempel ta bort eller uppdatera ändringar, till datorerna under den här perioden. Dessa ändringar kan ändra datorstatus eller taggar så att datorer inte väljs i datorlistan när uppdateringar distribueras.

  6. Justera dator- och resursinställningarna efter behov för att korrigera för datorstatus eller taggproblem.

  7. Kör uppdateringsschemat igen för att säkerställa att distributionen med de angivna dynamiska grupperna innehåller alla datorer.

Felaktig åtkomst för valda omfång

Azure-portalen visar endast datorer som du har skrivbehörighet för i ett visst omfång. Om du inte har rätt åtkomst för ett omfång läser du Självstudie: Bevilja en användare åtkomst till Azure-resurser med hjälp av Azure-portalen.

Resource Graph-frågan returnerar inte förväntade datorer

Följ stegen nedan för att ta reda på om dina frågor fungerar korrekt.

  1. Kör en Azure Resource Graph-fråga formaterad enligt nedan på bladet Resource Graph Explorer i Azure-portalen. Om du inte har använt Azure Resource Graph tidigare kan du läsa den här snabbstarten om du vill lära dig hur du arbetar med Resource Graph Explorer. Den här frågan efterliknar de filter som du valde när du skapade den dynamiska gruppen i Uppdateringshantering. Se Använda dynamiska grupper med uppdateringshantering.

    where (subscriptionId in~ ("<subscriptionId1>", "<subscriptionId2>") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "<Windows/Linux>" and resourceGroup in~ ("<resourceGroupName1>","<resourceGroupName2>") and location in~ ("<location1>","<location2>") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" and tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "All" option selected for tags
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" or tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "Any" option selected for tags
| project id, location, name, tags

    Här är ett exempel:

    where (subscriptionId in~ ("20780d0a-b422-4213-979b-6c919c91ace1", "af52d412-a347-4bc6-8cb7-4780fbb00490") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "Windows" and resourceGroup in~ ("testRG","withinvnet-2020-01-06-10-global-resources-southindia") and location in~ ("australiacentral","australiacentral2","brazilsouth") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("ms-resource-usage")] =~ "azure-cloud-shell" and tags[tolower("temp")] =~ "temp")
| project id, location, name, tags

  2. Kontrollera om de datorer som du letar efter visas i frågeresultatet.

  3. Om datorerna inte visas finns det förmodligen ett problem med det filter som valts i den dynamiska gruppen. Justera gruppkonfigurationen efter behov.

Hybrid Runbook Worker är inte installerat på datorer

Datorer visas i Azure Resource Graph-frågeresultat, men visas fortfarande inte i den dynamiska gruppförhandsgranskningen. I det här fallet kanske datorerna inte har angetts som Hybrid Runbook-systemarbetare och kan därför inte köra Azure Automation- och Update Management-jobb. Så här ser du till att de datorer som du förväntar dig att se är konfigurerade som hybrid runbook-arbetare i systemet:

  1. I Azure-portalen går du till Automation-kontot för en dator som inte visas korrekt.

  2. Välj Hybrid Worker-grupper under Processautomatisering.

  3. Välj fliken Systemhybridarbetsgrupper .

  4. Kontrollera att hybridarbetaren finns för den datorn.

  5. Om datorn inte har konfigurerats som en Hybrid Runbook Worker-system granskar du metoderna för att aktivera med någon av följande metoder:

    • Från ditt Automation-konto för en eller flera Azure- och icke-Azure-datorer, inklusive Azure Arc-aktiverade servrar.

    • Använda Runbooken Enable-AutomationSolution för att automatisera registrering av virtuella Azure-datorer.

    • För en vald virtuell Azure-dator från sidan Virtuella datorer i Azure-portalen. Det här scenariot är tillgängligt för virtuella Linux- och Windows-datorer.

    • För flera virtuella Azure-datorer genom att välja dem från sidan Virtuella datorer i Azure-portalen.

    Metoden som ska aktiveras baseras på den miljö som datorn körs i.

  6. Upprepa stegen ovan för alla datorer som inte har visats i förhandsversionen.

Scenario: Uppdateringshanteringskomponenter aktiverade medan den virtuella datorn fortsätter att visas som konfigurerad

Problem

Du fortsätter att se följande meddelande på en virtuell dator 15 minuter efter att distributionen har påbörjats:

The components for the 'Update Management' solution have been enabled, and now this virtual machine is being configured. Please be patient, as this can sometimes take up to 15 minutes.

Orsak

Felet kan uppstå på grund av någon av följande orsaker:

  • Kommunikationen med Automation-kontot blockeras.

  • Det finns ett duplicerat datornamn med olika källdator-ID:t. Det här scenariot inträffar när en virtuell dator med ett visst datornamn skapas i olika resursgrupper och rapporterar till samma logistics agent-arbetsyta i prenumerationen.

  • Vm-avbildningen som distribueras kan komma från en klonad dator som inte har förberetts med SystemFörberedelse (sysprep) med Log Analytics-agenten för Windows installerad.

Åtgärd

Om du vill hjälpa dig att fastställa det exakta problemet med den virtuella datorn kör du följande fråga på Log Analytics-arbetsytan som är länkad till ditt Automation-konto.

Update
| where Computer contains "fillInMachineName"
| project TimeGenerated, Computer, SourceComputerId, Title, UpdateState

Kommunikationen med Automation-kontot har blockerats

Gå till Nätverksplanering för att lära dig vilka adresser och portar som måste tillåtas för att uppdateringshantering ska fungera.

Duplicera datornamn

Byt namn på dina virtuella datorer för att säkerställa unika namn i deras miljö.

Distribuerad avbildning från en klonad dator

Om du använder en klonad avbildning har olika datornamn samma källdator-ID. I det här fallet:

  1. I Log Analytics-arbetsytan tar du bort den virtuella datorn från den sparade sökningen efter omfångskonfigurationen MicrosoftDefaultScopeConfig-Updates om den visas. Sparade sökningar finns under Allmänt på arbetsytan.

  2. Kör följande cmdlet.

    Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -Force

  3. Kör Restart-Service HealthService för att starta om hälsotjänsten. Den här åtgärden återskapar nyckeln och genererar ett nytt UUID.

  4. Om den här metoden inte fungerar kör du sysprep på avbildningen först och installerar sedan Log Analytics-agenten för Windows.

Scenario: Du får ett fel med en länkad prenumeration när du skapar en uppdateringsdistribution för datorer i en annan Azure-klientorganisation

Problem

Du får följande fel när du försöker skapa en uppdateringsdistribution för datorer i en annan Azure-klientorganisation:

The client has permission to perform action 'Microsoft.Compute/virtualMachines/write' on scope '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resourceGroupName/providers/Microsoft.Automation/automationAccounts/automationAccountName/softwareUpdateConfigurations/updateDeploymentName', however the current tenant '00000000-0000-0000-0000-000000000000' is not authorized to access linked subscription '00000000-0000-0000-0000-000000000000'.

Orsak

Det här felet uppstår när du skapar en uppdateringsdistribution som har virtuella Azure-datorer i en annan klientorganisation som ingår i en uppdateringsdistribution.

Åtgärd

Använd följande lösning för att få dessa objekt schemalagda. Du kan använda cmdleten New-AzAutomationSchedule med parametern ForUpdateConfiguration för att skapa ett schema. Använd sedan cmdleten New-AzAutomationSoftwareUpdateConfiguration och skicka datorerna i den andra klientorganisationen till parametern NonAzureComputer . Följande exempel visar hur du gör detta:

$nonAzurecomputers = @("server-01", "server-02")

$startTime = ([DateTime]::Now).AddMinutes(10)

$s = New-AzAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdateConfiguration

New-AzAutomationSoftwareUpdateConfiguration  -ResourceGroupName $rg -AutomationAccountName $aa -Schedule $s -Windows -AzureVMResourceId $azureVMIdsW -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100

Scenario: Oförklarliga omstarter

Problem

Även om du har angett alternativet Starta om kontroll till Starta aldrig om, startas datorerna fortfarande om efter att uppdateringar har installerats.

Orsak

Windows Update kan ändras av flera registernycklar, vilket kan ändra omstartsbeteendet.

Åtgärd

Granska registernycklarna som anges under Konfigurera automatiska uppdateringar genom att redigera registret och registernycklarna som används för att hantera omstart för att kontrollera att dina datorer är korrekt konfigurerade.

Scenario: Datorn visar "Det gick inte att starta" i en uppdateringsdistribution

Problem

En dator visar en Failed to start eller Failed status. När du visar den specifika informationen för datorn visas följande fel:

For one or more machines in schedule, UM job run resulted in either Failed or Failed to start state. Guide available at https://aka.ms/UMSucrFailed.

Orsak

Felet kan uppstå på grund av någon av följande orsaker:

  • Datorn finns inte längre.
  • Datorn är avstängd och går inte att nå.
  • Datorn har ett problem med nätverksanslutningen och därför går det inte att nå hybridarbetaren på datorn.
  • Det fanns en uppdatering av Log Analytics-agenten som ändrade källdatorns ID.
  • Uppdateringskörningen begränsades om du når gränsen på 200 samtidiga jobb på ett Automation-konto. Varje distribution betraktas som ett jobb och varje dator i en uppdateringsdistribution räknas som ett jobb. Alla andra automationsjobb eller uppdateringsdistributioner som för närvarande körs på ditt Automation-konto räknas mot den samtidiga jobbgränsen.

Åtgärd

Du kan hämta mer information programmatiskt genom att använda REST-API. Mer information om hur du hämtar en lista över uppdateringskonfigurationsdatorkörningar eller en enda programuppdateringskonfigurationsdator som körs med ID finns i Programuppdateringskonfigurationsdatorkörningar .

När det är tillämpligt använder du dynamiska grupper för dina uppdateringsdistributioner. Dessutom kan du utföra följande steg.

  1. Kontrollera att datorn eller servern uppfyller kraven.
  2. Verifiera anslutningen till Hybrid Runbook Worker med hjälp av felsökaren för Hybrid Runbook Worker-agenten. Mer information om felsökaren finns i Felsöka problem med uppdateringsagenten.

Scenario: Uppdateringar installeras utan distribution

Problem

När du registrerar en Windows-dator i Uppdateringshantering visas uppdateringar installerade utan distribution.

Orsak

I Windows installeras uppdateringar automatiskt så snart de är tillgängliga. Detta kan orsaka förvirring om du inte schemalägger en uppdatering som ska distribueras till datorn.

Åtgärd

Registernyckeln HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU är standardinställningen 4: auto download and install.

För Update Management-klienter rekommenderar vi att du anger den här nyckeln till 3: auto download but do not auto install.

Mer information finns i Konfigurera automatiska uppdateringar.

Scenario: Datorn är redan registrerad i ett annat konto

Problem

Du får följande felmeddelande:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.InvalidOperationException: {"Message":"Machine is already registered to a different account."}

Orsak

Datorn har redan distribuerats till en annan arbetsyta för uppdateringshanteringen.

Åtgärd

  1. Följ stegen under Datorer visas inte i portalen under Uppdateringshantering för att kontrollera att datorn rapporterar till rätt arbetsyta.
  2. Rensa artefakter på datorn genom att ta bort Hybrid Runbook-gruppen och försök sedan igen.

Scenario: Datorn kan inte kommunicera med tjänsten

Problem

Du får ett av följande felmeddelanden:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server can't communicate, because they do not possess a common algorithm

Unable to Register Machine for Patch Management, Registration Failed with Exception Newtonsoft.Json.JsonReaderException: Error parsing positive infinity value.

The certificate presented by the service <wsid>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

Access is denied. (Exception form HRESULT: 0x80070005(E_ACCESSDENIED))

Orsak

En proxy, gateway eller brandvägg kan blockera nätverkskommunikationen.

Lösning

Granska nätverket och se till att lämpliga portar och adresser tillåts. Se nätverkskrav för en lista över portar och adresser som krävs av Uppdateringshantering och Hybrid Runbook Workers.

Scenario: Det går inte att skapa ett självsignerat certifikat

Problem

Du får ett av följande felmeddelanden:

Unable to Register Machine for Patch Management, Registration Failed with Exception AgentService.HybridRegistration. PowerShell.Certificates.CertificateCreationException: Failed to create a self-signed certificate. ---> System.UnauthorizedAccessException: Access is denied.

Orsak

Hybrid Runbook Worker kunde inte generera ett självsignerat certifikat.

Lösning

Kontrollera att systemkontot har läsbehörighet till mappen C:\ProgramData\Microsoft\Crypto\RSA och försök igen.

Scenario: Den schemalagda uppdateringen misslyckades med ett MaintenanceWindowExceeded-fel

Problem

Standardunderhållsperioden för uppdateringar är 120 minuter. Du kan öka underhållsfönstret till högst 6 timmar eller 360 minuter. Du kan få felmeddelandet For one or more machines in schedule, UM job run resulted in Maintenance Window Exceeded state. Guide available at https://aka.ms/UMSucrMwExceeded.

Åtgärd

Om du vill veta varför detta inträffade under en uppdateringskörning när den har startats kontrollerar du jobbutdata från den berörda datorn under körningen. Där kan du hitta specifika felmeddelanden från dina datorer som du kan undersöka och åtgärda.

Du kan hämta mer information programmatiskt genom att använda REST-API. Mer information om hur du hämtar en lista över uppdateringskonfigurationsdatorkörningar eller en enda programuppdateringskonfigurationsdator som körs med ID finns i Programuppdateringskonfigurationsdatorkörningar .

Redigera eventuella misslyckade schemalagda uppdateringsdistributioner och utöka underhållsperioden.

Mer information om underhållsperioder finns i Installera uppdateringar.

Scenario: Datorn visas som "Inte utvärderad" och visar ett HRESULT-undantag

Problem

  • Du har datorer som visas som Not assessed under Efterlevnad och du ser ett undantagsmeddelande under dem.
  • Du ser en HRESULT-felkod i portalen.

Orsak

Uppdateringsagenten (Windows Update Agent i Windows, pakethanteraren för en Linux-distribution) är inte korrekt konfigurerad. Uppdateringshantering förlitar sig på datorns uppdateringsagent för att tillhandahålla de uppdateringar som behövs, status för korrigeringen och resultatet av distribuerade korrigeringar. Utan den här informationen kan uppdateringshantering inte rapportera de korrigeringar som behövs eller installeras korrekt.

Åtgärd

Försök att utföra uppdateringar lokalt på datorn. Om åtgärden misslyckas innebär det vanligtvis att det finns ett konfigurationsfel för uppdateringsagenten.

Det här problemet orsakas ofta av nätverkskonfigurations- och brandväggsproblem. Använd följande kontroller för att åtgärda problemet.

Om du ser ett HRESULT dubbelklickar du på undantaget som visas i rött för att se hela undantagsmeddelandet. I följande tabell finns möjliga lösningar och rekommenderade åtgärder.

Undantag Lösning eller åtgärd
Exception from HRESULT: 0x……C Sök efter ytterligare information om orsaken till undantaget genom att söka efter relevant felkod i felkodslistan för Windows Update.
0x8024402C
0x8024401C
0x8024402F		 Dessa indikerar problem med nätverksanslutningen. Kontrollera att datorn har nätverksanslutning till Uppdateringshantering. Se avsnittet nätverksplanering för en lista över nödvändiga portar och adresser.
0x8024001E Uppdateringsåtgärden slutfördes inte på grund av att tjänsten eller systemet avslutades.
0x8024002E Windows Update-tjänsten har inaktiverats.
0x8024402C Om du använder en WSUS-server kontrollerar du att registervärdena för WUServer och WUStatusServer under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registernyckeln anger rätt WSUS-server.
0x80072EE2 Det finns ett problem med nätverksanslutningen eller kommunikationen med en konfigurerad WSUS-server. Kontrollera inställningarna för WSUS och se till att tjänsten är tillgänglig från klienten.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422) Kontrollera att Windows Update-tjänsten (wuauserv) körs och inte är inaktiverad.
0x80070005 Ett fel om nekad åtkomst kan orsakas av något av följande:
Infekterad dator
Windows Update-inställningarna är inte korrekt konfigurerade
Filbehörighetsfel med mappen %WinDir%\SoftwareDistribution
Otillräckligt diskutrymme på systemenheten (C:).
Andra allmänna undantag Kör en sökning på Internet för att få möjliga lösningar och kontakta din lokala IT-support.

Att granska filen %Windir%\Windowsupdate.log kan också hjälpa dig att fastställa möjliga orsaker. Mer information om hur du läser loggen finns i Så här läser du filen Windowsupdate.log.

Du kan också ladda ned och köra felsökaren för Windows Update för att se om det finns några problem med Windows Update på datorn.

Kommentar

Dokumentationen för Windows Update-felsökaren anger att den är för användning på Windows-klienter, men den fungerar även på Windows Server.

Scenario: Uppdateringskörningen returnerar statusen Misslyckad (Linux)

Problem

En uppdateringskörning startar men får fel under körningen.

Orsak

Möjliga orsaker:

  • Pakethanteraren är inte felfri.
  • Uppdateringsagenten (WUA för Windows, distributionsspecifik pakethanterare för Linux) är felkonfigurerad.
  • Specifika paket stör molnbaserad korrigering.
  • Datorn kan inte nås.
  • Uppdateringarna hade beroenden som inte löstes.

Åtgärd

Om fel inträffar under en uppdateringskörning efter att den har startats kontrollerar du jobbutdata från den berörda datorn under körningen. Där kan du hitta specifika felmeddelanden från dina datorer som du kan undersöka och åtgärda. Uppdateringshantering kräver att pakethanteraren är felfri för lyckade uppdateringsdistributioner.

Om specifika korrigeringar, paket eller uppdateringar visas omedelbart innan jobbet misslyckas kan du prova att exkluderas från nästa uppdateringsdistribution. Information om hur du samlar in logginformation från Windows Update finns i Windows Update-loggfiler.

Om du inte kan lösa ett korrigeringsproblem gör du en kopia av filen /var/opt/microsoft/omsagent/run/automationworker/omsupdatemgmt.log och bevarar den i felsökningssyfte innan nästa uppdateringsdistribution startar.

Korrigeringar är inte installerade

Datorerna installerar inte uppdateringar

Försök att köra uppdateringar direkt på datorn. Om datorn inte kan tillämpa uppdateringarna läser du listan över potentiella fel i felsökningsguiden.

Om uppdateringar körs lokalt kan du prova att ta bort och installera om agenten på datorn genom att följa anvisningarna i Ta bort en virtuell dator från Uppdateringshantering.

Jag vet att uppdateringar är tillgängliga, men de visas inte som tillgängliga på mina datorer

Detta händer ofta om datorer är konfigurerade för att hämta uppdateringar från WSUS eller Microsoft Configuration Manager, men WSUS och Configuration Manager inte har godkänt uppdateringarna.

Du kan kontrollera om datorerna har konfigurerats för WSUS och SCCM genom att korsreferera UseWUServer registernyckeln till registernycklarna i avsnittet Konfigurera automatiska uppdateringar genom att redigera registret i den här artikeln.

Om uppdateringar inte godkänns i WSUS installeras de inte. Du kan söka efter icke godkända uppdateringar i Log Analytics genom att köra följande fråga.

Update | where UpdateState == "Needed" and ApprovalSource == "WSUS" and Approved == "False" | summarize max(TimeGenerated) by Computer, KBID, Title

Uppdateringar visas som installerade, men jag hittar dem inte på datorn

Uppdateringar ersätts ofta av andra uppdateringar. Mer information finns i Uppdatera ersätts i felsökningsguiden för Windows Update.

Installera uppdateringar efter klassificering i Linux

Distribution av uppdateringar till Linux efter klassificering ("Kritiska uppdateringar och säkerhetsuppdateringar") har viktiga varningar. Dessa begränsningar finns dokumenterade på översiktssidan för Uppdateringshantering.

KB2267602 saknas konsekvent

KB2267602 är Windows Defender-definitionsuppdateringen. Den uppdateras dagligen.

Nästa steg

Om du inte ser problemet eller inte kan lösa problemet kan du prova någon av följande kanaler för ytterligare support.

  • Få svar från Azure-experter via Azure-forum.
  • Anslut med @AzureSupport, det officiella Microsoft Azure-kontot för att förbättra kundupplevelsen.
  • Skapa en Azure-supportincident. Gå till Azure-supportwebbplatsen och välj Hämta support.