Migrar do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure

  • Artigo

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

Este artigo fornece diretrizes para mover máquinas virtuais do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure.

O Gerenciador de Atualizações do Azure fornece uma solução SaaS para gerenciar e controlar atualizações de software para computadores Windows e Linux em ambientes locais e multinuvem do Azure. Ele é uma evolução da solução de gerenciamento de Atualizações de Automação do Azure, com novos recursos e funcionalidades, para avaliação e implantação de atualizações de software em um computador ou em vários computadores em escala.

Para o Gerenciador de Atualizações do Azure, tanto o AMA quanto o MMA não são um requisito para o gerenciamento de fluxos de trabalho de atualização de software, uma vez que ele se baseia no Agente de VM do Microsoft Azure para as VMs do Azure e no Azure Connected Machine Agent para os servidores habilitados para o Arc. Quando você executa uma operação de atualização pela primeira vez em um computador, uma extensão é enviada por push para o computador e ela interage com os agentes para avaliar as atualizações ausentes e instalar as atualizações.

Observação

  • Se você estiver usando a Solução de Gerenciamento de Atualizações de Automação do Azure, recomendamos que você não remova agentes MMA dos computadores sem concluir a migração para o Gerenciador de Atualizações do Azure para as necessidades de gerenciamento de patch do computador. Se você remover o agente MMA do computador sem migrar para o Gerenciador de Atualizações do Azure, ele interromperá os fluxos de trabalho de aplicação de patch para esse computador.

  • Todas as funcionalidades do Gerenciamento de Atualizações de Automação do Azure estarão disponíveis no Gerenciador de Atualizações do Azure antes da data de desativação.

Experiência do portal do Azure (versão prévia)

Essa seção explica como usar a experiência do portal (versão prévia) para migrar agendamentos e computadores do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure. Com um mínimo de cliques e uma forma automatizada de migrar seus recursos, trata-se da maneira mais fácil de migrar esses recursos se você não tiver personalizações adicionais criadas na sua solução de Gerenciamento de Atualizações de Automação.

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

Selecione o botão Migrar Agora presente nos pontos de entrada a seguir. Após a seleção, você será orientado ao longo do processo de migração de seus agendamentos e computadores para o Gerenciador de Atualizações do Azure. Esse processo foi projetado para ser direto e fácil de usar, de modo a permitir que você execute a migração com o mínimo de esforço.

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

Selecione o botão Migrar Agora e uma folha de migração será aberta. Ela contém um resumo de todos os recursos, incluindo os computadores e agendamentos na conta de Automação. Por padrão, a conta de Automação a partir da qual você acessou essa folha estará pré-selecionada se você percorrer essa rota.

Captura de tela mostrando como migrar do ponto de entrada do Gerenciamento de Atualizações de Automação.

Aqui, você pode ver quantos servidores habilitados para o Azure Arc, servidores não habilitados para o Azure Arc e agendamentos estão habilitados no Gerenciamento de Atualizações de Automação e precisam ser migrados para o Gerenciador de Atualizações do Azure. Você pode ver também os detalhes desses recursos.

A folha de migração fornece uma visão geral dos recursos que serão migrados, permitindo que você reveja e confirme a migração antes de prosseguir. Quando estiver pronto, você poderá prosseguir com o processo de migração para transferir seus agendamentos e computadores para o Gerenciador de Atualizações do Azure.

Captura de tela mostrando como migrar todos os recursos da conta de Automação.

Após rever os recursos que precisam ser migrados, você pode prosseguir com o processo de migração, que é um processo em três etapas:

  1. Pré-requisitos

    Isso inclui duas etapas:

    a. Integrar computadores fora do Azure não habilitados para o Arc no Arc — porque a conectividade com o Arc é um pré-requisito para o Gerenciador de Atualizações do Azure. A integração de seus computadores no Azure Arc é gratuita e, após executá-la, você poderá se beneficiar de todos os serviços de gerenciamento que você já usa para qualquer computador do Azure. Para obter mais informações, confira a Documentação do Azure Arc sobre como integrar seus computadores.

    b. Baixe e execute o script do PowerShell localmente — 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. Esse script fornece o RBAC adequado à Identidade do Usuário na assinatura à qual a conta de automação pertence, computadores integrados ao Gerenciamento de Atualizações de Automação, escopos que fazem parte de consultas dinâmicas etc. para que a configuração possa ser atribuída aos computadores, as configurações do MRP possam ser criadas e a solução de atualizações possa ser removida. Para obter mais informações, confira a Documentação do Gerenciador de Atualizações do Azure.

    Captura de tela mostrando os pré-requisitos para a migração.

  2. Migrar recursos na conta de Automação para o Gerenciador de Atualizações do Azure

    A próxima etapa no processo de migração é permitir que o Gerenciador de Atualizações do Azure nos computadores seja migrado e crie configurações de manutenção equivalentes para que os agendamentos sejam migrados. Quando você seleciona o botão Migrar Agora, o runbook MigrateToAzureUpdateManager é importado para a sua conta de Automação e define o log detalhado como True.

    Captura de tela mostrando como migrar a carga de trabalho na sua conta de Automação.

    Selecione Iniciar runbook, que apresenta os parâmetros que precisam ser repassados para o runbook.

    Captura de tela mostrando como iniciar o runbook para permitir que os parâmetros sejam repassados para o runbook.

    Para obter mais informações sobre os parâmetros a serem buscados e o local onde devem ser buscados, confira migração de computadores e agendamentos. Assim que você iniciar o runbook após repassar todos os parâmetros, o Gerenciador de Atualizações do Azure começará a ser habilitado nos computadores e a configuração de manutenção no Gerenciador de Atualizações do Azure começará a ser criada. Você pode monitorar os logs do runbook do Azure para obter o status da execução e migração de agendamentos.

  3. Desprovisionar recursos do Gerenciamento de Atualizações de Automação

    Execute o script de limpeza para desprovisionar os computadores da solução de Gerenciamento de Atualizações de Automação e desabilitar os agendamentos do Gerenciamento de Atualizações de Automação.

    Após selecionar o botão Executar script de limpeza, o runbook DeboardFromAutomationUpdateManagement será importado para a sua conta de Automação e seu registro em log detalhado será definido como True.

    Captura de tela mostrando como executar a fase pós-migração.

    Quando você seleciona Iniciar o runbook, há uma solicitação dos parâmetros que devem ser repassados a ele. Para obter mais informações, confira Desprovisionar a solução de Gerenciamento de Atualizações de Automação para buscar os parâmetros a serem repassados para o runbook.

    Captura de tela mostrando como desprovisionar o Gerenciamento de Atualizações de Automação e iniciar o runbook.

Scripts de migração (versão prévia)

Usando runbooks de migração, você pode migrar automaticamente todas as cargas de trabalho (computadores e agendas) do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure. 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 todos os computadores e agendamentos em uma conta de automação de uma só vez. Se você tiver várias contas de automação, deverá executar o runbook para todas as contas de automação.

Em um alto nível, você precisa seguir as etapas abaixo para migrar seus computadores e agendamentos do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure.

Resumo dos pré-requisitos

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

Resumo de etapas

  1. Execute o runbook de migração para mover computadores e agendamentos do Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure. Consulte as instruções detalhadas no guia passo a passo.
  2. Execute scripts de limpeza para retirar do Gerenciamento de Atualizações de Automação. Consulte as instruções detalhadas no guia passo a passo.

Cenários sem suporte

  • Os agendamentos de atualização com pré/pós tarefas não serão migrados por enquanto.
  • Consultas de Pesquisa Não Salvas do Azure não serão migradas; elas precisam ser migradas manualmente.

Para obter a lista completa de limitações e itens a serem observados, 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: integrar computadores que não são do Azure ao Arc

O que fazer

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

Pré-requisito 2: criar atribuições de função e identidade do usuário executando o script do PowerShell

R. Pré-requisitos para executar o script

  • Execute o comando Install-Module -Name Az -Repository PSGallery -Force no PowerShell. O script de pré-requisito depende do Az.Modules. Essa etapa será necessária se o Az.Modules não estiver presente ou atualizado.
  • Para executar esse script de pré-requisito, você precisa ter permissões Microsoft.Authorization/roleAssignments/write em todas as assinaturas que contêm recursos de Gerenciamento de Atualizações de Automação, como computadores, agendamentos, workspace do Log Analytics e conta de automação. Confira como atribuir uma função do Azure.
  • Você precisa ter as permissões de Gerenciamento de Atualizações.

Captura de tela mostrando como executar o comando para instalar o módulo.

B. Executar o script

Baixe e execute o script MigrationPrerequisiteScript do PowerShell localmente. Esse script usa AutomationAccountResourceId da conta de Automação para ser migrado como a entrada.

Captura de tela mostrando como baixar e executar o script.

Você pode buscar AutomationAccountResourceId acessando Conta de Automação>Propriedades.

Captura de tela mostrando como buscar a ID do recurso.

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>Atribuída pelo usuário.

Captura de tela mostrando como verificar se uma identidade gerenciada pelo usuário foi criada.

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

  1. Atualizando o Az.Modules para a conta de Automação, que será necessária para executar scripts de migração e retirada

  2. Criação da Identidade do Usuário na mesma assinatura e grupo de recursos que a Conta de Automação. O nome da Identidade do Usuário será como AutomationAccount_aummig_umsi.

  3. Anexando a Identidade do Usuário à Conta de Automação.

  4. O script atribui as seguintes permissões à identidade gerenciada pelo usuário: permissões de Gerenciamento de Atualizações necessárias.

    1. Para isso, o script buscará todos os computadores integrados ao Gerenciamento de Atualizações de Automação nessa conta de automação e analisará as respectivas IDs de assinatura que deverão receber o RBAC necessário para a Identidade do Usuário.
    2. O script fornece um RBAC adequado para a 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 atribuirá as funções necessárias para a solução e o workspace do Log Analytics.

Etapa 1: Migração de computadores e agendamentos

Essa etapa envolve o uso de um runbook de automação para migrar todos os computadores e agendas de uma conta de automação para o Gerenciador de Atualizações do Azure.

Siga estas etapas:

  1. Importe o runbook de migração da galeria de runbooks e publique-o. Pesquise atualização de automação do Azure na galeria de navegação e importe o runbook de migração chamado Migrar do Gerenciamento de Atualizações de Automação do Azure para o Azure Update Manager e publique o runbook.

    Captura de tela mostrando como migrar do Gerenciamento de Atualizações de Automação.

    O Runbook dá suporte ao PowerShell 5.1.

    Captura de tela mostrando como o runbook dá suporte ao PowerShell 5.1 durante a importação.

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

    Captura de tela mostrando como definir registros de log detalhados.

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

    Captura de tela mostrando como executar o runbook e repassar os parâmetros necessários.

    1. Você pode buscar AutomationAccountResourceId acessando Conta de Automação>Propriedades.

      Captura de tela mostrando como buscar a ID do recurso da conta de Automação.

    2. Você pode buscar UserManagedServiceIdentityClientId de Conta de Automação>Identidade>Atribuído pelo Usuário>Identidade>Propriedades>ID do cliente.

      Captura de tela mostrando como buscar a ID do cliente.

    3. Definir EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement para TRUE habilitaria a propriedade de avaliação periódica em todos os computadores integrados ao Gerenciamento de Atualizações de Automação.

    4. Definir MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines para TRUE migraria todos os agendamentos de atualização no Gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure e também ativaria a propriedade de avaliação periódica para True em todos os computadores vinculados a esses agendamentos.

    5. Você precisa especificar ResourceGroupForMaintenanceConfigurations, em que todas as configurações de manutenção no Gerenciador de Atualizações do Azure seriam criadas. Se você fornecer um novo nome, um grupo de recursos será criado onde todas as configurações de manutenção seriam 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 Logs de Runbook do Azure quanto ao status de execução e de migração dos SUCs.

    Captura de tela mostrando os logs do runbook.

Operações do runbook no back-end

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

  • Habilita a avaliação periódica em todos os computadores.
  • Todos os agendamentos na conta de automação são migrados para o Gerenciador de Atualizações do Azure e uma configuração de manutenção correspondente é criada para cada um deles, tendo as mesmas propriedades.

Sobre o script

O seguinte é o comportamento do script de migração:

  • Verifique se um grupo de recursos com o nome usado 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 Cx. Esse grupo de recursos será usado para criar as configurações do MRP para a V2.

  • O script ignora os agendamentos de atualização que têm pré e pós-scripts associados a eles. Para agendamentos de atualização de pré e pós-scripts, migre-os manualmente.

  • A configuração RebootOnly não está disponível no Gerenciador de Atualizações do Azure. Os agendamentos com a configuração RebootOnly não são migrados.

  • Filtre os SUCs que estão no estado com erro/expirado/provisioningFailed/desabilitado, 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á ou não atribuído à configuração de Manutenção, verificando no Azure Resource Graph. Se não estiver atribuído, atribua apenas com o nome da atribuição no formato AUMMig_ AAName_SUCName_SomeGUID.

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

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

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

    • MigrationFailed
    • PartiallyMigrated
    • NotMigrated
    • Migrado

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

MigrationFailed PartiallyMigrated NotMigrated 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 computadores 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 de cliente/servidor, como talvez erro de serviço interno.
Número diferente de zero de computadores com atribuições de configuração com falha. A Configuração de Atualização de Software está tendo a configuração de reinicialização apenas como reinicialização. Não há suporte para isso atualmente no Gerenciador de Atualizações do Azure.
Falha na resolução do número diferente de zero de consultas dinâmicas que falharam ao executar a consulta no Azure Resource Graph. A Configuração de Atualização de Software está tendo pré/pós-tarefas. Atualmente, pré/pós em versão prévia no Gerenciador de Atualizações do Azure e esses agendamentos não serão migrados.
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 BD.
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 BD.
O agendamento associado à Configuração de Atualização de Software já expirou no momento da migração.
O agendamento associado à Configuração de Atualização de Software está desabilitado.
Exceção sem tratamento durante a migração da configuração de atualização de software. Zero computadores em que as Configurações de Patch não foram aplicadas.

And

Zero computadores com atribuições de configuração com falha.

And

Falha na resolução de zero de consultas dinâmicas que falharam ao executar a consulta no Azure Resource Graph.

And

Zero de 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 quais cenários/cenário correspondem ao motivo pelo qual a configuração de atualização de software tem um status específico, examine os logs detalhados/com falha/aviso para obter o código de erro e a mensagem de erro.

Você também pode pesquisar com o nome do agendamento de atualização para obter logs específicos a ele para depuração.

Captura de tela mostrando como ver logs específicos para depuração.

Etapa 2: Retirada da solução Gerenciamento de Atualizações de Automação

Siga estas etapas:

  1. Importe o runbook de migração da galeria de runbooks. Pesquise por atualização de automação do Azure na galeria de navegação e importe o runbook de migração chamado Retirar do Gerenciamento de Atualizações de Automação do Azure e publique o runbook.

    Captura de tela mostrando como importar o runbook de migração para o desprovisionamento.

    O Runbook dá suporte ao PowerShell 5.1.

    Captura de tela mostrando que o runbook dá suporte ao PowerShell 5.1 durante o desprovisionamento.

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

    Captura de tela mostrando a configuração de registros de log detalhados durante o desprovisionamento.

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

    Captura de tela mostrando como iniciar o runbook e repassar parâmetros durante o desprovisionamento.

    Você pode buscar AutomationAccountResourceId acessando Conta de Automação>Propriedades.

    Captura de tela mostrando como buscar a ID do recurso durante o desprovisionamento.

    Você pode buscar UserManagedServiceIdentityClientId de Conta de Automação>Identidade>Atribuído pelo Usuário>Identidade>Propriedades>ID do cliente.

    Captura de tela mostrando como buscar a ID do cliente durante o desprovisionamento.

  4. Verifique os logs de runbook do Azure para obter o status de retirada de computadores e agendamentos.

    Captura de tela mostrando como o runbook é logs durante o desprovisionamento.

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

  • Desabilite todos os agendamentos subjacentes para todas as configurações de atualização de software presentes nesta conta de Automação. Isso é feito para garantir que o Runbook Patch-MicrosoftOMSComputers não seja disparado para SUCs que foram parcialmente migrados para V2.
  • Exclua a solução de atualizações do workspace do Log Analytics vinculado para a conta de automação que está sendo retirada do Gerenciamento de Atualizações de Automação na V1.
  • Um log resumido de todos os SUCs desabilitados e o status da remoção da solução de atualizações do workspace vinculado do Log Analytics também são impressos no fluxo de saída.
  • Logs detalhados são impressos nos fluxos detalhados.

Textos explicativos sobre o processo de migração:

  • Os agendamentos com pré/pós tarefas não serão migrados por enquanto.
  • Consultas de pesquisa não salvas do Azure não serão migradas.
  • Os Runbooks de Migração e Retirada precisam ter o Az.Modules atualizado para funcionar.
  • O script de pré-requisito atualiza o Az.Modules para a versão mais recente, 8.0.0.
  • O StartTime do Agendamento MRP será igual ao nextRunTime da Configuração de Atualização de Software.
  • Os dados do Log Analytics não serão migrados.
  • Identidades gerenciadas não dão suporte a cenários entre locatários.
  • A configuração RebootOnly não está disponível no Gerenciador de Atualizações do Azure. Os agendamentos com a configuração RebootOnly não serão migrados.
  • Para Recorrência, os agendamentos de Automação dão suporte a valores entre (1 a 100) para agendamentos por hora/diária/semanal/mensal, enquanto a configuração de manutenção do Gerenciador de Atualizações do Azure dá suporte entre (6 a 35) para horários por hora e (1 a 35) para Diário/Semanal/Mensal.
    • Por exemplo, se o agendamento da automação tiver uma recorrência a cada 100 horas, o agendamento da configuração de manutenção equivalente terá uma recorrência a cada 100/24 = 4,16 (arredondando 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 agendamento de automação tiver recorrência diária de 100 dias, 100/7 = 14,28 (arredondado para o valor mais próximo) –> 14 semanas será a recorrência para o agendamento de configuração de manutenção.
      • Se o agendamento de automação tiver recorrência semanal de 100 semanas, 100/4.34 = 23,04 (arredondado para o valor mais próximo) –> 23 meses será a recorrência para o agendamento de configuração de manutenção.
      • Se o agendamento de automação deve ocorrer novamente a cada 100 semanas e tem que ser executado às sextas-feiras. Quando convertido em configuração de manutenção, será a cada 23 meses (100/4,34). Mas não há maneira de dizer, no Gerenciador de Atualizações do Azure, que a execução deve ocorrer a cada 23 meses em todas as sextas-feiras desse mês, portanto, a agenda não será migrada.
      • Se um agendamento de automação tiver uma recorrência de mais de 35 meses, na configuração de manutenção, ele sempre terá recorrência de 35 meses.
    • O SUC dá suporte a uma janela de manutenção entre 30 minutos e seis horas. O MRP dá suporte entre uma hora e 30 minutos e quatro horas.
      • Por exemplo, se o SUC tiver uma janela de manutenção de 30 minutos, o agendamento equivalente do MRP terá uma janela de manutenção de uma hora e 30 minutos.
      • Por exemplo, se o SUC tiver uma janela de manutenção de seis horas, o agendamento equivalente do MRP terá uma janela de manutenção de quatro horas.
  • Quando o runbook de migração é executado várias vezes, digamos que você tenha migrado todos os agendamentos de automação, depois tentado novamente migrar todos os agendamentos; se for assim, o runbook de migração executará a mesma lógica. Fazer isso novamente atualizará o agendamento MRP se qualquer nova alteração estiver presente no SUC. No entanto, esse procedimento não fará atribuições de configuração duplicadas. Além disso, as operações são realizadas apenas para agendamentos de automação com agendas habilitadas. Se um SUC tiver sido migrado anteriormente, ele será ignorado na próxima vez, pois o agendamento subjacente dele será Desabilitado.
  • No final, você pode resolver mais computadores do Azure Resource Graph que no Azure Update Manager; você não pode verificar se o Hybrid Runbook Worker está relatando ou não, ao contrário do Gerenciamento de Atualizações de Automação, em que ele era uma interseção entre as Consultas Dinâmicas e o Hybrid Runbook Worker.

Diretrizes de migração manual

As diretrizes para mover várias funcionalidades são fornecidas na tabela abaixo:

N. de série Recurso Gerenciamento de Atualizações da Automação do Azure Gerenciador de Atualizações do Azure Etapas usando o portal do Azure Etapas usando API/script
1 Gerenciamento de patch para computadores fora do Azure. Pode ser executado com ou sem conectividade Arc. O Azure Arc é um pré-requisito para computadores que não são do Azure. 1. Criar entidade de serviço
2. Gerar o script de instalação
3. Instalar o agente e conectar-se ao Azure		 1. Criar entidade de serviço
2. Gerar o script de instalação
3. Instalar o agente e conectar-se ao Azure
2 Habilite a avaliação periódica para verificar se há atualizações mais recentes automaticamente a cada poucas horas. Os computadores recebem automaticamente as atualizações mais recentes a cada 12 horas para Windows e a cada três horas para Linux. A avaliação periódica é uma configuração de atualização em seu computador. Se estiver ativado, o Gerenciador de Atualizações buscará atualizações a cada 24 horas para o computador e mostrará o status de atualização mais recente. 1. Apenas um computador
2. Em escala
3. Em escala usando política		 1. Para VM do Azure
2.Para VM habilitada para Arc
3 Agendamentos de implantação de Atualização Estática (lista estática de computadores para implantação de atualização). O Gerenciamento de Atualizações de Automação tinha agendamentos próprios. O Gerenciador de Atualizações do Azure cria um objeto de configuração de manutenção para um agendamento. Portanto, você precisa criar esse objeto, copiando todas as configurações de agendamento do Gerenciamento de Atualizações de Automação para o agendamento do Gerenciador de Atualizações do Azure. 1. Apenas uma VM
2. Em escala
3. Em escala usando política		 Criar um escopo estático
4 Agendamentos de implantação de Atualização Dinâmica (definindo o escopo de computadores usando grupo de recursos, marcas etc. que são avaliados dinamicamente em runtime). O mesmo que agendamentos de atualização estática. O mesmo que agendamentos de atualização estática. Adicionar um escopo dinâmico Criar um escopo dinâmico
5 Retire do Gerenciamento de Atualizações da Automação do Azure. Depois de concluir as etapas 1, 2 e 3, você precisará limpar objetos do Gerenciamento de Atualizações do Azure. Remover a Solução de Gerenciamento de Atualizações
 NA
6 Reporting Configurar relatórios de atualização usando consultas do Log Analytics. Os registros de conformidade são armazenados no ARG (Azure Resource Graph). Os clientes podem consultar dados do ARG para criar painéis personalizados, pastas de trabalho etc. Os dados antigos do Gerenciamento de Atualizações de Automação armazenados no Log Analytics podem ser acessados, mas não há nenhum provisionamento para mover dados para o ARG. Você pode escrever consultas ARG para acessar dados que serão armazenados no ARG depois que as máquinas virtuais forem corrigidas por meio do Gerenciador de Atualizações do Azure. Com as consultas ARG, você pode criar painéis e pastas de trabalho usando as seguintes instruções:
1. Estrutura de log do Azure Resource Graph atualiza os dados
2. Consultas de exemplo do ARG
3. Criar pastas de trabalho		 NA
7 Personalize fluxos de trabalho usando pré e pós-scripts. Disponível como runbooks de Automação. Recomendamos que você experimente a Visualização Pública para pré e pós-scripts em seus computadores que não são de produção e use o recurso em cargas de trabalho de produção depois que o recurso entrar em Disponibilidade Geral. Gerenciar pré e pós-eventos (versão prévia)
8 Criar alertas com base em dados de atualizações para seu ambiente Os alertas podem ser configurados em atualizações de dados armazenados no Log Analytics. Recomendamos que você experimente a Visualização Pública para alertas em seus computadores que não são de produção e use o recurso em cargas de trabalho de produção depois que o recurso entrar em Disponibilidade Geral. Criar alertas (versão prévia)

Próximas etapas