Azure Migrate my Appliance shows offline

Question

Azure Migrate my Appliance shows offline

Claus, Frank 45

I have been using Azure Migrate for over a year using the modern appliance. The appliance is currently showing offline when attempting to perform a migration. I recently removed an on prem authoritative zone for privatelink.blob.core.windows.net and have individual zones for specific azure private endpoints for blob resources. I have server level forwarders going out to google, comcast and cisco dns for public internet. I have tried also adding a conditional forwarder for privatelink.blob.core.windows.net pointing to my Azure Private DNS resolver IP. I can resolve all private endpoints including the storage account used by the Migrate project. I can also resolve the private endpoints for prod.migration.windowsazure.com. It looks to have been in a disconnected state since the 17th so I don't think the issue is related to my dns zone changes as that was yesterday. I have rebooted the appliance as well as restarting the relevant services. Any ideas on how to approach would be appreciated. Thanks

0 comments

2 answers

Your answer

Answer 1

Siva shunmugam Nadessin 7,735 Microsoft External Staff Moderator

Hello Claus, Frank,

Thank you for reaching out to the Microsoft Q&A forum.

We understand that your Azure Migrate appliance has been in a disconnected state since the 17th and you’ve already verified DNS for all private-link endpoints and rebooted/restarted services. Let’s walk through a focused approach to get it back online:

Re-run the appliance prerequisites

• On the appliance server, open the Azure Migrate Appliance Configuration Manager.

• Go to Set up prerequisites and click Re-run the checks.

• Look for any failures in “Internet connectivity,” “DNS resolution” or “Service status.”

Verify the DRA service

• Open an elevated PowerShell or CMD on the appliance and run: net stop dra net start dra

• In the Config Manager under View appliance services, ensure the DRA (Data Replication Agent) shows as Running.

Run the local diagnostics

• In the Appliance Configuration Manager, go to Troubleshooting > Diagnostic tests and click Run diagnostic tests.

• Address any issues flagged (disk space, service health, network tests, etc.).

Double-check DNS resolution and network connectivity

• From the appliance, run: Resolve-DnsName .migration.windowsazure.com Resolve-DnsName .privatelink.blob.core.windows.net Test-NetConnection –ComputerName .migration.windowsazure.com –Port 443

• If these fail, add host‐file entries or a conditional forwarder on your DNS server pointing the FQDNs to the correct private IPs, then clear the appliance cache: ipconfig /flushdns

Verify outbound port/URL access

• Ensure outbound TCP 443 isn’t blocked by a firewall or proxy.

• Confirm access to all required Azure Migrate URLs (see https://docs.microsoft.com/azure/migrate/migrate-appliance#url-access).

Check logs for errors

• Windows Event Viewer → Applications & Services Logs → Microsoft → AzureMigrate.

• Appliance logs under C:\ProgramData\Microsoft Azure\Migrate\Logs. Look for repeated connectivity or authentication errors.

Give it time

• After fixes, wait 5–10 minutes for the appliance to re-register in the portal.

• In the Azure Portal, refresh the Azure Migrate project and check the appliance tile for “Online.”

If you still see “Offline” after all of the above, please share:

• Any specific error messages or event IDs from the appliance logs

• Results of your DNS resolution and Test-NetConnection commands

• Confirmation of whether you’re using a proxy (and its settings) on the appliance

Hope this helps get your appliance back online!

References

Appliance URL requirements: https://docs.microsoft.com/azure/migrate/migrate-appliance#url-access
Verify DNS resolution for private endpoints: https://docs.microsoft.com/azure/migrate/how-to-use-azure-migrate-with-private-endpoints#verify-dns-resolution
Troubleshoot the Azure Migrate appliance: https://docs.microsoft.com/azure/migrate/troubleshoot-appliance

Claus, Frank 45 Reputation points

2026-03-27T17:31:54.01+00:00

I am using the modernized appliance so I dont see the dra service. All dns endpoints are resolvable the storage account as well as the isv.cus.hub.privatelink.prod.migration.windowsazure.com endpoints. Pre req check all shows green. I do not see Troubleshooting > Diagnostic tests and click Run diagnostic tests anywhere in the portal view. There is a replication job that shows execution stage completed but execution status shows running. This has been stuck this way since the 17th of this month. When I click on the appliance in the portal I am noticing the agents also show not connected with a last heartbeat of 3/17/2005. I also notice now that the original onboarding timestamp shows March 17 2025. Perhaps this is a certificate issue and it has expired. The One year to the day disconnect seems more than coincidental.
Claus, Frank 45 Reputation points

2026-03-27T17:42:18.42+00:00

I have validated that the app registration hasan expired certificate. What is the easiest way to create a new one. Search seems to indicate there should be a PS script to rotate the cert in the Scripts\PowerShell folder but i do not see it there.
Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-30T11:10:54.4266667+00:00
Hello Claus, Frank,

What you are seeing is exactly what happens when the Azure Migrate – modernized appliance app registration certificate expires. The “one year to the day” timing (March 17, 2025 → March 17, 2026) is not a coincidence — the default certificate lifetime for the modernized appliance is 12 months.

Once the cert expires:

Azure stops accepting tokens

Appliance services keep running, but cannot talk to Azure

Jobs appear “stuck” forever

·         You donot need redeploy anything, No re‑replication, No new app registration, No portal wizard. You just need to rotate the certificate locally on the appliance.

Follow below step-by-step steps.

1.     Log in directly to the appliance VM.

Use the account that originally onboarded it (or one with equivalent rights).

2.     Open Powershell as Administrator

3.     Navigate to the script folder

cd "C:\Program Files\Microsoft Azure Appliance Configuration Manager\Scripts\PowerShell\AzureMigrateCertificateRotation"

Run the rotation (recommended: 12 months)

.\AzureMigrateRotateCertificate.ps1 12

you omit the number, it defaults to 6 months, but I strongly recommend 12.

What the script does automatically & You do NOT have to touch Entra ID manually.

The script will:

Generate a new certificate, Update the existing app registration with the new public key Import the new PFX into the appliance, Remove the expired cert, Update appliance configuration files, Restart appliance services.

This preserves:

     Appliance ID, Migration project, Replication state, Storage account, Job history.

Required permissions

The identity running the script must have:

Owner on the Azure Migrate app registration

Contributor on the subscription containing the Migrate project

If permissions are missing, the script will fail during the Entra update step (and log it clearly).

What you should see after success

Within a few minutes (often faster):

Appliance status → Connected

Agents → Connected

Heartbeat timestamp updates

Replication job moves off “Running” and resumes normally

No reboot required unless the script prompts you.

If you do not see the script folder

This is rare, but if the folder truly doesn’t exist, it means one of these:

The appliance installation is incomplete

Appliance auto‑update is disabled and very old

Someone cleaned up program files

In that case, the supported recovery is:

Upgrade the appliance binaries in‑place

Or redeploy the appliance without deleting the project

The fix is a local certificate rotation script — nothing more.
Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-31T01:26:54.4333333+00:00

Hello Claus, Frank,

Just checking in to see if the solution shared above help you to resolve your issue. please reach out to us If you have any further questions.

Thanks
Claus, Frank 45 Reputation points

2026-03-31T12:48:56.9+00:00

Still having issue as it turns out the service principal used by migrate expired as apparently it only had a one year cert. I cannot find the cert anywhere in the local store on the appliance. I have tried to run the .\azuremoigraterotatecertificate.ps1 and it is failing with

Fetching the details for Azure Migrate project

Error occurred while fetching migrate project details.Please check if you have contributor access on the subscription to perform any operations on the migrate project and you have access to the endpoint management.azure.com

Learn more - https://go.microsoft.com/fwlink/?linkid=2180156

The remote server returned an error: (401) Unauthorized.

Is there not an easier way to renew this cert or create a new one etc
Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-04-01T07:00:35.71+00:00
Hello Claus, Frank,

The root cause of the issue Azure Migrate creates a service principal (app registration) and that SP uses a certificate, not a password older Migrate projects created a 1‑year certificate that certificate expires silently ✔ When it expires:

Appliance can’t authenticate

Rotation script tries to call ARM

ARM rejects it → 401 Unauthorized

This is why you cannot find the cert locally

The appliance does not store the cert in the Windows cert store

It’s embedded and managed internally by the Azure Migrate appliance

Once it expires, you cannot renew it locally

Why azuremigraterotatecertificate.ps1 fails

This error is expected in your scenario which is 401 Unauthorized Error occurred while fetching migrate project details because the expired cert is used to authenticate, azure refuses the call, script cannot rotate what it can’t authenticate.

Rotation only works before expiry, not after.

The EASIEST and CORRECT fix is Re-register (re-onboard) the Azure Migrate appliance

This is the recommended and fastest recovery path.

What this does

Creates a brand-new service principal, Generates a fresh certificate, Automatically updates all references

No manual cert handling required.

Below is step-by-step version to resolve it.

Go to Azure Migrate project → Discover

Select your Appliance

Choose Remove / De-register appliance

This does NOT delete discovered machines or assessments.

On the appliance VM

Run:

Reconfigure Azure Migrate appliance

Choose Register appliance again

This will:

Prompt Azure login

Create a new app registration

Assign correct roles automatically

Verify permissions

Ensure the logged-in user has:

Contributor on the subscription

Contributor or Owner on the Azure Migrate project

Access to management.azure.com

Start discovery again

Discovery resumes

Data flows normally

No cert error

Hope this helps & let us know if any questions?

Answer 2

Use the appliance’s private endpoint and DNS connectivity as the primary troubleshooting focus, since the appliance appears offline to Azure Migrate when it cannot reach its service endpoints, even if individual private endpoints resolve correctly.

Recommended approach:

Verify DNS resolution from the appliance itself Run these from the appliance (not from another server):
- For Azure Migrate discovery/assessment endpoints (from the downloaded DNS settings file):
```
     nslookup <migrate-agent-name>.disc.privatelink.prod.migration.windowsazure.com
     nslookup <migrate-agent-name>.asm.privatelink.prod.migration.windowsazure.com
     nslookup <migrate-agent-name>.hub.privatelink.prod.migration.windowsazure.com
```
- For the storage account used by the Migrate project:
```
     nslookup <storage-account-name>.blob.core.windows.net
```
- For the Key Vault used by the project (if applicable):
```
     nslookup <your-key-vault-name>.vault.azure.net
```
Each of these must resolve to a private IP address that matches the IPs in the Download DNS settings file from the Azure Migrate project properties. If any FQDN resolves to a public IP or fails to resolve, temporarily add host entries on the appliance with the FQDN → private IP mappings from the DNS settings file and retest. This is the recommended quick test path.
Confirm private DNS zone health and VNet linkage In the Azure portal:
- Ensure the following Private DNS Zones exist in the resource group that holds the private endpoints:
  - privatelink.blob.core.windows.net (for storage)
  - privatelink.vaultcore.azure.net (for Key Vault, if used)
  - privatelink.prod.migration.windowsazure.com (for Azure Migrate discovery/assessment/migration)
- On each zone, check Virtual network links and confirm the VNet that contains the Azure Migrate private endpoints is linked. If the zone is missing, create it and link it as described in the documentation.
Validate private endpoint connectivity from the appliance From the appliance, run Test-NetConnection (PowerShell) or equivalent to the private endpoint IPs for:
- Storage account
- Key Vault
- Azure Migrate service endpoints (from the DNS settings file)
The tests should show the ports as reachable. If DNS resolution is correct but ports are blocked, review:
- Any firewall on the appliance
- Azure Firewall or custom NVA in the path
- Network peering or custom gateway/NAT that might be altering routing or DNS behavior
Check proxy behavior for private-link FQDNs If the appliance uses a proxy:
- If the proxy is only for internet access, add bypass rules so that *.disc.privatelink.prod.migration.windowsazure.com, *.asm.privatelink.prod.migration.windowsazure.com, *.hub.privatelink.prod.migration.windowsazure.com, *.privatelink.siterecovery.windowsazure.com, *.vault.azure.net, and *.blob.core.windows.net go directly over the private link instead of via the proxy.
- If the proxy is used for all outbound traffic, ensure the proxy itself can resolve these FQDNs to the correct private IPs. For testing, manually add DNS records on the proxy with the mappings from the DNS settings file.
Re-validate Azure Migrate project DNS settings In the Azure portal:
- Go to Azure Migrate: Discovery and assessment → Properties and Migration and modernization → Properties.
- Use Download DNS settings and confirm that every FQDN in that file resolves correctly from the appliance to the listed private IPs.
If the appliance still shows offline
- After fixing any DNS or connectivity issues, restart the appliance services and retry registration/discovery.
- If the error message shows a specific endpoint (for example, AgentNotConnected with a URL), ensure that exact URL resolves to the correct private IP and is reachable from the appliance.

This sequence ensures the appliance uses the correct private DNS zones, resolves all Azure Migrate and storage/Key Vault endpoints to private IPs, and can reach them over the network without being intercepted or misrouted by proxies or firewalls.

References:

Troubleshoot network connectivity

Share via

Azure Migrate my Appliance shows offline

2 answers

Your answer