Why is the primary VM associated with the Test Failover VM IP after cleanup?

Question

Why is the primary VM associated with the Test Failover VM IP after cleanup?

faraz ahmad 20

After creating an ASR for a VM and performing a test failover, the test VM was created successfully. Post-testing, the test VM and its resources were deleted through the ASR UI. However, following this cleanup, the application on the primary VM stopped working.

During investigation, it was discovered that the primary VM was now responding to the IP address of the test VM, although it is still accessible via its original private IP through RDP. It appears that the DNS for the primary VM has changed.

What could cause the DNS to change for the primary VM in this scenario? The workaround identified was to restart the primary VM, which restored its ability to be pinged with its actual IP.

Key Point - primary and failover vnet are in different location

Naveena Patlolla 3,775 Reputation points Microsoft External Staff Moderator

2025-05-22T01:24:43.4933333+00:00

Hi faraz ahmad

Just want to check if the below answer provided by @Jose Benjamin Solis Nolasco worked for you or else please let us know if any help, we are always here to help whenever you need us.

Please do not forget to "Accept the answer” and “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.
Naveena Patlolla 3,775 Reputation points Microsoft External Staff Moderator

2025-05-26T07:46:45.9966667+00:00
Hi faraz ahmad

It appears that the test failover was performed in the main network, where your Domain Controller or Additional Domain Controller is hosted.

For example, if your source server is named Server1 with IP address 10.0.0.4, performing a test failover in the same Azure virtual network (that includes your Domain Controller) can cause the test VM to register a new IP address in DNS, potentially overwriting the original DNS entry.

How to Fix the Issue:

Log in to the DNS Server

Access the DNS server via RDP, SSH, or the DNS management console.

Open the DNS Management Console

On a Windows DNS Server: go to Server Manager → Tools → DNS.

Navigate to the Relevant Zone

Expand Forward Lookup Zones.

Select the appropriate zone (e.g., [example.com]).

Locate and update the DNS Record

Find the relevant A (Host) record for the affected server.

Right-click the record → Select Properties.

Update the IP address with the correct value.

Click OK to save the changes.

Clear the DNS Cache ipconfig /flushdns

How to Prevent This Issue in Future Test Failovers:

Use an Isolated Test Network: Always perform test failovers in an isolated Azure virtual network that is not connected to your Domain Controller or production network.

Create a Local User Account: Set up a local user and password on the source server before replication.

Connect with Local Credentials: During test failover, use the local account to log in and validate the machine, avoiding any DNS registration conflicts.
Please let me know if you face any challenge here, I can help you to resolve this issue furtherProvide your valuable Comments.

Please do not forget to “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.

Accepted answer

0 additional answers

Your answer

Naveena Patlolla 3,775 Reputation points Microsoft External Staff Moderator

2025-05-22T01:24:43.4933333+00:00

Hi faraz ahmad

Just want to check if the below answer provided by @Jose Benjamin Solis Nolasco worked for you or else please let us know if any help, we are always here to help whenever you need us.

Please do not forget to "Accept the answer” and “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.
Naveena Patlolla 3,775 Reputation points Microsoft External Staff Moderator

2025-05-26T07:46:45.9966667+00:00

Hi faraz ahmad

It appears that the test failover was performed in the main network, where your Domain Controller or Additional Domain Controller is hosted.

For example, if your source server is named Server1 with IP address 10.0.0.4, performing a test failover in the same Azure virtual network (that includes your Domain Controller) can cause the test VM to register a new IP address in DNS, potentially overwriting the original DNS entry.

How to Fix the Issue:

Log in to the DNS Server

Access the DNS server via RDP, SSH, or the DNS management console.

Open the DNS Management Console

On a Windows DNS Server: go to Server Manager → Tools → DNS.

Navigate to the Relevant Zone

Expand Forward Lookup Zones.

Select the appropriate zone (e.g., [example.com]).

Locate and update the DNS Record

Find the relevant A (Host) record for the affected server.

Right-click the record → Select Properties.

Update the IP address with the correct value.

Click OK to save the changes.

Clear the DNS Cache ipconfig /flushdns

How to Prevent This Issue in Future Test Failovers:

Use an Isolated Test Network: Always perform test failovers in an isolated Azure virtual network that is not connected to your Domain Controller or production network.

Create a Local User Account: Set up a local user and password on the source server before replication.

Connect with Local Credentials: During test failover, use the local account to log in and validate the machine, avoiding any DNS registration conflicts.
Please let me know if you face any challenge here, I can help you to resolve this issue furtherProvide your valuable Comments.

Please do not forget to “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.

Answer 1

Jose Benjamin Solis Nolasco 3,511

@faraz ahmad the cleanup process didn’t fully remove all resources associated with the test VM, leading to lingering configurations. Documentation highlights that incomplete cleanup can cause IP address conflicts, as noted in troubleshooting guides

See https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-failover-to-azure-troubleshoot

The most likely because of your issue is a DNS resolution problem, where DNS records were updated during test failover (either manually or through automation) and not reverted after cleanup, leading to cached incorrect entries on the primary VM. Restarting the VM cleared its DNS cache, restoring normal operation. To prevent recurrence, ensure DNS changes are reverted post-cleanup, verify no lingering resources in Azure, and monitor application behavior during future tests. If issues persist, contact Microsoft Support with detailed logs and configurations for further investigation.

😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

faraz ahmad 20 Reputation points

2025-05-21T03:25:53.23+00:00

Sure @Jose Benjamin Solis Nolasco , I'll have a quick try
Naveena Patlolla 3,775 Reputation points Microsoft External Staff Moderator

2025-05-21T05:42:21.65+00:00

Hi faraz ahmad
Thanks for your acknowledgement.

We will look forward for your response.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
faraz ahmad 20 Reputation points

2025-05-22T22:39:18.1533333+00:00

Thanks @Jose Benjamin Solis Nolasco for the answer, It is indeed DNS issue as per my question and your answer. We have to share the logs with Microsoft to understand the root cause. I am very keen to know why it happened and what exactly to do in such events.

Share via

Why is the primary VM associated with the Test Failover VM IP after cleanup?

0 additional answers

Your answer