ASR - VMWare VM Discovery Issue

We have registered an ASR appliance to replicate VMs from our VMware on-premises environment. The Recovery Services Vault has been enabled with a Private Endpoint.

The ASR appliance status is showing as healthy in the vault, and the vCenter connection is also showing as healthy. However, when we try to enable replication, none of the VMs are displayed in the VM selection list.

We checked the Discovery Service logs on the appliance and can see that the heartbeat/API calls to the prod.migration privatelink endpoint are succeeding.

The vCenter account has been verified and assigned the required roles and permissions.

Need Troubleshooting Guidance for this issue. Does VMware VM discovery work when a Private Endpoint is enabled on the Recovery Services Vault? Are there any known limitations or additional configuration requirements in this scenario?

  1. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    Hi @Anandha Chandrasekaran , we have shared the information about your issue. Let me know if it was helpful or please feel free to comment if you need further assistance,

Sign in to comment

2 answers

  1. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    Hi @Anandha Chandrasekaran

    Based on your description the Azure Site Recovery (ASR) appliance and vCenter connectivity are both healthy and we can see successful communication to the prod.migration.privatelink endpoint. This confirms that the control-plane communication is working correctly. However, the fact that no VMs appear during replication setup typically points to a networking or configuration gap rather than a discovery feature limitation.

    Is VMware discovery supported with Private Endpoint?

    Yes, VMware VM discovery is supported when using Private Endpoints with Azure Site Recovery. However, this setup introduces strict networking and DNS dependencies that must be correctly configured. Microsoft confirms that private endpoints restrict vault access to specific VNets, and proper DNS + connectivity must be in place for the service to function correctly.

    What is likely causing the issue?

    1. DNS resolution for Private Link is incomplete

    When using private endpoints, ASR requires correct resolution of service FQDNs such as:

    • *.privatelink.siterecovery.windowsazure.com

    If these entries are missing or not resolvable to private IPs, some operations (like VM discovery) may fail even though the appliance appears healthy.

    Microsoft explicitly highlights that DNS configuration is required to map ASR service endpoints to private IPs when using Private Link.

    1. Incomplete or inconsistent Private Endpoint configuration

    ASR uses multiple underlying microservices behind the vault. If private endpoints are:

    • Partially configured
    • Missing required DNS integration
    • Created out of sequence

    then certain operations (like discovery) may not function properly.

    Microsoft notes that private endpoints must be configured correctly and in sequence, otherwise the vault may not function as expected.

    1. Missing outbound connectivity to required services

    Even when Private Endpoint is enabled, ASR still requires outbound communication to:

    • Azure AD (authentication)
    • Storage accounts (cache/logs)
    • Site Recovery endpoints

    Microsoft confirms that outbound connectivity to required URLs is still necessary, especially for authentication and replication workflows.

    1. Standard VMware discovery conditions (secondary validation)

    Additionally, Microsoft notes that VM discovery may fail if:

    • vCenter permissions are insufficient
    • Duplicate VM UUIDs exist
    • Credentials are incorrect

    This article describes some common issues and specific errors you might encounter when you replicate on-premises VMware VMs and physical servers to Azure using Site Recovery Troubleshoot replication issues for disaster recovery of VMware virtual machines and physical serve…

    If you find the answer helpful, please click "upvote" and accept it. This will help others in the community with similar questions easily find the solution.

    0 comments No comments
    Sign in to comment
  2. Jerald Felix 13,500 Reputation points • Volunteer Moderator

    Hello Anandha Chandrasekaran,

    Greetings! Thanks for raising this question in Q&A forum.

    The root cause of your issue is a known behavior in the ASR Modernized experience. When using Private Link with the modernized experience for VMware VMs, public access is still needed for a few specific resources and more importantly, the privatelink.prod.migration.windowsazure.com private DNS zone must be explicitly created and linked, because this endpoint is used by Site Recovery to perform discovery of the on-premises environment. Without this DNS zone in place, the appliance can heartbeat successfully but the VM inventory never gets populated which matches exactly what you are seeing.

    Here are the steps to resolve this:

    Create the missing private DNS zone for discovery In the Azure portal, go to Private DNS Zones and create a new zone named privatelink.prod.migration.windowsazure.com. This is separate from the vault's private endpoint DNS zone and is specifically needed for vCenter VM discovery in the modernized architecture.

    Link the DNS zone to your bypass virtual network Go to the private DNS zone you just created, select Virtual network links in the left pane, click Add, and select your bypass network (the VNet where the ASR appliance communicates with Azure).

    Verify the private endpoint DNS records are resolving correctly on the appliance On the ASR appliance, run nslookup prod.migration.windowsazure.com and confirm it resolves to a private IP address. If it still resolves to a public IP, the DNS zone link or A-record is missing.

    Allowlist the required public URLs from the appliance Even with private endpoints, certain URLs must remain reachable from the appliance, including *.windows.net, *.msftauth.net, *.msauth.net, *.microsoft.com, *.live.com, and *.office.com. Ensure these are not blocked by your on-premises proxy or firewall.

    If using a proxy on the appliance, ensure CNAME resolution is working If proxy-based configuration is used, make sure that the proxy resolves any CNAME records received while looking up the URLs, otherwise discovery calls can silently fail even when the heartbeat looks healthy.

    Re-trigger VM discovery from the appliance configurator Once DNS is confirmed, open the appliance configuration manager (https://<appliance-IP>:44368), navigate to the vCenter connection, and trigger a re-discovery. Wait 10–15 minutes and then check the Enable Replication VM selection list again in the portal.

    If the issue persists after the above steps, raise a support ticket with Microsoft Share the Discovery Service logs from the appliance along with the DNS resolution output. A Microsoft support engineer can verify the private endpoint DNS record mappings on the backend and confirm whether all five private link microservice endpoints were created correctly for your vault.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,

    Jerald Felix.

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer