Azure Migrate discovery service unavailable behind Private Endpoint

Hello @Marian Romascanu ,

Thank you for taking the time to gather and share the connectivity results. They actually help narrow the investigation considerably.

From the table you provided, DNS resolution is working successfully for all FQDNs, and TCP connectivity over port 443 is successful for nine of the ten private endpoints. The only exception is the bac1750c-...-agent.cc.disc.privatelink... endpoint (10.1.7.13), which consistently fails connectivity checks.

Because DNS resolution is healthy across all endpoints and only a single endpoint is affected, this does not point to a broader DNS or Private DNS Zone configuration issue. In other words, the foundational networking components appear to be functioning as expected, which allows us to focus on the specific endpoint that is failing.

What stands out is the activity log entry showing "Validate a Private Endpoint Connection Proxy" failing with an InternalServerError, initiated by Azure Traffic Manager and DNS on July 13, 2026 at 16:35:50 EDT. This is an important observation because it suggests the private endpoint itself may not have been fully or successfully provisioned behind the scenes.

In some scenarios, a private endpoint can successfully receive an IP address and publish the correct DNS record, while the backend service it is intended to connect to is not completely provisioned. When that occurs, connectivity tests can look healthy from a DNS perspective while application-level operations still fail.

The endpoint involved here is associated with the Azure Migrate Discovery Service (disc). That aligns closely with the behavior you're seeing, where appliance registration fails during heartbeat communication, while other services such as Assessment (asm), Hub, Key Vault, Blob Storage, and the ASR-related services continue to respond normally.

I also want to acknowledge the workaround you identified. Registering the Microsoft.Discovery resource provider appears to have unblocked the issue, and that's valuable information for our investigation.

That said, I was unable to find documentation that lists Microsoft.Discovery as a required Azure Migrate resource provider. Based on what we know today, there are two possible explanations:

• Registering the provider may have triggered a re-validation or re-provisioning process for the private endpoint connection that had previously failed.
• There may be an undocumented dependency that warrants review by the product team.

Rather than assuming the current documentation fully explains the behavior, I think it's important to be transparent that your findings provide new data points which are worth highlighting.

Recommendations for future deployments

To help avoid similar issues in subsequent deployments, I would recommend the following:

1. Register all documented Azure Migrate resource providers before project creation

Ensuring the complete Azure Migrate prerequisite resource provider set is registered at the subscription level before creating the project will minimize provisioning-related issues.

Validation: Before generating the project key, verify that none of the required providers remain in a NotRegistered state.

2. Confirm role assignments are at the subscription scope

Some Azure Migrate provisioning operations, including automatic registration of certain resource providers, require permissions at the subscription level rather than only the resource-group level.

When permissions are limited to resource-group scope, the result can occasionally be a partially provisioned environment where most services function correctly but specific components fail to initialize completely.

Validation: Confirm the assigned role scope is the subscription and not only the resource group.

3. Preserve activity log details if the issue recurs

If the Discovery (disc) endpoint encounters the same issue again, capturing and preserving the activity log details, especially the Correlation ID, before removing or recreating resources would be extremely valuable.

This information gives engineering teams the best opportunity to trace backend provisioning failures and determine exactly where the process stopped.

Validation: Save the activity log JSON and confirm a valid correlationId is present for the relevant error event.

Responses to your additional questions

VMs with snapshots appearing unavailable for agentless replication

This behavior is expected and documented. Agentless replication relies on VMware Change Block Tracking (CBT), which cannot be enabled while snapshots already exist on the VM. Removing existing snapshots and temporarily pausing snapshot-based backup activities before retrying should allow the VM to become eligible.

Ubuntu kernel compatibility

Your observation is understandable, as the supported kernel matrix has expanded recently. While support now covers additional Ubuntu 22.04 and 24.04 kernel versions, the specific kernels currently in use (6.8.0-134-generic and 5.15.0-185-generic) still fall outside the supported matrix.

Rather than downgrading, which carries its own risks, the recommended approach would be to move to a currently supported kernel version listed in the latest support matrix.

For Linux workloads where appropriate, agentless migration may also be worth considering because it avoids guest-agent installation requirements altogether.

Replication appliance not appearing in wave target settings

This behavior is also consistent with documented requirements. Registration of the Azure Site Recovery replication appliance requires role assignments at the subscription scope and cannot be completed with only resource-group scoped access.

This explains why the VMware discovery appliance may register successfully while the replication appliance remains unavailable.

NXDOMAIN response for ...cnc.siterecovery.windowsazure.com

At this stage, I would treat this as an observation rather than a confirmed root cause.

Since the corresponding privatelink endpoint resolves successfully and responds on port 443, there is currently no evidence that this DNS response is contributing to the registration issue. It would become more relevant only if future ASR replication operations begin reporting failures that specifically reference the non-privatelink hostname.

Overall, based on the evidence collected so far, the strongest indicator remains the failed provisioning or validation of the Discovery service private endpoint. The activity log error, combined with the fact that all other private endpoints were healthy, points much more strongly toward a service-side provisioning issue than a DNS or network configuration problem.

Documentation references:

• Troubleshoot network connectivity (Azure Migrate) — https://learn.microsoft.com/azure/migrate/troubleshoot-network-connectivity?view=migrate — covers the *.disc/*.asm/*.hub privatelink FQDN mapping and the private DNS zone checks2
• Prepare Azure accounts for Azure Migrate — https://learn.microsoft.com/azure/migrate/prepare-azure-accounts?view=migrate#required-resource-providers — the 17 required RPs, the RG-scope key-generation warning, and the ASR replication appliance carve-out
• Azure Migrate support matrix (Azure permissions) — https://learn.microsoft.com/azure/migrate/migrate-support-matrix?view=migrate#azure-permissions — RP auto-registration during appliance registration
• Agentless migration architecture — https://learn.microsoft.com/azure/migrate/concepts-vmware-agentless-migration?view=migrate#replication-cycles — snapshots block agentless replication setup
• Troubleshooting replication issues in agentless VMware VM migration — https://learn.microsoft.com/azure/migrate/troubleshoot-changed-block-tracking-replication?view=migrate#vmware-changed-block-tracking-and-snapshot-data-errors — ProtectionReadinessError / CBT + snapshots
• ASR VMware/physical support matrix — https://learn.microsoft.com/azure/site-recovery/vmware-physical-azure-support-matrix#replicated-machines — Ubuntu 22.04/24.04 kernel lists for Mobility service 9.66

Kindly let us know if the above helps or you need further assistance on this issue.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".