Installation of mobility service on source machine has failed.

The error you're encountering, MachineWithSameBiosIdAndFqdnAlreadyExists, indicates that the Azure Site Recovery service has detected a machine with the same BIOS ID and fully qualified domain name (FQDN) already registered in the system. This can happen if the machine was previously registered and not properly removed from the Azure Site Recovery vault before attempting to re-register it.

Here are some steps you can take to resolve this issue:

1. Verify Deletion: Ensure that the protected item was completely deleted from the Azure Site Recovery vault. You can use the Azure CLI command you mentioned to delete the protected item, but also check if it is indeed removed by listing the protected items again.
2. Check for Duplicate Registrations: Sometimes, the registration may not be fully cleared. Check if there are any remnants of the previous registration in the Azure portal or via CLI commands.
3. Reboot the Source Machine: Since the initial installation completed with warnings and indicated that a reboot was required, ensure that the source machine has been rebooted after the installation attempt. This can help apply any pending changes.
4. Review Logs: Check the logs on the source machine for any additional error messages that may provide more context on why the registration is failing.
5. Contact Support: If the issue persists after ensuring that the protected item is deleted and the machine is rebooted, consider reaching out to Azure support for further assistance, as they can provide more detailed insights into the registration process.

By following these steps, you should be able to resolve the registration issue and successfully install the Mobility service on your source machine.

References:

• Troubleshoot Mobility service push installation
• About the Mobility service for VMware VMs and physical servers

Hello Hennelly, Jim (MPBSDP),

Why it happens

• The Configuration Server (CS) maintains a catalog keyed by hardware identifiers (BIOS ID) and machine identity (FQDN).
• A stale entry for the same machine exists on the CS (even if replication was previously stopped), so the new registration is rejected.

Fix (safe and clean approach)

Stop replication (Portal):

Azure portal → Recovery Services vault → Site Recovery → Replicated items → select the machine (old entry) → Stop replication.

Choose whether to retain recovery points (usually you won’t retain if you intend to re-seed; if this was mid-migration, retain only if you need those RP snapshots for investigation).

Clean up stale machine on the Configuration Server:

• On the Configuration Server, open the ASR Appliance Configuration Manager (web UI on the CS) → Manage → Machines (or Protected / Discovered machines) → find the entry with the same FQDN and remove it.

If the UI still shows it after stop-replication, perform a CS clean-up:

Restart the svagents/RCM services or reboot the CS.

If needed, clear stale entries using the Config tool (names vary a bit across versions). Typical paths:

      C:\Program Files (x86)\Microsoft Azure Site Recovery\ConfigTool\

      C:\Program Files\Microsoft Azure Site Recovery\home\svsystems\bin\

• Run the stale cleanup operation from the tool (menu-driven) to purge orphaned/duplicate records. (Tool names change across builds; look for actions like “Clean stale entries”, “Remove deleted VMs” or similar in the ConfigTool).

Reset the source machine’s agent identity (if the duplicate persists):

On the source machine:

• Uninstall the ASR Mobility service (Programs & Features).
• Delete residual agent state folders if left behind:
• %ProgramData%\Microsoft Azure Site Recovery\ (check for agent, rcm, or rcmdb subfolders).
• Check for leftover registry keys (only if instructed by support or if the reinstall still picks up old identity):
• HKLM\SOFTWARE\Microsoft\Azure Site Recovery\ (Agent/Replication keys).
• Reinstall the Mobility agent with the latest build.

Re-register to the same Configuration Server.

• Re-enable replication:
• In the vault/appliance, enable replication for the machine again.
• Verify the machine appears once and registration completes without error 20517.

Notes & sanity checks

• The host-id in your log f107edca-8bc9-497a-80e7-e7024b0e941c is the local agent identity. If that host-id already exists on the CS for the same FQDN/BIOS, the server will reject duplicates.
• If the machine name (FQDN) legitimately changed (e.g., domain join), ensure the CS has only one entry for this BIOS ID. If you intentionally need two entries (e.g., cloned lab), you must change hardware identifiers (not recommended) or use different source machine.

 Let us know if you have further questions?