Mobility Agent fails to register with Proxy Server

@Harrison, Tyler Sorry for the inconvenience this must have caused you!

I see that you've done a thorough job troubleshooting the Mobility Agent installation, but there are a few additional steps that I would like to suggest.

Make sure the versions of the Mobility Agent you're using are compatible with the OS versions you're trying to install them on. Sometimes, specific versions of the agent have known issues with certain Windows Server releases.

Check if all dependencies required for the Mobility Agent are installed. This includes .NET Framework and other prerequisites.

Review Mobility Service logs on the source VMs. These logs are typically located at C:\ProgramData\Microsoft Azure Site

Can you check the service account used for the Mobility Agent has the necessary permissions on both the source VM and the ASR appliance. You might need to explicitly grant permissions if they are not being picked up correctly. https://zcusa.951200.xyz/en-us/azure/site-recovery/region-move-cross-geos#verify-azure-account-permissions

As an alternative, try installing the Mobility Agent using PowerShell commands.

Start-Process -FilePath "C:\Path\To\AgentInstaller.exe" -ArgumentList "/quiet /norestart"

Though you've disabled firewalls, ensure there are no network security groups or other network configurations blocking the necessary ports. The Mobility Agent requires specific ports to communicate with the ASR service.

After making changes or installations, reboot the source VMs to ensure that all services and dependencies start fresh.

If none of the above steps resolve the issue, the best option would be to contact Azure technical support team by raising a support request. The ticket enables you to work closely with the support engineers and get a quick resolution to your issue.

Here is the link - https://docs.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request to create support case.

https://azure.microsoft.com/en-us/support/plans/

Please let us know if there are any challenges contacting support.

Hope this helps!

First time posting a question and managing responses; accidentally posted my comments as an answer.

Thanks for the suggestions, I will run through a few of these.

I have tried various version combinations between 2016/2019/2022 and today I tried two version of linux - all of them fail and fail in the same way.

I feel like the Microsoft documents are incomplete and are missing key steps. They are dated, reference Azure UI elements that no longer exist in Gov or Commercial cloud, and it took me three deployments (one Azure Migrate, and two Azure Site Recovery) to hammer out the differences.

I have verified the server-level dependencies, .net, GPOs/Reg Key, etc. I also verified that there was free-data-flow between the source VMs, the ASR appliance, all Microsoft Public Endpoints, and the RSV. There are no firewalls or NSGs etc that are in the way, no endpoint protection either.

It is frustrating to see a solution work so well when we migrated Vmware and hyper-v VMs out to azure, yet the moment we include the Mobility Agent for in-VM CDR, the entire solution becomes flaky at best. And again Microsoft’s failure on the Gov cloud buildout leaves us with so few resources available to move workloads to/from public cloud. It should be trivial for ASR Azure VM replication, to support cross geography replication. So many missed opportunities… I could go on all day about Microsoft’s numerous failures.

I will try the powershell deployment and see if it makes a difference. I will also triple check the accounts being used and their permissions in-VM as well as in Azure.

Unfortunately, our VAR botched our last EA renewal and coupled with Microsoft’s decision to drop bundled support for Azure services purchased on an EAs (see this article, https://azure.microsoft.com/en-us/updates/v2/azure-support-plan-discontinued), we are now without Tech support. Since EA changes must be made through the VAR, we cannot buy Standard support through the portal and have to work with them on it. It’s been a process.

Great time to be an Azure customer….

The Gov-2-Public cloud document doesn't make any mention of classic vs modernized deployments - I have only tried the modernized methods (aside from Azure migrate since it still uses classic), could the modernized version have limits that prevent our scenario from functioning? Is it worth the effort to try a classic-only deployment?

@Harrison, Tyler The Gov-2-Public cloud document you are referring to does not make any mention of classic vs modernized deployments because the document is focused on the process of migrating workloads from Azure Government to Azure Public cloud, and not on the deployment method.

The decision to use classic or modernized deployment methods depends on the specific requirements of your workloads and the resources you are deploying.Regarding your question about whether the modernized deployment method has limits that prevent your scenario from functioning, it is difficult to say without more information about your specific scenario. However, it is worth noting that modernized deployment methods are generally recommended over classic deployment methods, as they provide more features and capabilities.

If you are experiencing issues with the modernized deployment method, it may be worth trying a classic-only deployment to see if that resolves the issue.