Azure Update Manager – Patching .NET Core
This blog will share how to configure an Azure Virtual Machine or an Azure Arc-enabled virtual machine to utilize Azure Update Manager for patching .NET Core security updates. There are two different changes that need to be made to the server to allow .NET Core to receive updates with Azure Update Manager: Step 1: Create a registry entry for .NET core updates Step 2: Change the Windows Server to receive other Microsoft Updates for patching. The registry change allows .NET Core to become available to Automatic Updates. .NET Automatic Updates for Server Operating Systems - .NET Blog (microsoft.com) Step 1: Create a registry entry for .NET Core updates You may execute PowerShell to enable this registry setting or create a .reg file to execute. PowerShell example for all of .NET core versions: New-Item -Path "HKLM:\SOFTWARE\Microsoft" -Name ".NET" -Force | Out-Null Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NET" -Name "AllowAUOnServerOS" -Value 1 -Type DWord Or a PowerShell example for a specific .NET core version: New-Item -Path "HKLM:\SOFTWARE\Microsoft\.NET" -Name "6.0" -Force | Out-Null Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NET\6.0" -Name "AllowAUOnServerOS" -Value 1 -Type DWord Registry File example: To use a .reg file for creating the registry entries, copy the text below into a new file (ex: dotnetcore.reg) and execute. This example will create both options for all versions of .NET core and version 6.0 of .NET core. Remove lines as needed. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET] "AllowAUOnServerOS"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0] "AllowAUOnServerOS"=dword:00000001 Step 2: Change the Windows Server to receive other Microsoft Updates for patching. The other required change to make to the server is to change the Windows Server to receive “other Microsoft products” updates. This change allows other Microsoft products such as SQL Server, and in this example of .NET Core to become available for updating Windows Machines. Configure Windows Update settings in Azure Update Manager | Microsoft Learn Run these commands in PowerShell to change the update settings to receive other Microsoft product updates: $ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager") $ServiceManager.Services $ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d" $ServiceManager.AddService2($ServiceId,7,"") Once these settings are changed. Use the ‘Check for updates’ option in Azure Update Manager. The patch should become available to the virtual machine for .NET Core. In this example, an Azure Windows Server 2022 machine image had the .NET Core 6.0.27 installed. After the machine was checked for new updates, the patch is available now for .NET core 6.0.28. For testing purposes this link is the .NET Core 6.0.27 installer. .NET Core 6.0.27 - Versions of .NET. In conclusion, configuring Azure Update Manager to patch .NET Core security updates is a crucial step in maintaining the security and performance of your Azure Virtual Machines. By enabling the registry setting for automatic updates, you can ensure that your .NET Core installations are always up-to-date with the latest security patches. This process not only simplifies the management of updates but also enhances the overall security posture of your environment. Whether you choose to use PowerShell commands or create a .reg file, the steps outlined in this article provide a clear and effective method for keeping your .NET Core installations secure and up-to-date. *** 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.
At-Scale Failure Reporting for Azure Update Manager
Introduction Azure Update Manager simplifies patching across Azure virtual machines and Azure Arc-enabled servers by providing a centralized platform for patch assessment and installation. However, as environments scale, a key challenge emerges—efficiently identifying and troubleshooting patch failures across large fleets of machines. While Azure Update Manager surfaces detailed error messages in the Azure portal, this information is typically available only at an individual machine level. In enterprise environments managing hundreds or thousands of systems, drilling into each VM to find error details quickly becomes impractical. In this article, we walk through a real-world use case and demonstrate how to leverage Azure Resource Graph (ARG) to extract failed machines along with their error details for a specific maintenance run—using a single query. The Challenge: Scaling Patch Failure Visibility In a large enterprise deployment, Azure Update Manager was configured to manage patching across: Windows and Linux virtual machines Azure cloud VMs and Arc-enabled on‑premises servers Multiple regions and subscriptions While patching operations were largely successful, a subset of machines experienced failures. The key challenges faced by the operations team were: Error messages were visible only by drilling into each failed VM in the portal No built‑in way to aggregate failures across all machines Lack of a simple mechanism to export: Failed VMs Error codes Error messages The team needed a scalable, query‑driven approach to analyze failures across an entire maintenance run. Key Insight: Where Azure Update Manager Stores Data Azure Update Manager does not rely on Log Analytics to store operational results. Instead: Patch assessment and installation results are stored in Azure Resource Graph Azure Resource Graph acts as a centralized, queryable store for update operations This design enables powerful querying without requiring additional ingestion, configuration, or cost overhead. Understanding Maintenance Runs and Correlation IDs Each Azure Update Manager maintenance run generates a unique identifier: properties.correlationId represents the maintenance (schedule) run ID All machines involved in the same patch cycle share this ID This allows all machines within a single patch execution to be correlated and queried collectively. The Solution: Query Failed VMs with Error Messages Azure Resource Graph allows querying failures at scale using the maintenanceresources dataset. Core Query (Kusto Query Language) 1 maintenanceresources 2 | where type =~ "microsoft.maintenance/applyupdates" 3 | where tostring(properties.correlationId) contains "<YourMaintenanceRunID>" 4 | where tostring(properties.status) =~ "Failed" 5 | project properties.resourceId, properties.errorCode, properties.errorMessage What This Query Delivers All machines that failed in a specific maintenance run Error codes for troubleshooting Full error messages that are otherwise visible only in the Azure portal Note: Property names for error information can vary by environment. Validate available fields using Azure Resource Graph Explorer and adjust the project clause if required. Sample Output (Conceptual) Resource ID Error Code Error Message vm-01 0x80244007 Windows Update API failed vm-02 0x80072f8f Connectivity issue vm-03 1C WSUS configuration issue Advanced Scenario: Automatically Detecting the Latest Failed Maintenance Run In real-world scenarios, you may not always know the maintenance run ID. The following query dynamically identifies the most recent maintenance run that had failures, and then retrieves all failed machines from that run. 1 // Step 1: Identify the latest maintenance run ID with failures 2 let lastFailedRun = toscalar( 3 maintenanceresources 4 | extend runId = extract(@"applyupdates/(\d+)$", 1, properties.correlationId) 5 | where type =~ "microsoft.maintenance/applyupdates" 6 | where tostring(properties.status) =~ "Failed" 7 | order by tostring(properties.startDateTime) desc 8 | take 1 9 | project runId 10 ); 11 // Step 2: Query all failed VMs from that run 12 maintenanceresources 13 | where type =~ "microsoft.maintenance/applyupdates" 14 | where tostring(properties.correlationId) contains lastFailedRun 15 | where tostring(properties.status) =~ "Failed" 16 | project properties.resourceId, properties.errorCode, properties.errorMessage This approach is ideal for automation, scheduled reporting, and dashboard scenarios. Why This Approach Matters Operational Efficiency Eliminates manual portal navigation Provides consolidated failure insights in seconds Scalability Works across large, distributed environments Supports both Azure and hybrid (Arc‑enabled) machines Automation Ready Can be integrated into scripts, dashboards, and reporting pipelines Enables proactive monitoring and alerting scenarios Best Practices for Enterprise Patch Reporting To maximize the value of this approach: Capture and track maintenance run IDs Use Azure Resource Graph as the primary reporting layer Build reusable queries for different patch scenarios Export reports for compliance and auditing Correlate failures with root‑cause trends over time Conclusion As organizations scale patching operations with Azure Update Manager, visibility, speed, and automation become essential. While the Azure portal is effective for per‑machine troubleshooting, it is not optimized for fleet‑level analysis. Azure Resource Graph fills this gap by enabling a shift from manual troubleshooting to automated, query‑driven failure analysis at scale. By adopting this approach, teams can significantly improve operational efficiency, reduce mean time to resolution, and build a more mature patch management strategy. Final takeaway: Don’t rely only on the portal Leverage Azure Resource Graph to operationalize patch insights at enterprise scale References Azure Update Manager – Query resources with Azure Resource Graph https://learn.microsoft.com/azure/update-manager/query-logs Azure Update Manager – Troubleshooting guide https://learn.microsoft.com/azure/update-manager/troubleshoot Sample Azure Resource Graph queries for Azure Update Manager https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/update-manager/sample-query-logs.md
