Azure Site Recovery for Azure Local Is Now Generally Available!
Today, we are excited to announce the general availability of Azure Site Recovery (ASR) for Azure Local, making enterprise-grade disaster recovery for on-premises virtual machine workloads simpler, more secure, and more accessible than ever before. Since its public preview, Azure Site Recovery for Azure Local has helped organizations protect their business-critical workloads running on Azure Local clusters by replicating virtual machine workloads to Azure. With today’s release, we’re delivering a streamlined experience built on customer feedback and introducing key capabilities that remove the last friction points standing between organizations and a robust disaster recovery posture. What’s changing with General Availability: Azure Site Recovery for Azure Local is now fully supported for production workloads and available in all Azure Local-supported regions. Simple Deployment Wizard Before today, enabling Azure Site Recovery for Hyper-V involved a complex, multi-step setup process across multiple Azure portal blades. With this solution, you can now prepare your entire Azure Local environment for disaster recovery through a single, streamlined one-page wizard directly within the Azure Local resource in the Azure portal. The wizard handles everything in a single operation: It creates your Recovery Services Vault and a Hyper-V site, automatically downloads and installs the ASR agent on every node in the cluster, associates a replication policy, and registers each host with the Azure Site Recovery service, all without requiring you to repeat steps per node or jump between portal resources. How the wizard works: Navigate to Disaster Recovery From the Azure Local resource overview in the Azure portal, select the Capabilities tab and choose the Disaster Recovery tile. Launch Prepare Infrastructure Select “Protect VM workloads,” then “Prepare infrastructure.” The wizard opens. Configure in one place Select or create (or reuse) a Recovery Services Vault, a Hyper-V site, and a replication policy, all from the same page. Configure your proxy settings if required. Let Azure do the rest Click Prepare Infrastructure. Azure automatically installs the ASR agent on every node, registers the cluster, and associates with your policy. Monitor progress via the Notifications bell. Enable replication Once infrastructure is prepared, select Enable Replication to choose which VMs to protect. Replication begins immediately. See the wizard in action New in GA: WDAC Enforcement Mode Support Windows Defender Application Control (WDAC) is a foundational security capability in Azure Local that restricts which applications and code are allowed to run on cluster nodes. Many production and highly regulated environments, including government, financial services, and healthcare organizations, operate with WDAC in enforced mode as a mandatory part of their security posture. During public preview, customers using WDAC in enforced mode were required to temporarily switch to audit mode to install the Azure Site Recovery agent, an operationally disruptive workaround that reduced security assurance during deployment. This limitation has now been fully addressed. Azure Site Recovery for Azure Local now fully supports WDAC in enforce mode! Customers can prepare their Azure Local environment for disaster recovery without disabling or relaxing any Application Control policies. The ASR agent installation is WDAC-compliant and works seamlessly within enforced policy environments. New in GA: Built-In Proxy Support Enterprise networks commonly route outbound internet traffic through a proxy server, a requirement that is especially prevalent in regulated industries, government environments, and organizations with strict network egress controls. During public preview, configuring proxy settings for Azure Site Recovery required manual steps outside of the primary setup flow. With general availability, proxy configuration is now a first-class part of the one-page wizard. Customers who need to route ASR traffic through a proxy can configure proxy host, port, and credential settings directly within the Prepare Infrastructure wizard, in the same operation that sets up the rest of the disaster recovery infrastructure. This means no separate configuration files, no post-install manual steps, and no guesswork about whether proxy settings were applied correctly to each node. The wizard ensures consistent proxy configuration across the entire cluster as part of a single, atomic setup operation. Complete Disaster Recovery Lifecycle Azure Site Recovery for Azure Local supports the full disaster recovery lifecycle, giving organizations everything they need to meet recovery time objectives (RTO) and recovery point objectives (RPO) for on-premises workloads. Continuous Replication VM disks are replicated continuously to an Azure Storage Account, ensuring minimal data loss in the event of a disaster. Test Failover Validate your disaster recovery plan with non-disruptive test failovers that spin up snapshot of replicated VMs in Azure in an isolated network without impacting production replication. Failover to Azure (planned or unplanned) Fail over Windows and Linux VMs (Gen 1 and Gen 2) to Azure with a few clicks. Run workloads in Azure until your on-premises environment is restored. Recovery Plans Orchestrate failover for entire applications, not just individual VMs, with sequencing, automation, and dependency control. Failback Once your primary site is restored, fail back from Azure to your on-premises Azure Local environment and resume normal operations. Reverse Replicate Reverse replicate your VMs back to Azure to restore continuous replication and maintain ongoing protection against data loss, enabling rapid recovery in the event of another disaster. Who Should Enable Azure Site Recovery for Azure Local Today Azure Site Recovery for Azure Local is well-suited for any organization running business-critical workloads on Azure Local that requires a defined and tested disaster recovery strategy. It is particularly compelling for: Regulated industries such as financial services, healthcare, government, and the public sector who often operate in proxy-constrained network environments where BCDR requirements are mandatory and WDAC enforcement is a standard security requirement. With this GA release, the security and operational compromises that previously complicated adoption have been eliminated. Any organization that wants to use Azure as an extension of their on-premises environment for disaster recovery and business continuity. This cloud-integrated approach enables capabilities such as test failover, orchestrated recovery plans, and automated failback, all managed directly through the Azure portal. For organizations that prefer on-premises disaster recovery over cloud failover, a future option will support failback to an alternate on-premises location. Prerequisites and Getting Started To enable Azure Site Recovery on your Azure Local environment, ensure the following prerequisites are in place before you begin. For machines hosting the VMs you want to protect, internet access to Azure is required for the replication traffic, or a configured proxy, which can now be set up directly in the wizard. Support for Trusted Launch VMs is also planned for a future release. Start Protecting Your Azure Local Workloads Today Azure Site Recovery for Azure Local is generally available now. Open the Azure portal, navigate to your Azure Local resource, and launch the Prepare Infrastructure wizard to get started. Read the Documentation → Open the Azure Portal → Share feedback on the Azure Feedback Portal →
Azure Stack HCI Registration Help
We are waiting on arrival on our Azure Stack HCI cluster. In the meantime I have been trying to setup a test environment. The challenge I have is with registering the cluster with Azure. I understand their are specific Azure permissions need for the account that performs the registration. My intention was to register the system on my Visual Studio Subscription. Everything appeared to go ok until what I suspect was my last step. The last step - where I selected my Visual subscription gave me the somewhat expected permission error. Another organization within our college owns the tenant and we'll have to work with them when it comes time to register our production system. Here is where I could sure use some help. Since this permission issue still needs to be hammered out and this is just a test I figured I would try registering it with my personal Azure account. When I try to do that, it errors stating that my personal subscription is not found in the tenant. Which is true.... The problem is I can't figure out how to "unregister the incomplete registration." Everything I see shows the system to be "unregistered." Short of burning my test systems down and restarting, is there anything I can do to reset this registration process? Thanks, Jim
AKS on AzureLocal: KMSv1 -> KMSv2
Hey, quick question on AKS Arc — we're running moc-kms-plugin:0.2.172-official on an Arc-enabled AKS cluster on Azure Local and currently have KMSv1=true as a feature gate to keep encryption at rest working. KMSv1 is deprecated in 1.28+ and we want to migrate to KMSv2 before it gets removed. Since moc-kms-plugin is a Microsoft-managed component we can't just swap it out ourselves. A few questions: Does version 0.2.172 already support the KMSv2 gRPC API, or is that coming in a later release? Is there a supported migration path for AKS Arc specifically, or does this come automatically through a platform update? Any docs or internal guidance you can point us to? Thanks!
RDMA (RoCE) Test Failed over different Subnet
Hello Everyone, Let's say pSMBNIC1 and pSMBNIC2 are the names of the NICs to be used for RDMA on each node of a 3-node cluster. IP address assignments are as follows: pSMBNIC1 = 192.168.207.31 (N1), 192.168.207.32 (N2), 192.168.207.33 (N3) pSMBNIC2 = 192.168.206.51 (N1), 192.168.206.52 (N2), 192.168.206.53 (N3) RDMA Test is Successful when I run for the following scenarios: From pSMBNIC1 of N1 to pSMBNIC1 of N2 (192.168.207.32) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC1 of N2 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC1 of N3 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N2 (192.168.207.32) From pSMBNIC2 of N1 to pSMBNIC2 of N2 (192.168.206.52) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC2 of N2 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC2 of N3 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N2 (192.168.206.52) However, RDMA Test fails with "ERROR: RDMA traffic test FAILED: Please check ERROR: a) physical switch port configuration for Priority Flow Control. ERROR: b) job owner has write permission at 192.168.206.51 \C$" for the following scenarios: From pSMBNIC1 of N1 to pSMBNIC2 of N2 (192.168.206.52) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC1 of N2 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N3 (192.168.206.53) From pSMBNIC1 of N3 to pSMBNIC2 of N1 (192.168.206.51) and pSMBNIC2 of N2 (192.168.206.52) From pSMBNIC2 of N1 to pSMBNIC1 of N2 (192.168.207.32) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC2 of N2 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N3 (192.168.207.33) From pSMBNIC2 of N3 to pSMBNIC1 of N1 (192.168.207.31) and pSMBNIC1 of N2 (192.168.207.32) This means that RDMA Tests are passing for the same subnets but failing when run across different subnets. Is it normal? I have already enabled the PFC... But, even if the PFC is not enabled, then how tests are passing for the same subnet? Please guide... Thank you in anticipation.
Issue with Hyper-V VM on Tagged VLAN – Traffic Reaches Local Hosts but Not External Networks
Hi everyone, I’m having an issue getting a Hyper-V VM to work correctly when using a tagged VLAN interface. I have a test VM configured with a trunk port and a tagged VLAN. Here is the configuration I’m using: Set-VMNetworkAdapterVlan -VMName "testvlan" -Trunk -NativeVlanId 2 -AllowedVlanIdList "4" The strange part is this: When the VM is on VLAN 4 (tagged), it can reach other resources on the same VLAN as long as those resources are running on the same Hyper-V host. But if the target resource is outside the Hyper-V host, the VM cannot reach it at all. The hardware vendor has already ruled out any issue with the top-of-rack switches interconnecting the hosts. If I reconfigure the VM’s network adapter in access mode on the same VLAN, then all traffic works normally and the VM can reach resources outside the host without any problem. So it seems that traffic leaves the host correctly only when the adapter is in access mode, not when using a trunk with VLAN tagging. Has anyone seen this behavior before or has suggestions on what to check next?
Azure Stack HCI 23h2 upgrade & Azure local Resource
Good evening, After upgrading from 22H2 to 23H2, we encountered an issue where the Azure Local resource in the Azure portal appears as "not connected recently." Additionally, we are not seeing the "Your cluster can be upgraded to the latest version" option, likely due to this connection issue. Despite successful connectivity tests and extensive troubleshooting, the resource remains unsynchronised with Azure. As a result, we tried deleting the Azure Local resource and re-registering the nodes. Now, while both nodes are successfully registered and connected to Azure and passing the Invoke-AzStackHciUpgradeValidation , we are unable to find a way to re-register the Azure Local resource to proceed with the "Install the solution upgrade via Azure portal" step. The only option I see is going through the "Deploy Azure Local" process in Azure Arc. However, I believe this would overwrite existing settings and VMs, causing significant disruption—especially since this is a production cluster upgraded from 22H2. Is there a way to re-register the cluster and restore the Azure Local resource using existing settings, so we can proceed with deploying the rest of the solution upgrade via the Azure portal? Any guidance would be greatly appreciatedAzure Stack HCI version 23H2 is generally available
Today we’re announcing the general availability of Azure Stack HCI version 23H2, and the Azure Arc infrastructure needed to provision virtual machines and Kubernetes clusters, and Azure Virtual Desktop for Azure Stack HCI. Together, these capabilities enable an adaptive cloud approach, empowering customers to deploy and operate everything from hardware to applications using Azure Resource Manager and core Azure management services.
AVD on Azure Local: Increase memory of Sessionhosts after Hostpool deployment
Hi there, Is there a best practice for increasing the RAM of the session hosts in an Azure Virtual Desktop host pool? We are using the autoscaler to start and stop VMs on demand. Since this is an automated process, all the settings changed via HyperV-Manager get overwritten, presumably by the host pool template. Can someone confirm that I am on the right track and maybe give me a hint or a how-to on how to change the RAM for my session hosts? Hostpool Type: Pooled Uses Session Host Config: No Thanks in Advance, Maik
