Resolving MachineWithSameBiosIdAndFqdnAlreadyExists During Azure Migrate Mobility Agent Registration

While working on an Azure Migrate project, we encountered a failure during Mobility Agent registration with the error:

<ErrorCode>MachineWithSameBiosIdAndFqdnAlreadyExists</ErrorCode>

This error code is identified in C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentConfigurator.log file on Source Server.

This issue surfaced after a server was initially onboarded using credential-based discovery, followed by a manual Mobility Agent installation via credential-less discovery.

In this blog, we’ll walk you through:

• Why this issue occurs
• What it means technically
• The exact step-by-step resolution

🚨 Problem Statement

Here’s what happened in our scenario:

• A source server was successfully discovered using credential-based discovery via Azure Migrate.
• Later, the Mobility Agent was manually re-installed and re-registered using credential-less discovery.
• During registration, the Mobility Agent failed with the error: MachineWithSameBiosIdAndFqdnAlreadyExists
• Logs confirmed the issue at: C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentConfigurator.log
• As a result, Mobility Agent Registration with Azure Migrate Vault could not be completed and further replication steps were blocked.

Fig 1: 'ASRUnifiedAgentConfigurator.log' File with 'MachineWithSameBiosIdAndFqdnAlreadyExists' error

🔍 Root Cause

Azure Migrate uniquely identifies machines using BIOS ID + FQDN.

When the same machine is onboarded using different discovery methods:

• It results in multiple registrations for the same physical server
• Azure Migrate detects this as a duplicate identity conflict

Fig 2: Duplicate Registration Conflict in Azure Migrate

In this case:

• First registration → Credential-based discovery ✅
• Second registration → Credential-less discovery ❌
• Result → Azure rejects the second registration due to identity duplication

🛠️ Resolution

The fix involves realigning the Mobility Agent with the original machine identity.

✅ Step 1: Generate Agent Config Input (Source Machine)

Open Command Prompt as Administrator:

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\"
AzureRcmCli.exe --getagentconfiginput

👉 This generates a unique Agent Config Input string.

✅ Step 2: Generate Mobility Service Configuration File (Appliance)

On the Azure Migrate appliance:

1. Open Azure Appliance Configuration Manager
2. Go to Mobility Service Configuration
3. Paste the Agent Config Input
4. Download the generated configuration file

Fig 3: Download Configuration File Option in Azure Migrate Appliance Configuration Manager

✅ Step 3: Copy Config File to Source Server

Copy the downloaded file (example below):

e1fdc8ce-e518-4fd2-b281-cc71433d512e_config.json

Paste it into:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\etc

✅ Step 4: Validate & Update drscout.conf

Navigate to:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\etc

Edit drscout.conf file and ensure the following parameters exist under [vxagent]:

[vxagent]
HostId="Collect from support team"
ResourceID="Collect from support team"

Fig 4: How to edit drscout.conf file

⚠️ Important:

• Use the original HostId and ResourceID
• These correspond to the first (credential-based) discovery
• If unavailable, obtain them from the Azure Migrate support team

✅ Step 5: Unregister Existing Mobility Agent

Run:

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\"
AzureRcmCli.exe --unregistersourceagent
UnifiedAgentConfigurator.exe /Unconfigure true

👉 This removes the conflicting registration.

✅ Step 6: Regenerate Configuration File

Repeat Step 2 using the same Agent Config Input to generate a fresh config file.

✅ Step 7: Re-register Mobility Agent

cd "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\"
UnifiedAgentConfigurator.exe /SourceConfigFilePath "config.json" /CSType CSPrime

✅ After this:

• Mobility Agent registers successfully
• Replication works without errors

💡 Key Learnings

• Avoid mixing credential-based and credential-less discovery for the same machine
• Azure Migrate enforces strict identity uniqueness (BIOS ID + FQDN)
• Always align the Mobility Agent with the original HostId and ResourceID
• Proper cleanup + re-registration resolves the issue without deleting the machine

🧾 Conclusion

The MachineWithSameBiosIdAndFqdnAlreadyExists error is a classic identity conflict scenario in Azure Migrate.

By:

• Cleaning up the incorrect registration
• Reusing the original machine metadata
• Re-registering the agent correctly

…you can resolve the issue cleanly and safely, without impacting the migration workflow.