Enabling Replication for OnPremises Virtual Machines (VMWare) using ASR with Private Endpoints

Hello Anandha Chandrasekaran, You are trying to configure Azure Site Recovery (ASR) for replicating On-Premises VMware virtual machines to Azure using the modernized ASR deployment approach along with Private Endpoints.

You have the following concerns:

• Whether manual MySQL installation is still required for the modernized ASR appliance.
• Whether the ASR appliance must be joined to Active Directory (AD) for Private Endpoint DNS resolution.
• Whether your current DNS conditional forwarders are sufficient.
• Specifically, whether forwarding for: privatelink.blob.core.windows.net

must also be configured.

MySQL is NOT required for the Modernized architecture.

The MySQL installation requirement applies only to the Classic (configuration server) architecture. The note in the Microsoft docs that mentions MySQL is scoped specifically to the classic experience: "While setting up private endpoints to protect VMware and physical machines, you will need to install MySQL on the configuration server manually - this refers to the Classic configuration server setup only."

https://learn.microsoft.com/en-us/azure/site-recovery/hybrid-how-to-enable-replication-private-endpoints

The modernized architecture uses an Azure Site Recovery replication appliance, which is a completely different deployment model from the classic configuration server. There is no MySQL component in the modernized appliance — it uses Azure-managed backend services instead. The classic experience has also now been retired, so if you are doing a fresh deployment, you should be on the modernized path exclusively, and MySQL is irrelevant. https://learn.microsoft.com/en-us/azure/site-recovery/replication-appliance-support-matrix

Domain join is NOT required.

The modernized ASR replication appliance is deployed via an OVF template and registered to the Recovery Services vault using device code flow authentication with Microsoft Entra ID (Azure AD) credentials. It authenticates to Azure using Entra ID, not Windows AD domain credentials. There is no documented requirement to join the appliance to your on-premises AD domain.

https://learn.microsoft.com/en-us/azure/site-recovery/deploy-vmware-azure-replication-appliance-modernized

However, DNS resolution from the appliance is critical and this is where your AD DNS infrastructure plays an indirect but important role (see Q3 below).

DNS Resolution for Private Endpoints- Are Your Conditional Forwarders Correct?

This is the most important part. Let's break it down.

How DNS for Private Endpoints Works (On-Premises to Azure)

When the ASR appliance (on-premises) tries to reach an Azure service via a private endpoint, it needs to resolve the service FQDN to the private IP of the endpoint (not the public IP). The flow is:

1. ASR appliance queries its configured DNS server (your on-prem AD DNS)
2. On-prem AD DNS has a conditional forwarder for the relevant zone → forwards to Azure DNS (via Azure DNS Private Resolver inbound endpoint, or via a DNS server in Azure that forwards to 168.63.129.16)
3. Azure DNS resolves the name from the Private DNS Zone and returns the private IP

Your Current Conditional Forwarders - What Needs to Change

You have forwarders set for:

• blob.core.windows.net
• siterecovery.windowsazure.com
• prod.migration.windowsazure.com

These are incorrect zone names for private endpoint DNS resolution.

For private endpoints, Azure creates privatelink.* subzones, and the DNS records live in those. The public zone names will return public IPs. You need to configure conditional forwarders for the privatelink.* versions:

For the modernized architecture specifically, you also need a private DNS zone (and corresponding forwarder) for privatelink.prod.migration.windowsazure.com, which is used by Site Recovery to perform discovery of the on-premises environment.

https://learn.microsoft.com/en-us/azure/site-recovery/hybrid-how-to-enable-replication-private-endpoints

Should Forwarders Point to privatelink.* Zones? YES.

To directly answer your question: yes, you need forwarders for privatelink.blob.core.windows.net (and the other privatelink.* zones listed above), not the bare zones. Here is why:

• When the ASR appliance resolves <storageaccount>.blob.core.windows.net, Azure returns a CNAME → <storageaccount>.privatelink.blob.core.windows.net
• Your on-prem DNS must then resolve that CNAME, which requires a forwarder for privatelink.blob.core.windows.net
• Without it, the query falls through to public DNS and returns the public IP — which won't be reachable over your VPN/ExpressRoute

All the public DNS zone names used by Azure services need to be configured as conditional forwarders on your on-premises domain controllers, pointing toward Azure DNS.

What to Point the Forwarders At

The forwarders should point to either:

• The inbound endpoint IP of an Azure DNS Private Resolver (recommended, modern approach), or
• The IP of a DNS server in Azure (e.g., a DC in Azure VNet) that itself forwards to 168.63.129.16

Replicating traffic over a site-to-site VPN from an on-premises site to Azure is only supported when using private endpoints, so getting DNS right is essential without proper private IP resolution, the appliance traffic will attempt to go to public endpoints and be blocked.

Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.