Azure Virtual Machines (VM’s) can receive windows updates automatically if updates are enabled. There are multiple ways to on-board a VM for automatic update management.
Once a deployment is scheduled the updates will be installed based on the schedule. There are few shortcomings with the Azure update management feature.
- It can only install updates if the VM is up and running.
- It cannot maintain the state of the VM(running/stopped) after any updates
Update Management — Pre/Post scripts
Thankfully update management can invoke a script like a runbook, before and after running the updates. You can learn more about pre and post script configuration here.
If all VM’s in the update schedule are either stopped or running, it will be easy to make a call to a script that can Start or Stop them based on the need. For example, the pre-script can start all VM’s and the post-script can stop after the updates are complete.
What if you have a mix of both and you want to maintain the status of the VM’s after installing the updates? In our Non-Production environment, we have a few VM’s which will never turn off (shared VM’s) and Development, Staging VM’s will be shutdown at the end of the day to reduce costs.
Update Management — Maintain VM status after the deployment
This context will be sent as an input parameter when the pre or post script is invoked. It contains a wealth of information about the update schedule including the schedule name, VM’s that are part of the schedule, schedule start time, duration, etc.
I have created a runbook which accepts the context and the pre or post action name as input parameters and performs one of the following actions:
Invoked as pre-script (Input Parameter: Start)
- Read the VM’s that are part of this schedule
- Find their status (Running/Stopped)
- Store the status information in a storage account as a JSON file
- Start the VM’s that are not running
Invoked as post-script (Input Parameter: Stop)
- Read the JSON file from the storage account
- Stop the VM’s that were started in the pre-script
- Delete the JSON file from storage
A few things to remember:
- As of now, you cannot pass Boolean, Object or Array types as input to the runbook. Find the supported types here.
- Do not create the runbook as ‘Workflow’ type. A workflow type runbook is not listed as an available pre or post script file.
- SoftwareUpdateConfigurationRunContext has no parameter to distinguish whether the context is for Pre/Post script invocation. Hopefully MicroSoft includes it one day based on my suggestion for this feature.