Managed VM Module (Platform Side)

The Managed VM module deploys virtual machines with a fixed baseline: security settings, owner groups, monitoring, backup and patching. Workload teams use it through standard requests, see Managed virtual machines. This page is for the platform team: how a request becomes a change, what to check regularly, and how to keep the module's release notes.

Optional module

The module is not part of the core hub and spoke code. Its configuration lives next to the spoke configuration, and its own releases and release notes are separate. Check which version and which options your platform runs, and which pipeline deploys it.

How a request becomes a change

Step	Who	What
1	Requester	Fills in the request (Request and change), or opens a pull request on the VM configuration file when they have access
2	Platform team	Checks the request, edits the VM configuration file for the spoke and environment, opens or reviews the pull request
3	Reviewer	Design review (for example the customer's architecture team, where the contract says so)
4	Operator	Reviews, merges and deploys with the module pipeline. Updates the ticket.
5	Operator	Informs the requester

One configuration file exists per spoke and environment in a folder per spoke. A new spoke folder must also be added to the list of spokes in the module's deployment pipeline. Otherwise nothing is deployed and the pipeline stays green. Add this to your new-spoke checklist (New spoke).

Do not let requesters complete their own pull request. The requester opens it, the platform team merges it. See Making a change safely.

The reviewer's checklist and the deployment steps are in Managed VM pull request review. The scope of the service and its boundaries are in the service description.

Change types that fit a standard change

These changes are expected, and are valid as standard changes, as long as they go through a pull request:

• a new VM configuration;
• resizing (changing the SKU);
• tag updates;
• retention or backup changes;
• owner changes;
• a change of the number of instances;
• switching access packages on or off.

Anything else (a new module option, a new image, a change in the baseline) is a change of the module, not a standard change.

Request fields

The fields are listed on Request and change. Keep this table of the less obvious ones:

Field	Mapping and traps
Workload short name + configuration short name	Together they have a maximum length (8 characters non-production, 11 production in the source module). Longer names break derived resource names. The key_vault_name variable overrides the generated Key Vault name when the generated one is wrong, for example for an existing Key Vault or very long names.
OS SKU	An internal SKU name mapped to an Azure image. Missing means the latest. Supported names grow with module versions.
Data disk to remove	The 0-based index in the data_disks array. Removing a disk in the middle of the list shifts the indexes of the others: re-read the file first.
Backup RPO and retention	Separate values for each backup solution. The Backup Vault RPO can't be changed afterwards.
Owners	E-mail addresses that exist in Entra ID. owners_members sets the members of the owner group.
Encryption at host	Needs a feature registration on the subscription before it can be enabled.

Module options worth knowing

These names come from the module's release notes. Your version can differ.

Option	Purpose
backup_solutions	List of BackupVault and RecoveryServicesVault
rsv_alerts_for_all_job_failures_enabled, rsv_alerts_for_critical_operation_failures_enabled	Alert on failures in the Recovery Services vault
disable_default_maintenance_configuration	Switch off the module's own maintenance configuration, so that the policy-assigned one applies
deploy_defender_plans	Which Defender plans (default CloudPosture and VirtualMachines)
deploy_change_tracking	Change Tracking and Inventory
custom_alert_rules	Extra alert rules on Log Analytics data
encryption_at_host_enabled, disk_encryption_enabled	Encryption at host, and Azure Disk Encryption
deploy_guest_configuration	Guest Configuration extension. Off by default. Keep it off when an Azure Policy deploys the extension.
license_type	Hybrid Benefit for Windows and Linux VMs
key_vault_name	Explicit Key Vault name
instances	Number of identical VMs of one configuration. With a value above 1, the VMs get the same configuration and the standard names with an incrementing suffix.
useAccessPackages	Access packages in Entra ID, so owners assign users in the My Access portal. Some platforms no longer use them. When your platform prefers false, ask the requester to confirm if the pull request sets true.

Patch assignment by policy

VMs are assigned to maintenance configurations by dynamic scopes on the maintenance configurations. The scopes select VMs by the tag PatchPriority:

• An Azure Policy initiative is assigned at a management group. It makes sure that every subscription below it is in the dynamic scope of both maintenance configurations (non-business-critical and business-critical), so new subscriptions need no change.
• Subscriptions outside that management group (for example directly under the tenant root group) need the same policy assigned at that level, by hand or in code.
• The managed identity of each policy assignment needs rights at the assignment scope: Contributor (to create remediation tasks when needed) and Scheduled Patching Contributor.
• The configuration files in the code repository define the schedules. Documentation that repeats the schedule is a convenience and can be outdated.

The policy names and assignment names are your own. Use the policy conventions of Policy assignments.

Nobody patches a VM without the tag

A VM without PatchPriority (or with a different spelling) is not in any dynamic scope. Check for VMs without the tag as part of the regular check, for example with an Azure Policy audit or a resource graph query.

Regular check

After each patch window (for example on the next working morning):

1. Open Update Manager → Manage → History, filter Update operation on Install updates and Resource type on Azure Virtual Machine.
2. Look for Failed and Completed with warnings. Compare installed with total updates: "8 of 10" is a miss.
3. Look at Machines for No updates data (remove filters first). Those machines were off or have no assessment.
4. For each failure, create a task, contact the workload owner and fix the cause.

A monthly report has the same shape: the list of managed VMs per environment, patch status (pending, failed, installed, excluded, date), backup status and open follow-ups. Do not copy customer data into shared documentation.

Also keep a list of VMs with special handling: VMs that are patched by their owners, VMs that must not reboot automatically, and VMs that are off most of the time. The owners' contacts belong in that list.

Regular check: backups

• Review the failed backup jobs and alert rules of the Recovery Services vaults.
• Test a restore at least once for each type of workload, following Backup and restore.

Release notes

Keep release notes per module version and put them where the workload teams can read them. A pattern that works:

• One heading per version with the release month: ## Version 1.4.11 (June 2025).
• Bullet points per change, starting with Add, Change, Fix or Ignore.
• The new option names in code format, with a link to the Microsoft documentation if a feature needs a subscription-level prerequisite.
• A line for every behaviour change that affects existing VMs (defaults, retention, roles), because those are the changes consumers notice.

Excerpt of notable changes, to show the level of detail:

Version	Change
1.1.0	Change Tracking and Inventory, custom alert rules. VM owners get the Virtual Machine Administrator role
1.2.0	Choice of Defender plans
1.3.0	Recovery Services vault as backup solution (the Backup Vault was the default for compatibility), retention options
1.3.1	Boot diagnostics; administrators get Virtual Machine Contributor so they can use the Serial Console
1.3.7	license_type for Hybrid Benefit
1.3.9	Staging storage account of the Recovery Services vault denies public access
1.4.0	Tags on VMs; disable_default_maintenance_configuration
1.4.4	Encryption at host, Azure Disk Encryption, Guest Configuration, owner members; storage account without public access or shared keys
1.4.5	Alerts for Recovery Services vault job failures
1.4.9	Default backup solution changed to Recovery Services vault
1.4.11	Windows Server 2025, Ubuntu 24.04, more RHEL versions

See also What to do when a new version is released for how new platform versions are rolled out, and Backwards compatibility for how changes of defaults are announced.