Passare da Gestione aggiornamenti di Automazione a Gestore aggiornamenti di Azure

Articolo
05/09/2024

Si applica a: ✔️ Macchine virtuali ✔️ Windows Vm Linux ✔️ Server abilitati per Azure Arc nell'ambiente ✔️ locale

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 gestire gli aggiornamenti software nei computer Windows e Linux in ambienti Azure, locali e multicloud. Si tratta di un'evoluzione della soluzione di gestione degli aggiornamenti Automazione di Azure con nuove funzionalità e funzionalità, per la valutazione e la distribuzione di aggiornamenti software in un singolo computer o su 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 Automazione di Azure Gestione aggiornamenti 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 semplice 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 ora e si apre un pannello di migrazione. Contiene un riepilogo di tutte le risorse, inclusi i computer e le pianificazioni nell'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. È anche possibile visualizzare i dettagli di queste risorse.

Il pannello della migrazione offre una panoramica delle risorse che verranno spostate, consentendo di esaminare e confermare la migrazione prima di procedere. Una volta pronti, è possibile procedere con il processo di migrazione per spostare le pianificazioni e i computer in Azure Update Manager.

Dopo aver esaminato le risorse che devono essere spostate, è possibile procedere con il processo di migrazione che è un processo in tre passaggi:

Prerequisiti

Sono inclusi due passaggi:

a. Eseguire l'onboarding di computer non abilitati per Azure non Arc in Arc : questo perché la connettività Arc è un prerequisito per Azure Update Manager. L'onboarding dei computer in Azure Arc è gratuito e, dopo aver eseguito questa operazione, è possibile usufruire di tutti i servizi di gestione come si può fare per qualsiasi computer di 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 il controllo degli accessi in base al ruolo appropriato all'identità utente 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 modo che la configurazione possa 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 Gestione aggiornamenti di Azure nei computer da spostare e creare configurazioni di manutenzione equivalenti per le pianificazioni di cui eseguire la migrazione. 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 deve essere recuperato, vedere Migrazione di computer e pianificazioni. Dopo aver avviato il runbook dopo aver passato tutti i parametri, Azure Update Manager inizierà a essere abilitato nei computer e nella configurazione di manutenzione in Gestione aggiornamenti di Azure inizierà a creare. È 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 from Automation Update Management solution (Deboarding from Automation Update Management solution ) 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 delle autorizzazioni 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 MigrationPrerequisiteScript di PowerShell in locale. 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 a Proprietà dell'account>di Automazione.

C. Verificare

Dopo aver eseguito lo script, verificare che nell'account di automazione venga creata un'identità gestita dall'utente. Identità>dell'account>di Automazione 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 il 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 Migrate from Automazione di Azure Update Management to Azure Update Manager (Eseguire la migrazione da Gestione aggiornamenti ad 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 dalle proprietà dell'account>di Automazione.
2. È possibile recuperare UserManagedServiceIdentityClientId dall'ID client delle proprietà>dell'identità>>assegnata>dall'account di Automazione.>
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 pre/post manutenzione. Per altre informazioni, vedere funzionamento preliminare/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
- Parzialmentemigrato
- NotMigrated
- Migrati

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

MigrationFailed	Parzialmentemigrato	NotMigrated	Migrati
Impossibile creare la configurazione di manutenzione per la configurazione dell'aggiornamento software.	Numero diverso da zero di computer in cui Patch-Impostazioni non è possibile applicare.	Impossibile ottenere la configurazione dell'aggiornamento software dall'API a causa di un errore client/server, ad esempio un 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 Azure Update Manager.
	Numero diverso da zero di query dinamiche non riuscite a risolvere che non è riuscito a eseguire la query su Azure Resource Graph.
	Numero diverso da zero di errori di assegnazione della configurazione dell'ambito dinamico.	Configurazione aggiornamento software non ha avuto esito positivo dello stato di provisioning nel database.
	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 patch-Impostazioni non è stato possibile applicare. 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/scenario corrisponde al motivo per cui la configurazione dell'aggiornamento software ha uno stato specifico, esaminare i log dettagliati/non riusciti/avvisi 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 dalla raccolta di esplorazioni e importare il runbook di migrazione denominato Deboard da Automazione di Azure Gestione aggiornamenti 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 dalle proprietà dell'account>di Automazione.

È possibile recuperare UserManagedServiceIdentityClientId dall'ID client delle proprietà>dell'identità>>assegnata>dall'account di Automazione.>
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 da deboarding da Gestione aggiornamenti di Automazione nella versione 1.
Viene stampato anche un log riepilogato di tutti i controller di archiviazione disabilitati e lo stato della rimozione della soluzione aggiornamenti dall'area di lavoro Log Analytics collegata al flusso di output.
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.
RebootOnly L'impostazione non è disponibile in Gestione aggiornamenti di Azure. Le pianificazioni con l'impostazione RebootOnly non verranno migrate.
Per Ricorrenza, Automazione pianifica il supporto dei valori compresi tra (da 1 a 100) per pianificazioni orarie/giornaliere/settimanali/mensili, mentre la configurazione di manutenzione di Azure Update Manager supporta tra (6 e 35) per Ogni ora e (da 1 a 35) per giornaliero/settimanale/mensile.
- Ad esempio, se la pianificazione di automazione ha una ricorrenza ogni 100 ore, la pianificazione della configurazione di manutenzione equivalente lo 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 1 ora, la pianificazione della configurazione di manutenzione equivalente avrà ogni 6 ore.
- Applicare la stessa convenzione per Settimanale e Giornaliero.
  - 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 convertito in configurazione di manutenzione, sarà ogni 23 mesi (100/4.34). Tuttavia, non c'è modo in Azure Update Manager di dire che l'esecuzione ogni 23 mesi su tutti i venerdì del 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 35 mesi ricorrenza.
- SUC supporta da 30 minuti a sei ore per la finestra di manutenzione. MRP supporta da 1 ora 30 minuti a 4 ore.
  - Ad esempio, se SUC ha una finestra di manutenzione di 30 minuti, la pianificazione MRP equivalente avrà per 1 ora 30 minuti.
  - Ad esempio, se SUC ha una finestra di manutenzione di 6 ore, la pianificazione MRP equivalente avrà per 4 ore.
Quando il runbook di migrazione viene eseguito più volte, si supponga di eseguire la migrazione di tutte le pianificazioni di automazione e quindi si è tentato di eseguire di nuovo la migrazione di tutte le pianificazioni, quindi il runbook di migrazione eseguirà la stessa logica. In questo modo, la pianificazione MRP verrà aggiornata se è presente una nuova modifica 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 segnala o meno, a differenza di Gestione aggiornamenti di Automazione, in cui si tratta di un'intersezione tra query dinamiche e ruolo di lavoro ibrido per runbook.

Linee guida 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	Procedura con portale di Azure	Passaggi 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 l'entità servizio 2. Generare lo script di installazione 3. Installare l'agente e connettersi ad Azure	1. Creare un'entità servizio 2. Generare lo 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. Macchina singola 2. Scala 3. Su larga scala usando i criteri	1. Per la macchina virtuale di Azure 2.Per la macchina virtuale abilitata 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 di 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. Macchina virtuale singola 2. 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 di gestione degli 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 pre e post-script 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 ad Azure Update Manager

Condividi tramite