Can i treat Azure Vm as other cloud VM or physical server.

Hello @Kum Wing Kit ,

Thank you for reaching out to Microsoft Q&A.

Yes, you can treat an Azure VM as a physical server (or other-cloud VM) when testing the agent-based migration path with Azure Site Recovery / Azure Migrate. This is a supported approach.

When installing the Mobility service, use the VMware platform parameter. Microsoft’s documentation specifically notes:

“If you're treating Azure VMs as physical machines, specify VMware.”

Recommended:
For the most reliable results on an Azure VM, do a manual installation rather than relying on push install:

1. Download the correct Mobility service installer from your replication appliance (Configuration Server / Process Server).
2. Run the installer with the VMware platform flag. Example (modernized / CSPrime):

UnifiedAgentInstaller.exe /Platform vmware /Silent /Role MS /CSType CSPrime /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery"

1. Complete the registration step with the appliance using the configurator and passphrase.

If you’re still seeing the internal error

- Check the logs under C:\ProgramData\ASRSetupLogs.

- Confirm no leftover Mobility service components remain from a previous attempt (uninstall via Control Panel or the MSI command in the docs).

- Verify prerequisites (admin rights, required ports, antivirus exclusions for the ASR folders, supported OS, sufficient disk space, and runtimes such as .NET / Visual C++ redistributables).

**Reference Document:**

- Mobility service overview & installation (includes the “treat Azure VMs as physical” note): [https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-mobility-service-overview](https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-mobility-service-overview)

- Troubleshoot Mobility Service push installation: [https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-troubleshoot-push-install](https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-troubleshoot-push-install)

- Agent-based migration architecture: [https://learn.microsoft.com/en-us/azure/migrate/agent-based-migration-architecture](https://learn.microsoft.com/en-us/azure/migrate/agent-based-migration-architecture)

- Migrate machines as physical servers: [https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-physical-virtual-machines](https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-physical-virtual-machines)

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

Hello Kum Wing Kit,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

Regarding your question:

If your goal is normal Azure VM disaster recovery, use Azure-to-Azure ASR replication and do not manually install the VMware/physical Mobility Service agent. Azure Site Recovery installs the Mobility Service extension automatically during Azure-to-Azure replication. - https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/site-recovery/azure-to-azure-autoupdate.md

If your goal is specifically to test agent-based migration, then you can treat the Azure VM as a physical machine, but you must use the VMware/physical-server Mobility Service flow and install the agent with /Platform vmware. Do not use /Platform Azure for this test scenario. - https://docs.azure.cn/en-us/migrate/agent-based-migration-architecture

Also note the important limitation: if the Azure VM was created from an Azure Marketplace image, it is not valid for full failover validation because failover of Azure VMs with Marketplace image disks is not supported when treated as physical machines. - https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/site-recovery/vmware-azure-troubleshoot-replication.md

The best supported is to use one of these two paths:

• For Azure VM disaster recovery: configure Azure-to-Azure ASR from the Recovery Services vault.
• For Mobility Service / agent-based migration testing: deploy a replication appliance, add the Azure VM as a physical server by IP/FQDN, copy the correct Mobility Service installer from the appliance, install it with /Platform vmware, generate the configuration file, and register the agent.

After using the correct flow and installation parameter, the Mobility Service installation should complete unless there is a separate prerequisite issue such as admin credential failure, WMI/File and Printer Sharing being blocked, network connectivity to the process server, unsupported OS, unsupported boot configuration, or antivirus interference.

Use the associated resource links for more reading and steps, and if the internal error persists, collect the exact ASR job error ID and logs before escalating to Microsoft Azure Support via your Azure Portal.

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Hi @Kum Wing Kit

If the source VM is already running in Azure, you generally shouldn't treat it as a physical server or another cloud VM for Azure Site Recovery (ASR) agent-based migration. Azure VMs have a native Azure-to-Azure replication workflow that doesn't require installing the Mobility Service agent.

If you're attempting an agent-based migration and encountering an internal error while installing the Mobility Service, it may indicate that the selected migration scenario doesn't match the source environment.

Could you clarify a few details?

Is the source VM already hosted in Microsoft Azure, or is it running in another cloud provider (AWS, GCP, etc.) or on-premises?

Are you using Azure Migrate or Azure Site Recovery?

What is the source OS (Windows/Linux)?

What's the exact error message or error code returned during the Mobility Service installation?

If your goal is to replicate an Azure VM to another Azure region, use the native Azure-to-Azure replication option instead of agent-based migration. The Mobility Service is intended for physical servers, VMware VMs, Hyper-V VMs, and supported third-party cloud VMs, not standard Azure-to-Azure replication.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.