Using Azure Update Management to Automate On-Premises Server Patching

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

 

Hello everyonemy name is Daniel Metzger and I am a Senior Premier Field Engineer for Secure Infrastructure based in Switzerland. Lately, when delivering an Active Directory Risk Assessment, it turned out the public sector customer had never patched his domain controllers for more than a year. Investigating the reason for during the assignmentI was told internal IT staff simply had no time to apply security updates to their most critical Windows servers. 

 

Wait a minute – no time for very basic security routine? I told them about Azure Update Management which is provided by Microsoft almost free of charge. You will find the service documentation here. Additionally I made them aware of the PowerShell tools to maintain Windows Server Update Services (WSUS) and especially the Get-WsusUpdate and Approve-WsusUpdate cmdlets. 

 

Within a few hours we set up a local WSUS dedicated to Tier 0 servers (although they had no tiering in place, yet, because – yes, no time for), auto-approval for Windows Defender updates and a simple, scheduled script to approve specific updates automatically. A snippet from that script looks like: 

 

Get-WsusUpdate -Approval Unapproved | Where {$_.update.title -like "*for Windows Server 2016 for x64*"} | Approve-WsusUpdate -Action Install -TargetGroupName "Tier 0 Server"
Get-WsusUpdate -Approval Unapproved | Where {$_.update.title -like "*Windows Server 2016 (1803)*"} | Deny-WsusUpdate 

 

Introducing Azure Update Management

 

The ultimate piece to the fully automated patch solution is provided by Azure Update Management:

 

https://docs.microsoft.com/en-us/azure/automation/automation-update-management 
"Update Management solution in Azure" 

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/gateway 
"Connect computers without internet access by using the Log Analytics gateway in Azure Monitor" 

https://docs.microsoft.com/en-us/azure/automation/automation-onboard-solutions-from-automation-account 
"Onboard Update Management, Change Tracking, and Inventory solutions" 

https://docs.microsoft.com/en-us/azure/automation/automation-tutorial-update-management 
"Manage updates and patches for your Azure VMs" 

 

The high level steps to create the necessary resources for Tier 0 servers are: 

 

  1. Create a resource group for Tier 0 assets 
  2.  Create a Log Analytics workspace in the resource group 
  3.  Create an automation account in the resource group 
  4.  Enable Update Management for the automation account 
  5.  Install and configure an Azure Log Analytics (OMS) gateway for Tier 0 assets 
  6.  Install and configure the Azure Log Analytics agent (MMA) to Tier 0 assets 
  7.  Create deployment schedules for Update Management 
  8.  Repeat for Tier 1 assets 

  

Create a resource group and resources for Tier 0 assets 

 

 

For on-premises environments we strongly recommend Microsoft's tiering model. The documentation for is located hereIn Azure we can split Tier 0 and Tier 1 update management by creating separate resource groups, Log Analytics workspaces and automation accounts, each with its own Role Based Access Control (RBAC) setting to separate administrative permissions. Organizations can even have distinct subscriptions for Tier 0 and Tier 1. 

 

For the purpose of this demo we start with creating the resource group and resources for Tier 0. I have an habit to open PowerShell locally and work from there. The following script ask you for your credentials to sign in to your Azure tenant and subscription. It then creates the resource group and places an automation account and Log Analytics workspace there before enabling the Update Management solution for the workspace. 

 

 

Disclaimer 
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. 
 
#******************************************************************************************* 
# Sign in to your Azure account 
#******************************************************************************************* 
Connect-AzAccount 
#******************************************************************************************* 
# Get your AD subscription ID 
#******************************************************************************************* 
Get-AzSubscription | Sort Name,SubscriptionID | Select Name,SubscriptionID 
#******************************************************************************************* 
# Set your Azure subscription. Replace everything within the quotes, 
# including the < and > characters, with the correct SubscriptionID 
#******************************************************************************************* 
$subscrID="<SubscriptionID>" 
Select-AzSubscription -SubscriptionID $subscrID 
#******************************************************************************************* 
# Set parameters 
#******************************************************************************************* 
$rgName="Tier0Infrastructure" 
$locName="West Europe" 
$AutoAccName="Tier0InfrastructureAutomation" 
$WSName="Tier0InfrastructureWS" 
$solution="Updates" 
#******************************************************************************************* 
# Create new resource group. Adjust location if you want a different one 
#******************************************************************************************* 
New-AzResourceGroup -Name $rgName -Location $locName 
New-AzAutomationAccount -Name $AutoAccName -Location $locName -ResourceGroupName $rgName 
New-AzOperationalInsightsWorkspace -Location $locName -Name $WSName -Sku Standard -ResourceGroupName $rgName 
Set-AzOperationalInsightsIntelligencePack -ResourceGroupName $rgName -WorkspaceName $WSName -IntelligencePackName $solution -Enabled $true 

  

This is the result of running the script: 

  

DanielMetzger_0-1587812269515.png

  

Enable Update Management solution for the automation account 

 

 

Next we enable Update Management for the automation account. Select the automation account created, select Update management and the Log Analytics workspace. 

 

 

DanielMetzger_1-1587812269516.png

 

 

__00.png 

Install and configure an Log Analytics gateway (OMS) Gateway for Tier 0 assets 

 

 

Since we do not want Tier 0 servers to connect to the Internet directly we will set up a OMS Gateway for them. This requires the installation of the OMS Gateway which can be downloaded here. Although the OMS Gateway is being rebranded to Log Analytics Gateway many components and documentations still refer to the old name. The gateway sends data to Azure Automation and the Log Analytics workspace in Azure Monitor on behalf of the computers that cannot directly connect to the Internet. 

 

You can install the gateway using an elevated command line as follows, assuming you want to define port 8080 for the gateway: 

 

msiexec.exe /i "<Path>\OMS gateway.msi" /qn PORTNUMBER=8080 LicenseAccepted=1 

 

For the Automation Hybrid Runbook Workers to work we need to add allowed hosts to the OMS gateway. The host entries depend on the region you want your Tier 0 servers connect to. The list of DNS records for available regions can be found here. Automation Hybrid Runbook Workers are required to run Azure Update Management cycles on Tier 0 servers. We will define some sample update cycles later after connecting Automation Hybrid Runbook Workers to the Log Analytics workspace we have created. 

 

The following elevated PowerShell commands add the agent service registration URL and the Job Runtime Data service URL for West Europe (WE) to the Allowed Host list on the Log Analytics gateway. 

 

Import-Module OMSGateway 
Add-OMSGatewayAllowedHost we-agentservice-prod-1.azure-automation.net 
Add-OMSGatewayAllowedHost we-jobruntimedata-prod-su1.azure-automation.net 
Restart-Service OMSGatewayService 

 

You can check for the list of Allowed Hosts using the following PowerShell line. 

 

Get-OMSGatewayAllowedHost 

 

DanielMetzger_3-1587812269521.png

 

  

Next we need to install the Log Analytics agent which is also referred to as the Microsoft Monitoring Agent (MMA) on the same host as the Log Analytics gateway runs. The Log Analytics agent must report to the same workspace as the agents that communicate through the gateway. You download the agent from the Log Analytics workspace as documented here. 

 

From an elevated command prompt you can initiate the installation of the agent on the Log Analytics gateway host as follows. Before installing the Log Analytics agent for Windows, you need the workspace ID and key for your Log Analytics workspace. 

 

MMASetup-AMD64.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID="<Workspace ID>" OPINSIGHTS_WORKSPACE_KEY="<Workspace key>" OPINSIGHTS_PROXY_URL=<FQDN:PORT> AcceptEndUserLicenseAgreement=1 

 

 

Add Tier 0 servers to the workspace 

 

 

The same command will work on all Tier 0 servers you want to add to the Log Analytics workspace and the Azure Update Management solution. The Log Analytics agent supports the Automation Hybrid Runbook Worker. 

 

After you have added the first couple of Tier 0 servers including the Log Analytics gateway host to your Log Analytics workspace, you get the following view. It might take a few minutes for them to show up but they eventually will. 

 

__00.png

 

Add update deployments to the Update management 

 

 

Next we need to define update cycles a.k.a. Deployment schedules for updates to be applied. An example would be a schedule which runs every hour but does not restart servers after updates have been installed. Such a cycle would install Windows Defender signature updates shortly after the have been automatically approved on a local Windows Server Update Services (WSUS) server dedicated to Tier 0 servers and administrative workstations. 

 

DanielMetzger_5-1587812269507.png

 

 

To add an update cycle, select Schedule update deployment. 

 

 

DanielMetzger_6-1587812269508.png

 

  

To simplify adding computers to specific update deployments I always work with security groups imported from the local Active Directory. In AD, you create groups like "Tier0-AZ-UpdateAutomation-NoRestartCycle" or "Tier0-AZ-UpdateAutomation-RestartCycle1" and add servers as members. You do not have to select those groups to get synchronized with Azure AD Connect to show up in your Log Analytics workspace. They get there automatically as the Log Analytics agent recognizes memberships of the host it runs on. In fact, Azure AD Connect is not required for Azure Update Management at all. 

 

You define which group or groups will be included in an update deployment, which update classifications are included or which specific updates are excluded, the schedule, any scripts you want to run before or after applying updates and whether you want the targeted servers to reboot if necessary. The Maintenance window is something I almost never touch but leave it to its default 120 minutes. This is the time the runbooks have to execute and finish. Shortening the maintenance window could potentially lead to deployment run errors if runbooks do not finish in time. 

 

__00.png

 

 

DanielMetzger_8-1587812269509.png

 

 

DanielMetzger_9-1587812269510.png

 

Repeat for Tier 1 assets 

  

Once your done you would repeat the same steps for Tier 1 servers in your environment, creating separate resources in Azure to accomplish update automation for them. 

 

So next time we meet, having no time for patching will not be an excuse anymore thanks to Azure Update Management and the fine automation tools Microsoft provides in the cloud. Enjoy! 

2 Replies to “Using Azure Update Management to Automate On-Premises Server Patching”

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

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