Mover da Gestão de Atualizações da Automatização para o Azure Update Manager

Aplica-se a: ✔️ VMs ✔️ do Windows VMs ✔️ Linux Ambiente local ✔️ Servidores habilitados para Azure Arc

Este artigo fornece orientação para mover máquinas virtuais do Automation Update Management para o Azure Update Manager.

O Azure Update Manager fornece uma solução SaaS para gerenciar e controlar atualizações de software para máquinas Windows e Linux em ambientes Azure, locais e multicloud. É uma evolução da solução de gerenciamento de Atualização de Automação do Azure com novos recursos e funcionalidades, para avaliação e implantação de atualizações de software em uma única máquina ou em várias máquinas em escala.

Para o Azure Update Manager, tanto o AMA quanto o MMA não são um requisito para gerir fluxos de trabalho de atualização de software, pois dependem do Agente de VM do Microsoft Azure para VMs do Azure e do Agente de máquina conectada do Azure para servidores habilitados para Arc. Quando executa uma operação de atualização pela primeira vez numa máquina, uma extensão é enviada por push para a máquina e interage com os agentes para avaliar as atualizações ausentes e instalar atualizações.

Nota

• Se estiver a utilizar a Solução de Gestão de Atualizações da Automatização do Azure, recomendamos que não remova os agentes MMA das máquinas sem concluir a migração para o Azure Update Manager para as necessidades de gestão de patches da máquina. Se remover o agente MMA da máquina sem mover para o Azure Update Manager, os fluxos de trabalho de aplicação de patches para essa máquina serão interrompidos.

• Todos os recursos do Azure Automation Update Management estarão disponíveis no Azure Update Manager antes da data de descontinuação.

Experiência do portal do Azure

Esta seção explica como usar a experiência do portal para mover agendas e máquinas do Automation Update Management para o Azure Update Manager. Com o mínimo de cliques e uma maneira automatizada de mover seus recursos, é a maneira mais fácil de mover se você não tiver personalizações criadas sobre sua solução de gerenciamento de atualizações de automação.

Para acessar a experiência de migração do portal, você pode usar vários pontos de entrada.

Selecione o botão Migrar agora presente nos seguintes pontos de entrada. Após a seleção, você será guiado pelo processo de mover suas agendas e máquinas para o Azure Update Manager. Esse processo foi projetado para ser fácil de usar e direto para permitir que você conclua a migração com o mínimo de esforço.

Você pode migrar de qualquer um dos seguintes pontos de entrada:

Gerenciamento de atualizações de automação

Selecione o botão Migrar agora e uma folha de migração será aberta. Ele contém um resumo de todos os recursos, incluindo máquinas e agendas na conta de automação. Por padrão, a conta de automação a partir da qual você acessou essa folha é pré-selecionada se você seguir essa rota.

Aqui, você pode ver quantos servidores do Azure, habilitados para Arc, servidores não habilitados para ArcGIS não Azure e agendas estão habilitados no Gerenciamento de Atualização de Automação e precisam ser movidos para o Azure Update Manager. Você também pode visualizar os detalhes desses recursos.

A folha de migração fornece uma visão geral dos recursos que serão movidos, permitindo que você revise e confirme a migração antes de prosseguir. Quando estiver pronto, você pode continuar com o processo de migração para mover suas agendas e máquinas para o Azure Update Manager.

Depois de revisar os recursos que devem ser movidos, você pode prosseguir com o processo de migração, que é um processo de três etapas:

1. Pré-requisitos

   Isso inclui duas etapas:

   a. Onboard non-Azure non-Arc-enabled machines to Arc - Isso ocorre porque a conectividade Arc é um pré-requisito para o Azure Update Manager. A integração de suas máquinas ao Azure Arc é gratuita e, depois de fazer isso, você pode aproveitar todos os serviços de gerenciamento como pode fazer para qualquer máquina do Azure. Para obter mais informações, consulte a documentação do Azure Arc sobre como integrar suas máquinas.

   b. Baixar e executar o script do PowerShell localmente - Isso é necessário para a criação de uma identidade de usuário e atribuições de função apropriadas para que a migração possa ocorrer. Este script fornece RBAC adequado à Identidade do Usuário na assinatura à qual a conta de automação pertence, máquinas integradas ao Automation Update Management, escopos que fazem parte de consultas dinâmicas, etc., para que a configuração possa ser atribuída às máquinas, configurações MRP possam ser criadas e a solução de atualizações possa ser removida. Para obter mais informações, consulte a documentação do Azure Update Manager.

   

2. Mover recursos na conta de automação para o Azure Update Manager

   A próxima etapa no processo de migração é habilitar o Azure Update Manager nas máquinas a serem movidas e criar configurações de manutenção equivalentes para as agendas a serem migradas. Quando você seleciona o botão Migrar Agora , ele importa o runbook MigrateToAzureUpdateManager para sua conta de Automação e define o log detalhado como True.

   

   Selecione Iniciar runbook, que apresenta os parâmetros que devem ser passados para o runbook.

   

   Para obter mais informações sobre os parâmetros a serem buscados e o local de onde ele deve ser buscado, consulte migração de máquinas e horários. Depois de iniciar o runbook depois de passar todos os parâmetros, o Azure Update Manager começará a ser habilitado em máquinas e a configuração de manutenção no Azure Update Manager começará a ser criada. Você pode monitorar os logs de runbook do Azure para o status de execução e migração de agendas.

3. Desembarque de recursos do gerenciamento de atualizações de automação

   Execute o script de limpeza para desmontar máquinas da solução Automation Update Management e desative as agendas do Automation Update Management.

   Depois de selecionar o botão Executar script de limpeza, o runbook DeboardFromAutomationUpdateManagement será importado para sua conta de automação e seu log detalhado será definido como True.

   

   Quando você seleciona Iniciar o runbook, solicita que os parâmetros sejam passados para o runbook. Para obter mais informações, consulte Deboarding from Automation Update Management solution para buscar os parâmetros a serem passados para o runbook.

   

Azure Update Manager

Você pode iniciar a migração do Azure Update Manager. Na parte superior da tela, você pode ver um banner de descontinuação com um botão Migrar agora na parte superior da tela.

Selecione o botão Migrar Agora para exibir a folha de migração que permite selecionar a conta de Automação cujos recursos você deseja mover do Gerenciamento de Atualização de Automação para o Azure Update Manager. Você deve selecionar assinatura, grupo de recursos e, finalmente, o nome da conta de automação. Depois de selecionar, você exibirá o resumo das máquinas e agendas a serem migradas para o Azure Update Manager. A partir daqui, siga as etapas de migração listadas em Automation Update Management.

Máquina virtual

Para iniciar a migração a partir de uma única vista de Atualizações de VM, siga estes passos:

1. Selecione a máquina habilitada para o Gerenciamento de atualizações de automação e, em Operações, selecione Atualizações.

2. No banner de descontinuação, selecione o botão Migrar agora .

   

   Você pode ver que a conta de automação à qual a máquina pertence está pré-selecionada e um resumo de todos os recursos na conta de automação é apresentado. Isso permite migrar os recursos do Automation Update Management para o Azure Update Manager.

   

   A partir daqui, siga as etapas de migração listadas em Automation Update Management.

   Para obter mais informações sobre como os scripts são executados no back-end e seu comportamento, consulte Scripts de migração.

Scripts de migração

Usando runbooks de migração, você pode migrar automaticamente todas as cargas de trabalho (máquinas e agendas) do Gerenciamento de Atualização de Automação para o Azure Update Manager. Esta seção detalha como executar o script, o que o script faz no back-end, o comportamento esperado e quaisquer limitações, se aplicável. O script pode migrar todas as máquinas e agendas em uma conta de automação de uma só vez. Se você tiver várias contas de automação, terá que executar o runbook para todas as contas de automação.

Em um alto nível, você precisa seguir as etapas abaixo para migrar suas máquinas e agendas do Automation Update Management para o Azure Update Manager.

Resumo dos pré-requisitos

1. Integre máquinas que não sejam do Azure no Azure Arc.
2. Baixe e execute o script do PowerShell para a criação de Identidade de Usuário e Atribuições de Função localmente em seu sistema. Veja instruções detalhadas no guia passo a passo, pois ele também tem certos pré-requisitos.

Resumo das etapas

1. Execute o runbook de automação de migração para migrar máquinas e agendas do Gerenciamento de Atualização de Automação para o Azure Update Manager. Consulte as instruções detalhadas no guia passo-a-passo.
2. Execute scripts de limpeza para sair do Automation Update Management. Consulte as instruções detalhadas no guia passo-a-passo.

Cenários não suportados

• As Consultas de Pesquisa Salvas que não são do Azure não serão migradas; estes têm de ser migrados manualmente.

Para obter a lista completa de limitações e coisas a observar, consulte a última seção deste artigo.

Guia passo a passo

As informações mencionadas em cada uma das etapas acima são explicadas em detalhes abaixo.

Pré-requisito 1: Máquinas não Azure integradas ao Arc

O que fazer

O runbook de automação de migração ignora recursos que não estão integrados ao Arc. Portanto, é um pré-requisito integrar todas as máquinas que não são do Azure ao Azure Arc antes de executar o runbook de migração. Siga as etapas para integrar máquinas no Azure Arc.

Pré-requisito 2: Criar Identidade de Usuário e Atribuições de Função executando o script do PowerShell

A. Pré-requisitos para executar o script

• Execute o comando Install-Module -Name Az -Repository PSGallery -Force no PowerShell. O script de pré-requisito depende de Az.Modules. Esta etapa é necessária se Az.Modules não estiver presente ou atualizado.
• Para executar esse script de pré-requisito, você deve ter permissões Microsoft.Authorization/roleAssignments/write em todas as assinaturas que contêm recursos do Automation Update Management, como máquinas, agendas, espaço de trabalho de análise de log e conta de automação. Veja como atribuir uma função do Azure.
• Você deve ter as Permissões de Gerenciamento de Atualizações.

B. Executar o script

Baixe e execute o script MigrationPrerequisiteScript do PowerShell localmente. Esse script usa AutomationAccountResourceId da conta de automação a ser migrada e AutomationAccountAzureEnvironment como entradas. Os valores aceitos para AutomationAccountAzureEnvironment são AzureCloud, AzureUSGovernment e AzureChina, significando a nuvem à qual a conta de automação pertence.

Você pode buscar AutomationAccountResourceId indo para Propriedades da conta>de automação.

C. Verificar

Depois de executar o script, verifique se uma identidade gerenciada pelo usuário foi criada na conta de automação. Conta de automação>Identidade>do usuário atribuída.

D. Operações de back-end pelo script

1. Atualização do Az.Modules para a conta de automação, que será necessária para executar scripts de migração e desembarque.

2. Cria uma variável de automação com o nome AutomationAccountAzureEnvironment que armazenará o Ambiente de Nuvem do Azure ao qual a Conta de Automação pertence.

3. Criação de Identidade de Usuário no mesmo grupo de Assinatura e recursos da Conta de Automação. O nome da Identidade de Usuário será como AutomationAccount_aummig_umsi.

4. Anexar a identidade do usuário à conta de automação.

5. O script atribui as seguintes permissões à identidade gerenciada pelo usuário: Update Management Permissions Required.

   1. Para isso, o script busca todas as máquinas integradas ao Automation Update Management sob essa conta de automação e analisa seus IDs de assinatura para receber o RBAC necessário para a Identidade do Usuário.
   2. O script fornece um RBAC adequado à Identidade do Usuário na assinatura à qual a conta de automação pertence para que as configurações do MRP possam ser criadas aqui.
   3. O script atribui as funções necessárias para o espaço de trabalho e a solução do Log Analytics.

6. Registro das assinaturas necessárias para Microsoft.Maintenance e Microsoft.EventGrid Resource Providers.

Etapa 1: Migração de máquinas e horários

Esta etapa envolve o uso de um runbook de automação para migrar todas as máquinas e agendas de uma conta de automação para o Azure Update Manager.

Siga estes passos:

1. Importe o runbook de migração da galeria de runbooks e publique. Procure a atualização de automação do Azure na galeria de navegação e importe o runbook de migração chamado Migrar do Azure Automation Update Management para o Azure Update Manager e publique o runbook.

   

   O Runbook suporta o PowerShell 5.1.

   

2. Defina o registro detalhado como True para o runbook.

   

3. Execute o runbook e passe os parâmetros necessários, como AutomationAccountResourceId, UserManagedServiceIdentityClientId, etc.

   

   1. Você pode buscar AutomationAccountResourceId em Propriedades da conta>de automação.

      

   2. Você pode buscar UserManagedServiceIdentityClientId de Automation Account>Identity>User Assigned>Identity>Properties>Client ID.

      

   3. Definir EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement como TRUE permitiria a propriedade de avaliação periódica em todas as máquinas integradas ao Automation Update Management.

   4. Definir MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines como TRUE migraria todas as agendas de atualização no Automation Update Management para o Azure Update Manager e também ativaria a propriedade de avaliação periódica para True em todas as máquinas vinculadas a essas agendas.

   5. Você precisa especificar ResourceGroupForMaintenanceConfigurations onde todas as configurações de manutenção no Azure Update Manager seriam criadas. Se você fornecer um novo nome, um grupo de recursos será criado onde todas as configurações de manutenção serão criadas. No entanto, se você fornecer um nome com o qual já existe um grupo de recursos, todas as configurações de manutenção serão criadas no grupo de recursos existente.

4. Verifique os Runbook Logs do Azure para obter o status de execução e migração de SUCs.

   

Operações de runbook em back-end

A migração do runbook executa as seguintes tarefas:

• Permite a avaliação periódica em todas as máquinas.
• Todas as agendas na conta de automação são migradas para o Azure Update Manager e uma configuração de manutenção correspondente é criada para cada uma delas, com as mesmas propriedades.

Sobre o roteiro

A seguir está o comportamento do script de migração:

• Verifique se um grupo de recursos com o nome tomado como entrada já está presente na assinatura da conta de automação ou não. Caso contrário, crie um grupo de recursos com o nome especificado pelo cliente. Este grupo de recursos é usado para criar as configurações MRP para V2.

• A Configuração RebootOnly não está disponível no Azure Update Manager. As agendas com a configuração RebootOnly não são migradas.

• Filtre os SUCs que estão no estado errored/expired/provisioningFailed/disabled e marque-os como Não migrados e imprima os logs apropriados indicando que esses SUCs não foram migrados.

• O nome da atribuição de configuração é uma cadeia de caracteres que estará no formato AUMMig_AAName_SUCName

• Descubra se esse Escopo Dinâmico já está atribuído à configuração de Manutenção ou não, verificando o Azure Resource Graph. Se não for atribuído, atribua apenas com o nome da atribuição no formato AUMMig_ AAName_SUCName_SomeGUID.

• Para agendas com tarefas pré/pós configuradas, o script criará um webhook de automação para os runbooks em tarefas pré/pós e assinaturas de grade de eventos para eventos de manutenção pré/pós. Para obter mais informações, consulte como pré/pós funciona no Azure Update Manager

• Um conjunto resumido de logs é impresso no fluxo de saída para fornecer um status geral de máquinas e SUCs.

• Os logs detalhados são impressos no Fluxo Detalhado.

• Após a migração, uma Configuração de Atualização de Software pode ter qualquer um dos quatro status de migração a seguir:

  • MigraçãoFalhou
  • ParcialmenteMigrado
  • NotMigrou
  • Migrado

A tabela abaixo mostra os cenários associados a cada Status de Migração.

MigraçãoFalhou	ParcialmenteMigrado	NotMigrou	Migrado
Falha ao criar a Configuração de Manutenção para a Configuração de Atualização de Software.	Número diferente de zero de máquinas em que as configurações de patch não foram aplicadas.	Falha ao obter a configuração de atualização de software da API devido a algum erro cliente/servidor, como talvez erro de serviço interno.
	Número diferente de zero de máquinas com atribuições de configuração com falha.	A Configuração de Atualização de Software está tendo a configuração de reinicialização como somente reinicialização. Isso não é suportado atualmente no Azure Update Manager.
	Falha ao resolver um número diferente de zero de Consultas Dinâmicas que falhou ao executar a consulta no Azure Resource Graph.
	Número diferente de zero de falhas de atribuição de Configuração de Escopo Dinâmico.	A Configuração de Atualização de Software não está tendo o estado de provisionamento bem-sucedido no banco de dados.
	A Configuração de Atualização de Software está tendo Consultas de Pesquisa Salvas.	A Configuração de Atualização de Software está em estado de erro no banco de dados.
	Configuração de Atualização de Software está tendo tarefas pré/pós que não foram migradas com êxito.	A agenda associada à Configuração de Atualização de Software já expirou no momento da migração.
		A agenda associada à Configuração de Atualização de Software está desativada.
		Exceção não tratada durante a migração da configuração de atualização de software.	Zero Máquinas onde as configurações de patch não foram aplicadas. And Zero máquinas com atribuições de configuração com falha. And Zero Consultas Dinâmicas não conseguiu resolver que falhou ao executar a consulta no Azure Resource Graph. And Zero falhas de atribuição de Configuração de Escopo Dinâmico. And A Configuração de Atualização de Software tem zero Consultas de Pesquisa Salvas.

Para descobrir na tabela acima qual cenário/cenários correspondem ao motivo pelo qual a configuração de atualização de software tem um status específico, examine os logs detalhados/falhados/de aviso para obter o código de erro e a mensagem de erro.

Você também pode pesquisar com o nome da agenda de atualização para obter logs específicos para depuração.

Etapa 2: Desembarque da solução de gerenciamento de atualizações de automação

Siga estes passos:

1. Importe o runbook de migração da galeria de runbooks. Procure a atualização de automação do azure na galeria de navegação e importe o runbook de migração chamado Deboard do Azure Automation Update Management e publique o runbook.

   

   O Runbook suporta o PowerShell 5.1.

   

2. Defina o registro detalhado como true para o runbook.

   

3. Inicie o runbook e passe parâmetros como Automation AccountResourceId, UserManagedServiceIdentityClientId, etc.

   

   Você pode buscar AutomationAccountResourceId em Propriedades da conta>de automação.

   

   Você pode buscar UserManagedServiceIdentityClientId de Automation Account>Identity>User Assigned>Identity>Properties>Client ID.

   

4. Verifique os logs de runbook do Azure para obter o status de desembarque de máquinas e agendas.

   

Operações de script de desembarque no back-end

• Desative todas as agendas subjacentes para todas as configurações de atualização de software presentes nesta conta de automação. Isso é feito para garantir que o Patch-MicrosoftOMSComputers Runbook não seja acionado para SUCs que foram parcialmente migrados para a V2.
• Exclua a Solução de Atualizações do Espaço de Trabalho do Log Analytics Vinculado para a Conta de Automação que está sendo Desembarcada do Gerenciamento de Atualizações de Automação na V1.
• Um log resumido de todos os SUCs desativados e o status da solução de remoção de atualizações do espaço de trabalho de análise de log vinculado também é impresso no fluxo de saída.
• Logs detalhados são impressos nos fluxos detalhados.

Textos explicativos para o processo de migração:

• As Consultas de Pesquisa Salvas que não sejam do Azure não serão migradas.
• Os Runbooks de Migração e Desembarque precisam ter os Az.Modules atualizados para funcionar.
• O script de pré-requisito atualiza o Az.Modules para a versão mais recente 8.0.0.
• O StartTime da Agenda MRP será igual ao nextRunTime da Configuração de Atualização de Software.
• Os dados do Log Analytics não serão migrados.
• As Identidades Gerenciadas pelo Usuário não oferecem suporte a cenários entre locatários.
• A Configuração RebootOnly não está disponível no Azure Update Manager. As agendas com a configuração RebootOnly não serão migradas.
• Para Recorrência, as agendas de Automação suportam valores entre (1 a 100) para agendas Horárias/Diárias/Semanais/Mensais, enquanto a configuração de manutenção do Azure Update Manager suporta entre (6 a 35) para Horária e (1 a 35) para Diária/Semanal/Mensal.
  • Por exemplo, se o cronograma de automação tiver uma recorrência de cada 100 horas, então o cronograma de configuração de manutenção equivalente o terá para cada 100/24 = 4,16 (arredondar para o valor mais próximo) -> Quatro dias será a recorrência para a configuração de manutenção.
  • Por exemplo, se o agendamento de automação tiver uma recorrência a cada 1 hora, o agendamento de configuração de manutenção equivalente o terá a cada 6 horas.
  • Aplique a mesma convenção para Semanal e Diário.
    • Se o cronograma de automação tiver recorrência diária de digamos 100 dias, então 100/7 = 14,28 (arredondar para o valor mais próximo) -> 14 semanas será a recorrência para o cronograma de configuração de manutenção.
    • Se o cronograma de automação tiver recorrência semanal de digamos 100 semanas, então 100/4,34 = 23,04 (arredondar para o valor mais próximo) -> 23 meses será a recorrência para o cronograma de configuração de manutenção.
    • Se o cronograma de automação que deve se repetir a cada 100 semanas e tem que ser executado às sextas-feiras. Quando traduzido para configuração de manutenção, será a cada 23 meses (100/4.34). Mas não há como no Azure Update Manager dizer que é executado a cada 23 meses em todas as sextas-feiras desse mês, portanto, o cronograma não será migrado.
    • Se um cronograma de automação tiver uma recorrência de mais de 35 meses, então na configuração de manutenção ele sempre terá 35 meses de recorrência.
  • O SUC suporta entre 30 minutos a seis horas para a janela de manutenção. O MRP suporta entre 1 hora e 30 minutos a 4 horas.
    • Por exemplo, se o SUC tiver uma Janela de Manutenção de 30 Minutos, o cronograma MRP equivalente a terá por 1 hora e 30 minutos.
    • Por exemplo, se o SUC tiver uma Janela de Manutenção de 6 horas, então o cronograma MRP equivalente a terá por 4 horas.
• Quando o runbook de migração é executado várias vezes, digamos que você fez Migrar todas as agendas de automação e, em seguida, tentou novamente migrar todas as agendas, então o runbook de migração executará a mesma lógica. Fazê-lo novamente atualizará o cronograma do MRP se alguma nova alteração estiver presente no SUC. Ele não fará atribuições de configuração duplicadas. Além disso, as operações são realizadas apenas para agendas de automação que habilitaram as agendas. Se um SUC foi migrado anteriormente, ele será ignorado no próximo turno, pois sua programação subjacente será desativada.
• No final, você pode resolver mais máquinas do Azure Resource Graph como no Azure Update Manager; Você não pode verificar se o Hybrid Runbook Worker está relatando ou não, ao contrário do Automation Update Management, onde era uma interseção de Dynamic Queries e Hybrid Runbook Worker.

Orientação de migração manual

A orientação para mover várias capacidades é disponibilizada na tabela abaixo:

S.No	Capacidade	Gerenciamento de atualizações de automação	Azure Update Manager	Etapas usando o portal do Azure	Etapas usando API/script
1	Gestão de patches para máquinas fora do Azure.	Pode ser executado com ou sem conectividade ao Arc.	O Azure Arc é um pré-requisito para máquinas não Azure.	1. Criar entidade de serviço 2. Gerar script de instalação 3. Instalar o agente e conectar-se ao Azure	1. Criar um principal de serviço 2. Gerar script de instalação 3. Instalar o agente e conectar-se ao Azure
2	Ative a avaliação periódica para procurar as atualizações mais recentes automaticamente a cada poucas horas.	As máquinas recebem automaticamente as atualizações mais recentes a cada 12 horas para Windows e a cada 3 horas para Linux.	A avaliação periódica é uma definição de atualização na sua máquina. Se estiver ativada, o Update Manager obtém atualizações a cada 24 horas para a máquina e mostra o estado da atualização mais recente.	1. Máquina única 2. Na escala 3. Em escala usando a política	1. Para a VM do Azure 2.Para VM habilitada para Arc
3	Agendas estáticas de implementação de atualizações (Lista estática de máquinas para implementação de atualizações).	A Gestão de Atualizações da Automatização tinha as suas próprias agendas.	O Azure Update Manager cria um objeto de configuração de manutenção para uma agenda. Portanto, tem de criar este objeto ao copiar todas as definições da agenda da Gestão de Atualizações da Automatização para a agenda do Azure Update Manager.	1. VM única 2. Na escala 3. Em escala usando a política	Criar um âmbito estático
4	Agendas dinâmicas de implementação de atualizações (Definição do âmbito das máquinas mediante a utilização de grupos de recursos, etiquetas, etc., que é avaliado dinamicamente no runtime).	Igual às agendas estáticas de atualizações.	Igual às agendas estáticas de atualizações.	Adicionar um âmbito dinâmico	Criar um âmbito dinâmico
5	Deixe de utilizar a Gestão de Atualizações da Automatização do Azure.	Depois de concluir os passos 1, 2 e 3, tem de limpar os objetos da gestão de Atualizações do Azure.		Remover a solução de Gestão de Atualizações	ND
6	Relatórios	Relatórios de atualização personalizados mediante a utilização de consultas do Log Analytics.	Os dados de atualização são armazenados no Azure Resource Graph (ARG). Os clientes podem consultar os dados do ARG para criar dashboards personalizados, livros, etc.	É possível aceder aos dados antigos da Gestão de Automatização de Atualizações armazenados no Log Analytics, mas não há nenhuma planos para mover dados para o ARG. Pode escrever consultas do ARG para aceder a dados que serão armazenados no ARG após terem sido aplicados os patches às máquinas virtuais através do Azure Update Manager. Com as consultas ARG você pode, construir painéis e pastas de trabalho usando as seguintes instruções: 1. A estrutura de log do gráfico de Recursos do Azure atualiza os dados 2. Exemplos de consultas ARG 3. Criar pastas de trabalho	ND
7	Personalize fluxos de trabalho com pre-scripts e post-scripts.	Disponíveis como runbooks da Automatização.	Recomendamos que você experimente a visualização pública para scripts pré e pós em suas máquinas que não sejam de produção e use o recurso em cargas de trabalho de produção assim que o recurso entrar na disponibilidade geral.	Gerenciar eventos pré e pós (visualização) e Tutorial: Criar eventos pré e pós usando um webhook com automação
8	Crie alertas com base em dados de atualizações para o seu ambiente	Os alertas podem ser configurados em dados de atualizações armazenados no Log Analytics.	Recomendamos que você experimente a visualização pública para alertas em suas máquinas que não sejam de produção e use o recurso em cargas de trabalho de produção assim que o recurso entrar na disponibilidade geral.	Criar alertas (pré-visualização)

Próximos passos

• Orientação sobre como migrar VMs do Azure do Microsoft Configuration Manager para o Azure Update Manager