Simplify Azure Arc agent updates with Automatic Agent Upgrade, now generally available
Keeping the Azure Connected Machine agent up to date across a large server estate requires persistent coordination and manual work. When enabled, Automatic Agent Upgrade simplifies this process by allowing Microsoft to manage agent upgrades for you. What is Automatic Agent Upgrade? Automatic Agent Upgrade helps keep the Azure Connected Machine agent up to date. When enabled, machines are scheduled to upgrade to the latest agent version without requiring you to manually deploy each new agent version. Upgrades are rolled out in batches across regions and initiated during off-peak hours to help maintain stability and minimize disruption. This helps: Reduce operational overhead associated with manually managing agent upgrades. Stay current with the latest available security, reliability, quality, and platform improvements. Manage upgrades at scale across Azure Arc-enabled server environments. Enable Automatic Agent Upgrade at scale Since the initial public preview, we’ve added additional ways to make Automatic Agent Upgrade easier to adopt and manage across your environment. Azure Policy Use the built-in Configure Azure Arc-enabled Servers to enable automatic upgrades policy to turn on Automatic Agent Upgrade across an assigned scope and remediate machines that are not yet configured. For setup guidance, see the Azure Policy walkthrough. Enable during onboarding Automatic Agent Upgrade can also be used when connecting a new server to Azure Arc by adding --enable-automatic-upgrade to the azcmagent connect command. This makes it easier to include Automatic Agent Upgrade as part of existing at-scale onboarding processes. For setup guidance, see the onboarding walkthrough. Azure portal onboarding When generating an onboarding script through the Azure portal, you can select Automatic Agent Upgrade so that the generated script includes the required configuration. For setup guidance, see the Portal onboarding walkthrough. Frequently asked questions What is Automatic Agent Upgrade for Azure Arc-enabled servers? Automatic Agent Upgrade is a feature that helps keep the Azure Connected Machine agent up to date. After you turn it on, Microsoft manages agent upgrades for your Azure Arc-enabled servers. How does Automatic Agent Upgrade work? Machines are scheduled to receive the latest agent version. Upgrades roll out in batches across regions and occur during off-peak hours to help maintain stability and minimize disruption. What are the benefits of Automatic Agent Upgrade? Automatic Agent Upgrade reduces the operational work of managing upgrades manually, helps servers stay current with security, reliability, quality, and platform improvements, and supports upgrade management at scale. How can I turn on Automatic Agent Upgrade at scale? You can use the built-in Configure Azure Arc-enabled Servers to enable automatic upgrades policy across an assigned scope. The policy can also remediate machines that are not yet configured. Can I configure Automatic Agent Upgrade while onboarding a server? Yes. Add --enable-automatic-upgrade to the azcmagent connect command, or select Automatic Agent Upgrade when generating an onboarding script in the Azure portal. Get started Automatic Agent Upgrade is now generally available for Azure Arc-enabled servers. To get started, review the Automatic Agent Upgrade documentation for prerequisites and the available options for enabling and managing automatic upgrades across your environment.Stay ahead of Azure Arc agent health with Azure Advisor
Azure Advisor helps you stay ahead of potential connectivity issues by analyzing your Azure Arc-enabled servers and providing reliability recommendations when servers have been disconnected for an extended period. These recommendations give you visibility into potential issues and help you act before they affect your ability to manage your hybrid environment through Azure Arc. Understand your Azure Arc-enabled server health A reliable connection to Azure is an important part of keeping your Azure Arc-enabled servers healthy and manageable. The Azure Connected Machine agent sends regular heartbeats to Azure to confirm that connection and help identify when a server needs attention. If Azure does not receive a heartbeat for more than 15 minutes, the server is marked Disconnected. While disconnected, Azure-based management is limited, although existing extensions can continue running locally. If the server remains disconnected for an extended period, the agent’s managed identity certificate can eventually expire. The certificate is valid for 90 days, and the agent attempts to renew it when 45 or fewer days remain. Once the certificate expires, simply restoring connectivity is not enough. You’ll need to re-onboard the server to Azure Arc to restore management. For more information about how connectivity affects Arc-enabled servers, see Troubleshoot Azure Arc-enabled servers in disconnected scenarios. A look into the Azure Advisor recommendations Azure Advisor provides recommendations based on how long an Arc-enabled server has been disconnected: Restore connectivity for a server disconnected for 30–44 days. This provides an early opportunity to investigate the server and restore its connection to Azure. Reconnect a server that has been disconnected for at least 45 days. At this stage, the server's managed identity certificate is still valid, but connectivity should be restored so the agent can renew its credential before it expires. Re-onboard an expired server. If the server's managed identity certificate has expired, Azure Arc management capabilities remain unavailable until the server is reconnected using onboarding credentials. Azure Advisor helps surface connectivity conditions earlier, giving you an opportunity to identify disconnected servers and restore connectivity before they reach an expired state. How to view recommendations Azure Portal You can start in Azure Advisor to review recommendations across your environment or open an individual Azure Arc-enabled server and focus on that singular machine. From Azure Advisor blade In the Azure portal, search for and select Advisor. Select Operational Excellence. Use the subscription and resource type filters to narrow the results, but for only Azure Arc-enabled servers ensure the Type filter only has Machines - Azure Arc selected. If applicable to your machine, the health recommendation will be shown. From an Azure Arc-enabled server In the Azure portal, search for and select Azure Arc Select Machines. Select the server you want to review to open its resource page. Open the server’s Recommendations from the Overview page. If applicable to your machine, the health recommendation will be shown. Azure Resource Graph You can also use Azure Resource Graph to view Azure Advisor recommendations for Azure Arc-enabled servers across your selected subscriptions. In the Azure Resource Graph Explorer input the following query: advisorresources | where type =~ "microsoft.advisor/recommendations" | where properties.recommendationStatus == "New" | extend recommendationTypeId = tostring(properties.recommendationTypeId) | where recommendationTypeId in~ ( "18700d61-0b5a-4807-86a1-b7d669475335", // Restore connectivity (30-44 days) "5a6e1150-2d8a-4865-b423-df234577d29b", // Reconnect before cert expires (45+ days) "157eb7ac-9b3d-4a0c-9bfb-dd2ffa37d1ae" // Re-onboard expired server ) | extend id = tostring(properties.resourceMetadata.resourceId) | extend machineName = tostring(split(id, "/")[8]) | extend recommendation = case( recommendationTypeId =~ "18700d61-0b5a-4807-86a1-b7d669475335", "Restore connectivity (disconnected 30-44 days)", recommendationTypeId =~ "5a6e1150-2d8a-4865-b423-df234577d29b", "Reconnect before certificate expires (disconnected 45+ days)", recommendationTypeId =~ "157eb7ac-9b3d-4a0c-9bfb-dd2ffa37d1ae", "Re-onboard expired server", "Unknown") | distinct recommendation, machineName, id | order by recommendation asc, machineName asc Keep your Arc environment healthy As your Azure Arc environment grows, regularly reviewing Azure Advisor recommendations can help you identify servers that need attention and address connectivity issues before they become more disruptive. If you see an Azure Arc-related recommendation in Azure Advisor, review the affected server, investigate its agent and network connectivity, and take the recommended action to return it to a Connected state. Learn more: Resolve Azure Advisor recommendations for Azure Arc-enabled serversScheduled backups for Azure Local with disconnected operations: Advancing control plane resilience
For organizations operating in sovereign and disconnected environments, resilience is more than keeping infrastructure available. It also means having a reliable way to recover critical platform services when something goes wrong. Backup and restore capabilities of the control plane for the Azure Local with disconnected operations is available today. Operators can create an on-demand backup of the control plane and use it to recover the environment when needed. With the Azure Local 2609 release, we are building on this foundation by introducing scheduled backups. We built this capability to reduce reliance on manual backup processes and help customers maintain recovery points more consistently. By automating backups on a defined cadence, organizations can improve recovery readiness and better align protection of the control plane with their recovery objectives. From on-demand recovery to routine protection On-demand backup and restore established an important recovery path for the disconnected operations control plane. However, the value of any backup depends on having an appropriate recovery point available when an incident occurs. When backups depend entirely on manual execution, they can be delayed or missed. Scheduled backups help address this operational risk by automatically creating control plane backups at a defined cadence. This moves the experience from: “An operator can create a backup” to: “Backups run automatically as part of regular platform operations.” Operators can continue to initiate on-demand backups whenever they need an additional recovery point. What scheduled backups provide With scheduled backups, operators can: Configure recurring control plane backups Select a frequency ranging from twice-daily, daily, weekly, or monthly Use the default backup configuration or create named configurations View the current schedule and its next planned run Pause, resume, update, or remove the schedule Continue creating on-demand backups when needed Backup schedules are managed through PowerShell. A schedule can reference either the default backup configuration or a named configuration, giving operators flexibility in how backup destinations are organized. Supporting recovery objectives Scheduled backups make it easier to maintain recovery points at a consistent cadence. They provide a more predictable and an automated mechanism to implement the recovery point objectives as required by the organization. Reduced manual dependency: Backups run automatically after the schedule is configured. More consistent recovery points: Organizations can establish a cadence aligned with their operational requirements. Greater flexibility: On-demand backups remain available before significant changes or whenever an additional recovery point is needed. Simpler operations: Operators can manage the schedule and backup configurations through a consistent PowerShell experience. Continuing the resilience journey Backup and restore established a supported recovery foundation for the Azure Local disconnected operations control plane. Scheduled backups strengthen that foundation by making backup creation automatic, recurring, and easier to incorporate into regular operations. This is an important step toward greater recovery readiness, helping operators maintain more consistent recovery points and reduce reliance on manual processes. Learn more in the Azure Local documentation: https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-back-up-restore?view=azloc-2609#configure-scheduled-backupsEpisode 2: Reduce restarts with Hotpatch for Windows Server 2025 | The Azure Arc Check-In
Once a month, the Azure Arc team releases an episode covering a new hybrid and multicloud management scenario. To request a topic or view additional episodes, visit aka.ms/the-azure-arc-check-in. Scenario: Your infrastructure team needs to apply monthly security updates across hybrid Windows servers, but every restart creates another maintenance window and potential workload interruption. Hotpatch can reduce that restart-driven effort while helping you keep eligible servers protected. Try now in Azure aka.ms/aaci-episode2 Why Hotpatch matters Security updates are essential, but coordinating restarts across a distributed server estate takes time and can disrupt workloads. Hotpatch updates Windows security code in memory, allowing eligible security updates to take effect without requiring a restart. For Azure Arc-enabled Windows Server 2025 machines, enabling and using Hotpatch is available at no additional charge. Hotpatch reduces restart frequency, but it does not eliminate every restart. Baseline updates and updates outside the Hotpatch program can still require one. Confirm that your server is eligible Before enabling Hotpatch, confirm that the machine meets the operating system, Azure Arc, and security prerequisites. The server must: Run Windows Server 2025 Standard or Datacenter, build 26100.1742 or later. Run a generally available release. Preview and Windows Server Insider builds are not supported. Meet the Azure Connected Machine agent prerequisites and be connected to Azure Arc. Support virtualization-based security and Virtual Secure Mode. Use Unified Extensible Firmware Interface (UEFI) with Secure Boot enabled. Be a Generation 2 virtual machine when hosted on Hyper-V. Windows Server 2025 Datacenter: Azure Edition follows a different path because Hotpatch is enabled by default and does not require Azure Arc connectivity. For the latest requirements, see Enable Hotpatch for Azure Arc-enabled servers. Verify Virtual Secure Mode Run the following PowerShell command on the server to check its Virtual Secure Mode status: Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' -ClassName 'win32_deviceGuard' | Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus' A result of 2 means Virtual Secure Mode is configured and running. If the result is not 2, resolve the prerequisite before enrolling the machine in Hotpatch. Enabling Virtual Secure Mode requires a server restart, so make that change during a planned maintenance window. Enable Hotpatch through Azure Arc After confirming the prerequisites, enroll the server from the Azure portal: Open Azure Arc, then select Machines. Select the eligible server. Select Hotpatch. Review the confirmation, then select Confirm. Allow about ten minutes for the changes to apply. Verify that enrollment completes and the status is no longer pending. The portal enrollment is intentionally short. Most of the work is making sure the server meets the prerequisites before you begin. Choose how to manage updates Hotpatch enrollment and update installation are separate. After enrollment, continue to manage available updates according to your organization's patch policy and change-control process. Supported options for Arc-connected machines include: Windows Update Azure Update Manager Group Policy SConfig Supported non-Microsoft patch-management solutions Choose the method that fits your existing operations model. Enrolling a server in Hotpatch does not, by itself, install every available update automatically. Plan for the restart cadence Hotpatch changes the monthly update rhythm, but restart planning still matters. Every three months, Microsoft releases a planned baseline with the latest cumulative update. Installing a baseline requires a restart. Hotpatch releases normally follow during the next two months, allowing eligible security updates to be applied without a restart. An unplanned baseline can replace a scheduled Hotpatch release when necessary and will also require a restart. Updates outside the Hotpatch program can require restarts as well, including: Nonsecurity Windows updates .NET updates Drivers Firmware Other non-Windows updates The practical operating model is fewer restart-driven maintenance windows, not a server that never needs to restart. FAQs 1. Does Hotpatch mean I never need to restart the server? No. Planned baselines arrive every three months and require a restart. Unplanned baselines and updates outside the Hotpatch program can also require restarts. Hotpatch reduces restart frequency for eligible security updates; it does not eliminate restart planning. See Hotpatch for Windows Server. 2. Is Hotpatch an extra-cost service for Azure Arc-enabled Windows Server 2025? Enabling and using Hotpatch on eligible Azure Arc-enabled Windows Server 2025 machines is available at no additional charge. Optional Azure management services may have separate pricing. 3. Does enrolling in Hotpatch install every update automatically? No. Enrollment makes the machine eligible to receive Hotpatch updates. Continue using Windows Update or a supported patch-management tool, such as Azure Update Manager, Group Policy, SConfig, or a non-Microsoft solution, to manage available updates according to your patch policy. 4. Can I use Hotpatch with Windows Server Core? Yes. Both Server Core and Server with Desktop Experience are supported when the machine meets all other Hotpatch prerequisites. 5. What does a Virtual Secure Mode status of 2 mean? For the documented Device Guard PowerShell query, a result of 2 means Virtual Secure Mode is configured and running. If you receive another result, resolve the prerequisite before attempting enrollment. Review the current Hotpatch enablement guidance and Hotpatch concepts and update cadence, then visit The Azure Arc Check-in for more episodes.Generally Available: Transition to WS2012 / R2 ESUs enabled by Azure Arc from Volume Licensing
Customers that have enrolled in WS2012/ R2 ESUs through Volume Licensing for Year 1 can transition to Azure Arc for Year 2 of the program by specifying their Volume Licensing entitlements (Invoice Ids) in provisioning new Azure Arc WS2012/R2 ESU licenses. Extended Security Updates afford customers with critical security patches for end of support Windows Server 2012/R2 machines.Generally Available: Windows Server 2012 and 2012 R2 Extended Security Updates enabled by Azure Arc
Secure your End-of-Life Windows Server infrastructure on your own terms with Azure Arc. Benefit from the flexibility of a monthly Azure billed service and free access to Azure management services by leveraging Extended Security Updates enabled by Azure Arc for your Windows Server 2012 and 2012 R2 machines.The first Windows Server 2012/R2 ESU Patches are out! Are you protected?
Receive critical security patches for your WS2012/R2 machines enrolled in ESUs enabled by Azure Arc. Follow these detailed instructions outlining all of the enrollment and prerequisites, so you are protecting your EOL infrastructure.Episode 1: Onboarding Azure Arc at Scale | The Azure Arc Check-In
Once a month the Azure Arc team will release an episode covering a variety of topics. To request a topic or view additional episodes please visit: aka.ms/the-azure-arc-check-in Episode 1: Onboarding Azure Arc at Scale Scenario: Imagine your organization has 1,000 Windows and Linux servers spread across multiple locations. You want them all in Azure Arc, but first you need to deploy the Azure Connected Machine agent at scale. Try now in Azure aka.ms/aaci-episode1 Why onboarding strategy matters Interactive sign-in works well for testing and proof-of-concepts, but it quickly becomes impractical when you’re onboarding large server estates. At scale, organizations need a deployment model that can: Automate onboarding across many machines Align with existing management tooling Apply consistent configuration and governance from day one Minimize manual effort and human error This episode focuses on using non-interactive authentication and automation to onboard large server fleets efficiently. One of the key recommendations is to use a dedicated authentication mechanism designed for scale rather than relying on interactive administrator sign-ins. Onboard a Linux fleet with Ansible The Ansible deployment begins with an Ansible node that is already connected to Azure Arc. The deployment uses the credential on the Ansible node to deploy the Azure Connected Machine agent to the Linux fleet. To enable this, the managed identity of the Ansible node has the Azure Connected Machine Onboarding role in Azure assigned. Below are the steps for role assignment in the Azure portal: Open the resource group where the servers will be deployed. In Access control, add a role assignment. Select the Azure Connected Machine Onboarding role. Choose managed identities, select Machine - Azure Arc, and find the Ansible node. Review and assign the role. Configure the Ansible playbook With the permissions in place, the deployment uses three files: inventory.ini: Represents the machines configured by the playbook. arc-vars.yml: Contains non-secret configuration, including the resource group name, subscription and tenant IDs, location, and tags. arc-onboard.yml: References arc-vars.yml and configures the playbook to use managed identity, or MSI, for authentication. After the playbook runs, Ansible deploys the Azure Connected Machine agent to the Linux fleet. You can return to the resource group, refresh the view, and verify that your Linux machines appear as Azure Arc connected servers. Onboard Windows machines with Group Policy For Windows Server environments joined to Active Directory, Group Policy remains one of the simplest and most scalable deployment mechanisms. The process includes: Creating the required onboarding identity Preparing a shared location for deployment assets Downloading the Azure Arc GPO deployment package Generating a Group Policy Object with the required settings Linking that GPO to the appropriate organizational unit (OU) Allowing targeted servers to automatically onboard during policy refresh cycles For organizations that already manage Windows Server through Active Directory, this approach enables onboarding at scale without introducing additional management infrastructure. FAQs What is the best way to onboard servers to Azure Arc at scale? For large Windows and Linux server environments, use automated deployment with non-interactive authentication rather than signing in interactively on each machine. This approach lets you deploy the Azure Connected Machine agent consistently across many servers while reducing manual effort and human error. Azure Connected Machine Agent Deployment Options - Azure Arc Can I use Ansible to onboard Linux servers to Azure Arc? Yes. You can use an Azure Arc-enabled Ansible node to deploy the Azure Connected Machine agent across a Linux server fleet. In the approach demonstrated here, the Ansible node uses its managed identity, which is assigned the Azure Connected Machine Onboarding role, to authenticate the deployment. Connect machines to Azure Arc at scale using Ansible - Azure Arc Can I use Group Policy to onboard Windows servers to Azure Arc? Yes. Group Policy can automate Azure Arc onboarding for Windows Server machines that are joined to Active Directory. The process uses a Group Policy Object linked to the appropriate organizational unit, allowing targeted servers to onboard automatically during Group Policy refresh cycles. Connect machines at scale using Group Policy with a PowerShell script - Azure Arc What files are needed to onboard Linux servers to Azure Arc with Ansible? The Ansible deployment shown in this episode uses three files: inventory.ini to identify the target machines, arc-vars.yml to store non-secret configuration such as subscription, tenant, resource group, location, and tags, and arc-onboard.yml to run the onboarding playbook using managed identity authentication. Should I use Ansible or Group Policy for Azure Arc onboarding? Use Ansible when onboarding Linux servers in an environment that already uses Ansible playbooks and automation. Use Group Policy when onboarding domain-joined Windows servers managed through Active Directory. Both approaches help organizations automate Azure Connected Machine agent deployment by using tools already present in their server-management environment. Additional options are available for onboarding servers at scale. See Azure Connected Machine Agent deployment options.
