Azure Migrate with Azure Local: Critical services are either not updated, installed or status not available

Question

Azure Migrate with Azure Local: Critical services are either not updated, installed or status not available

Jayanth Dattatri YKB 40 MVP

Auto update of source appliance fails with the error "Critical services are either not updated, installed or status not available". The source appliance connects to the proxy via proxy which has been configured and step1 and checks if the appliance can connect to Azure. I can see the green tick for Step 1a, 1b. Even the Azure Migrate project is verified. But update of the appliance fails. See the screenshot below

User's image

Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-19T06:40:38.1533333+00:00
Hello Jayanth Dattatri YKB,

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

When investigated we see that the “Critical services are either not updated, installed or status not available” error is coming straight from the appliance itself—it isn’t seeing the services it needs to perform the auto‐update. Here’s how you can troubleshoot:

RDP into your source appliance VM and open PowerShell (Run as Administrator).

Verify that all of these services are present and in the Running state:

Microsoft Azure Gateway Service (asrgwy)

Azure Site Recovery Management Service (asrmgmtsvc)

Hyper-V appliances: Microsoft Azure Hyper-V Discovery Service (amhvdiscoverysvc)

VMware appliances: Microsoft Azure VMware Discovery Service (amvmwdiscoverysvc)

Example:

Get-Service -Name asrgwy, asrmgmtsvc, amhvdiscoverysvc

If any of the services are stopped or reporting an error, set their startup type to Automatic and start them:

Set-Service -Name asrmgmtsvc -StartupType Automatic Start-Service asrmgmtsvc

Once the services are healthy, go back to the Azure Migrate portal and hit Update appliance (or Retry).

If you still see failures,

grab the AutoUpdate logs from the appliance: C:\ProgramData\Microsoft Azure\Migrate\Logs\AutoUpdate Look for any proxy or authentication errors in those logs.

A few other quick checks:

• Make sure the appliance’s clock is in sync with an NTP server.

• Verify your proxy settings haven’t changed (and that the appliance can still reach update.azure.com).

• If services are missing or corrupt you can repair the appliance agent by running the installer with /repair.

Hope this helps & let us know if you have further queries?

Reference docs:

Troubleshoot issues migrating VMs to Azure Local via Azure Migrate https://learn.microsoft.com/azure/azure-local/migrate/migrate-troubleshoot?view=azloc-2603

Troubleshooting Azure Migrate Assessment Guide https://supportability.visualstudio.com/AzureDatabaseMigrationService/_wiki/wikis/AzureDatabaseMigrationService/923050/Azure%20Migrate/SQL%20Assessment%20telemetries%20and%20trouble%20shooting%20guide/Troubleshooting%20Azure%20Migrate%20Assessment%20Guide
Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-20T01:02:15.6333333+00:00

Hello Jayanth Dattatri YKB

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
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-20T03:28:08.08+00:00

@Siva shunmugam Nadessin The Azure Site Recovery Management Service is not running and errors out when trying to restart

Event Viewer:

AgentUpdater.log
Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-20T05:32:28.75+00:00
Hello Jayanth Dattatri YKB,

Thanks for sharing the screenshots and command output — this actually gives very strong signals about what’s wrong. I’ll break it down clearly and then give you actionable recovery steps, based strictly on what is visible in your output and Event Viewer.

What we can clearly see from your evidence

Services state

From your PowerShell output:

PowerShell

Running amvmwdiscoverysvc Microsoft Azure VMware Discovery Service

Running asrgwy Microsoft Azure Gateway Service

Stopped asrmgmtsvc Azure Site Recovery Management Service

It indicates Gateway & Discovery service is running & Azure Site Recovery Management Service (asrmgmtsvc) is NOT running and fails immediately when started.

This already tells us the problem is local to the ASR management service, not networking alone.

From the event view we see that service starts, but fails during Azure authentication / registration validation.

So, Your ASR appliance / provider is no longer registered correctly with Azure, or its registration state is corrupted.

Because of that:

asrmgmtsvc tries to load registration + auth settings

Azure registration check fails

Service throws NullReferenceException

Service exits immediately

This is NOT a simple “restart service” issue.

This usually happens because of following error pattern.

Recovery Services vault was deleted / recreated

Appliance was removed from the vault but not cleaned locally

Subscription / tenant changed

Outbound Azure endpoints blocked (DNS / firewall / proxy)

Provider upgrade or partial update failure

Appliance cloned or restored from snapshot

Your DNS failure to update.azure.com strongly suggests outbound connectivity or proxy issues, which can cause or worsen this state.

What we understand from here is that restarting the service will NEVER work here

Because:

The failure is during initialization

The service cannot start without valid registration metadata

Restarting only repeats the same crash

Kindly follow below options and see if it works

Option 1: Re‑register the appliance (most common fix)

In Azure Portal:

Go to Recovery Services Vault

Check if this appliance still appears

If present but unhealthy → Remove / delete it.

On the appliance:

Unregister ASR provider

Re‑register it using a fresh vault registration key

This resets:

Authentication

Vault association

Certificates

Service configuration

After re‑registration, asrmgmtsvc starts normally.

Option 2: Fix outbound connectivity (must be done regardless)

DNS can resolve public Azure endpoints

Firewall / proxy allows outbound HTTPS (443)

At minimum, the appliance must reach:

Azure service endpoints

Recovery Services endpoints

Microsoft update / CRL endpoints

Option 3: Repair / reinstall ASR provider (when registration is corrupted)

If re‑registration fails or the provider state is broken:

Perform a provider repair or reinstall

Then re‑register to the vault

Kindly check and let us know if have questions?
Naveena Patlolla 9,310 Reputation points Microsoft External Staff Moderator

2026-03-24T07:22:26.5866667+00:00

Hello Jayanth Dattatri YKB,
We haven’t heard back from you yet. Please let us know if you are still experiencing the same issue.
Naveena Patlolla 9,310 Reputation points Microsoft External Staff Moderator

2026-03-25T09:14:01.7966667+00:00

Hello Jayanth Dattatri YKB,
Have you tried the above resolution steps? Please let us know if they worked for you. If not, feel free to reach out—we’re always here to help.
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-25T17:47:51.2233333+00:00

Hello @Naveena Patlolla

Interestingly, it started working on its own after the I left the appliance in the same state overnight. I observed a similar behavior for the target appliance as well. The only additional step I did is to enable winhttp proxy at the system level. Not sure why this is required since the proxy details are captured in the set up proxy step. But I did see the same issue on the target appliance as well.
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-26T16:50:30.0933333+00:00

@Naveena Patlolla FYI most of the steps you provided are not applicable in my case. The appliance is not registered. please read my issue carefully. I have ensured all the URLs can be resolved via proxy. The question is when I setup the proxy in the config wizard, why is the appliance not getting updated. It works in a non-proxy environment. After I setup the system wide proxy using netsh winhttp command, I was able to get it to work not immediately but after sometime. Not sure why it takes so much time.

1 answer

Your answer

Siva shunmugam Nadessin 7,735 Reputation points Microsoft External Staff Moderator

2026-03-20T01:02:15.6333333+00:00

Hello Jayanth Dattatri YKB

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
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-20T03:28:08.08+00:00

@Siva shunmugam Nadessin The Azure Site Recovery Management Service is not running and errors out when trying to restart

Event Viewer:

AgentUpdater.log
Naveena Patlolla 9,310 Reputation points Microsoft External Staff Moderator

2026-03-24T07:22:26.5866667+00:00

Hello Jayanth Dattatri YKB,
We haven’t heard back from you yet. Please let us know if you are still experiencing the same issue.
Naveena Patlolla 9,310 Reputation points Microsoft External Staff Moderator

2026-03-25T09:14:01.7966667+00:00

Hello Jayanth Dattatri YKB,
Have you tried the above resolution steps? Please let us know if they worked for you. If not, feel free to reach out—we’re always here to help.
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-25T17:47:51.2233333+00:00

Hello @Naveena Patlolla

Interestingly, it started working on its own after the I left the appliance in the same state overnight. I observed a similar behavior for the target appliance as well. The only additional step I did is to enable winhttp proxy at the system level. Not sure why this is required since the proxy details are captured in the set up proxy step. But I did see the same issue on the target appliance as well.
Jayanth Dattatri YKB 40 Reputation points MVP

2026-03-26T16:50:30.0933333+00:00

@Naveena Patlolla FYI most of the steps you provided are not applicable in my case. The appliance is not registered. please read my issue carefully. I have ensured all the URLs can be resolved via proxy. The question is when I setup the proxy in the config wizard, why is the appliance not getting updated. It works in a non-proxy environment. After I setup the system wide proxy using netsh winhttp command, I was able to get it to work not immediately but after sometime. Not sure why it takes so much time.

Answer 1

The error indicates that the Azure Migrate appliance cannot successfully auto‑update its internal services, even though connectivity and the project key validation are passing. Use the following steps that are specific to appliance auto‑update and MSI validation.

Verify internet and aka.ms connectivity
- From the appliance, ensure outbound HTTPS access (via your proxy if used) to all required Azure Migrate URLs, including the aka.ms endpoints used for downloading service components.
- If the connectivity check fails specifically for aka.ms during prerequisites, follow these steps:
  - Add aka.ms/* to the proxy/firewall allowlist.
  - Re‑enter proxy details in Setup proxy and save.
  - Go back to the configuration manager and rerun prerequisites to trigger auto‑update.
  - If it still fails, download latestcomponents.json from the aka.ms link and manually update the failing services using the download URLs in that file.
Run the built‑in diagnostic checks
- In the appliance configuration manager, use Diagnose and solve (if available) and confirm:
  - Connectivity checks pass.
  - Auto update check reports that all agents are up to date.
  - Service endpoint connectivity is healthy.
  - Replication appliance/ASR components check confirms the server is not also used as a replication appliance (this configuration is unsupported and can break services).
Fix MSI digital‑signature validation (common cause of auto‑update failures) A recent change to MSI validation can cause auto‑update to fail with errors about critical services not updating. Ensure the appliance can validate Microsoft‑signed MSIs:
1. Open Settings → search for Certificates → Manage computer certificates.
2. Under the appropriate certificate stores, confirm that these certificates exist:
  - Microsoft Root Certificate Authority 2011
  - Microsoft Code Signing PCA 2011
3. If either is missing, download and install them on the appliance using:
  - MicrosoftRootCertificateAuthority2011.cer
  - MicCodSigPCA2011_2011-07-08.crt
4. Check local Group Policy (gpedit.msc) and ensure Network Retrieval policies are configured as shown in the documentation so that certificate chain validation can reach Microsoft’s servers.
5. Make sure no firewall or proxy rule blocks certificate validation traffic.
Confirm MSI validation works end‑to‑end
- Download the sample MSI MicrosoftAzureAutoUpdate.msi to the appliance.
- Right‑click → Properties → Digital Signatures → Details.
- Confirm that Digital Signature Information shows status OK.
- If this succeeds, rerun the appliance prerequisites so auto‑update can complete and the “Critical services are either not updated, installed or status not available” message clears.
If auto‑update still fails
- Use the manual service update approach from latestcomponents.json as described above.
- Ensure the appliance is not running any anti‑virus or endpoint protection that blocks or quarantines the downloaded MSI files or running services.

Once MSI validation and aka.ms connectivity are working, the appliance auto‑update check should pass, and the registration step can complete successfully.

References:

Share via

Azure Migrate with Azure Local: Critical services are either not updated, installed or status not available

1 answer

Your answer