Migration using automated runbook scripts

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

This article details on how by using migration runbooks, you can automatically migrate all workloads (machines and schedules) from Automation Update Management to Azure Update Manager.

The following sections 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.

Unsupported scenarios

• 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 key points in migration

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.

B. Run the script

Download and run the PowerShell script MigrationPrerequisiteScript locally. This script takes AutomationAccountResourceId of the Automation account to be migrated and AutomationAccountAzureEnvironment as the inputs. The accepted values for AutomationAccountAzureEnvironment are AzureCloud, AzureUSGovernment and AzureChina signifying the cloud to which the automation account belongs.

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

C. Verify

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

D. Backend operations by the script

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

• Creates an automation variable with name AutomationAccountAzureEnvironment which will store the Azure Cloud Environment to which Automation Account belongs.

• 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.

• Attaching the User Identity to the Automation Account.

• 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.

• Registration of required subscriptions to Microsoft.Maintenance and Microsoft.EventGrid Resource Providers.

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.

   

   Runbook supports PowerShell 5.1.

   

2. Set Verbose Logging to True for the runbook.

   

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

   

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

      

   2. You can fetch UserManagedServiceIdentityClientId from Automation Account > Identity > User Assigned > Identity > Properties > 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.

   

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 customer. This resource group is used for creating the MRP configs for V2.

• 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.

• For schedules having pre/post tasks configured, the script will create an automation webhook for the runbooks in pre/post tasks and Event Grid subscriptions for pre/post maintenance events. For more information, see how pre/post works in Azure Update Manager

• 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.

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.

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.

   

   Runbook supports PowerShell 5.1.

   

2. Set Verbose Logging to True for the Runbook.

   

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

   

   You can fetch AutomationAccountResourceId from Automation Account > Properties.

   

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

   

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

   

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.

Next steps

• An overview of migration
• Migration using Azure portal
• Manual migration guidance
• Key points during migration