Patch Management on Microsoft Azure

Patch Management

This blog post is intended to provide a detailed guidance around setting up a Patch Management process on Microsoft Azure Cloud.

For all Cloud IaaS deployments, having a Patch Management process is essential. It is as Important as Patch Management process at your on-premises DC

Why we need Patch management?

There are many compelling reasons, like:

  • Plugging any security vulnerabilities in the OS or Installed Application Software
  • Proactive protection against newer threats and malware
  • Fixing existing platform/software bugs
  • Performance and stability Improvements
  • Addressing known Issues
  • Meet Compliance requirements (like SOX)
  • And many more…

In this post, we will look at Patch Management for Cloud IaaS deployments, specifically on Microsoft Azure, and for Windows Server based Azure VMs. We will not specifically cover Linux based Azure VMs here, but same base guidance would apply to them equally.

However, what we discuss here would equally apply to any other Cloud IaaS platform like AWS or GCP. Though, we will occasionally reference the traditional on-premises Patch management process, wherever required.

Fundamentally, Cloud IaaS model is a virtualized abstraction of  physical Infrastructure. It is built on underlying clusters of physical host servers of various capacities/capabilities. The responsibility of patching these underlying physical host servers rests with the Cloud provider. In case of Azure, Microsoft holds this responsibility.

However, for VMs provisioned on the Cloud IaaS layer, VM maintenance is sole responsibility of the customers. This model of shared responsibility is same across all Cloud providers, like Azure, AWS, GCP etc.

Now let’s focus on Patch Management from Microsoft Azure perspective.

Microsoft does regularly update VM Images they have published in the Azure Marketplace, with latest patches. These Images are thoroughly tested for stability, before being published in the Marketplace. However, Microsoft does not make the frequency/schedule public for updation of these VM Images. Hence, whenever you create a new VM based on an Image from the Azure Marketplace, you would be lucky if you get one which has been just updated with latest patches. That will save you from applying any additional updates (rare chance). In nearly most cases, depending on how far did Microsoft update the Image, you will have to download a larger/smaller delta of the applicable patches.

Given that both Windows Server OS and Azure Platform are Microsoft products, would have been Ideal if Microsoft had a native automated patch management service in Azure.

[Update Start: 28th Jan 2018]

However, Microsoft does not currently have any full-featured standard Azure based native service offering for Patching/Update management. At best what they offer is a revised “Update Management” solution (still in preview as of date of this blog post version) through Azure Automation, which is linked with another external Microsoft service called Microsoft Operations Management Suite (OMS). This new Update Management solution collects Updates related data from all the VMs (Windows/Linux) deployed in Azure and/or On-premises (Hybrid setup) through Microsoft OMS agents installed on those VMs, and pushes that data to OMS. Thereafter, you can use OMS to monitor the Update status of the monitored VMs to see which ones are missing any updates, and push Installation of those missing Updates unilaterally. However, OMS based Update management solution currently misses many critical features/capabilities essential for a good Update/Patch management solution, and is a no-go option for any production IaaS deployments.

[Update End: 28th Jan 2018]

Microsoft still expects customers to either manually do the patch management themselves (using native tools like WSUS, MBSA, PowerShell etc.), or use commercial patch management systems. This strategy does not make things any easier for customers. However,  it does Indirectly benefit promoting an ecosystem of ISVs, who build such products to be sold commercially.

You can see my feedback to Microsoft around this concern at the Official Azure User Voice forum here: Azure User Voice. Once I get a response on this feedback, I will update this post with the response.

Organizations considering either migrating their existing on-premises workloads to Azure, or building net new Cloud Infrastructure, will necessarily need to consider having a Cloud Patch management process.

  • Orgs already having an existing and mature patch management process at on-premises, would assume that all they need to do is follow the same process on Azure. While that is true to some extent, they will still need to revisit their existing process, and fine-tune it for Azure IaaS model
  • Orgs who do not already have an existing or mature Patch management process, can follow guidance in this post to help them establishing one for their Azure IaaS environment.

Let’s look at the following step-wise approach an Organization should consider, for establishing a patch management process on Azure (or any Cloud IaaS for that matter):

  1. Prepare Patch Inventory
  2. Perform VM Baselining
  3. Discover Patch Notification & Repository Channels
  4. Setup Patch Management System
  5. Patch Testing & Authorization
  6. Patch Monitoring

Stage 1: Prepare Patch Inventory

You should first create a Patch Inventory, which should capture following information for your IaaS deployment:

  • Identify and list of all patches, past and present, for each VM Server OS versions – You can start with patches applied to the VM Baseline you prepare. See Stage 2 below.
  • All patches which failed during testing, and were eventually never applied in production– When? With reason(s)
  • All patches which failed during testing, but were later fixed and applied in production – Why/How/When?
  • Details of any patch related support Incidents raised with Microsoft PSS or an external Support provider
  • Authorization status for each patch – This will come after Patch testing stage
  • Production Impact of applying each patch- This will come from Patch testing stage
  • Justification for applying the patch in production – This will come from Patch testing stage
  • Approvals for applying patch in production – This will come after patch testing stage

Additionally, you should also prepare another related Inventory for production VM’s in your environment, which should capture following information:

  • List of all Azure production VMs deployed in the concerned Azure IaaS Solution
  • For each production Azure VM:
    • Configuration Information like Server OS/version, Software/versions Installed
    • Role, function, business and security criticality
    • Access/ownership information
    • All patches applied to the VM in chronological order – Since VM provisioning till current date
    • For each patch successfully applied – Testing date and outcome status
    • Any patch rollbacks performed – Why/How/When?
    • All rollbacks performed, due to Issues arising from failed/rogue patches applied – Why/How/When?
    • Known security Issues, and newly discovered ones
    • Change tracking/history for any changes on Security levels

These Inventory Items should be regularly updated on a predefined frequency, which will depend on the patching cycle you may want to follow. Inputs for this Inventory will also come from later  stages in the Patch management process, like from Patch Testing stage.

The above listed Inventory data points are not absolutely exhaustive, but should give you a fair Idea on what levle of Inventory you must have, before embarking on Incorporating a patch management process on Azure.

Stage 2 – Perform VM Baselining

Baselining VMs refers to building an initial stable configuration of the VMs, established at a specific point-in-time. This means that the VM Server OS, Application Software(s) Installed within, and any Initial configurations done on either of these, are thoroughly tested, found stable, and standardized for being used as a base VM configuration. Baselining VMs enables us to reliably restore them from any future state to a previously stable state, and helps probing/rectifying any potential problems with a later version. It also helps to minimize amount of patches/updates we need to deploy on the VMs as well as gives us an ability to monitor compliance at a granular level.

For baselining Azure VMs, you should consider following high-level process:

  • Group Azure VMs in your Azure IaaS deployment, into different Asset categories
  • Prepare and maintain standard VM baselines for each category, which should have similar Azure VM Server OS/version, Application Software/version, and patches
  • You could either have a single VM baseline for all Asset categories in your deployment, or have different VM baselines for each Asset category
  • Whether you need a single or multiple VM baselines primarily depends on the differences between VM and Application Software configuration across different Asset categories, and how certain patches affect different baselines differently
  • Prioritize distribution of patches to Azure VMs on the basis of Asset categories

Stage 3 – Discover Patch Notifications and Repository Channels

Next, you would need to discover and setup channels for getting regularly notified on new patches for the VM Server OS/version and Application Software(s)/version installed within.

You will also need a remote repository source/mechanism to download these patches on an Update server (where they will be tested first against VM Asset categories), through an automated mechanism preferably.

For the Windows Server OS running on Azure VM, and any other Microsoft Application Software(s) Installed within, you can get regular notifications through Microsoft Security Bulletin Service from Microsoft Security Response Center (MSRC). You can then automatically trigger download of these patches/updates through existing native services/tools (like WSUS, MBSA etc.)

However, for non-Microsoft Application Software(s) installed in the Azure VM, this will vary greatly, and will depend on existing update notification channel for those Software  vendors (if they exist, what frequency they operate on, and in what form) as well as downloading mechanism.

Stage 4 – Setup Patch Management System

After you have discovered and setup patch notification and repository channels, next step would be to look at setting up a patch management system.

Before you move forward on selecting a patch management system, you should:

  • Determine one or more locations (a.k.a Update Servers), where the patches would be downloaded for further distribution. For Azure IaaS environment, you could either have these Update Server(s) located on Azure itself, or on-premises (In case of a Hybrid setup), or at both places. You will need to carefully decide on where these Update Server(s) should be for your specific scenario, and will depend heavily on your current Infrastructure architecture. Some common scenarios are depicted below:
    • Cloud only scenario: If your entire Infrastructure is on Azure, you will obviously decide to have the Update Server(s) on Azure itself. If your deployment is spread across Azure regions/subscriptions, better Idea would have an Update Server for each region/subscription combine
    • Hybrid Cloud scenario: If you have majority of your servers (>50%) on-premises, but relatively fewer servers on Azure (>10%), or vice-versa, you should consider having an Update Server both on-premises, and on Azure. If you have very minimal number of servers (<10%) at either location, compared to the other location having majority of the servers (>=90%), you are better off having an Update Server only at the location with majority of the severs and distributing the patches/updates to the location with minimal servers
    • Remember this – If you have Update Server(s) on-premises, and would be pushing patches/update to Azure, or vice-versa, you will generate considerable traffic between boundaries, leading to reliability, latency, and cost Implications
  • Ensure that you maintain patch Inventory for production based on stable criteria), and for pre-production environments as given in stage 1 above – This will simplify the overall patch management process

There are a number of tools/solutions available for Patch management, few from Microsoft, and several from commercial vendors. Some of these tools/solutions support only Windows Server OS, and others also support Linux Server OS. You could use either of these tools/solutions for your Azure IaaS environment. However, your choice will depend on factors like Implementation efforts, time, cost of deployment, licensing, support options etc.

Few such popular tools/solutions are listed below:

  1. Microsoft Baseline Security Analyzer and WSUS – Free
  2. System Center Configuration Manager (SCCM) – Paid
  3. Microsoft OMS – Paid
  4. SolarWinds Patch Manager – Paid
  5. Shavlik Protect + Empower, and Shavlik Patch – Paid
  6. LANDesk Patch Manager – Paid
  7. GFI LanGuard – Paid
  8. PDQ Deploy Pro – Paid

Some of these tools offer limited support for few stages detailed in this post, but none of them supports the whole defined process end-to-end.

Stage 5 – Patch Testing & Authorization

You need to establish a mandatory Patch Testing process as part of the overall Patch Management process. Let us look why.

Imagine a scenario, where you apply a new patch on one or more VMs in your Azure IaaS environment. You then discover that suddenly one or many things stopped working. Maybe you are unable to RDP into the VMs, or Installed Application starts misbehaving, or host of other problems surface. These are some of the many common Issues, which frequently occur when you don’t test patches before applying them in production VMs.

Testing any patches, before applying on production Azure VMs is always deemed a mandatory step you will need to rigorously follow. Not doing so may lead to very serious Implications for your deployment.

  • You should NEVER consider applying any patches directly to the Azure VMs in your Production environments. It is a BIG RISK, any whichever way you look at it.
  • You should first test patches on Azure VMs in a test (Pre-Production/Staging) Infrastructure environment on Azure, with corresponding equivalent configuration/roles of the Production Environment Azure VMs. You might ask here on the need for requiring exact configuration/role Azure VMs are in the test environment. This should be so that you don’t get unpredictable outcomes from applying patches on different VM configurations.

However, misses do happen in real-life, and few untested patches may very well make their way to production Azure VMs. Also, If the testing process is not thorough, problematic patches can easily escape undetected to production, causing Issues.

When untested patches make their way to production environment, they may fail and also break current configuration/operations of the VMs. Your patch management process should have the ability to rollback and restore those Azure VMs to an earlier restore point. Not being able to do so can seriously compromise the intended functioning of the concerned VMs.

For VM rollbacks to be possible, you need to be already performing regular backups of your Azure VMs. Couple options for taking backup are through Azure Recovery Services Vault, and through System Center DPM.

All patch testing activity should be recorded in a separate testing repository, and should reference/record against the existing Patch Inventory from Stage 1.

Depending upon if a patch passed or failed during testing, an authorization status should be assigned to it in the Patch Inventory. This authorization status will determine if a patch is ready to be applied to the target VMs (or VM Asset categories), or needs to be deferred for future testing, or rejected.

After successful authorization of each patch, you also need to assess and record the Impact it will have, when applied to an Individual  VM or a VM Asset category in your deployment. The possible impacts could be like forced downtime, dependency on other patches/components, order of applying etc.

As a final step, each patch will need to undergo an approval process, based on justification you give on why is it Important to be applied to the production servers. This Information will also get captured in the Patch inventory.

Stage 6 – Patch Monitoring

Once you have the Patch testing process setup, you will then need to setup a Patch monitoring process. Here you will need to regularly probe all your Azure VMs to identify the following:

  • Missing Updates
  • Installed Updates
  • Failed Updates
  • Incomplete Updates

Once you are able to get above Information, you will need to compare that against the list of authorized/approved patches in Patch Inventory. This way you will be able to find out which patches need to be applied/reapplied, where, when, and in what order. Thereafter, you can schedule for their manual/automated deployment accordingly.

Additionally, you should consider performing following activities on a schedule as a part of patch monitoring:

  • Perform regular Audit for Installed vs Authorized Updates for your Azure VMs
  • Regularly track your patch inventory, and update Installation status/progress for all patches on Azure VMs in your deployment.


Intent of this post was to give you good understanding on how to plan for Incorporating patching management for your Azure deployments.

Hope you enjoy reading this post. I would really appreciate any feedback/thoughts/comments/questions you may have, which you can communicate through comments below or direct mail.

Update 4/11/2016:

I was asked an interesting question from a reader today, after he read this post.

His question was:

“Why don’t we enable auto-update on all Cloud/Azure VMs, and let them update themselves whenever the need be? Windows already has this mechanism of Auto Updates, and same can be scheduled similarly on Linux too. If any updates fail, we can always restore from the Backups, isn’t it?”

My response:

“Never should we allow auto-updates to happen on Windows or Linux servers in production, whether on-premises or on Cloud. If we do, we expose our production deployment to a Huge Risk as anytime an update related failure may occur, rendering our production environment unusable. This practice of disallowing auto-updates is mandatorily followed by most Orgs across the world, for both their on-premises and Cloud deployments. You could maybe enable auto-updates in a dev/test environment, because there is minimal Impact there.

Furthermore, all good Infrastructure deployments in the Cloud or on-premises, will either never give VMs direct access to Internet, or only give restricted access secured behind proxies/bastions/WAF’s. So enabling auto-updates over Internet would anyways be not available”



  1. Arjun, It’s a very detailed, informative, and helpful post. The article has provided the complete knowledge and right approach for the Patch management which fits in all scenarios.
    Thanks for the enlightenment and looking forward for your next word.

    • OMS does have an update management solution, which can be scheduled to patch target VMs, but then I wouldn’t call it practically much usable. It needs to evolve further (and hoping it will) offering a more complete and robust patching management solution OOTB.

      OMS does update management currently by creating an Azure automation account in the subscription which is associated with the OMS workspace. In that automation account, couple hidden runbooks are created, viz. Patch-MicrosoftOMSComputer and Patch-MicrosoftOMSComputers, which you cannot view/edit/control. The Patch-MicrosoftOMSComputers runbook configures all VMs in your OMS workspace as an Azure Hybrid Runbook Worker. The Patch-MicrosoftOMSComputer runbook is then run once for each VM that you target your Updates for. Once patching finishes, you can see the updated patch status of all the VMs from within OMS. This is all that is currently offered, missing out on many more important features required for patching management.


  2. Most of the on-premise use HPE Server Automation tool, we could have some definitive solution in Azure to in a near future. OMS is quite complex and has its limitations.

    • I agree HPE Automation tools do have large presence among enterprises for on-premises environments. There are also other solutions, which have some part of the overall market share, especially the SMB segment.

      However, for Cloud environments, any of these vendors offering capabilities like patch management need to make their respective commercial offerings available in respective Cloud Marketplaces (like Azure or AWS etc.). I do not see that having happened as yet, even with HPE Automation tools. I can think of a number of realistic reasons why this would be so (and would be intentional), primarily emanating from vendor strategies around their future focus and their own investments in Cloud. Besides making vendor tools available through respective Cloud marketplaces under a cloud model, they would also require defining cloud oriented consumption based licensing model of their tools, licensing mobility to cloud for existing customers, ability to split licenses between on-premises and cloud for hybrid cloud setups, agreements with the cloud vendor etc. Its a lot of Investment and effort from the vendor, which needs to go into making this a possibility, and then all of that needs to be justified with an ROI, which will be realized only over a long term compared to existing on-premises model.

      Ideally, Microsoft has the ability to Introduce a native patch management service for Azure (they have something remotely similar in Azure Service Fabric, known as POA), and that too very fast. However, from a business strategy perspective this would mean cannibalizing certain partners, and would likely backfire (like in the case of Azure RemoteApp and Citrix). I think that is why they don’t have a native service for this in Azure yet, but then knowing Microsoft, we never know they may pop-up with such a service anytime in near future, which they either could build themselves, or enable (fund) one or more of their partners to offer on Cloud. I asked some Azure Product Group folks on this, and all of them denied any knowledge – Probably they already knew or they didn’t.

      In my experience, OMS is not complex at all. It is just half-baked in certain areas, Including patch management. MS is apparently working on Improving it further. What OMS has today around patching, you can identify the patches/updates missing on VM’s in your environment, and then push them to those respective VMs through Azure Automation. However, that is where the capability stops, and many other important aspects of patch management are not at all touched there. Hopefully, we will see that improve in future, if MS comes up with a separate dedicated patch management service of their own or enables their partners to offer such solutions on Cloud.

  3. The new Update Management solution is neither available across all US regions nor does it work when the Log Analytics workspace is in a different subscription. It doesn’t even let you cherry pick what updates once can push through.
    A lot more use cases need to be satisfied and long way to go for Update Management in OMS/Log Analytics

    • I agree with your points. MS is going pretty slow on making a full-fledged Update management solution available, for reasons known best to them. I wonder, why to take so much time when if you think technically it is not that complex.

  4. thank you for this wonderful article concerning patch management in Azure. It helped me with issues I am having going from a datacenter solution to a cloud solution. Just a quick comment on MS coming up with a patch management system, I wouldn’t forsee them pushing it past where they are now. They already have a fully baked solution, SCCM. And they are pushing users that have moved to the cloud from IaaS to PaaS or SaaS solutions. I do agree, OMS is only partially baked. I cannot tell my app developers EXACTLY what patches will be applied to their VM’s. The reporting is only after the updates are completed.

    My biggest headache currently is that as our IaaS environment continues to grow, I cannot add to the groups I have already created and have to recreate them every month, to ensure I am not missing any VM’s in the update cycle.

    thanks again for the great info in your article

  5. Update management from OMS seems performing auto update , just as what default windows update provides.
    I`m looking to control what patches to be applied on Azure VM, is OMS still the appropriate option, any other product?

    • Unfortunately, OMS still provides a half-baked solution to update/patch management as well as the new Update feature within Azure is also the same more or less. As I noted, Microsoft seems to be holding back on providing a full-featured native patch management solution most probably because they want to leave the space open for their partners. You could still install/configure the 3rd party tools I have mentioned in the post on Azure VMs to get the desired results like many are doing now (or use SCCM if you have that). HTH

  6. Hi every one!,
    Thanks for this greatefull Article which help me a lot.
    I know that it has taken a year before now, but I have some others doubts to figure out about the Software as a Service Model (SaaS).
    Is there a way to retrive from Microsoft Azure reports about the Patch Management of thoses Applications which are using SaaS and not only IaaS ???

    You know!, it’s so clear to me that in IaaS we need to provide a Workspace and order and configure the Patch Management and whatever, and afterall pick up the rights Virtual Machines we desire to update, ok…
    But what about SaaS ? I understand that obviusly Microsoft has to support and provide the SaaS Pach Management automatically because we don’t have access into the infrastructure, but how can we know about this patch management process?
    There are reports to the customers ?


    • Hi Rafael,

      Sorry for the delay in response.

      I had posed somewhat the same question long back to few PG contacts at MSFT about the availability of data/reports about the patch management process, and the cadence they follow for the underlying VMs they utilize (and hide as per the services model) for the PaaS and SaaS services. However, MSFT folks clearly stated that they are under no obligation to share any related data outside the Internal teams responsible for managing/monitoring the patching. They deem this data strictly Internal restricted only, and sharing this data outside of the concerned teams is both legally and policy-wise not allowed. The only Indicators you can get right now is in terms of what is exposed through “Azure Service Health” reports, which tells you about Service Issues, Planned Maintenance, and Health Advisories.

      If you analyze the sense in them not sharing this data in any form, you would realize that it is sensibly right because customers go for PaaS/SaaS models primarily because they don’t want to do management and maintenance of the underlying Infra, and how the cloud provider does the management/maintenance is not their problem anymore. While for some Orgs this data or any reports might be required for compliance purposes, but then if any Org plans to move to the Cloud, they are also required to re-analyze their current compliance needs, and ascertain if the compliance requirements needs to be adjusted in tandem with the Cloud model or not. Without adapting breaking aspects to the Cloud model, adoption of Cloud would be not very useful for Orgs.


  7. MS should have introduced a reliable and feature complete native Patch management solution for Azure right when they Introduced IaaS as part of Azure. They got too late on this, and still there is no definitive solution out yet. Hopefully they will have some in near future.


1 Trackback / Pingback

  1. Azure Patch Management -

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.