Home Cloud Azure Server Patching with Azure Update Management for Azure Servers

Server Patching with Azure Update Management for Azure Servers


Let’s learn Server Patching with Azure Update Management for Azure Servers (Windows & Linux). How many of you are wondering what is the solution for server patching? Obliviously SCCM (a.k.a ConfigMgr) can handle Windows server patching using Orchestration groups.

NOTE! – Let’s use this method to patch SCCM servers hosted in Azure and On-Prem SCCM servers? What do you think? Note down in the comments section or ask a question over https://forum.howtomanagedevices.com/

Azure Update Management

Update Management is available for both Windows and Linux. The solution uses the Microsoft Monitoring Agent (MMA) for Windows or Linux, PowerShell Desired State Configuration (DSC) for Linux, an Automation Hybrid Runbook Worker, and Microsoft Update or Windows Server Update Services (WSUS) for Windows servers.

NOTE! – You can manage both LINUX and Windows server with Azure Update Management (AUM) solution. AUM solution can be used for both on-prem and Azure servers.

Advertisement Altaro Office 365 Backup

Supported Operating System Versions

Let’s see what are the supported OS version of Azure Update Management solution.

Operating systemNotes
Windows Server 2019 (Datacenter/Datacenter Core/Standard) 
Windows Server 2016 (Datacenter/Datacenter Core/Standard)
Windows Server 2012 R2(Datacenter/Standard)
Windows Server 2012
Windows Server 2008 R2 (RTM and SP1 Standard)Update Management only supports performing assessments for this operating system, patching is not supported as the Hybrid Runbook Worker is not supported for Windows Server 2008 R2.
CentOS 6 (x86/x64) and 7 (x64)Linux agents requires access to an update repository. Classification-based patching requires yum to return security data that CentOS doesn’t have in its RTM releases. For more information on classification-based patching on CentOS, see Update classifications on Linux.
Red Hat Enterprise 6 (x86/x64) and 7 (x64)Linux agents requires access to an update repository.
SUSE Linux Enterprise Server 11 (x86/x64) and 12 (x64)Linux agents requires access to an update repository.
Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 (x86/x64)Linux agents requires access to an update repository.

Unsupported Operating System Versions

Let’s see what are the unsupported OS version of Azure Update Management solution.

Operating systemNotes
Windows clientClient operating systems (such as Windows 7 and Windows 10) aren’t supported.
Windows Server 2016 Nano ServerNot supported.
Azure Kubernetes Service NodesNot supported. Use the patching process described in Apply security and kernel updates to Linux nodes in Azure Kubernetes Service (AKS)

Client Requirements

The following information describes OS-specific client requirements. For additional guidance, see Network planning.

Windows agents must be configured to communicate with a WSUS server, or they require access to Microsoft Update.

You can use Update Management with Configuration Manager. To learn more about integration scenarios, see Integrate Configuration Manager with Update Management. The Log Analytics Windows agent is required. The agent is installed automatically if you’re onboarding an Azure VM.

By default, Windows VMs that are deployed from the Azure Marketplace are set to receive automatic updates from Windows Update Service. This behavior doesn’t change when you add this solution or add Windows VMs to your workspace. If you don’t actively manage updates by using this solution, the default behavior (to automatically apply updates) applies.

Note! – A user can modify Group Policy so that machine reboots can be performed only by the user, not by the system. Managed machines can get stuck if Update Management doesn’t have rights to reboot the machine without manual interaction from the user.

For more information, see Configure Group Policy settings for Automatic Updates.

Update classifications

The following tables list the update classifications in Update Management, with a definition for each classification.

Critical updatesAn update for a specific problem that addresses a critical, non-security-related bug.
Security updatesAn update for a product-specific, security-related issue.
Update rollupsA cumulative set of hotfixes that are packaged together for easy deployment.
Feature packsNew product features that are distributed outside a product release.
Service packsA cumulative set of hotfixes that are applied to an application.
Definition updatesAn update to virus or other definition files.
ToolsA utility or feature that helps complete one or more tasks.
UpdatesAn update to an application or file that currently is installed.

How to add computer to Azure Update Management

You must have a subscription to Microsoft Azure if you don’t have subscription you can create free subscription.

Get workspace ID and Key for Log Analytics

To connect computer with Azure Log Analytics. Workspace ID and Key is required during the setup for each installation methods to properly configure the agent and ensure it can successfully communicate with Azure Monitor in Azure commercial and US Government cloud.

  • In the Azure portal, search for and select Log Analytics workspaces.
  • In your list of Log Analytics workspaces, select the workspace you intend on configuring the agent to report to.
  • Select Advanced settings.
Server Patching with Azure Update Management for Azure Servers
Find Log Analytics Workspace ID and Primary KEY – Server Patching with Azure Update Management for Azure Servers
  • Select Connected Sources, and then select Windows Servers.
  • Copy and paste into your favorite editor, the Workspace ID and Primary Key.

Are you still using the old the workspace? You might want to consider moving to portal.azure.com, as I imagine the workspace will go away.

That is how you find those keys. Remember when reading any documentation for Azure Log Analytics, CustomerID = Workspace ID and Shared Key = Primary Key.

Configure Agent to use TLS 1.2

To configure use of the TLS 1.2 protocol for communication between the Windows agent and the Log Analytics service, you can follow the steps below to enable before the agent is installed on the virtual machine or afterwards.

 Note! – If you are configuring a VM running Windows Server 2008 SP2 x64 to use TLS 1.2, you first need to install the following SHA-2 code signing support update before performing the steps below.

  1. Locate the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
  2. Create a subkey under Protocols for TLS 1.2 HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
  3. Create a Client subkey under the TLS 1.2 protocol version subkey you created earlier. For example, HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client.
  4. Create the following DWORD values under HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client:
    1. Enabled [Value = 1]
    1. DisabledByDefault [Value = 0]

Configure .NET Framework 4.6 or later to support secure cryptography, as by default it is disabled. The strong cryptography uses more secure network protocols like TLS 1.2, and blocks protocols that are not secure.

  1. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319.
  2. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
  3. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319.
  4. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
  5. Restart the system for the settings to take effect.

Install the agent using setup wizard

The following steps install and configure the Log Analytics agent in Azure and Azure Government cloud by using the setup wizard for the agent on your computer.

  • In your Log Analytics workspace, from the Windows Servers page you navigated to earlier, select the appropriate Download Windows Agent version to download depending on the processor architecture of the Windows operating system.
  • Run Setup to install the agent on your computer.
  • On the Welcome page, click Next.
  • On the License Terms page, read the license and then click I Agree.
  • On the Destination Folder page, change or keep the default installation folder and then click Next.
  • On the Agent Setup Options page, choose to connect the agent to Azure Log Analytics and then click Next.
  • On the Azure Log Analytics page, perform the following:
    1. Paste the Workspace ID and Workspace Key (Primary Key) that you copied earlier. If the computer should report to a Log Analytics workspace in Azure Government cloud, select Azure US Government from the Azure Cloud drop-down list.
    1. If the computer needs to communicate through a proxy server to the Log Analytics service, click Advanced and provide the URL and port number of the proxy server. If your proxy server requires authentication, type the username and password to authenticate with the proxy server and then click Next.
  • Click Next once you have completed providing the necessary configuration settings.
Server Patching with Azure Update Management for Azure Servers
  • On the Ready to Install page, review your choices and then click Install.
  • On the Configuration completed successfully page, click Finish.

When complete, the Microsoft Monitoring Agent appears in Control Panel. To confirm it is reporting to Log Analytics, review Verify agent connectivity to Log Analytics.

Install the agent using the command line

The downloaded file for the agent is a self-contained installation package. The setup program for the agent and supporting files are contained in the package and need to be extracted in order to properly install using the command line shown in the following examples.

 Note! – If you want to upgrade an agent, you need to use the Log Analytics scripting API. See the topic Managing and maintaining the Log Analytics agent for Windows and Linux for further information.

The following table highlights the specific parameters supported by setup for the agent, including when deployed using Automation DSC.

MMA-specific optionsNotes
NOAPM=1Optional parameter. Installs the agent without .NET Application Performance Monitoring.
ADD_OPINSIGHTS_WORKSPACE1 = Configure the agent to report to a workspace
OPINSIGHTS_WORKSPACE_IDWorkspace ID (guid) for the workspace to add
OPINSIGHTS_WORKSPACE_KEYWorkspace key used to initially authenticate with the workspace
OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPESpecify the cloud environment where the workspace is located
0 = Azure commercial cloud (default)
1 = Azure Government
OPINSIGHTS_PROXY_URLURI for the proxy to use
OPINSIGHTS_PROXY_USERNAMEUsername to access an authenticated proxy
OPINSIGHTS_PROXY_PASSWORDPassword to access an authenticated proxy
  1. To extract the agent installation files, from an elevated command prompt run MMASetup-<platform>.exe /c and it will prompt you for the path to extract files to. Alternatively, you can specify the path by passing the arguments MMASetup-<platform>.exe /c /t:<Full Path>.
  2. To silently install the agent and configure it to report to a workspace in Azure commercial cloud, from the folder you extracted the setup files to type:

or to configure the agent to report to Azure US Government cloud, type:


 Note! – The string values for the parameters OPINSIGHTS_WORKSPACE_ID and OPINSIGHTS_WORKSPACE_KEY need to be encapsulated in double-quotes to instruct Windows Installer to interprit as valid options for the package.

Install the agent using DSC in Azure Automation

You can use the following script example to install the agent using Azure Automation DSC. If you do not have an Automation account, see Get started with Azure Automation to understand requirements and steps for creating an Automation account required before using Automation DSC. If you are not familiar with Automation DSC, review Getting started with Automation DSC.

The following example installs the 64-bit agent, identified by the URI value. You can also use the 32-bit version by replacing the URI value. The URIs for both versions are:

 Note! – This procedure and script example does not support upgrading the agent already deployed to a Windows computer.

The 32-bit and 64-bit versions of the agent package have different product codes and new versions released also have a unique value. The product code is a GUID that is the principal identification of an application or product and is represented by the Windows Installer ProductCode property. The ProductId value in the MMAgent.ps1 script has to match the product code from the 32-bit or 64-bit agent installer package.

To retrieve the product code from the agent install package directly, you can use Orca.exe from the Windows SDK Components for Windows Installer Developers that is a component of the Windows Software Development Kit or using PowerShell following an example script written by a Microsoft Valuable Professional (MVP). For either approach, you first need to extract the MOMagent.msi file from the MMASetup installation package. This is shown earlier in the first step under the section Install the agent using the command line.

  1. Import the xPSDesiredStateConfiguration DSC Module from https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration into Azure Automation.
  2. Create Azure Automation variable assets for OPSINSIGHTS_WS_ID and OPSINSIGHTS_WS_KEY. Set OPSINSIGHTS_WS_ID to your Log Analytics workspace ID and set OPSINSIGHTS_WS_KEY to the primary key of your workspace.
  3. Copy the script and save it as MMAgent.ps1.
  4. Update the ProductId value in the script with the product code extracted from the latest version of the agent install package using the methods recommended earlier.
  5. Import the MMAgent.ps1 configuration script into your Automation account.
  6. Assign a Windows computer or node to the configuration. Within 15 minutes, the node checks its configuration and the agent is pushed to the node.

Install agent by using PowerShell script

Configuration MMAgent
    $OIPackageLocalPath = "C:\Deploy\MMASetup-AMD64.exe"
    $OPSINSIGHTS_WS_ID = Get-AutomationVariable -Name "OPSINSIGHTS_WS_ID"
    $OPSINSIGHTS_WS_KEY = Get-AutomationVariable -Name "OPSINSIGHTS_WS_KEY"

    Import-DscResource -ModuleName xPSDesiredStateConfiguration
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Node OMSnode {
        Service OIService
            Name = "HealthService"
            State = "Running"
            DependsOn = "[Package]OI"

        xRemoteFile OIPackage {
            Uri = "https://go.microsoft.com/fwlink/?LinkId=828603"
            DestinationPath = $OIPackageLocalPath

        Package OI {
            Ensure = "Present"
            Path  = $OIPackageLocalPath
            Name = "Microsoft Monitoring Agent"
            ProductId = "8A7F2C51-4C7D-4BFD-9014-91D11F24AAE2"
            DependsOn = "[xRemoteFile]OIPackage"

Validate agent connectivity

Once installation of the agent is complete, verifying it is successfully connected and reporting can be accomplished in two ways.

in Control Panel, find the item Microsoft Monitoring Agent. Select it and on the Azure Log Analytics tab, the agent should display a message stating: The Microsoft Monitoring Agent has successfully connected to the Microsoft Operations Management Suite service.

MMA Agent connected Azure Log analytics – Server Patching with Azure Update Management for Azure Servers

Update Management Solutions for Patching

Creating Schedule job in Azure Update Management

Connect Azure Portal click on subscriptions – Automation Account – Update Management – Schedule Update Deployment

Schedule Deployments

When you select Update Management on Right page Select “Schedule Update Deployment” to create schedule job for window patches installation.

Server Patching with Azure Update Management for Azure Servers

New Update Deployment

New Update Deployment window will open as in below screenshot.

Server Patching with Azure Update Management for Azure Servers

Enter the deployment name based on the easy understandable naming convention,

Example: “MonthlyPatching_TEST_April2020

One of the biggest asks from the community this year is for more flexibility in targeting update deployments, specifically support for groups with dynamic membership. Instead of specifying a static set of machines when you create an update deployment, groups allow you to specify a query that will be evaluated each time an update deployment occurs.

Server Patching with Azure Update Management for Azure Servers

After select the required patch group click OK

Update Classifications

Under Update classification select update classifications which you want to install them with schedule deployments as per your requirement

Server Patching with Azure Update Management for Azure Servers

Include / Exclude Updates

Under Include/Exclude Section any KB’s exclusive including or exclude can be done of required, enter required KB on the respective tab and Click OK

Server Patching with Azure Update Management for Azure Servers Linux and Windows

Schedule Time and Timezone settings

Under Schedule settings, select Time Zone and select time based on the downtime provided by application teams. (Time schedule should be after 15 mins for schedule deployment creation)

Server Patching with Azure Update Management for Azure Servers Linux and Windows

Maintenance Window

Select Maintenance window, minimum of 30 mins and maximum of 300 mins based on Windows Security patches count and Servers count

Server Patching with Azure Update Management for Azure Servers Linux and Windows

Reboot Options

Select Reboot option once patches installation completed.

  • Always Reboot
  • Reboot If required
  • Never Reboot
  • Only Reboot – Will not install updates

Schedule Deployment Validation

Once schedule deployment created Goto – Deployment schedules under Update management and could able to see recently created schedule and status as the timing mentioned while creating the schedule.

Server Patching with Azure Update Management for Azure Servers Linux and Windows

Schedule will begin at the time provisioned and we can find the progress of the schedule under History tab

Server Patching with Azure Update Management for Azure Servers Linux and Windows

To find the status of scan and each server’s patch status we could able to see in the server name and select the server name, to understand KB’s status (In-Progress, attempted, failed, succeeded, not-attempted)

Server Patching with Azure Update Management for Azure Servers Linux and Windows

Update Management Schedule Deployment logs

We can see the logs in under the logs tab in below.

Server Patching with Azure Update Management for Azure Servers Linux and Windows
Server Patching with Azure Update Management for Azure Servers Linux and Windows



  1. Hello Praveen,

    Can you help me to explain how to use RBAC with update management Automation account ? we have one centralize Update Management solution with multiple resource group . how we can manage permission where every resource group owner/Contributer can manage their respective workload with his ID only and cant do any modification in different resource group workload


Please enter your comment!
Please enter your name here

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

Exit mobile version