Azure Update Manager Dynamic Scopes: do not deploy without at least 1 attached resource

Mick Collins 0

We would like to confirm if the following observation is by design or maybe a bug:

From our testing of template deployments of Azure Update Manager (maintenance configurations) we've found that a Maintenance Configuration that has a dynamic scope but no statically attached resources will run but will not install any updates.

The scenario is that we want to deploy via Bicep/ARM, maintenance configurations with dynamic scopes, also policies for machine pre-requisites. Then also ensure orchestration settings we are set on machines that already exist.

We have most of this in place and testing, however a maintenance configuration with only dynamic scope/s will have maintenance runs, but will not engage any installations on machines (no activity in agent logs on machines).

As soon as a single machine is manually directly attached to the maintenance configuration the dynamic scopes then start working for all machines.

So we we're seeking if this is by design or maybe not expected to be the behaviour. With this current behaviour we'll also have to plan to deploy some configuration assignments to our at scale implementations and not rely on only dynamic scopes.

Thanks

1 answer

Ryan Hill 25,981 Reputation points Microsoft Employee

2024-01-11T14:42:58.22+00:00
Apologies for the late reply @Mick Collins.

If I understand you correctly, you want to confirm that an update won't be applied to a virtual machine is attached to the configuration defined in the dynamic scope.

Rather than using the term attached, meet would be a better term. Updates won't get be applied until your Azure VM meets the following prerequisites,

Patch Orchestration must be set to Customer Managed Schedules. This sets patch mode to AutomaticByPlatform and the BypassPlatformSafetyChecksOnUserSchedule = True.

Associate a Schedule with the VM.

and the VM meets the criteria set forth in your dynamic scope. The dynamic scope gets evaluated at the scheduled runtime of the maintenance window. Meaning, it is possible to adjust the VM resource, so it doesn't meet the criteria and therefore patches not be applied and vice versa.See Manage various operations of Dynamic Scoping. | Microsoft Learn for additional information.
Please sign in to rate this answer.
Mick Collins 0 Reputation points

2024-01-15T11:54:26.37+00:00

Hi Ryan,

So are you saying that a machine must be associated with a schedule (maintenance configuration) and also meet the criteria of the Dynamic Scope? This is not what we expected, and we have also not observed this.

What we expected:

That we have to meet the pre-requisite of setting the Patch Orchestration to Customer Managed Schedules.

Then that we can either directly attach a resource to a maintenance configuration (I say 'attach' as this is what the button reads in the portal 'Attach existing maintenance configuration'). Or that we just meet the Dynamic Scope criteria.

What we have seen:

A bit of both from the above, but the main catch is that if no machines are attached to the maintenance configuration then the Dynamic Scopes have no effect.

But if we attach a single resource to a maintenance configuration, we have then seen that the Dynamic Scopes effect all of the machines that meet the criteria (not just the one that is attached).

Example:

Maintenance runs will happen as per schedule. With only a dynamic scope configured with machines existing that meet the criteria, NO machines will patch (as we have not got any statically attached/associated resources).

As soon as we attach just a single resource:

Where the dynamic scope includes other resources:

All of those machines will then patch within that configuration:

---As mentioned we would like to confirm what is the expected design so we can ensure our deployments at scale will always be valid.

If you have to attach all machines, what is the point of a dynamic scope?

If you have to attach a machine this adds another dimension to ARM template deployments of maintenance configurations and dynamic scopes, as a machine deployment also has to be included.

There is also a risk that if only a single machine was attached to a maintenance Configuration and it was decommissioned, that looks like it would render the Dynamic Scope useless on that configuration, until something else was attached.

Ryan Hill 25,981 Reputation points Microsoft Employee

2024-01-23T16:55:25.8666667+00:00

@Mick Collins apologies for the late reply.

So are you saying that a machine must be associated with a schedule (maintenance configuration) and also meet the criteria of the Dynamic Scope?

No, the Dynamic Scope is effectively a query based off the criteria you selected. When you create a Dynamic Scope, you will have the option to convert all machines that discovered under that scope to update the Patch Orchestration to Customer Managed Schedules.

Then that we can either directly attach a resource to a maintenance configuration (I say 'attach' as this is what the button reads in the portal 'Attach existing maintenance configuration'). Or that we just meet the Dynamic Scope criteria.

The attach you're referring to is to statically associate a VM to the maintenance configuration that you know may not fall within the Dynamic Scope but always want to have patched by this same schedule. This is separate from Dynamic Scopes and is not required for functionality.

If you have to attach all machines, what is the point of a dynamic scope?

No, this is not required.

If you have to attach a machine this adds another dimension to ARM template deployments of maintenance configurations and dynamic scopes, as a machine deployment also has to be included.

There is also a risk that if only a single machine was attached to a maintenance Configuration and it was decommissioned, that looks like it would render the Dynamic Scope useless on that configuration, until something else was attached.

Because this operation is statically assigning a VM to the schedule, it's at your own volition of how to implement any sort of ARM deployment. I could see a special use case for deploying a VM that may fall outside scope of your Dynamic Scope criteria that you would want included, i.e., a singular VM in a region where you don't want to include all the others.

Having said that, this doesn't have any affect on Dynamic Scope. If you use criteria such as tags and remove that tag value, that VM will drop from that query result.

A bit of both from the above, but the main catch is that if no machines are attached to the maintenance configuration then the Dynamic Scopes have no effect.

If you have a VM that shows under the Dynamic Scope that doesn't update, the History blade under Azure Update Manager will indicate why the machine failed to update.
Sign in to comment