Edit

Move from Automation Update Management to Azure Update Manager

  • Article

Applies to: ✔️ Windows VMs ✔️ Linux VMs ✔️ On-premises environment ✔️ Azure Arc-enabled servers

This article provides guidance to move virtual machines from Automation Update Management to Azure Update Manager.

Azure Update Manager provides a SaaS solution to manage and govern software updates to Windows and Linux machines across Azure, on-premises, and multicloud environments. It's an evolution of Azure Automation Update management solution with new features and functionality, for assessment and deployment of software updates on a single machine or on multiple machines at scale.

For the Azure Update Manager, both AMA and MMA aren't a requirement to manage software update workflows as it relies on the Microsoft Azure VM Agent for Azure VMs and Azure connected machine agent for Arc-enabled servers. When you perform an update operation for the first time on a machine, an extension is pushed to the machine and it interacts with the agents to assess missing updates and install updates.

Note

  • If you are using Azure Automation Update Management Solution, we recommend that you don't remove MMA agents from the machines without completing the migration to Azure Update Manager for the machine's patch management needs. If you remove the MMA agent from the machine without moving to Azure Update Manager, it would break the patching workflows for that machine.

  • All capabilities of Azure Automation Update Management will be available on Azure Update Manager before the deprecation date.

Azure portal experience (preview)

This section explains how to use the portal experience (preview) to move schedules and machines from Automation Update Management to Azure Update Manager. With minimal clicks and automated way to move your resources, it's the easiest way to move if you don't have customizations built on top of your Automation Update Management solution.

To access the portal migration experience, you can use several entry points.

Select the Migrate Now button present on the following entry points. After the selection, you're guided through the process of moving your schedules and machines to Azure Update Manager. This process is designed to be user-friendly and straight forward to allow you to complete the migration with minimal effort.

You can migrate from any of the following entry points:

Select the Migrate Now button and a migration blade opens. It contains a summary of all resources including machines, and schedules in the Automation account. By default, the Automation account from which you accessed this blade is preselected if you go by this route.

Screenshot that shows how to migrate from Automation Update Management entry point.

Here, you can see how many of Azure, Arc-enabled servers, non-Azure non Arc-enabled servers, and schedules are enabled in Automation Update Management and need to be moved to Azure Update Manager. You can also view the details of these resources.

The migration blade provides an overview of the resources that will be moved, allowing you to review and confirm the migration before proceeding. Once you're ready, you can proceed with the migration process to move your schedules and machines to Azure Update Manager.

Screenshot that shows how to migrate all resources from Automation account.

After you review the resources that must be moved, you can proceed with the migration process which is a three-step process:

  1. Prerequisites

    This includes two steps:

    a. Onboard non-Azure non-Arc-enabled machines to Arc - This is because Arc connectivity is a prerequisite for Azure Update Manager. Onboarding your machines to Azure Arc is free of cost, and once you do so, you can avail all management services as you can do for any Azure machine. For more information, see Azure Arc documentation on how to onboard your machines.

    b. Download and run PowerShell script locally - This is required for the creation of a user identity and appropriate role assignments so that the migration can take place. This script gives proper RBAC to the User Identity on the subscription to which the automation account belongs, machines onboarded to Automation Update Management, scopes that are part of dynamic queries etc. so that the configuration can be assigned to the machines, MRP configurations can be created and updates solution can be removed. For more information, see Azure Update Manager documentation.

    Screenshot that shows the prerequisites for migration.

  2. Move resources in Automation account to Azure Update Manager

    The next step in the migration process is to enable Azure Update Manager on the machines to be moved and create equivalent maintenance configurations for the schedules to be migrated. When you select the Migrate Now button, it imports the MigrateToAzureUpdateManager runbook into your Automation account and sets the verbose logging to True.

    Screenshot that shows how to migrate workload in your Automation account.

    Select Start runbook, which presents the parameters that must be passed to the runbook.

    Screenshot that shows how to start runbook to allow the parameters to be passed to the runbook.

    For more information on the parameters to fetch and the location from where it must be fetched, see migration of machines and schedules. Once you start the runbook after passing in all the parameters, Azure Update Manager will begin to get enabled on machines and maintenance configuration in Azure Update Manager will start getting created. You can monitor Azure runbook logs for the status of execution and migration of schedules.

  3. Deboard resources from Automation Update management

    Run the clean-up script to deboard machines from the Automation Update Management solution and disable Automation Update Management schedules.

    After you select the Run clean-up script button, the runbook DeboardFromAutomationUpdateManagement will be imported into your Automation account, and its verbose logging is set to True.

    Screenshot that shows how to perform post migration.

    When you select Start the runbook, asks for parameters to be passed to the runbook. For more information, see Deboarding from Automation Update Management solution to fetch the parameters to be passed to the runbook.

    Screenshot that shows how to deboard from Automation Update Management and starting the runbook.

Migration scripts (preview)

Using migration runbooks, you can automatically migrate all workloads (machines and schedules) from Automation Update Management to Azure Update Manager. This section details on how to run the script, what the script does at the backend, expected behavior, and any limitations, if applicable. The script can migrate all the machines and schedules in one automation account at one go. If you have multiple automation accounts, you have to run the runbook for all the automation accounts.

At a high level, you need to follow the below steps to migrate your machines and schedules from Automation Update Management to Azure Update Manager.

Prerequisites summary

  1. Onboard non-Azure machines on to Azure Arc.
  2. Download and run the PowerShell script for the creation of User Identity and Role Assignments locally on your system. See detailed instructions in the step-by-step guide as it also has certain prerequisites.

Steps summary

  1. Run migration automation runbook for migrating machines and schedules from Automation Update Management to Azure Update Manager. See detailed instructions in the step-by-step guide.
  2. Run cleanup scripts to deboard from Automation Update Management. See detailed instructions in the step-by-step guide.

Unsupported scenarios

  • Update schedules having Pre/Post tasks won't be migrated for now.
  • Non-Azure Saved Search Queries won't be migrated; these have to be migrated manually.

For the complete list of limitations and things to note, see the last section of this article.

Step-by-step guide

The information mentioned in each of the above steps is explained in detail below.

Prerequisite 1: Onboard Non-Azure Machines to Arc

What to do

Migration automation runbook ignores resources that aren't onboarded to Arc. It's therefore a prerequisite to onboard all non-Azure machines on to Azure Arc before running the migration runbook. Follow the steps to onboard machines on to Azure Arc.

Prerequisite 2: Create User Identity and Role Assignments by running PowerShell script

A. Prerequisites to run the script

  • Run the command Install-Module -Name Az -Repository PSGallery -Force in PowerShell. The prerequisite script depends on Az.Modules. This step is required if Az.Modules aren't present or updated.
  • To run this prerequisite script, you must have Microsoft.Authorization/roleAssignments/write permissions on all the subscriptions that contain Automation Update Management resources such as machines, schedules, log analytics workspace, and automation account. See how to assign an Azure role.
  • You must have the Update Management Permissions.

Screenshot that shows how the command to install module.

B. Run the script

Download and run the PowerShell script MigrationPrerequisiteScript locally. This script takes AutomationAccountResourceId of the Automation account to be migrated as the input.

Screenshot that shows how to download and run the script.

You can fetch AutomationAccountResourceId by going to Automation Account > Properties.

Screenshot that shows how to fetch the resource ID.

C. Verify

After you run the script, verify that a user managed identity is created in the automation account. Automation account > Identity > User Assigned.

Screenshot that shows how to verify that a user managed identity is created.

D. Backend operations by the script

  1. Updating the Az.Modules for the Automation account, which will be required for running migration and deboarding scripts

  2. Creation of User Identity in the same Subscription and resource group as the Automation Account. The name of User Identity will be like AutomationAccount_aummig_umsi.

  3. Attaching the User Identity to the Automation Account.

  4. The script assigns the following permissions to the user managed identity: Update Management Permissions Required.

    1. For this, the script fetches all the machines onboarded to Automation Update Management under this automation account and parse their subscription IDs to be given the required RBAC to the User Identity.
    2. The script gives a proper RBAC to the User Identity on the subscription to which the automation account belongs so that the MRP configs can be created here.
    3. The script assigns the required roles for the Log Analytics workspace and solution.

Step 1: Migration of machines and schedules

This step involves using an automation runbook to migrate all the machines and schedules from an automation account to Azure Update Manager.

Follow these steps:

  1. Import migration runbook from the runbooks gallery and publish. Search for azure automation update from browse gallery, and import the migration runbook named Migrate from Azure Automation Update Management to Azure Update Manager and publish the runbook.

    Screenshot that shows how to migrate from Automation Update Management.

    Runbook supports PowerShell 5.1.

    Screenshot that shows runbook supports PowerShell 5.1 while importing.

  2. Set Verbose Logging to True for the runbook.

    Screenshot that shows how to set verbose log records.

  3. Run the runbook and pass the required parameters like AutomationAccountResourceId, UserManagedServiceIdentityClientId, etc.

    Screenshot that shows how to run the runbook and pass the required parameters.

    1. You can fetch AutomationAccountResourceId from Automation Account > Properties.

      Screenshot that shows how to fetch Automation account resource ID.

    2. You can fetch UserManagedServiceIdentityClientId from Automation Account > Identity > User Assigned > Identity > Properties > Client ID.

      Screenshot that shows how to fetch client ID.

    3. Setting EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement to TRUE would enable periodic assessment property on all the machines onboarded to Automation Update Management.

    4. Setting MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines to TRUE would migrate all the update schedules in Automation Update Management to Azure Update Manager and would also turn on periodic assessment property to True on all the machines linked to these schedules.

    5. You need to specify ResourceGroupForMaintenanceConfigurations where all the maintenance configurations in Azure Update Manager would be created. If you supply a new name, a resource group would be created where all the maintenance configurations would be created. However, if you supply a name with which a resource group already exists, all the maintenance configurations would be created in the existing resource group.

  4. Check Azure Runbook Logs for the status of execution and migration status of SUCs.

    Screenshot that shows the runbook logs.

Runbook operations in backend

The migration of runbook does the following tasks:

  • Enables periodic assessment on all machines.
  • All schedules in the automation account are migrated to Azure Update Manager and a corresponding maintenance configuration is created for each of them, having the same properties.

About the script

The following is the behavior of the migration script:

  • Check if a resource group with the name taken as input is already present in the subscription of the automation account or not. If not, then create a resource group with the name specified by the Cx. This resource group is used for creating the MRP configs for V2.

  • The script ignores the update schedules that have pre and post scripts associated with them. For pre and post scripts update schedules, migrate them manually.

  • RebootOnly Setting isn't available in Azure Update Manager. Schedules having RebootOnly Setting aren't migrated.

  • Filter out SUCs that are in the errored/expired/provisioningFailed/disabled state and mark them as Not Migrated, and print the appropriate logs indicating that such SUCs aren't migrated.

  • The config assignment name is a string that will be in the format AUMMig_AAName_SUCName

  • Figure out if this Dynamic Scope is already assigned to the Maintenance config or not by checking against Azure Resource Graph. If not assigned, then only assign with assignment name in the format AUMMig_ AAName_SUCName_SomeGUID.

  • A summarized set of logs is printed to the Output stream to give an overall status of machines and SUCs.

  • Detailed logs are printed to the Verbose Stream.

  • Post-migration, a Software Update Configuration can have any one of the following four migration statuses:

    • MigrationFailed
    • PartiallyMigrated
    • NotMigrated
    • Migrated

The below table shows the scenarios associated with each Migration Status.

MigrationFailed PartiallyMigrated NotMigrated Migrated
Failed to create Maintenance Configuration for the Software Update Configuration. Non-Zero number of Machines where Patch-Settings failed to apply. Failed to get software update configuration from the API due to some client/server error like maybe internal Service Error.
Non-Zero number of Machines with failed Configuration Assignments. Software Update Configuration is having reboot setting as reboot only. This isn't supported today in Azure Update Manager.
Non-Zero number of Dynamic Queries failed to resolve that is failed to execute the query against Azure Resource Graph. Software Update Configuration is having Pre/Post Tasks. Currently, Pre/Post in Preview in Azure Update Manager and such schedules won't be migrated.
Non-Zero number of Dynamic Scope Configuration assignment failures. Software Update Configuration isn't having succeeded provisioning state in DB.
Software Update Configuration is having Saved Search Queries. Software Update Configuration is in errored state in DB.
Schedule associated with Software Update Configuration is already expired at the time of migration.
Schedule associated with Software Update Configuration is disabled.
Unhandled exception while migrating software update configuration. Zero Machines where Patch-Settings failed to apply.

And

Zero Machines with failed Configuration Assignments.

And

Zero Dynamic Queries failed to resolve that is failed to execute the query against Azure Resource Graph.

And

Zero Dynamic Scope Configuration assignment failures.

And

Software Update Configuration has zero Saved Search Queries.

To figure out from the table above which scenario/scenarios correspond to why the software update configuration has a specific status, look at the verbose/failed/warning logs to get the error code and error message.

You can also search with the name of the update schedule to get logs specific to it for debugging.

Screenshot that shows how to view logs specific for debugging.

Step 2: Deboarding from Automation Update Management solution

Follow these steps:

  1. Import the migration runbook from runbooks gallery. Search for azure automation update from browse gallery, and import the migration runbook named Deboard from Azure Automation Update Management and publish the runbook.

    Screenshot that shows how to import the deaboard migration runbook.

    Runbook supports PowerShell 5.1.

    Screenshot that shows the runbook supports PowerShell 5.1 while deboarding.

  2. Set Verbose Logging to True for the Runbook.

    Screenshot that shows log verbose records setting while deboarding.

  3. Start the runbook and pass parameters such as Automation AccountResourceId, UserManagedServiceIdentityClientId, etc.

    Screenshot that shows how to start runbook and pass parameters while deboarding.

    You can fetch AutomationAccountResourceId from Automation Account > Properties.

    Screenshot that shows how to fetch resource ID while deboarding.

    You can fetch UserManagedServiceIdentityClientId from Automation Account > Identity > User Assigned > Identity > Properties > Client ID.

    Screenshot that shows how to fetch client ID while deboarding.

  4. Check Azure runbook logs for the status of deboarding of machines and schedules.

    Screenshot that shows how runbook logs while deboarding.

Deboarding script operations in the backend

  • Disable all the underlying schedules for all the software update configurations present in this Automation account. This is done to ensure that Patch-MicrosoftOMSComputers Runbook isn't triggered for SUCs that were partially migrated to V2.
  • Delete the Updates Solution from the Linked Log Analytics Workspace for the Automation Account being Deboarded from Automation Update Management in V1.
  • A summarized log of all SUCs disabled and status of removing updates solution from linked log analytics workspace is also printed to the output stream.
  • Detailed logs are printed on the verbose streams.

Callouts for the migration process:

  • Schedules having pre/post tasks won't be migrated for now.
  • Non-Azure Saved Search Queries won't be migrated.
  • The Migration and Deboarding Runbooks need to have the Az.Modules updated to work.
  • The prerequisite script updates the Az.Modules to the latest version 8.0.0.
  • The StartTime of the MRP Schedule will be equal to the nextRunTime of the Software Update Configuration.
  • Data from Log Analytics won't be migrated.
  • User Managed Identities don't support cross tenant scenarios.
  • RebootOnly Setting isn't available in Azure Update Manager. Schedules having RebootOnly Setting won't be migrated.
  • For Recurrence, Automation schedules support values between (1 to 100) for Hourly/Daily/Weekly/Monthly schedules, whereas Azure Update Manager’s maintenance configuration supports between (6 to 35) for Hourly and (1 to 35) for Daily/Weekly/Monthly.
    • For example, if the automation schedule has a recurrence of every 100 Hours, then the equivalent maintenance configuration schedule has it for every 100/24 = 4.16 (Round to Nearest Value) -> Four days will be the recurrence for the maintenance configuration.
    • For example, if the automation schedule has a recurrence of every 1 hour, then the equivalent maintenance configuration schedule will have it every 6 hours.
    • Apply the same convention for Weekly and Daily.
      • If the automation schedule has daily recurrence of say 100 days, then 100/7 = 14.28 (Round to Nearest Value) -> 14 weeks will be the recurrence for the maintenance configuration schedule.
      • If the automation schedule has weekly recurrence of say 100 weeks, then 100/4.34 = 23.04 (Round to Nearest Value) -> 23 Months will be the recurrence for the maintenance configuration schedule.
      • If the automation schedule that should recur Every 100 Weeks and has to be Executed on Fridays. When translated to maintenance configuration, it will be Every 23 Months (100/4.34). But there's no way in Azure Update Manager to say that execute every 23 Months on all Fridays of that Month, so the schedule won't be migrated.
      • If an automation schedule has a recurrence of more than 35 Months, then in maintenance configuration it will always have 35 Months Recurrence.
    • SUC supports between 30 Minutes to six Hours for the Maintenance Window. MRP supports between 1 hour 30 minutes to 4 hours.
      • For example, if SUC has a Maintenance Window of 30 Minutes, then the equivalent MRP schedule will have it for 1 hour 30 minutes.
      • For example, if SUC has a Maintenance Window of 6 hours, then the equivalent MRP schedule will have it for 4 hours.
  • When the migration runbook is executed multiple times, say you did Migrate All automation schedules and then again tried to migrate all the schedules, then migration runbook will run the same logic. Doing it again will update the MRP schedule if any new change is present in SUC. It won't make duplicate config assignments. Also, operations are carried only for automation schedules having enabled schedules. If an SUC was Migrated earlier, it will be skipped in the next turn as its underlying schedule will be Disabled.
  • In the end, you can resolve more machines from Azure Resource Graph as in Azure Update Manager; You can't check if Hybrid Runbook Worker is reporting or not, unlike in Automation Update Management where it was an intersection of Dynamic Queries and Hybrid Runbook Worker.

Manual migration guidance

Guidance to move various capabilities is provided in table below:

S.No Capability Automation Update Management Azure Update Manager Steps using Azure portal Steps using API/script
1 Patch management for Off-Azure machines. Could run with or without Arc connectivity. Azure Arc is a prerequisite for non-Azure machines. 1. Create service principal
2. Generate installation script
3. Install agent and connect to Azure		 1. Create service principal
2. Generate installation script
3. Install agent and connect to Azure
2 Enable periodic assessment to check for latest updates automatically every few hours. Machines automatically receive the latest updates every 12 hours for Windows and every 3 hours for Linux. Periodic assessment is an update setting on your machine. If it's turned on, the Update Manager fetches updates every 24 hours for the machine and shows the latest update status. 1. Single machine
2. At scale
3. At scale using policy		 1. For Azure VM
2.For Arc-enabled VM
3 Static Update deployment schedules (Static list of machines for update deployment). Automation Update management had its own schedules. Azure Update Manager creates a maintenance configuration object for a schedule. So, you need to create this object, copying all schedule settings from Automation Update Management to Azure Update Manager schedule. 1. Single VM
2. At scale
3. At scale using policy		 Create a static scope
4 Dynamic Update deployment schedules (Defining scope of machines using resource group, tags, etc. that is evaluated dynamically at runtime). Same as static update schedules. Same as static update schedules. Add a dynamic scope Create a dynamic scope
5 Deboard from Azure Automation Update management. After you complete the steps 1, 2, and 3, you need to clean up Azure Update management objects. Remove Update Management solution
NA
6 Reporting Custom update reports using Log Analytics queries. Update data is stored in Azure Resource Graph (ARG). Customers can query ARG data to build custom dashboards, workbooks etc. The old Automation Update Management data stored in Log analytics can be accessed, but there's no provision to move data to ARG. You can write ARG queries to access data that will be stored to ARG after virtual machines are patched via Azure Update Manager. With ARG queries you can, build dashboards and workbooks using following instructions:
1. Log structure of Azure Resource graph updates data
2. Sample ARG queries
3. Create workbooks		 NA
7 Customize workflows using pre and post scripts. Available as Automation runbooks. We recommend that you try out the Public Preview for pre and post scripts on your non-production machines and use the feature on production workloads once the feature enters General Availability. Manage pre and post events (preview)
8 Create alerts based on updates data for your environment Alerts can be set up on updates data stored in Log Analytics. We recommend that you try out the Public Preview for alerts on your non-production machines and use the feature on production workloads once the feature enters General Availability. Create alerts (preview)

Next steps