Flytta från Automation Update Management till Azure Update Manager

  • Artikel

Gäller för: ✔️ Virtuella Windows-datorer ✔️ – Virtuella Linux-datorer ✔️ Lokal miljö ✔️ Azure Arc-aktiverade servrar

Den här artikeln innehåller vägledning för att flytta virtuella datorer från Automation Update Management till Azure Update Manager.

Azure Update Manager tillhandahåller en SaaS-lösning för att hantera och styra programuppdateringar till Windows- och Linux-datorer i Azure, lokalt och i miljöer med flera moln. Det är en utveckling av Azure Automation Update-hanteringslösningen med nya funktioner, för utvärdering och distribution av programuppdateringar på en enskild dator eller på flera datorer i stor skala.

För Azure Update Manager är både AMA och MMA inte ett krav för att hantera arbetsflöden för programuppdatering eftersom de förlitar sig på Microsoft Azure VM-agenten för virtuella Azure-datorer och Azure-ansluten datoragent för Arc-aktiverade servrar. När du utför en uppdateringsåtgärd för första gången på en dator skickas ett tillägg till datorn och det interagerar med agenterna för att utvärdera saknade uppdateringar och installera uppdateringar.

Kommentar

  • Om du använder Azure Automation Update Management Solution rekommenderar vi att du inte tar bort MMA-agenter från datorerna utan att slutföra migreringen till Azure Update Manager för datorns korrigeringshanteringsbehov. Om du tar bort MMA-agenten från datorn utan att flytta till Azure Update Manager skulle det bryta korrigeringsarbetsflödena för den datorn.

  • Alla funktioner i Azure Automation Update Management är tillgängliga i Azure Update Manager före utfasningsdatumet.

Azure Portal-upplevelse (förhandsversion)

I det här avsnittet beskrivs hur du använder portalupplevelsen (förhandsversion) för att flytta scheman och datorer från Automation Update Management till Azure Update Manager. Med minimala klick och automatiserat sätt att flytta dina resurser är det det enklaste sättet att flytta om du inte har anpassningar som bygger på din Automation Update Management-lösning.

Om du vill komma åt portalmigreringsupplevelsen kan du använda flera startpunkter.

Välj knappen Migrera nu som finns på följande startpunkter. Efter valet vägleds du genom processen att flytta dina scheman och datorer till Azure Update Manager. Den här processen är utformad för att vara användarvänlig och rakt fram så att du kan slutföra migreringen med minimal ansträngning.

Du kan migrera från någon av följande startpunkter:

Välj knappen Migrera nu så öppnas ett migreringsblad. Den innehåller en sammanfattning av alla resurser, inklusive datorer och scheman i Automation-kontot. Som standard är det Automation-konto som du har använt det här bladet från förvalt om du går den här vägen.

Skärmbild som visar hur du migrerar från startpunkten för Automation Update Management.

Här kan du se hur många Azure-, Arc-aktiverade servrar, icke-Arc-aktiverade servrar och scheman som är aktiverade i Automation Update Management och behöver flyttas till Azure Update Manager. Du kan också visa information om dessa resurser.

Migreringsbladet innehåller en översikt över de resurser som ska flyttas, så att du kan granska och bekräfta migreringen innan du fortsätter. När du är klar kan du fortsätta med migreringsprocessen för att flytta dina scheman och datorer till Azure Update Manager.

Skärmbild som visar hur du migrerar alla resurser från Automation-kontot.

När du har granskat de resurser som måste flyttas kan du fortsätta med migreringsprocessen, som är en trestegsprocess:

  1. Krav

    Detta omfattar två steg:

    a. Registrera icke-Azure-datorer som inte är Arc-aktiverade till Arc – det beror på att Arc-anslutning är en förutsättning för Azure Update Manager. Det är kostnadsfritt att registrera dina datorer i Azure Arc, och när du gör det kan du utnyttja alla hanteringstjänster som du kan göra för alla Azure-datorer. Mer information finns i Azure Arc-dokumentationen om hur du registrerar dina datorer.

    b. Ladda ned och kör PowerShell-skript lokalt – Detta krävs för att skapa en användaridentitet och lämpliga rolltilldelningar så att migreringen kan ske. Det här skriptet ger rätt RBAC till användaridentiteten för prenumerationen som automationskontot tillhör, datorer som är registrerade i Automation Update Management, omfång som ingår i dynamiska frågor osv. så att konfigurationen kan tilldelas datorerna, MRP-konfigurationer kan skapas och uppdateringslösningen kan tas bort. Mer information finns i Dokumentation om Azure Update Manager.

    Skärmbild som visar förutsättningarna för migrering.

  2. Flytta resurser i Automation-kontot till Azure Update Manager

    Nästa steg i migreringsprocessen är att göra det möjligt att flytta Azure Update Manager på datorerna och skapa motsvarande underhållskonfigurationer för scheman som ska migreras. När du väljer knappen Migrera nu importeras Runbooken MigrateToAzureUpdateManager till ditt Automation-konto och anger den utförliga loggningen till True.

    Skärmbild som visar hur du migrerar arbetsbelastning i ditt Automation-konto.

    Välj Starta runbook, som visar de parametrar som måste skickas till runbooken.

    Skärmbild som visar hur du startar runbook för att tillåta att parametrarna skickas till runbooken.

    Mer information om de parametrar som ska hämtas och platsen där den måste hämtas finns i migrering av datorer och scheman. När du startar runbooken när du har passerat alla parametrar börjar Azure Update Manager aktiveras på datorer och underhållskonfigurationen i Azure Update Manager börjar skapas. Du kan övervaka Azure Runbook-loggar för status för körning och migrering av scheman.

  3. Avregistrera resurser från automationsuppdateringshantering

    Kör rensningsskriptet för att ta bort datorer från automationsuppdateringshanteringslösningen och inaktivera Automation Update Management-scheman.

    När du har valt knappen Kör rensningsskript importeras runbooken DeboardFromAutomationUpdateManagement till ditt Automation-konto och dess utförliga loggning är inställd på Sant.

    Skärmbild som visar hur du utför efter migreringen.

    När du väljer Starta runbooken ber du om att parametrar skickas till runbooken. Mer information finns i Avboarding from Automation Update Management solution to fetch the parameters to be passed to the runbook (Avboarding from Automation Update Management solution to fetch the parameters to be passed to the runbook).

    Skärmbild som visar hur du avregistrerar dig från Automation Update Management och startar runbooken.

Migreringsskript (förhandsversion)

Med hjälp av migreringsrunbooks kan du automatiskt migrera alla arbetsbelastningar (datorer och scheman) från Automation Update Management till Azure Update Manager. Det här avsnittet beskriver hur du kör skriptet, vad skriptet gör på serverdelen, förväntat beteende och eventuella begränsningar, om tillämpligt. Skriptet kan migrera alla datorer och scheman på ett automationskonto på en gång. Om du har flera automationskonton måste du köra runbooken för alla automationskonton.

På hög nivå måste du följa stegen nedan för att migrera dina datorer och scheman från Automation Update Management till Azure Update Manager.

Sammanfattning av förutsättningar

  1. Registrera datorer som inte är Azure-datorer på Azure Arc.
  2. Ladda ned och kör PowerShell-skriptet för att skapa användaridentitets- och rolltilldelningar lokalt i systemet. Se detaljerade instruktioner i steg-för-steg-guiden eftersom den även har vissa förutsättningar.

Sammanfattning av steg

  1. Kör Runbook för migreringsautomatisering för migrering av datorer och scheman från Automation Update Management till Azure Update Manager. Se detaljerade instruktioner i steg-för-steg-guiden.
  2. Kör rensningsskript för att avregistrera från Automation Update Management. Se detaljerade instruktioner i steg-för-steg-guiden.

Scenarier som inte stöds

  • Uppdateringsscheman med uppgifter före/efter migreras inte för tillfället.
  • Icke-Azure-sparade sökfrågor migreras inte. dessa måste migreras manuellt.

Den fullständiga listan över begränsningar och saker att notera finns i det sista avsnittet i den här artikeln.

Steg-för-steg-guide

Informationen som nämns i var och en av ovanstående steg beskrivs i detalj nedan.

Krav 1: Registrera datorer som inte är Azure-datorer till Arc

Vad du ska göra

Runbook för migreringsautomatisering ignorerar resurser som inte registreras i Arc. Därför är det en förutsättning att alla datorer som inte är Azure-datorer registreras i Azure Arc innan du kör migreringskörningen. Följ stegen för att registrera datorer i Azure Arc.

Krav 2: Skapa användaridentitet och rolltilldelningar genom att köra PowerShell-skript

A. Förutsättningar för att köra skriptet

  • Kör kommandot Install-Module -Name Az -Repository PSGallery -Force i PowerShell. Det nödvändiga skriptet beror på Az.Modules. Det här steget krävs om Az.Modules inte finns eller uppdateras.
  • Om du vill köra det här nödvändiga skriptet måste du ha behörigheten Microsoft.Authorization/roleAssignments/write för alla prenumerationer som innehåller Automation Update Management-resurser som datorer, scheman, log analytics-arbetsyta och automationskonto. Se hur du tilldelar en Azure-roll.
  • Du måste ha behörigheter för uppdateringshantering.

Skärmbild som visar hur kommandot för att installera modulen.

B. Kör skriptet

Ladda ned och kör PowerShell-skriptet MigrationPrerequisiteScript lokalt. Det här skriptet tar AutomationAccountResourceId för Automation-kontot som ska migreras som indata.

Skärmbild som visar hur du laddar ned och kör skriptet.

Du kan hämta AutomationAccountResourceId genom att gå till Egenskaper för Automation-konto>.

Skärmbild som visar hur du hämtar resurs-ID:t.

C. Verifiera

När du har kört skriptet kontrollerar du att en användarhanterad identitet har skapats i automationskontot. Användartilldelad automationskontoidentitet>>.

Skärmbild som visar hur du verifierar att en användarhanterad identitet skapas.

D. Serverdelsåtgärder efter skriptet

  1. Uppdatera Az.Modules för Automation-kontot, vilket krävs för att köra migrerings- och avboardingskript

  2. Skapa användaridentitet i samma prenumeration och resursgrupp som Automation-kontot. Namnet på användaridentiteten blir som AutomationAccount_aummig_umsi.

  3. Koppla användaridentiteten till Automation-kontot.

  4. Skriptet tilldelar följande behörigheter till den användarhanterade identiteten: Behörigheter för uppdateringshantering krävs.

    1. För detta hämtar skriptet alla datorer som registrerats i Automation Update Management under det här automationskontot och parsar sina prenumerations-ID:n för att få nödvändig RBAC till användaridentiteten.
    2. Skriptet ger en korrekt RBAC till användaridentiteten för den prenumeration som automationskontot tillhör så att MRP-konfigurationerna kan skapas här.
    3. Skriptet tilldelar de roller som krävs för Log Analytics-arbetsytan och lösningen.

Steg 1: Migrering av datorer och scheman

Det här steget omfattar att använda en Automation-runbook för att migrera alla datorer och scheman från ett automationskonto till Azure Update Manager.

Följ stegen nedan:

  1. Importera migreringsrunbook från runbooks-galleriet och publicera. Sök efter azure automation-uppdatering från blödningsgalleriet och importera migreringsrunbooken med namnet Migrera från Azure Automation Update Management till Azure Update Manager och publicera runbooken.

    Skärmbild som visar hur du migrerar från Automation Update Management.

    Runbook stöder PowerShell 5.1.

    Skärmbild som visar att Runbook stöder PowerShell 5.1 vid import.

  2. Ange Utförlig loggning till Sant för runbooken.

    Skärmbild som visar hur du anger utförliga loggposter.

  3. Kör runbooken och skicka nödvändiga parametrar som AutomationAccountResourceId, UserManagedServiceIdentityClientId osv.

    Skärmbild som visar hur du kör runbooken och skickar de obligatoriska parametrarna.

    1. Du kan hämta AutomationAccountResourceId från Egenskaper för Automation-konto>.

      Skärmbild som visar hur du hämtar automationskontots resurs-ID.

    2. Du kan hämta UserManagedServiceIdentityClientId från Klient-ID för användartilldelade>identitetsegenskaper>>för Automation-kontoidentitet.>>

      Skärmbild som visar hur du hämtar klient-ID.

    3. Om du anger EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement till TRUE aktiveras regelbunden utvärderingsegenskap på alla datorer som registreras i Automation Update Management.

    4. Om du ställer in MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines på TRUE migreras alla uppdateringsscheman i Automation Update Management till Azure Update Manager och aktiverar även den periodiska utvärderingsegenskapen till True på alla datorer som är länkade till dessa scheman.

    5. Du måste ange ResourceGroupForMaintenanceConfigurations där alla underhållskonfigurationer i Azure Update Manager skulle skapas. Om du anger ett nytt namn skapas en resursgrupp där alla underhållskonfigurationer skapas. Men om du anger ett namn som en resursgrupp redan finns med skapas alla underhållskonfigurationer i den befintliga resursgruppen.

  4. I Azure Runbook-loggarna finns status för körnings- och migreringsstatus för SUC:er.

    Skärmbild som visar runbook-loggarna.

Runbook-åtgärder i serverdelen

Migreringen av runbook utför följande uppgifter:

  • Aktiverar periodisk utvärdering på alla datorer.
  • Alla scheman i automationskontot migreras till Azure Update Manager och en motsvarande underhållskonfiguration skapas för var och en av dem med samma egenskaper.

Om skriptet

Följande är beteendet för migreringsskriptet:

  • Kontrollera om en resursgrupp med namnet som tas som indata redan finns i prenumerationen på automationskontot eller inte. Om inte skapar du en resursgrupp med det namn som anges av Cx. Den här resursgruppen används för att skapa MRP-konfigurationerna för V2.

  • Skriptet ignorerar de uppdateringsscheman som har för- och efterskript associerade med dem. För uppdateringsscheman för för- och efterskript migrerar du dem manuellt.

  • RebootOnly-inställningen är inte tillgänglig i Azure Update Manager. Scheman med RebootOnly-inställningen migreras inte.

  • Filtrera bort sucs som är i tillståndet errored/expired/provisioningFailed/disabled och markera dem som Inte migrerade och skriv ut lämpliga loggar som anger att sådana sucs inte migreras.

  • Namnet på konfigurationstilldelningen är en sträng som kommer att vara i formatet AUMMig_AAName_SUCName

  • Ta reda på om det här dynamiska omfånget redan har tilldelats till underhållskonfigurationen eller inte genom att kontrollera mot Azure Resource Graph. Om den inte har tilldelats tilldelar du endast tilldelningsnamnet i formatet AUMMig_ AAName_SUCName_SomeGUID.

  • En sammanfattad uppsättning loggar skrivs ut till utdataströmmen för att ge en övergripande status för datorer och SUC:er.

  • Detaljerade loggar skrivs ut till verbose Stream.

  • Efter migreringen kan en programuppdateringskonfiguration ha någon av följande fyra migreringsstatusar:

    • MigrationFailed
    • DelvisMigrerad
    • NotMigrated
    • Migrerade

Tabellen nedan visar scenarier som är associerade med varje migreringsstatus.

MigrationFailed DelvisMigrerad NotMigrated Migrerade
Det gick inte att skapa underhållskonfigurationen för programuppdateringskonfigurationen. Antal datorer som inte är noll där Patch-Inställningar inte kunde tillämpas. Det gick inte att hämta programuppdateringskonfigurationen från API:et på grund av ett klient-/serverfel som kanske ett internt tjänstfel.
Antal datorer som inte är noll med misslyckade konfigurationstilldelningar. Programuppdateringskonfigurationen har endast omstartsinställning som omstart. Detta stöds inte i dag i Azure Update Manager.
Det gick inte att lösa antalet dynamiska frågor som inte är noll och det gick inte att köra frågan mot Azure Resource Graph. Programuppdateringskonfigurationen har uppgifter före/efter. För närvarande migreras inte pre/post i förhandsversionen i Azure Update Manager och sådana scheman migreras inte.
Antal tilldelningsfel för dynamiskt omfång som inte är noll. Programuppdateringskonfigurationen har inte slutfört etableringstillståndet i DB.
Programuppdateringskonfigurationen har sparade sökfrågor. Programuppdateringskonfigurationen är i feltillstånd i DB.
Schemat som är associerat med programuppdateringskonfigurationen har redan upphört att gälla vid tidpunkten för migreringen.
Schemat som är associerat med programuppdateringskonfigurationen är inaktiverat.
Ohanterat undantag vid migrering av programuppdateringskonfiguration. Noll datorer där Patch-Inställningar inte kunde tillämpas.

och

Noll datorer med misslyckade konfigurationstilldelningar.

och

Det gick inte att lösa noll dynamiska frågor som inte kunde köra frågan mot Azure Resource Graph.

och

Noll problem med konfiguration av dynamiskt omfång.

och

Programuppdateringskonfigurationen har noll sparade sökfrågor.

Om du vill ta reda på från tabellen ovan vilket scenario/scenarier som motsvarar varför programuppdateringskonfigurationen har en specifik status kan du titta på utförliga/misslyckade/varningsloggar för att hämta felkoden och felmeddelandet.

Du kan också söka med namnet på uppdateringsschemat för att hämta loggar som är specifika för det för felsökning.

Skärmbild som visar hur du visar loggar som är specifika för felsökning.

Steg 2: Avboarding från Automation Update Management-lösningen

Följ stegen nedan:

  1. Importera migrerings-runbooken från Runbooks-galleriet. Sök efter azure automation-uppdatering från blödningsgalleriet och importera migreringsrunbooken med namnet Deboard från Azure Automation Update Management och publicera runbooken.

    Skärmbild som visar hur du importerar runbooken för deaboard-migrering.

    Runbook stöder PowerShell 5.1.

    Skärmbild som visar att runbooken stöder PowerShell 5.1 vid avboarding.

  2. Ange Utförlig loggning till True för Runbook.

    Skärmbild som visar inställningen för utförliga loggposter vid avboarding.

  3. Starta runbook- och passparametrarna, till exempel Automation AccountResourceId, UserManagedServiceIdentityClientId osv.

    Skärmbild som visar hur du startar runbook- och passparametrar vid avboarding.

    Du kan hämta AutomationAccountResourceId från Egenskaper för Automation-konto>.

    Skärmbild som visar hur du hämtar resurs-ID vid avboarding.

    Du kan hämta UserManagedServiceIdentityClientId från Klient-ID för användartilldelade>identitetsegenskaper>>för Automation-kontoidentitet.>>

    Skärmbild som visar hur du hämtar klient-ID vid avboarding.

  4. I Azure Runbook-loggarna finns status för avboarding av datorer och scheman.

    Skärmbild som visar hur runbook-loggar vid avboarding.

Avboarding-skriptåtgärder i serverdelen

  • Inaktivera alla underliggande scheman för alla programuppdateringskonfigurationer som finns i det här Automation-kontot. Detta görs för att säkerställa att Patch-MicrosoftOMSComputers Runbook inte utlöses för sucs som delvis migrerades till V2.
  • Ta bort Uppdateringar-lösningen från den länkade Log Analytics-arbetsytan för automationskontot som tas bort från Automation Update Management i V1.
  • En sammanfattad logg över alla sucs inaktiverade och status för att ta bort uppdateringslösningen från den länkade log analytics-arbetsytan skrivs också ut till utdataströmmen.
  • Detaljerade loggar skrivs ut på utförliga strömmar.

Pratbubblar för migreringsprocessen:

  • Scheman med uppgifter före/efter migreras inte för tillfället.
  • Icke-Azure-sparade sökfrågor migreras inte.
  • Runbooks för migrering och avregistrering måste ha Az.Modules uppdaterade för att fungera.
  • Det nödvändiga skriptet uppdaterar Az.Modules till den senaste versionen 8.0.0.
  • StartTime för MRP-schemat är lika med nästaRunTime för programuppdateringskonfigurationen.
  • Data från Log Analytics migreras inte.
  • Användarhanterade identiteter stöder inte scenarier mellan klientorganisationer.
  • RebootOnly-inställningen är inte tillgänglig i Azure Update Manager. Scheman med RebootOnly-inställning migreras inte.
  • För Upprepning schemalägger Automation stödvärden mellan (1 och 100) för scheman per timme/varje dag/varje vecka/varje månad, medan Azure Update Managers underhållskonfiguration stöder mellan (6 och 35) för varje timme och (1 till 35) för varje dag/vecka/månad.
    • Om automationsschemat till exempel har en upprepning av var 100:e timme har motsvarande underhållskonfigurationsschema det för varje 100/24 = 4,16 (avrunda till närmaste värde) –> Fyra dagar blir upprepningen för underhållskonfigurationen.
    • Om automationsschemat till exempel har en upprepning var 1 timme kommer motsvarande underhållskonfigurationsschema att ha det var 6:e timme.
    • Tillämpa samma konvention för Varje vecka och Varje dag.
      • Om automationsschemat har dagliga upprepningar på upp till 100 dagar blir 100/7 = 14,28 (avrunda till närmaste värde) –> 14 veckor återkommande för underhållskonfigurationsschemat.
      • Om automationsschemat har veckovisa upprepningar på säg 100 veckor blir 100/4,34 = 23,04 (avrunda till närmaste värde) –> 23 månader återkommande för underhållskonfigurationsschemat.
      • Om automationsschemat som ska upprepas var 100:e vecka och måste köras på fredagar. När det översätts till underhållskonfiguration blir det var 23:e månad (100/4.34). Men det finns inget sätt i Azure Update Manager att säga att körs var 23:e månad på alla fredagar den månaden, så schemat migreras inte.
      • Om ett automationsschema har en upprepning på mer än 35 månader har det alltid 35 månaders upprepning i underhållskonfigurationen.
    • SUC stöder mellan 30 minuter och sex timmar för underhållsfönstret. MRP stöder mellan 1 timme och 30 minuter till 4 timmar.
      • Om SUC till exempel har ett underhållsfönster på 30 minuter kommer motsvarande MRP-schema att ha det i 1 timme och 30 minuter.
      • Om SUC till exempel har en underhållsperiod på 6 timmar kommer motsvarande MRP-schema att ha den i 4 timmar.
  • När migrerings-runbooken körs flera gånger säger du att du har migrerat alla automationsscheman och sedan försökte migrera alla scheman igen. Sedan kör migreringskörningen samma logik. Om du gör det igen uppdateras MRP-schemat om det finns någon ny ändring i SUC. Det kommer inte att göra duplicerade konfigurationstilldelningar. Dessutom utförs åtgärder endast för automatiseringsscheman som har aktiverat scheman. Om en SUC migrerades tidigare hoppas den över i nästa tur eftersom dess underliggande schema inaktiveras.
  • I slutändan kan du lösa fler datorer från Azure Resource Graph som i Azure Update Manager. Du kan inte kontrollera om Hybrid Runbook Worker rapporterar eller inte, till skillnad från i Automation Update Management där det var en skärningspunkt mellan dynamiska frågor och Hybrid Runbook Worker.

Vägledning för manuell migrering

Vägledning för att flytta olika funktioner finns i tabellen nedan:

S.No Kapacitet Automation Update Management Azure Update Manager Steg med Hjälp av Azure-portalen Steg med API/skript
1 Korrigeringshantering för datorer utanför Azure. Kan köras med eller utan Arc-anslutning. Azure Arc är en förutsättning för datorer som inte är Azure-datorer. 1. Skapa tjänstens huvudnamn
2. Generera installationsskript
3. Installera agenten och anslut till Azure		 1. Skapa tjänstens huvudnamn
2. Generera installationsskript
3. Installera agenten och anslut till Azure
2 Aktivera periodisk utvärdering för att söka efter de senaste uppdateringarna automatiskt med några timmars mellanrum. Datorer får automatiskt de senaste uppdateringarna var 12:e timme för Windows och var tredje timme för Linux. Periodisk utvärdering är en uppdateringsinställning på din dator. Om den är aktiverad hämtar Uppdateringshanteraren uppdateringar var 24:e timme för datorn och visar den senaste uppdateringsstatusen. 1. Enskild dator
2. På skala
3. I stor skala med hjälp av princip		 1. För Azure VM
2.För Arc-aktiverad virtuell dator
3 Distributionsscheman för statisk uppdatering (statisk lista över datorer för uppdateringsdistribution). Automation uppdateringshantering hade egna scheman. Azure Update Manager skapar ett underhållskonfigurationsobjekt för ett schema. Därför måste du skapa det här objektet och kopiera alla schemainställningar från Automation Update Management till schemat för Azure uppdateringshanterare. 1. Enskild virtuell dator
2. På skala
3. I stor skala med hjälp av princip		 Skapa ett statiskt omfång
4 Distributionsscheman för dynamisk uppdatering (Definiera omfång för datorer med hjälp av resursgrupp, taggar osv. som utvärderas dynamiskt vid körning). Samma som statiska uppdateringsscheman. Samma som statiska uppdateringsscheman. Lägga till ett dynamiskt omfång Skapa ett dynamiskt omfång
5 Hoppa av från Azure Automation uppdateringshantering. När du har slutfört steg 1, 2 och 3 måste du rensa Azure uppdateringshanterareobjekt. Ta bort lösningen för uppdateringshantering
 NA
6 Rapportering Anpassade uppdateringsrapporter med hjälp av Log Analytics-frågor. Uppdateringsdata lagras i Azure Resource Graph (ARG). Kunder kan köra frågor mot ARG-data för att skapa anpassade instrumentpaneler, arbetsböcker osv. Du kan komma åt gamla Automation Update Management-data som lagras i Log Analytics, men det finns ingen bestämmelse om att flytta data till ARG. Du kan skriva ARG-frågor för att komma åt data som lagras i ARG när Virtual Machines har korrigerats via Azure uppdateringshanterare. Med ARG-frågor kan du skapa instrumentpaneler och arbetsböcker med hjälp av följande instruktioner:
1. Loggstrukturen i Azure Resource Graph uppdaterar data
2. Exempel på ARG-frågor
3. Skapa arbetsböcker		 NA
7 Anpassa arbetsflöden med hjälp av för- och efterskript. Tillgänglig som Automation-runbooks. Vi rekommenderar att du provar den offentliga förhandsversionen för för- och efterskript på dina icke-produktionsdatorer och använder funktionen för produktionsarbetsbelastningar när funktionen har angett allmän tillgänglighet. Hantera händelser före och efter (förhandsversion)
8 Skapa varningar baserat på uppdateringsdata för din miljö Varningar kan konfigureras för uppdateringsdata som lagras i logganalys. Vi rekommenderar att du provar den offentliga förhandsversionen för aviseringar på dina icke-produktionsdatorer och använder funktionen för produktionsarbetsbelastningar när funktionen har angett allmän tillgänglighet. Skapa aviseringar (förhandsversion)

Nästa steg