Azure Windows Update Management — VM State management

Raja Shekhar Chava
Oct 14 · 2 min read

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
Azure runbook to maintain the VM status during patch updates

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.

TeleTracking Engineering

Engineering a future where #nopatientwaits.

Raja Shekhar Chava

Written by

I am a Software Development Manager at TeleTracking Technologies. My technology interests are Azure cloud, DevOps and IaaS.

TeleTracking Engineering

Engineering a future where #nopatientwaits.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade