Traslado de Update Management de Automation a Administrador de actualizaciones de Azure

Se aplica a: ✔️ VM de Windows ✔️ VM de Linux ✔️ Entorno local ✔️ Servidores habilitados para Azure Arc

En este artículo se proporcionan instrucciones para trasladar máquinas virtuales de Automation Update Management a Azure Update Manager.

Azure Update Manager proporciona una solución SaaS para administrar y controlar las actualizaciones de software en máquinas Windows y Linux en entornos locales y multinube de Azure. Es una evolución de la solución de Azure Automation Update Management con nuevas características y funcionalidades, para la evaluación e implementación de actualizaciones de software en una sola máquina o en varias máquinas a escala.

Para Administración de actualizaciones de Azure, AMA y MMA no son un requisito a fin de administrar flujos de trabajo de actualización de software, ya que se basa en el agente de máquina virtual de Microsoft Azure para máquinas virtuales de Azure y el agente de Azure Connected Machine para servidores habilitados para Arc. Cuando se realiza una operación de actualización por primera vez en una máquina, se inserta una extensión en la máquina e interactúa con los agentes para evaluar las actualizaciones que faltan e instalar las actualizaciones.

Nota:

• Si usa la solución Update Management de Azure Automation, se recomienda no quitar agentes MMA de las máquinas sin completar la migración a Azure Update Manager para las necesidades de administración de revisiones de la máquina. Si elimina el agente de MMA de la máquina sin pasar a Azure Update Manager, se interrumpirían los flujos de trabajo de revisión para esa máquina.

• Todas las funcionalidades de Azure Automation Update Management estarán disponibles en Azure Update Manager antes de la fecha de su retirada.

Experiencia de Azure Portal (versión preliminar)

En esta sección se explica cómo usar la experiencia del portal (versión preliminar) para mover programaciones y máquinas de Update Management de Automation a Administrador de actualizaciones de Azure. Con un mínimo de clics y una forma automatizada de mover sus recursos, es la forma más fácil de mover si no tiene personalizaciones basadas en su solución Update Management de Automation.

Para acceder a la experiencia de migración del portal, puede usar varios puntos de entrada.

Seleccione el botón Migrar ahora presente en los siguientes puntos de entrada. Después de la selección, se le guiará a través del proceso de traslado de las programaciones y máquinas a Administrador de actualizaciones de Azure. Este proceso está diseñado para que sea fácil de usar y sencillo, para que pueda completar la migración con el mínimo esfuerzo.

Puede migrar desde cualquiera de los siguientes puntos de entrada:

Automation Update Management

Seleccione el botón Migrar ahora y se abrirá una hoja de migración. Contiene un resumen de todos los recursos, incluidas las máquinas, y las programaciones de la cuenta de Automation. De forma predeterminada, la cuenta de Automation desde la que accedió a esta hoja está preseleccionada si opta por esta ruta.

Aquí puede ver cuántos servidores Azure con Arc, servidores sin Azure sin Arc y programaciones están habilitados en Update Management de Automation y deben moverse a Administrador de actualizaciones de Azure. También puede ver los detalles de estos recursos.

La hoja de migración proporciona información general sobre los recursos que se moverán, lo que le permite revisar y confirmar la migración antes de continuar. Una vez que esté listo, puede continuar con el proceso de migración para mover las programaciones y las máquinas a Administrador de actualizaciones de Azure.

Después de revisar los recursos que se deben mover, puede continuar con el proceso de migración, que es un proceso de tres pasos:

1. Requisitos previos

   Esto incluye dos pasos:

   a. Incorporar máquinas no habilitadas para Azure a Arc: esto se debe a que la conectividad Arc es un requisito previo para Administrador de actualizaciones de Azure. La incorporación de las máquinas a Azure Arc es gratuita y, una vez que la ejecute, podrá disponer de todos los servicios de administración como puede hacer con cualquier máquina de Azure. Para obtener más información, consulte la documentación de Azure Arc sobre cómo incorporar las máquinas.

   b. Descargar y ejecutar el script de PowerShell localmente: esto es necesario para crear una identidad de usuario y asignar roles adecuados para que se pueda realizar la migración. Este script proporciona el RBAC adecuado a la identidad del usuario en la suscripción a la que pertenece la cuenta Automation, las máquinas incorporadas a Update Management de Automation, los ámbitos que forman parte de las consultas dinámicas, etc. para que la configuración se pueda asignar a las máquinas, se puedan crear configuraciones MRP y se pueda quitar la solución de actualizaciones. Para obtener más información, consulte la documentación de Administrador de actualizaciones de Azure.

   

2. Traslado de recursos de la cuenta de Automation a Administrador de actualizaciones de Azure

   El siguiente paso del proceso de migración es habilitar Administrador de actualizaciones de Azure en las máquinas que se van a mover y crear configuraciones de mantenimiento equivalentes para las programaciones que se van a migrar. Al seleccionar el botón Migrar ahora, importa el runbook MigrateToAzureUpdateManager en la cuenta de Automation y establece el registro detallado en True.

   

   Seleccione Iniciar runbook, que presenta los parámetros que se deben pasar al runbook.

   

   Para obtener más información sobre los parámetros que se deben recuperar y la ubicación desde la que se deben recuperar, consulte Migración de máquinas y programaciones. Una vez que inicie el runbook después de pasar todos los parámetros, el Administrador de actualizaciones de Azure comenzará a habilitarse en las máquinas y la configuración de mantenimiento en el Administrador de actualizaciones de Azure empezará a crearse. Puede supervisar los registros de runbook de Azure para conocer el estado de ejecución y migración de programaciones.

3. Suprimir recursos de Update Management de Automation

   Ejecute el script de limpieza para suprimir las máquinas desde la solución Administración de actualizaciones y deshabilitar las programaciones de Update Management de Automation.

   Después de seleccionar el botón Ejecutar script de limpieza, el runbook DeboardFromAutomationUpdateManagement se importará a su cuenta de Automation y su registro detallado se establecerá en True.

   

   Al seleccionar Iniciar runbook, solicita que se pasen parámetros al runbook. Para obtener más información, consulte Suprimir la solución Update Management de Automation para capturar los parámetros que se van a pasar al runbook.

   

Azure Update Manager

Puede iniciar la migración desde Administrador de actualizaciones de Azure. En la parte superior de la pantalla, puede ver un banner de desuso con un botón Migrar ahora en la parte superior de la pantalla.

Seleccione el botón Migrar ahora para ver la hoja de migración que le permite seleccionar la cuenta de Automation cuyos recursos desea mover de Update Management de Automation a Administrador de actualizaciones de Azure. Debe seleccionar la suscripción, el grupo de recursos y, por último, el nombre de la cuenta de Automation. Después de seleccionar, verá el resumen de las máquinas y programaciones que se van a migrar a Administrador de actualizaciones de Azure. A partir de aquí, siga los pasos de migración que se enumeran en Update Management de Automation.

Máquina virtual

Para iniciar la migración a partir de la vista Actualizaciones de una única máquina virtual, siga estos pasos:

1. Seleccione la máquina que está habilitada para Update Management de Automation y, en Operaciones, seleccione Actualizaciones.

2. En el banner de desuso, seleccione el botón Migrar ahora.

   

   Puede ver que la cuenta de Automation a la que pertenece la máquina está preseleccionada y se presenta un resumen de todos los recursos de la cuenta de Automation. Esto le permite migrar los recursos de Update Management de Automation a Administrador de actualizaciones de Azure.

   

   A partir de aquí, siga los pasos de migración que se enumeran en Update Management de Automation.

   Para obtener más información sobre cómo se ejecutan los scripts en el back-end y su comportamiento, consulte Scripts de migración (versión preliminar).

Scripts de migración (versión preliminar)

Con los runbooks de migración, puede migrar automáticamente todas las cargas de trabajo (máquinas y programaciones) de Automation Update Management a Azure Update Manager. En esta sección se detalla cómo ejecutar el script, qué hace el script en el back-end, el comportamiento esperado y las limitaciones, si procede. El script puede migrar todas las máquinas y programaciones de una cuenta de Automation en una sola vez. Si tiene varias cuentas de Automation, debe ejecutar el runbook para todas las cuentas de Automation.

En un nivel alto, debe seguir los pasos siguientes para migrar las máquinas y programaciones de Automation Update Management a Azure Update Manager.

Resumen de requisitos previos

1. Incorporar máquinas que no son de Azure en Azure Arc.
2. Descargue y ejecute el script de PowerShell para la creación de asignaciones de roles e identidad de usuario localmente en el sistema. Consulte instrucciones detalladas en la guía paso a paso, ya que también tiene ciertos requisitos previos.

Resumen de pasos

1. Ejecute La migración de automatización de runbook para migrar máquinas y programaciones de Automation Update Management a Azure Update Manager. Consulte instrucciones detalladas en la guía paso a paso.
2. Ejecute scripts de limpieza para salir de Automation Update Management. Consulte instrucciones detalladas en la guía paso a paso.

Escenarios no admitidos

• Los calendarios de actualización que tengan tareas anteriores o posteriores no se migrarán por ahora.
• Las consultas de búsqueda guardadas que no sean de Azure no se migrarán; deberán migrarse manualmente.

Para obtener la lista completa de limitaciones y aspectos que se deben tener en cuenta, consulte la última sección de este artículo.

Guía paso a paso

La información mencionada en cada uno de los pasos anteriores se explica en detalle a continuación.

Requisito previo 1: Incorporación de máquinas que no son de Azure a Arc

Qué hacer

La migración de automatización de runbook ignora los recursos que no están incorporados a Arc. Por lo tanto, es un requisito previo incorporar todas las máquinas que no son de Azure en Azure Arc antes de ejecutar el runbook de migración. Siga los pasos para incorporar máquinas en Azure Arc.

Requisito previo 2: Creación de asignaciones de roles e identidad de usuario mediante la ejecución del script de PowerShell

A Requisitos previos para ejecutar el script

• Ejecute el comando Install-Module -Name Az -Repository PSGallery -Force en PowerShell. El script de requisitos previos depende de Az.Modules. Este paso es necesario si Az.Modules no está presente o actualizado.
• Para ejecutar este script de requisitos previos, debe tener permisos de Microsoft.Authorization/roleAssignments/write en todas las suscripciones que contienen recursos de Automation Update Management, como máquinas, programaciones, área de trabajo de Log Analytics y cuenta de Automation. Consulte cómo asignar un rol de Azure.
• Debe tener los permisos de Update Management.

B. Ejecución del script

Descargue y ejecute el script de PowerShell MigrationPrerequisiteScript localmente. Este script toma AutomationAccountResourceId de la cuenta de Automation que se va a migrar como entrada.

Puede capturar AutomationAccountResourceId si va a Cuenta de Automation>Propiedades.

C. Verify

Después de ejecutar el script, compruebe que se crea una identidad administrada por el usuario en la cuenta de Automation. cuenta de Automation>Identidad>usuario asignado.

D. Operaciones de back-end por el script

1. Actualización de Az.Modules para la cuenta de Automation, que será necesaria para ejecutar los scripts de migración y retirada

2. Creación de identidad de usuario en la misma suscripción y grupo de recursos que la cuenta de Automation. El nombre de identidad de usuario será como AutomationAccount_aummig_umsi.

3. Adjuntar la identidad de usuario a la cuenta de Automation.

4. El script asigna los permisos siguientes a la identidad administrada por el usuario, se requieren:permisos de Update Management.

   1. Para ello, el script captura todas las máquinas incorporadas a Update Management de Automation en esta cuenta de Automation y analizará sus identificadores de suscripción para asignar el RBAC necesario a la identidad de usuario.
   2. El script proporciona un RBAC adecuado a la identidad de usuario de la suscripción a la que pertenece la cuenta de Automation para que las configuraciones de MRP se puedan crear aquí.
   3. El script asigna los roles necesarios para el área de trabajo y la solución de Log Analytics.

Paso 1: Migración de máquinas y programaciones

Este paso implica el uso de un runbook de automatización para migrar todas las máquinas y programaciones de una cuenta de Automation a Azure Update Manager.

Siga estos pasos:

1. Importe runbook de migración desde la galería de runbooks y publique. Busque actualización de Azure Automation desde la galería de exploración e importe el runbook de migración denominado Migrate from Azure Automation Update Management to Azure Update Manager y publique el runbook.

   

   Runbook admite PowerShell 5.1.

   

2. Establezca Registro detallado en True para el runbook.

   

3. Ejecute el runbook y pase los parámetros necesarios, como AutomationAccountResourceId, UserManagedServiceIdentityClientId, etc.

   

   1. Puede capturar AutomationAccountResourceId desde Cuenta de Automation>Propiedades.

      

   2. Puede capturar UserManagedServiceIdentityClientId desde Cuenta de Automation>Identidad>asignada por el usuario>Identidad>Propiedades>id. de cliente.

      

   3. Establecer EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement en TRUE habilitaría la propiedad de evaluación periódica en todas las máquinas incorporadas a Automation Update Management.

   4. Establecer MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines en TRUE migraría todas las programaciones de actualización de Automation Update Management a Azure Update Manager y también activaría la propiedad de evaluación periódica en True en todas las máquinas vinculadas a estas programaciones.

   5. Debe especificar ResourceGroupForMaintenanceConfigurations donde se crearían todas las configuraciones de mantenimiento en Azure Update Manager. Si proporciona un nuevo nombre, se creará un grupo de recursos donde se crearían todas las configuraciones de mantenimiento. Sin embargo, si proporciona un nombre con el que ya existe un grupo de recursos, todas las configuraciones de mantenimiento se crearían en el grupo de recursos existente.

4. Compruebe los registros de Runbook de Azure para conocer el estado de ejecución y migración de los SUC.

   

Operaciones de runbook en back-end

La migración del runbook realiza las siguientes tareas:

• Habilita la evaluación periódica en todas las máquinas.
• Todas las programaciones de la cuenta de Automation se migran a Azure Update Manager y se crea una configuración de mantenimiento correspondiente para cada una de ellas, con las mismas propiedades.

Acerca del script

A continuación se muestra el comportamiento del script de migración:

• Compruebe si un grupo de recursos con el nombre tomado como entrada ya está presente en la suscripción de la cuenta de Automation o no. Si no es así, cree un grupo de recursos con el nombre especificado por el Cx. Este grupo de recursos se usa para crear las configuraciones de MRP para V2.

• El script ignora las programaciones de actualización que tienen asociadas scripts previos y posteriores. En el caso de las programaciones de actualización previas y posteriores a los scripts, migrelas manualmente.

• La configuración RebootOnly no está disponible en Azure Update Manager. Las programaciones que tienen la configuración RebootOnly no se migran.

• Filtre los SUC que se encuentran en el estado errored/expired/provisioningFailed/disabled y márquelos como No migradoe imprima los registros adecuados que indican que dichos SUC no se migran.

• El nombre de la asignación de configuración es una cadena que estará en el formato AUMMig_AAName_SUCName

• Compruebe si este Ámbito dinámico ya está asignado a la configuración de mantenimiento o no consultando Azure Resource Graph. Si no está asignado, asigne solo con nombre de asignación en el formato AUMMig_ AAName_SUCName_SomeGUID.

• Se imprime un conjunto resumido de registros en el flujo de salida para proporcionar un estado general de las máquinas y los SUC.

• Los registros detallados se imprimen en el flujo detallado.

• Después de la migración, una configuración de actualización de software puede tener cualquiera de los cuatro estados de migración siguientes:

  • MigrationFailed
  • PartiallyMigrated
  • NotMigrated
  • Migrated

En la tabla siguiente se muestran los escenarios asociados a cada estado de migración.

MigrationFailed	PartiallyMigrated	NotMigrated	Migrated
No se pudo crear la configuración de mantenimiento para la configuración de actualización de software.	Número distinto de cero de máquinas en las que no se pudo aplicar la configuración de revisión.	No se pudo obtener la configuración de actualización de software de la API debido a algún error de cliente o servidor, como tal vez error interno del servicio.
	Número distinto de cero de máquinas con asignaciones de configuración con errores.	La configuración de actualización de software tiene el valor de reinicio solo como reinicio. Esto no se admite actualmente en Azure Update Manager.
	Número no nulo de consultas dinámicas no resueltas, es decir, no se ha podido ejecutar la consulta en Azure Resource Graph.	La configuración de actualización de software tiene tareas previas y posteriores. Actualmente, no se migrarán las programaciones previas y posteriores en la versión preliminar de Azure Update Manager.
	Número distinto de cero de errores de asignación de configuración de ámbito dinámico.	La configuración de actualización de software no tiene el estado de aprovisionamiento correcto en la base de datos.
	La configuración de actualización de software tiene consultas de búsqueda guardadas.	La configuración de actualización de software está en estado de error en la base de datos.
		La programación asociada a la configuración de actualización de software ya ha expirado en el momento de la migración.
		La programación asociada a la configuración de actualización de software está deshabilitada.
		Excepción no controlada durante la migración de la configuración de actualización de software.	Cero máquinas en las que no se pudo aplicar la configuración de revisión. Y Cero máquinas con asignaciones de configuración con errores. Y No se pudo resolver ninguna consulta dinámica que no pudo ejecutar la consulta en Azure Resource Graph. Y Cero errores de asignación de la configuración de ámbito dinámico. Y La configuración de actualización de software tiene cero consultas de búsqueda guardadas.

Para averiguar en la tabla anterior qué escenario o escenarios corresponden al motivo por el que la configuración de la actualización del software tiene un estado específico, consulte los registros detallados con errores o advertencias para obtener el código de error y el mensaje de error.

También puede buscar con el nombre de la programación de actualizaciones para obtener registros específicos para la depuración.

Paso 2: retirada de la solución Automation Update Management

Siga estos pasos:

1. Importe el runbook de migración desde la galería de runbooks. Busque actualización de Azure Automation desde la galería de exploración e importe el runbook de migración denominado Deboard from Azure Automation Update Management to Azure Update Manager y publique el runbook.

   

   Runbook admite PowerShell 5.1.

   

2. Establezca Registro detallado en True para el Runbook.

   

3. Inicie el runbook y pase parámetros como AccountResourceId de Automation, UserManagedServiceIdentityClientId, etc.

   

   Puede capturar AutomationAccountResourceId desde Cuenta de Automation>Propiedades.

   

   Puede capturar UserManagedServiceIdentityClientId desde Cuenta de Automation>Identidad>asignada por el usuario>Identidad>Propiedades>id. de cliente.

   

4. Compruebe los registros de runbook de Azure para ver el estado de retirada de máquinas y programaciones.

   

Operaciones de script de retirada en el back-end

• Deshabilite todas las programaciones subyacentes para todas las configuraciones de actualización de software presentes en esta cuenta de Automation. Esto se hace para asegurarse de que Patch-MicrosoftOMSComputers Runbook no se desencadene para los SUC que se migraron parcialmente a V2.
• Elimine la solución Actualizaciones del área de trabajo de Log Analytics vinculada para la cuenta de Automation que se va a retirar de Automation Update Management en V1.
• También se imprime en el flujo de salida un registro resumido de todos los SUC deshabilitados y el estado de la eliminación de la solución de actualizaciones del área de trabajo de Log Analytics vinculada.
• Los registros detallados se imprimen en los flujos detallados.

Llamadas para el proceso de migración:

• Las programaciones que tienen tareas previas y posteriores no se migrarán por ahora.
• Las consultas de búsqueda guardadas que no son de Azure no se migrarán.
• Los runbooks de migración y retirada deben tener actualizados los módulos Az.Modules para que funcionen.
• El script de requisitos previos actualiza Az.Modules a la versión 8.0.0 más reciente.
• La hora de inicio de la programación de MRP será igual a la nextRunTime de la configuración de actualización de software.
• Los datos de Log Analytics no se migrarán.
• Las identidades administradas por el usuariono admiten escenarios entre inquilinos.
• La configuración RebootOnly no está disponible en Azure Update Manager. Las programaciones que tengan RebootOnly Setting no se migrarán.
• Para periodicidad, las programaciones de Automation admiten valores entre (1 y 100) para las programaciones diarias, diarias, semanales o mensuales, mientras que la configuración de mantenimiento de Azure Update Manager admite entre (6 y 35) para cada hora y (de 1 a 35) para diarias, semanales o mensuales.
  • Por ejemplo, si la programación de automatización tiene una periodicidad de cada 100 Horas, la programación de configuración de mantenimiento equivalente la tiene por cada 100/24 = 4,16 (Redondeo al valor más cercano):> cuatro días será la periodicidad de la configuración de mantenimiento.
  • Por ejemplo, si la programación de automatización tiene una periodicidad de cada 1 hora, la programación de configuración de mantenimiento equivalente la tendrá cada 6 horas.
  • Aplique la misma convención para Semanal y Diaria.
    • Si la programación de automatización tiene periodicidad diaria de 100 días, 100/7 = 14,28 (Redondeo al valor más cercano):> 14 semanas será la periodicidad de la programación de configuración de mantenimiento.
    • Si la programación de automatización tiene periodicidad semanal de 100 semanas, 100/4.34 = 23.04 (Redondeo al valor más cercano):> 23 meses será la periodicidad de la programación de configuración de mantenimiento.
    • Si la programación de automatización que debe repetirse cada 100 semanas y tiene que ejecutarse los viernes. Cuando se traduce a la configuración de mantenimiento, será cada 23 meses (100/4.34). Pero no hay forma en Azure Update Manager de decir que se ejecute cada 23 meses todos los viernes de ese mes, por lo que la programación no se migrará.
    • Si una programación de automatización tiene una periodicidad de más de 35 meses, en la configuración de mantenimiento siempre tendrá periodicidad de 35 meses.
  • SUC admite entre 30 minutos y seis horas para la ventana de mantenimiento. MRP admite entre 1 hora y 30 minutos y 4 horas.
    • Por ejemplo, si SUC tiene una ventana de mantenimiento de 30 minutos, entonces el programa MRP equivalente la tendrá durante 1 hora y 30 minutos.
    • Por ejemplo, si SUC tiene un período de mantenimiento de 6 horas, la programación equivalente de MRP la tendrá durante 4 horas.
• Cuando el libro de ejecución de la migración se ejecuta varias veces, digamos que ha migrado todas las programaciones de automatización y luego ha intentado migrar de nuevo todas las programaciones, entonces el runbook de migración ejecutará la misma lógica. Si hay algún cambio nuevo en SUC, se actualizará de nuevo la programación de MRP. No realizará asignaciones de configuración duplicadas. Además, las operaciones solo se llevan a cabo para las programaciones de automatización que tienen programaciones habilitadas. Si un SUC se Migró antes, se omitirá en el siguiente turno ya que su programación subyacente estará Deshabilitada.
• Al final, puede resolver más máquinas desde Azure Resource Graph como en Azure Update Manager; No puede comprobar si Hybrid Runbook Worker está informando o no, al contrario que en Automation Update Management donde había una intersección de Dynamic Queries y Hybrid Runbook Worker.

Guía de migración manual

Las instrucciones para mover varias funcionalidades se proporcionan en la tabla siguiente:

S.No	Funcionalidad	Automation Update Management	Azure Update Manager	Pasos para usar Azure Portal	Pasos para usar API/script
1	Administración de revisiones para máquinas fuera de Azure.	Podría ejecutarse con o sin conectividad de Arc.	Azure Arc es un requisito previo para las máquinas que no son de Azure.	1. Creación de una entidad de servicio 2. Generar script de instalación 3. Instalación del agente y conexión a Azure	1. Creación de una entidad de servicio 2. Generar script de instalación 3. Instalación del agente y conexión a Azure
2	Active la evaluación periódica para comprobar automáticamente las últimas actualizaciones cada pocas horas.	Las máquinas reciben automáticamente las actualizaciones más recientes cada 12 horas para Windows y cada 3 horas para Linux.	La evaluación periódica es una configuración de actualización en la máquina. Si está activado, Update Manager captura las actualizaciones cada 24 horas para la máquina y muestra el estado de actualización más reciente.	1. Máquina única 2. A escala 3. A escala mediante la directiva	1. para la VM de Azure 2.para la VM habilitada para Arc
3	Programaciones de implementación de actualizaciones estáticas (lista estática de máquinas para la implementación de actualizaciones).	Automation Update Management tenía sus propias programaciones.	Azure Update Manager crea un objeto deconfiguración de mantenimiento para una programación. Por lo tanto, debe crear este objeto, copiando toda la configuración de programación de Automation Update Management a la programación de Azure Update Manager.	1. Máquina virtual única 2. A escala 3. A escala mediante la directiva	Creación de un ámbito estático
4	Programaciones de implementación de actualizaciones dinámicas (definir el ámbito de las máquinas mediante el grupo de recursos, las etiquetas, etc.) que se evalúan dinámicamente en tiempo de ejecución.	Igual que las programaciones de actualizaciones estáticas.	Igual que las programaciones de actualizaciones estáticas.	Adición de un ámbito dinámico	Creación de un ámbito dinámico
5	Abandonar Azure Automation Update Management.	Después de completar los pasos 1, 2 y 3, debe limpiar los objetos de Azure Update Management.		Eliminación de la solución Update Management	N/D
6	Generación de informes	Informes de actualización personalizados mediante consultas de Log Analytics.	Los datos de actualización se almacenan en Azure Resource Graph (ARG). Los clientes pueden consultar datos de ARG para crear paneles personalizados, libros, etc.	Se puede acceder a los antiguos datos de Automation Update Management almacenados en Log Analytics, pero no hay ninguna disposición para trasladar los datos a ARG. Puede escribir consultas de ARG para acceder a los datos que se almacenarán en ARG después de aplicar revisiones a las máquinas virtuales a través de Azure Update Manager. Con las consultas de ARG, puede crear paneles y libros mediante las instrucciones siguientes: 1. La estructura de registro de Azure Resource Graph actualiza los datos 2. Consultas ARG de ejemplo 3. Creación de libros	N/D
7	Personalice los flujos de trabajo mediante scripts anteriores y posteriores.	Disponible como runbooks de Automation.	Se recomienda que pruebe la versión preliminar pública para scripts previos y posteriores en las máquinas que no estén en producción y que use las características en cargas de trabajo de producción una vez que la característica entre en la Disponibilidad General.	Administrar eventos anteriores y posteriores (versión preliminar)
8	Creación de alertas basadas en los datos de actualizaciones de su entorno	Las alertas se pueden configurar en los datos de actualizaciones almacenados en Log Analytics.	Se recomienda probar la versión preliminar pública de las alertas en las máquinas que no son de producción y usar la característica en cargas de trabajo de producción una vez que la característica entre en Disponibilidad general.	Creación de alertas (versión preliminar)

Pasos siguientes

• Guía sobre la migración de máquinas virtuales de Azure de Microsoft Configuration Manager a Azure Update Manager