Azure Site Recovery - Modernized Appliance: Mobility Service Agent Registration Loop Issue

Rogerio Verissimo 0 Pontos de reputação
2026-08-09T16:53:04.14+00:00

Problem Summary

We have a modernized Azure Site Recovery appliance (Windows Server 2022) deployed on-premises with IP *XXX.XXX.X.171 **port 44368.

We don't have VCenter on ESXi Vmware, so, we follow the suggest to use like a physical machine

When attempting to replicate a VMware VM (tfs - Windows Server 2022) from on-premises to Azure, the Mobility Service Agent enters an infinite registration loop and never completes the registration process.

Error Messages Received:


Error ID539: The requested action couldn't be performed by the Replication Provider

Error ID310045: Virtual machine 'tfs' cannot be protected from on-premises to Azure

Possible Cause: The mobility agent on the machine 'tfs' is not yet registered with Proxy server

Environment Details

  • Appliance: Windows Server 2022 (XXX.XXX.X.171:44368)
  • Appliance Deployment: Modernized Site Recovery Appliance
  • Source VM: tfs (Windows Server 2022, VMware)
  • Source VM IP: XXX.XXX.X.76
  • Subscription ID: xxxxx-xxxxxx-xxxxx
  • Region: East US
  • Appliance Status in Portal: Health = Green, all components showing success

Steps Taken So Far

1. Appliance Setup

  • Deployed modernized appliance on fresh Windows Server 2022
  • Appliance accessible at https://localhost:44368
  • Appliance health status: Success in Portal Azure
  • Both machines (tfs-build and tfs) discovered successfully with Success status

2. Mobility Service Installation

  • Copied C:\DRAppliance\DRAppliance\Agents\Microsoft-ASR_UA_9.66.7567.1_Windows_GA_20Sep2025_release.exe to machines that we want replicate (tfs and tfs-build)
  • Installed Mobility Service via GUI installer on source VM
  • Service svagents is Running consistently
  • Installation log shows: Exit code returned by unified agent configurator: 0(Successful)

3. Configuration File Setup

  • Generated configuration JSON from appliance portal (44368)
  • File name: xxxx-xxxx-xxxx.json
  • File location: C:\ProgramData\Microsoft Azure Site Recovery\agent\
  • File size: ~7KB (complete and valid JSON)
  • File contains all required fields:
  • SubscriptionId: valid
  • BiosId: xxxx-xxxxx
  • FQDN: tfs.xxxx.xxxx
  • ClientCertificate: valid PFX certificate
  • RcmProxyTransportSettings with correct appliance IP (XXX.XXX.X.171) and port (443)
  • Successfull conectivity between these machines to appliance machine on ports 9443 e 443

4. Network Connectivity Verification

  • Test-NetConnection to appliance port 443: Success
  • Test-NetConnection to appliance port 9443: Success
  • Machine has internet access: Confirmed
  • No proxy required
  • DNS resolution working

5. Service Troubleshooting

  • Restarted svagents service multiple times
  • Cleared cache and logs multiple times
  • Cleaned ProgramData and registry completely
  • Reinstalled Mobility Service from scratch
  • Verified file permissions

6. Appliance Verification

  • Appliance shows both machines as Discovered with Success status
  • Machines appear in "Physical server details" > "List of physical servers"
  • Mapped credentials: ADM-VMs (valid)
  • No pending approvals needed

7. Multiple Replication Attempts

  • Attempted replication job multiple times
  • Each attempt returns the same Error 539 and 310045
  • No progress towards actual replication

Current Behavior

The Mobility Service Agent is stuck in a registration loop:

  • Service starts successfully
  • Attempts to register every ~15 minutes (seen in logs)
  • Never completes registration - service continues trying indefinitely
  • No error messages in logs preventing the registration
  • Configuration file is valid and in correct location
  • Appliance recognizes the machine but registration doesn't complete

Example from logs (svagents_curr_25.log):


10:50:30 - RcmClientLib::RcmClient::RegisterMachine: Registering VM security type as None

11:05:33 - RcmClientLib::RcmClient::RegisterMachine: Registering VM security type as None (15 min later)

11:20:35 - RcmClientLib::RcmClient::RegisterMachine: Registering VM security type as None (15 min later)

[Pattern repeats indefinitely]

What Works

  • Appliance is healthy
  • Machines are discovered
  • Mobility Service installs successfully
  • Network connectivity is confirmed
  • Configuration file is valid
  • Service is running
  • Certificate is valid (expires Aug 8, 2027)

What Doesn't Work

  • Mobility Service Agent will not complete registration
  • Replication cannot be enabled from Portal
  • Agent stuck in registration retry loop
  • No clear error indicating what's blocking registration

Additional Context

Anyone, can help us to solve this? For security reasons we haven't sent the log files.

Please advise on:

  1. Root cause of the registration loop
  2. Steps to resolve or workaround
  3. Additional diagnostics needed from appliance or VM side
  4. Known issues or limitations in current modernized appliance version
Azure Site Recovery
Azure Site Recovery

Um serviço de recuperação de desastre nativo do Azure. Anteriormente conhecido como Gerenciador de Recuperação Microsoft Azure Hyper-V.

0 comentários

2 respostas

Classificar por: Mais Antigo
Mais útil Mais Novo Mais Antigo
  1. Suchitra Suregaunkar 16,780 Pontos de reputação Equipe Externa da Microsoft Moderador
    2026-08-09T17:51:32.2066667+00:00

    Hello Rogerio Verissimo

    Thank you for posting your query on Microsoft Q&A platform.

    The repeating RcmClient::RegisterMachine entry every ~15 minutes with no error is the agent's normal retry timer. It means svagents is issuing the RegisterMachine call to the RCM proxy on the appliance, but the call is never being accepted on the service side. Because the agent logs no terminal error, the failure is almost always on one of three things — and, importantly, manually copying the JSON into C:\ProgramData\Microsoft Azure Site Recovery\agent\ does not register the machine. The config file must be consumed by the configurator/registration step; simply having a valid file in the folder produces exactly the symptom described (service healthy, file valid, registration never completes).

    Ranked, the three realistic causes:

    1. Registration step never executed — the JSON was placed on disk but UnifiedAgentConfigurator.exe / the installer's Register step was never run against it.
    2. Config file generated from the wrong "Machine Details" string — the configuration file is machine-specific. It's generated by pasting the Machine Details string copied from that exact source VM into the appliance's Mobility service configuration details section. A file generated for tfs-build will never register tfs.
    3. Duplicate BIOS ID / FQDN already registered in the vault — very likely here, because tfs and tfs-build look like clones of the same template. ASR rejects this with MachineWithSameBiosIdAndFqdnAlreadyExists, and stale entries from a previously deleted appliance persist in the vault. Reference: aka.ms/BIOSID_conflict.

    Resolution steps:

    On the source VM tfs, run these from an elevated command prompt:

    1. Extract the installer: .\Microsoft-ASR_UA*Windows*release.exe /q /x:"C:\Azure Site Recovery\Agent"
    2. Launch the installer in modernized mode: .\UnifiedAgentInstaller.exe /Platform vmware /Role MS /CSType CSPrime /InstallLocation "C:\Azure Site Recovery\Agent" CSType CSPrime is what selects the modernized flow if the UI shows the classic passphrase prompt instead of a Registration step, the wrong mode was used and registration can never succeed.
    3. At the Registration screen, copy the Machine Details string shown for this machine.
    4. On the appliance (https://<applianceIP>:44368), open Microsoft Azure Appliance Configuration Manager → Mobility service configuration details, paste the Machine Details string, and select Download configuration file.
    5. Back on tfs, supply the path to that file in the Unified Agent configurator and select Register.

    If the agent is already installed and you only need to re-register, run UnifiedAgentConfigurator.exe from the agent install path directly rather than reinstalling.

    Additional diagnostics to request:

    • Full svagents_curr*.log from C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\ — the documented location for mobility agent health triage. Ask them to grep for ErrorCode, RcmReportedError, IsRetryableError rather than sending the whole file, since they cited security concerns.
    • ua_install.log and the configurator output/exit code from the register operation (not the install operation —install exit code 0 only confirms installation).
    • Output of wmic csproduct get UUID on both tfs and tfs-build. Identical UUIDs confirm the BIOS ID conflict path.
    • Confirmation of whether any earlier appliance/vault was deployed and deleted for these same machines — stale registrations survive appliance deletion.
    • Client certificate validity window vs. current system time on the source VM; clock skew invalidates the cert and produces ClientCertificateIsInvalidOrExpired, whose documented fix is to regenerate the configuration file and re-register.

    Known limitations worth flagging:

    • For physical servers added without credentials, Microsoft explicitly requires manual mobility service install + manual enable replication push install is not an option.
    • There is no supported self-service way to unregister/delete a modernized appliance; cleanup historically required deleting the vault and resource group, which is why stale BIOS ID/FQDN entries linger.
    • Antivirus must exclude C:\ProgramData\ASR\agent on replicated machines.

    Thanks,
    Suchitra.

    Esta resposta foi útil?

    0 comentários
  2. Rogerio Verissimo 0 Pontos de reputação
    2026-08-10T23:11:47.68+00:00

    Thank you for support, finally I finished the job here.

    Here are the conditions:

    1. Reset ASR
    2. Create a New Azure Vault Services
    3. Uninstall Agents from Vmwares's machines
    4. Reinstall ASR
    5. Install manually agent on VM's machines
    6. Copy de string
    7. Put string on ASR interface
    8. Download de config json file
    9. Put the config json file on directory of agent (Step 5)
    10. Acess Portal Azure and Add Replicate item

    That's all ! If you put your credentials of physical machines, or add physical machines on ASR interface, nothing work in my case.

    Esta resposta foi útil?

    1 pessoa achou esta resposta útil.
    0 comentários

Sua resposta

As respostas podem ser marcadas como ‘Aceitas’ pelo autor da pergunta e ‘Recomendadas’ pelos moderadores, o que ajuda os usuários a saber a resposta que resolveu o problema do autor.