Passare da Gestione aggiornamenti di Automazione a Gestore aggiornamenti di Azure

Articolo
05/09/2024

Si applica a: ✔️ Macchine virtuali Windows ✔️ Macchine virtuali Linux ✔️ Ambiente locale ✔️ Server abilitati per Azure Arc

Questo articolo fornisce indicazioni per spostare le macchine virtuali da Gestione aggiornamenti di Automazione ad Azure Update Manager.

Azure Update Manager offre una soluzione SaaS per gestire e governare gli aggiornamenti software nei computer Windows e Linux in ambienti Azure, locali e multicloud. Si tratta di un'evoluzione di soluzione di gestione degli aggiornamenti di Automazione di Azure con nuove funzionalità e funzionalità, per la valutazione e la distribuzione di aggiornamenti software in un singolo computer o in più computer su larga scala.

Per il Gestore aggiornamenti di Azure, AMA e MMA non sono un requisito per gestire i flussi di lavoro di aggiornamento software perché si basa sull'agente di macchine virtuali di Microsoft Azure per le macchine virtuali di Azure e l'agente di Azure Connected Machine per i server abilitati per Arc. Quando si esegue un'operazione di aggiornamento per la prima volta in un computer, viene eseguito il push di un'estensione nel computer e interagisce con gli agenti per valutare gli aggiornamenti mancanti e installare gli aggiornamenti.

Nota

Se si usa la soluzione di gestione degli aggiornamenti di Automazione di Azure, è consigliabile non rimuovere gli agenti MMA dai computer senza completare la migrazione al Gestore aggiornamenti di Azure per le esigenze di gestione delle patch del computer. Se si rimuove l'agente MMA dal computer senza passare al Gestore aggiornamenti di Azure, i flussi di lavoro di applicazione delle patch per quel computer verranno interrotti.
Tutte le funzionalità di Gestione aggiornamenti di Automazione di Azure saranno disponibili in Gestione aggiornamenti di Azure prima della data di deprecazione.

Esperienza del portale di Azure

Questa sezione illustra come usare l'esperienza del portale per spostare pianificazioni e computer da Gestione aggiornamenti di Automazione ad Azure Update Manager. Con i clic minimi e il modo automatizzato per spostare le risorse, è il modo più semplice per spostarsi se non si dispone di personalizzazioni basate sulla soluzione Gestione aggiornamenti di Automazione.

Per accedere all'esperienza di migrazione del portale, è possibile usare diversi punti di ingresso.

Selezionare il pulsante Esegui migrazione ora presente nei punti di ingresso seguenti. Dopo la selezione, viene illustrato il processo di spostamento delle pianificazioni e dei computer in Gestione aggiornamenti di Azure. Questo processo è progettato per essere semplice e diretto da usare per consentire di completare la migrazione con un minimo sforzo.

È possibile eseguire la migrazione da uno dei punti di ingresso seguenti:

Selezionare il pulsante Esegui migrazione e si apre un pannello di migrazione. Esso contiene un riepilogo di tutte le risorse, inclusi i computer, e delle pianificazioni dell'account di Automazione. Per impostazione predefinita, l'account di Automazione da cui è stato eseguito l'accesso a questo pannello è preselezionato se si passa da questa route.

Qui è possibile vedere quanti server abilitati per Azure, server abilitati per Arc, server non abilitati per Azure Arc e pianificazioni sono abilitati in Gestione aggiornamenti di Automazione e devono essere spostati in Gestione aggiornamenti di Azure. È inoltre possibile visualizzare i dettagli di queste risorse.

Il pannello di migrazione offre una panoramica delle risorse che verranno spostate, consentendo di ricontrollare e confermare la migrazione prima di procedere. Una volta pronti, si può procedere con il processo di migrazione per spostare le pianificazioni e i computer in Gestore aggiornamenti di Azure.

Dopo aver ricontrollato le risorse che devono essere spostate, si può procedere con il processo di migrazione, costituito da tre passaggi:

Prerequisiti

Sono inclusi due passaggi:

a. Eseguire l'onboarding di computer non abilitati per Azure né per Arc in Arc: questo perché la connettività Arc è un prerequisito per Azure Update Manager. L'onboarding dei computer su Azure Arc è gratuito e, dopo aver eseguito questa operazione, è possibile usufruire di tutti i servizi di gestione allo stesso modo di qualsiasi computer Azure. Per altre informazioni, vedere la documentazione di Azure Arc su come eseguire l'onboarding dei computer.

b. Scaricare ed eseguire script di PowerShell in locale: questa operazione è necessaria per la creazione di un'identità utente e delle assegnazioni di ruolo appropriate in modo che la migrazione possa essere eseguita. Questo script fornisce all'identità utente il controllo degli accessi in base al ruolo appropriato nella sottoscrizione a cui appartiene l'account di automazione, i computer di cui è stato eseguito l'onboarding in Gestione aggiornamenti di Automazione, gli ambiti che fanno parte di query dinamiche e così via. In questo modo la configurazione può essere assegnata ai computer, è possibile creare configurazioni MRP e rimuovere la soluzione di aggiornamenti. Per altre informazioni, vedere la documentazione di Azure Update Manager.
Spostare le risorse nell'account di Automazione in Azure Update Manager

Il passaggio successivo del processo di migrazione consiste nell'abilitare Gestore aggiornamenti di Azure sui computer da spostare e creare configurazioni di manutenzione equivalenti per le pianificazioni da migrare. Quando si seleziona il pulsante Esegui migrazione adesso, importa il runbook MigrateToAzureUpdateManager nell'account di Automazione e imposta la registrazione dettagliata su True.

Selezionare Avvia runbook, che presenta i parametri che devono essere passati al runbook.

Per altre informazioni sui parametri da recuperare e sul percorso da cui devono essere recuperati, vedere Migrazione di computer e pianificazioni. Dopo aver avviato il runbook in seguito all’inserimento di tutti i parametri, Gestore aggiornamenti di Azure inizierà a essere abilitato nei computer, e la configurazione di manutenzione in Gestore aggiornamenti di Azure inizierà a essere creata. È possibile monitorare i log dei runbook di Azure per verificare lo stato dell'esecuzione e della migrazione delle pianificazioni.
Eseguire il deboarding delle risorse dalla gestione degli aggiornamenti di Automazione

Eseguire lo script di pulizia per eseguire il deboarding dei computer dalla soluzione Gestione aggiornamenti di Automazione e disabilitare le pianificazioni di Gestione aggiornamenti di Automazione.

Dopo aver selezionato il pulsante Esegui script di pulizia, il runbook DeboardFromAutomationUpdateManagement verrà importato nell'account di Automazione e la registrazione dettagliata è impostata su True.

Quando si seleziona Avvia il runbook, chiede di passare parametri al runbook. Per altre informazioni, vedere Deboarding dalla soluzione Gestione aggiornamenti di Automazione per recuperare i parametri da passare al runbook.

Script di migrazione

Usando i runbook di migrazione, è possibile eseguire automaticamente la migrazione di tutti i carichi di lavoro (computer e pianificazioni) da Gestione aggiornamenti di Automazione ad Azure Update Manager. Questa sezione descrive in dettaglio come eseguire lo script, le operazioni eseguite dallo script nel back-end, il comportamento previsto e le eventuali limitazioni, se applicabili. Lo script può eseguire la migrazione di tutti i computer e le pianificazioni in un unico account di automazione in un'unica operazione. Se si dispone di più account di automazione, è necessario eseguire il runbook per tutti gli account di automazione.

A livello generale, è necessario seguire la procedura seguente per eseguire la migrazione dei computer e delle pianificazioni da Gestione aggiornamenti di Automazione ad Azure Update Manager.

Riepilogo dei prerequisiti

Eseguire l'onboarding di computer non Azure in Azure Arc.
Scaricare ed eseguire lo script di PowerShell per la creazione di identità utente e assegnazioni di ruolo in locale nel sistema. Vedere le istruzioni dettagliate nella guida dettagliata perché presenta anche alcuni prerequisiti.

Riepilogo dei passaggi

Eseguire il runbook di automazione della migrazione per la migrazione di computer e pianificazioni da Gestione aggiornamenti di Automazione ad Azure Update Manager. Vedere le istruzioni dettagliate nella guida dettagliata.
Eseguire script di pulizia per eseguire il deboarding da Gestione aggiornamenti di Automazione. Vedere le istruzioni dettagliate nella guida dettagliata.

Scenari non supportati

Le query di ricerca non salvate di Azure non verranno migrate; devono essere migrati manualmente.

Per l'elenco completo delle limitazioni e degli elementi da notare, vedere l'ultima sezione di questo articolo.

Guida dettagliata

Le informazioni indicate in ognuno dei passaggi precedenti sono illustrate in dettaglio di seguito.

Prerequisito 1: Eseguire l'onboarding di computer non Azure in Arc

Cosa fare

Il runbook di automazione della migrazione ignora le risorse che non vengono caricate in Arc. È quindi un prerequisito per eseguire l'onboarding di tutti i computer non Azure in Azure Arc prima di eseguire il runbook di migrazione. Seguire la procedura per eseguire l'onboarding dei computer in Azure Arc.

Prerequisito 2: Creare identità utente e assegnazioni di ruolo eseguendo lo script di PowerShell

R. Prerequisiti per l'esecuzione dello script

Eseguire il comando Install-Module -Name Az -Repository PSGallery -Force in PowerShell. Lo script dei prerequisiti dipende da Az.Modules. Questo passaggio è obbligatorio se Az.Modules non è presente o aggiornato.
Per eseguire questo script prerequisito, è necessario disporre di autorizzazioni di Microsoft.Authorization/roleAssignments/write per tutte le sottoscrizioni che contengono risorse di Gestione aggiornamenti di Automazione, ad esempio computer, pianificazioni, area di lavoro Log Analytics e account di automazione. Informazioni su come assegnare un ruolo di Azure.
È necessario disporre delle autorizzazioni di Gestione aggiornamenti.

B. Eseguire lo script

Scaricare ed eseguire lo script di PowerShell MigrationPrerequisiteScript localmente. Questo script accetta la migrazione di AutomationAccountResourceId dell'account di Automazione e AutomationAccountAzureEnvironment come input. I valori accettati per AutomationAccountAzureEnvironment sono AzureCloud, AzureUSGovernment e AzureChina che firmano il cloud a cui appartiene l'account di automazione.

È possibile recuperare AutomationAccountResourceId passando ad Account di Automazione>Proprietà.

C. Verificare

Dopo aver eseguito lo script, verificare che nell'account di automazione venga creata un'identità gestita dall'utente. Account di Automazione>Identità>Assegnata dall'utente.

D. Operazioni back-end dallo script

Aggiornamento di Az.Modules per l'account di Automazione, che sarà necessario per l'esecuzione di script di migrazione e deboarding.
Crea una variabile di automazione con il nome AutomationAccountAzureEnvironment che archivierà l'ambiente cloud di Azure a cui appartiene l'account di Automazione.
Creazione dell'identità utente nello stesso gruppo di risorse e sottoscrizione dell'account di Automazione. Il nome dell'identità utente sarà simile a AutomationAccount_aummig_umsi.
Collegamento dell'identità utente all'account di Automazione.
Lo script assegna le autorizzazioni seguenti all'identità gestita dall'utente: Autorizzazioni di gestione aggiornamenti necessarie.
1. A questo scopo, lo script recupera tutti i computer di cui è stato eseguito l'onboarding in Gestione aggiornamenti di Automazione con questo account di automazione e analizza gli ID sottoscrizione in modo da assegnare il controllo degli accessi in base al ruolo richiesto all'identità utente.
2. Lo script fornisce un controllo degli accessi in base al ruolo appropriato all'identità utente nella sottoscrizione a cui appartiene l'account di automazione in modo che le configurazioni MRP possano essere create qui.
3. Lo script assegna i ruoli necessari per l'area di lavoro Log Analytics e la soluzione.
Registrazione delle sottoscrizioni necessarie ai provider di risorse Microsoft.Maintenance e Microsoft.EventGrid.

Passaggio 1: Migrazione di computer e pianificazioni

Questo passaggio prevede l'uso di un runbook di automazione per eseguire la migrazione di tutti i computer e le pianificazioni da un account di automazione ad Azure Update Manager.

Segui questi passaggi:

Importare runbook di migrazione dalla raccolta di runbook e pubblicare. Cercare l'aggiornamento di Automazione di Azure dalla raccolta e importare il runbook di migrazione denominato Eseguire la migrazione da Gestione aggiornamenti di Automazione di Azure in Azure Update Manager e pubblicare il runbook.

Il runbook supporta PowerShell 5.1.
Impostare Registrazione dettagliata su True per il runbook.
Eseguire il runbook e passare i parametri necessari, ad esempio AutomationAccountResourceId, UserManagedServiceIdentityClientId e così via.
1. È possibile recuperare AutomationAccountResourceId da account di Automazione>Proprietà.
2. È possibile recuperare UserManagedServiceIdentityClientId da account di Automazione>Identità>Assegnata dall'utente>Identità>Proprietà>ID client.
3. L'impostazione di EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement su TRUE abilita la proprietà di valutazione periodica in tutti i computer di cui è stato eseguito l'onboarding in Gestione aggiornamenti di Automazione.
4. L'impostazione di MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines su TRUE esegue la migrazione di tutte le pianificazioni degli aggiornamenti in Gestione aggiornamenti di Automazione ad Azure Update Manager e attiva anche la proprietà di valutazione periodica su True in tutti i computer collegati a queste pianificazioni.
5. È necessario specificare ResourceGroupForMaintenanceConfigurations in cui verranno create tutte le configurazioni di manutenzione in Gestione aggiornamenti di Azure. Se si specifica un nuovo nome, verrà creato un gruppo di risorse in cui verranno create tutte le configurazioni di manutenzione. Tuttavia, se si specifica un nome con cui esiste già un gruppo di risorse, tutte le configurazioni di manutenzione verranno create nel gruppo di risorse esistente.
Controllare i log dei runbook di Azure per verificare lo stato di esecuzione e migrazione dei controller di archiviazione.

Operazioni del runbook nel back-end

La migrazione del runbook esegue le attività seguenti:

Abilita la valutazione periodica in tutti i computer.
Tutte le pianificazioni nell'account di automazione vengono migrate in Gestione aggiornamenti di Azure e viene creata una configurazione di manutenzione corrispondente per ognuna di esse, con le stesse proprietà.

Informazioni sullo script

Di seguito è riportato il comportamento dello script di migrazione:

Controllare se un gruppo di risorse con il nome preso come input è già presente nella sottoscrizione dell'account di automazione o meno. In caso contrario, creare un gruppo di risorse con il nome specificato dal cliente. Questo gruppo di risorse viene usato per la creazione delle configurazioni MRP per la versione 2.
RebootOnly L'impostazione non è disponibile in Gestione aggiornamenti di Azure. Le pianificazioni con l'impostazione RebootOnly non vengono migrate.
Filtrare i controller di archiviazione che si trovano nello stato errored/expired/provisioningFailed/disabled e contrassegnarli come Non migrati, e stampare i log appropriati che indicano che tali controller di archiviazione non vengono migrati.
Il nome dell'assegnazione di configurazione è una stringa che sarà nel formato AUMMig_AAName_SUCName
Determinare se questo ambito dinamico è già assegnato alla configurazione di manutenzione o meno controllando Azure Resource Graph. Se non è assegnato, assegnare solo con il nome dell'assegnazione nel formato AUMMig_ AAName_SUCName_SomeGUID.
Per le pianificazioni con attività pre/post configurate, lo script creerà un webhook di automazione per i runbook nelle attività pre/post e nelle sottoscrizioni di Griglia di eventi per gli eventi di manutenzione pre/post. Per altre informazioni, vedere funzionamento pre/post in Gestione aggiornamenti di Azure
Un set riepilogato di log viene stampato nel flusso di output per fornire uno stato complessivo di computer e controller di streaming.
I log dettagliati vengono stampati nel flusso dettagliato.
Dopo la migrazione, una configurazione di aggiornamento software può avere uno dei quattro stati di migrazione seguenti:
- MigrationFailed
- PartiallyMigrated
- NotMigrated
- Migrated

La tabella seguente illustra gli scenari associati a ogni stato di migrazione.

MigrationFailed	PartiallyMigrated	NotMigrated	Migrated
Impossibile creare la configurazione di manutenzione per la configurazione dell'aggiornamento software.	Numero diverso da zero di computer in cui non è stato possibile applicare Patch-Settings.	Impossibile ottenere la configurazione dell'aggiornamento software dall'API a causa di un errore client/server, ad esempio errore interno del servizio.
	Numero diverso da zero di computer con assegnazioni di configurazione non riuscite.	Configurazione aggiornamento software ha l'impostazione di riavvio solo come riavvio. Questo non è attualmente supportato in Gestore aggiornamenti di Azure.
	Numero diverso da zero di query dinamiche non risolte, ovvero non è stato possibile eseguire la query con Azure Resource Graph.
	Numero diverso da zero di errori di assegnazione della configurazione dell'ambito dinamico.	La configurazione dell'aggiornamento software non ha uno stato di provisioning riuscito nel DB.
	La configurazione dell'aggiornamento software prevede query di ricerca salvate.	La configurazione dell'aggiornamento software è in stato di errore nel database.
	La configurazione dell'aggiornamento software prevede attività pre/post che non sono state migrate correttamente.	La pianificazione associata alla configurazione dell'aggiornamento software è già scaduta al momento della migrazione.
		La pianificazione associata alla configurazione dell'aggiornamento software è disabilitata.
		Eccezione non gestita durante la migrazione della configurazione degli aggiornamenti software.	Zero computer in cui non è stato possibile applicare le impostazioni patch. And Zero computer con assegnazioni di configurazione non riuscite. And Impossibile risolvere zero query dinamiche che non sono riuscite a eseguire la query in Azure Resource Graph. And Zero errori di assegnazione della configurazione dell'ambito dinamico. And Configurazione aggiornamento software ha zero query di ricerca salvate.

Per capire dalla tabella precedente quale scenario/quali scenari corrispondono al motivo per cui la configurazione dell'aggiornamento software ha uno stato specifico, esaminare i log dettagliati/non riusciti/di avviso per ottenere il codice di errore e il messaggio di errore.

È anche possibile cercare con il nome della pianificazione degli aggiornamenti per ottenere i log specifici per il debug.

Passaggio 2: Deboarding dalla soluzione Gestione aggiornamenti di Automazione

Segui questi passaggi:

Importare il runbook di migrazione dalla raccolta di runbook. Cercare l'aggiornamento di Automazione di Azure da sfoglia raccolta e importare il runbook di migrazione denominato Deboard da Gestione aggiornamenti di Automazione di Azure e pubblicare il runbook.

Il runbook supporta PowerShell 5.1.
Impostare Registrazione dettagliata su True per il runbook.
Avviare il runbook e passare parametri come AccountResourceId di Automazione, UserManagedServiceIdentityClientId e così via.

È possibile recuperare AutomationAccountResourceId da account di Automazione>Proprietà.

È possibile recuperare UserManagedServiceIdentityClientId da account di Automazione>Identità>Assegnata dall'utente>Identità>Proprietà>ID client.
Controllare i log dei runbook di Azure per verificare lo stato di deboarding di computer e pianificazioni.

Operazioni script di deboarding nel back-end

Disabilitare tutte le pianificazioni sottostanti per tutte le configurazioni di aggiornamento software presenti in questo account di Automazione. Questa operazione viene eseguita per assicurarsi che il runbook Patch-MicrosoftOMSComputers non venga attivato per i controller di streaming di cui è stata eseguita la migrazione parziale alla versione 2.
Eliminare la soluzione Aggiornamenti dall'area di lavoro Log Analytics collegata per l'account di Automazione di cui è stato eseguito il deboarding da Gestione aggiornamenti di Automazione nella versione 1.
Nel flusso di output viene stampato anche un log riassuntivo di tutti i SUC disattivati e dello stato di rimozione della soluzione di aggiornamento dall'area di lavoro Log Analytics collegata.
I log dettagliati vengono stampati sui flussi dettagliati.

Callout per il processo di migrazione:

Le query di ricerca non salvate di Azure non verranno migrate.
Per il funzionamento dei runbook di migrazione e deboarding è necessario aggiornare Az.Modules.
Lo script dei prerequisiti aggiorna Az.Modules alla versione 8.0.0 più recente.
Il valore StartTime della pianificazione MRP sarà uguale a nextRunTime della configurazione dell'aggiornamento software.
I dati di Log Analytics non verranno migrati.
Le identità gestite dall'utente non supportano scenari tra tenant.
L'impostazione RebootOnly non è disponibile in Gestione aggiornamenti di Azure. Le pianificazioni con l'impostazione RebootOnly non verranno migrate.
Per Ricorrenza, le pianificazioni di Automazione supportano valori compresi tra (da 1 a 100) per pianificazioni orarie/giornaliere/settimanali/mensili, mentre la configurazione di manutenzione di Azure Update Manager supporta tra (da 6 a 35) per quelle orarie e (da 1 a 35) per quelle giornaliere/settimanali/mensili.
- Ad esempio, se la pianificazione di Automazione ha una ricorrenza ogni 100 ore, la pianificazione della configurazione di manutenzione equivalente ce l’ha per ogni 100/24 = 4,16 (arrotondamento al valore più vicino) -> Quattro giorni saranno la ricorrenza per la configurazione di manutenzione.
- Ad esempio, se la pianificazione di automazione ha una ricorrenza ogni ora, la pianificazione della configurazione di manutenzione equivalente ce l’avrà ogni 6 ore.
- Applicare la stessa convenzione per quella Settimanale e Giornaliera.
  - Se la pianificazione di automazione ha una ricorrenza giornaliera di 100 giorni, 100/7 = 14,28 (arrotondamento al valore più vicino) -> 14 settimane sarà la ricorrenza per la pianificazione della configurazione della manutenzione.
  - Se la pianificazione di automazione ha una ricorrenza settimanale di 100 settimane, 100/4,34 = 23,04 (arrotondamento al valore più vicino) -> 23 mesi sarà la ricorrenza per la pianificazione della configurazione della manutenzione.
  - Se la pianificazione di Automazione che deve essere eseguita ogni 100 settimane e deve essere eseguita il venerdì. Se convertita in configurazione di manutenzione, sarà ogni 23 mesi (100/4.34). Tuttavia, non c'è modo in Azure Update Manager di dire che viene eseguita ogni 23 mesi per tutti i venerdì di quel mese, quindi la pianificazione non verrà migrata.
  - Se una pianificazione di Automazione ha una ricorrenza di più di 35 mesi, nella configurazione di manutenzione avrà sempre una ricorrenza di 35 mesi.
- SUC supporta da 30 minuti a sei ore per la finestra di manutenzione. MRP supporta da 1 ora e 30 minuti a 4 ore.
  - Ad esempio, se SUC ha una finestra di manutenzione di 30 minuti, la pianificazione MRP equivalente ce l’avrà per 1 ora e 30 minuti.
  - Ad esempio, se SUC ha una finestra di manutenzione di 6 ore, la pianificazione MRP equivalente ce l’avrà per 4 ore.
Quando il runbook di migrazione viene eseguito più volte, ad esempio se si esegue la migrazione di tutte le pianificazioni di automazione e poi si tenta nuovamente di migrare tutte le pianificazioni, il runbook di migrazione eseguirà la stessa logica. Se si ripete l'operazione, la pianificazione MRP viene aggiornata se sono presenti nuove modifiche in SUC. Non effettuerà assegnazioni di configurazione duplicate. Inoltre, le operazioni vengono eseguite solo per le pianificazioni di Automazione con pianificazioni abilitate. Se in precedenza è stata eseguita la migrazione di un SUC, verrà ignorato nel turno successivo perché la pianificazione sottostante sarà Disabilitata.
Alla fine, è possibile risolvere più computer da Azure Resource Graph come in Azure Update Manager; non è possibile verificare se il ruolo di lavoro ibrido per runbook stia creando o meno un report, a differenza di Gestione aggiornamenti di Automazione, in cui si trattava di un'intersezione tra query dinamiche e ruolo di lavoro ibrido per runbook.

Materiale sussidiario per la migrazione manuale

La tabella seguente fornisce indicazioni per lo spostamento delle varie funzionalità:

S.No	Funzionalità	Gestione aggiornamenti di Automazione	Gestore aggiornamenti di Azure	Passi con il portale di Azure	Passi con API/script
1	Gestione delle patch per computer non Azure.	Può essere eseguito con o senza connettività Arc.	Azure Arc è un prerequisito per i computer non Azure.	1. Creare un'entità servizio 2. Genera script di installazione 3. Installare l'agente e connettersi ad Azure	1. Creare un'entità servizio 2. Genera script di installazione 3. Installare l'agente e connettersi ad Azure
2	Abilitare la valutazione periodica per verificare automaticamente la disponibilità degli ultimi aggiornamenti ogni poche ore.	I computer ricevono automaticamente gli aggiornamenti più recenti ogni 12 ore per Windows e ogni 3 ore per Linux.	La valutazione periodica è un'impostazione di aggiornamento sul computer. Se è attivata, la Gestione degli aggiornamenti recupera gli aggiornamenti ogni 24 ore per il computer e mostra lo stato dell'aggiornamento più recente.	1. Singolo computer 2. Su larga scala 3. Su larga scala usando i criteri	1. Per la macchina virtuale di Azure 2.Per le macchine virtuali abilitate per Arc
3	Pianificazioni di distribuzione degli aggiornamenti statici (elenco statico di computer per la distribuzione degli aggiornamenti).	La gestione degli aggiornamenti di Automazione aveva le proprie pianificazioni.	Gestione aggiornamenti di Azure crea un oggetto configurazione di manutenzione per una pianificazione. È quindi necessario creare questo oggetto copiando tutte le impostazioni di pianificazione da Gestione degli aggiornamenti di Automazione alla pianificazione del Gestore aggiornamenti di Azure.	1. Singola macchina virtuale 2. Su larga scala 3. Su larga scala usando i criteri	Creare un ambito statico
4	Pianificazioni di distribuzione degli aggiornamenti dinamici (definizione dell'ambito dei computer che usano gruppi di risorse, tag e così via che vengono valutati in modo dinamico in fase di esecuzione).	Uguale alle pianificazioni degli aggiornamenti statici.	Uguale alle pianificazioni degli aggiornamenti statici.	Aggiungere un ambito dinamico	Creare un ambito dinamico
5	Effettuare il deboarding dalla gestione degli aggiornamenti di Automazione di Azure.	Dopo aver completato i passaggi 1, 2 e 3, è necessario pulire gli oggetti di Gestione degli aggiornamenti di Azure.		Rimuovere la soluzione Gestione aggiornamenti	ND
6	Creazione di report	Report di aggiornamento personalizzato con query di analisi dei log.	I dati di aggiornamento vengono archiviati in Azure Resource Graph (ARG). I clienti possono eseguire query sui dati ARG per creare dashboard personalizzati, cartelle di lavoro e così via.	È possibile accedere ai vecchi dati di Gestione degli aggiornamenti di Automazione archiviati nell'analisi dei log, ma non è previsto lo spostamento dei dati in ARG. È possibile scrivere query ARG per accedere ai dati che verranno archiviati in ARG dopo l'applicazione di patch alle macchine virtuali tramite il Gestore aggiornamenti di Azure. Con le query ARG è possibile compilare dashboard e cartelle di lavoro seguendo le istruzioni seguenti: 1. La struttura dei log di Azure Resource Graph aggiorna i dati 2. Query ARG di esempio 3. Creare cartelle di lavoro	ND
7	Personalizzare i flussi di lavoro usando pre-script e post-script.	Disponibile come runbook di Automazione.	È consigliabile provare l'anteprima pubblica per script pre e post nei computer non di produzione e usare la funzionalità nei carichi di lavoro di produzione dopo che la funzionalità entra in disponibilità generale.	Gestire gli eventi pre e post (anteprima) e Esercitazione: Creare eventi pre e post usando un webhook con Automazione
8	Creare avvisi in base ai dati degli aggiornamenti per l'ambiente	È possibile impostare avvisi sui dati degli aggiornamenti archiviati nell'analisi dei log.	È consigliabile provare l'anteprima pubblica per gli avvisi nei computer non di produzione e usare la funzionalità nei carichi di lavoro di produzione dopo che la funzionalità entra in disponibilità generale.	Creare avvisi (anteprima)

Passaggi successivi

Linee guida sulla migrazione di macchine virtuali di Azure da Microsoft Configuration Manager a Gestore aggiornamenti di Azure

Condividi tramite