Introduction
I have spent the last 3 months speaking at various events on how to use Azure update management, Inventory and change tracking. This blog series is a continuation of the first blog I wrote on this subject. In that blog I covered the background, planning, enabling the capabilities and finally on-boarding machines into the solution.
In this blog I share the approach I took on getting organised so I can leverage 2 grouping features to support the update deployment; Dynamic groups for Azure VMs and Dynamic saved searches (Computer groups) for Non-Azure machines. If you have used SCCM before then this will be the equivalent to using query based collections.
Dynamic Groups (Azure VM)
Using dynamic groups you can group your deployments by the following
- Subscription
- Resource groups
- Locations
- Tags
The first 3 options subscription, resource groups and locations are very broad and might be suited to a mass unstructured deployment. The most flexible option, and the one I focused on is the use of Tags. In the illustration you can see that each Azure VM is Tagged with 3 categories to support the update deployment
You can tag manually by using the VM blade in the Azure Portal but that does not scale for a large amount of VMs. I decided to leverage Azure policy for that little task. I duplicated the Built-in policy definition “Append tag and its default value”. I added the custom policy 3 times to an initiative called Update Management tags and used parameters with a list of values that I select when assigning the policy to a resource group.
My VMs in the subscription are organised by resource groups aligned with my environment life cycle (Dev, Preprod and Prod). The tags are now available for use in creating my dynamic groups for Azure VMs
Non-Azure Machines
The options you have for grouping Non-Azure machines are, AD/WSUS group, SCCM collections, standard log analytics saved searches or the new Dynamic saved searches. These options range in complexity and flexibility. For example, in order to leverage SCCM collections you will have to setup the OMS connector in SCCM which is not trivial. By far the easiest and most flexible is using Dynamic saved searches. Dynamic saved searches differ from standard saved searches in the fact that with dynamic saved searches the query is evaluated before the deployment whereas for non-dynamic this is done at the time you save the search and becomes a static list.
In my initial approach I opted to use my computer naming conventions to create my saved searches. The prerequisite for this is simple. On-board the Computer into the Log analytics workspace and use the following query.
Heartbeat | distinct Computer |where Computer contains "<part of computer name>"
You have two ways to create the Dynamic saved search computer group. Using the saved searches node in your workspace or using the create computer group option in Inventory. Using computer groups in Inventory is simpler but you cannot make changes after creation. You can however make changes to the computer group using the saved searches even if you created it using the Inventory computer groups option.
In my example the result of the query yields 2 machines currently matching that criteria.
I opted for a much more flexible option using a custom registry Key and string values. I created 2 string values; environment and PatchPhaseType under a custom key called ITP Patch Settings
[HKEY_LOCAL_MACHINE\SOFTWARE\ITP Patch Settings]
“PatchPhaseType”=”Slot1 With Reboot”
“Environment”=”Dev”
I configured Change Tracking to pick up the custom registry values, so it is available in Log analytics to support my computer groups creation for the Non-azure machines
Slot 1 with Reboot (these are my on-prem dev machines in Slot 1 patch phase)
ConfigurationData |where ValueName == “PatchPhaseType” and ValueData == “Slot1 With Reboot” |distinct Computer
Slot 3 No Reboot (in my case Slot 3 represents production)
ConfigurationData |where ValueName == “PatchPhaseType” and ValueData == “Slot3 No Reboot” |distinct Computer
My resultant computer groups were: Slot 1 No Reboot; Slot 1 with Reboot; Slot 2 No Reboot; Slot 2 with Reboot; Slot 3 No Reboot and Slot 3 with Reboot.
These will show up under the Machine groups in Inventory and will also be available for selection when you create your update deployment schedule (Groups to update section). Note: The category name is up to you. In my case I created a category called NonAzure.
I used “Slot” as a place holder so I can specify sepecific dates and times for the deployments. You can also edit the schedule property of a deployment so this gives you a great deal of flexibility.
You will see these groups (once created) in the section “Groups to to update”
That is it! You are all set to start using dynamic groups (Azure) and Dynamic saved searches (Non-Azure) for your deployments. Part 2 digs into scheduling the deployment.
