Azure Migrate "Generate key" permanently disabled - Appliance name not found error

Question

Azure Migrate "Generate key" permanently disabled - Appliance name not found error

Akshat Singh 0

I'm trying to set up an Azure Migrate appliance for server discovery (Physical or other source type), but the "Generate key" button never activates, regardless of appliance name entered.

Symptoms:

Tooltip shows "Appliance name not found" even though the name check itself should just confirm availability
Confirmed via DevTools: the background call MigrateV2-ApplianceListHelper-fetchApplianceNameToSiteIdList fails repeatedly (fetchApplianceNameToSiteIdList: Failed to get appliance name to site id list for the migrate project)
No corresponding failed request visible in the Network tab - appears to fail via a different channel (possibly WebSocket/SignalR)

What I've already tried, all unsuccessful:

Confirmed my account has Owner role at the subscription level
Explicitly assigned the "Azure Migrate Owner" role (per official docs) - no change after waiting for propagation
Created policy exemptions for subscription-level tag and allowed-region policies on the resource group - no change
Tested in a fresh browser, incognito mode, and a different browser entirely - same result
Tested on a brand new Azure Migrate project in a different region (West Europe) and a different resource group entirely (previously used successfully for a separate POC project, which did generate a key successfully weeks ago) - same "Appliance name not found" result on the new project every time
Confirmed via Activity Log that a related deployment (Microsoft.MigrateV2.CreateAMHProjectWithDefaultTools) was blocked by policy on one early attempt, but exemptions were applied afterward with no change to the button behavior

This strongly suggests a tenant-level issue (possibly an expired/restricted Entra ID app registration or service principal tied to Azure Migrate's backend), since the same account successfully generated a key for a different project in the same tenant previously, but cannot do so now for any new project.

Any guidance on what tenant-level Entra ID logs or service

0 comments

1 answer

Your answer

Answer 1

Hello @Akshat Singh

Based on what you've tested so far, I don't think this is an issue with the physical Azure Migrate appliance itself. You're failing earlier in the workflow, while the Azure portal is trying to validate the appliance name and generate the project key.

Since you're seeing "MigrateV2-ApplianceListHelper-fetchApplianceNameToSiteIdList" followed by "fetchApplianceNameToSiteIdList: Failed to get appliance name to site id list for the migrate project," and you've reproduced it in a completely new project and a different region, focus on the Azure Migrate portal/backend operation rather than changing appliance configuration.

Also check RBAC against the current Azure Migrate requirements. This requires Azure Migrate Owner or a higher-privileged role to create Azure Migrate projects. Check the effective access assignment under Subscription → Access control (IAM) → Check access.

You've already assigned Azure Migrate Owner, so assuming Check access confirms that role is effective at the correct scope, I wouldn't keep adding broader permissions.

Also, don't assume this is caused by an expired Microsoft Entra application/service principal yet. Azure Migrate workflow doesn't instruct customers to create or repair a tenant-level service principal simply to generate the appliance project key. Without an Entra sign-in/audit failure identifying a particular application or service principal, that would be speculation.

The earlier Activity Log entry is more interesting: "Microsoft.MigrateV2.CreateAMHProjectWithDefaultTools"

An Azure Policy denial could indicate that project initialization didn't complete correctly. However, because you've now reproduced the same appliance-name failure in another project after applying the policy exemptions, I wouldn't conclude that the original policy denial is the root cause either.

Check these three things next:

1. Verify the project resources actually provisioned

Open the resource group containing the new Azure Migrate project and confirm the Azure Migrate project exists successfully rather than remaining in a failed/partial deployment state. Also check Resource group → Deployments and Activity log for failed Microsoft.Migrate, Microsoft.MigrateV2, Key Vault, Storage, or related resource operations.

2. Check effective Azure Policy rather than adding more exemptions

From the affected resource/resource group, open Policies → Compliance and look for denies associated with the timestamp when you attempted Generate key. This helps because Azure Migrate key generation creates supporting Azure resources; selecting Generate key starts creating the required Azure resources.

3. Capture the portal correlation information

Reproduce the failure once, note the exact UTC timestamp, and collect any correlation ID/session ID/operation ID shown in the Azure portal or Activity Log. Include the DevTools error you've already captured as well.

Don't spend time troubleshooting firewall connectivity from the future appliance yet. The appliance needs to reach Azure Migrate, Service Bus, authentication, management, Key Vault, and other endpoints, but those requirements apply when the appliance is deployed/configured. You haven't reached that stage yet.

Given everything you've already eliminated, if the same failure occurs after confirming effective RBAC and there are no remaining Policy denies, this warrants an Azure Support case for the Azure Migrate / Discovery and assessment service.

Phrase the escalation specifically as: “Azure Migrate Discovery and assessment - Generate project key permanently disabled because MigrateV2-ApplianceListHelper-fetchApplianceNameToSiteIdList fails across multiple newly created projects.” Include the needed information I mentioned.

Microsoft should then be able to trace the MigrateV2 backend call and determine why the portal can't retrieve the appliance-name/site-ID mapping.

Don't delete your existing working/previous Azure Migrate project or modify tenant-level Entra service principals while investigating this. Your observation that the same tenant generated an appliance key successfully a few weeks ago is useful evidence for Support because it suggests something has changed in either tenant policy/configuration or service/backend behavior.

References:

Set up an Azure Migrate appliance for physical servers

Create an Azure Migrate project

Azure Migrate appliance

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.