Azure Hybrid & Cloud Migration Blog

Author: Zahir Hussain Shah | MVP Exchange Server, CISSP

Step by Step Troubleshooting of Microsoft Outlook Prompting for User Login Password, after a failed Live Migration of Domain Controller Virtual Machine, and the DNS Name Resolution Issues, while also discussing the Name Resolution and Domain Controller Best Practices for Virtualized Environments

With the above title of the post, we will also be discussing the following topics in the blog post:

• Hyper-V Live Migration Best Practices
• Virtualized Domain Controller Best Practices
• Domain Controllers and DNS Name Resolution Strategy in heterogeneous Domain Controller Environment

Recently, I came across an issue, where after a failed Live Migration of a Windows Server 2008 SP2 VM based Domain Controller (DC) on Windows Server 2008 R2 SP1 Hyper-V Server, caused serious problem for DNS Name Resolution, and since this Virtual DC was the primary DNS Server for all the Servers and clients, it also caused Microsoft Outlook to prompt the user passwords, whenever a user was opening Microsoft Outlook.

Problem: Live Migration Failure:

This Virtual DC was running on Windows Sever 2008 R2 Hyper-V Cluster, and at the time of performing Live Migration of this VM, the Live Migration failed at the source Hyper-V Server due to the fact that, VM was having an ISO image configured in the VM settings, which was located on the local C:\ drive of the Hyper-V host.

As a result of failing the Live Migration, VM stays at the same source Hyper-V Server, but its Virtual NIC settings got an error, and practically you can say that VM DC V-NIC association with the Hyper-V Physical NIC got broken, which resulted the VM lost connection to the Network.

Problem: Bad DNS Resolution and Microsoft Outlook Password Prompt for Users:
Okay, so we know now what happened to the DC VM, so to fix this problem without restarting the machine, I went to the VM properties, and set the Network to the same Hyper-V Virtual Network for the DC VM, and found that the VM came back online on the Network, so we were able to ping the DC, but later soon after that we found that Outlook users started complaining that, they are requested every time to provider user password, whenever they open Microsoft Outlook.

Nevertheless, as being a primary DNS Server and DC for authentication, after Live Migration Failure and resetting up of VMs network settings, it was noticed that, this DC as being a preferred DNS Server is no longer functional, means if you try to nslookup any name, it was getting failed, and also we found that the DNS Server service got stopped on the DC.

Okay now lets talk about Resolution to fix this problem, as its grown massively and affected all the clients and server for DNS Name Resolution and Outlook password prompts, which are quite annoying in nature.

Lets first discuss the Hyper-V Live Migration Best Practices:

I would recommend to always:

• Make sure that you dismount any ISO file attached to the Virtual Machine before hitting Live Migrate to other Hyper-V host, if your ISO file is not highly available, means if it cannot be accessed from the destination Live-Migration Hyper-V host.
• Your preferred DNS Server for Hyper-V Name Resolution and Authentication Server (DC) should bet set to the one, which is either on the different Hyper-V Cluster or Hyper-V Host, which will help you to be still in the game if your Live Migration fails or the DC VM fails.
• It would also be advisable to make sure that instead of pausing the VM, you always go for shutdown on Hyper-V, as a general good-practice.

Secondly to further discuss the above explained problems with regards to DNS Name Resolution and Microsoft Outlook password prompt for end-users, see the below guidelines:

Follow the steps to fix the problem in the order: (Note: We will try not to shut down the VM):

• After failing the Live Migration, the Network settings needs to bet setup correctly, means attaching the VMs NIC to the Hyper-V Virtual Network.
• Since now after doing the above setup, the VM will come on the Network, so either you can take RDP or from the Hyper-V Console, login into the VM, and try to START the DNS Server Service.
• After doing starting the DNS Server Service, you will see the NIC card of VM will be having a small warning sign, which will tell you that there is a problem with the Network Connectivity, so you can reset (Disable / Enable) the NIC of the VM.
• After the NIC resetting try to clear the DNS Cache and Register the machine in the DNS Server database, by ipchonfig /flushdns and ipconfig /registerdns.

So now, when you will open NSLOOKUP on the VM or on the other Servers / Clients, where this VM was having as preferred DNS Server, you will see the FQDN as the Server in the NSLOOKUP utility, and you can resolve the names.

Okay so now the DNS Name Resolution problem has been resolved, now we will go ahead and will try to fix the Microsoft Outlook password prompt issue, which caused due to the bad DNS Name Resolution issue:

You can follow the below steps to fix the Outlook password prompt issue:

Lets give a restart of one Exchange 2010 CAS Server at once, and once you will have both the Exchange 2010 CAS Server restarted, check for the below:

• Try to see the status of the Active Directory Replication, and give a repadmin /sycnall from the CMD with elevated administrative rights.
• Check for the Name Resolution from both Exchange 2010 CAS Servers.
• Since we didnt restarted the Exchange Mailbox Servers, try to go to them, and clear their DNS Cache and Register them back to the DNS Server with (ipconfig /flushdns, ipconfig /registerdns).
• o Everywhere you to make sure that you are able to resolve names, means the Server status at NSLOOKUP after the DNS Name Resolution steps performed, it should be okay.
• After giving the adequate time of AD Replication, you will find that Microsoft Outlook users are no longer asked for the password prompt, and they can open Outlook without any Windows Security dialog box.

Virtualized Domain Controller Best Practices:

In past, I published a blog post Best Practices for Running Virtualized Domain Controller, today in addition to all the best practices explained in that blog post, I would like to add the few down:

If your Primary DC (preferred DNS Server) is a Virtual Machine, always try to run it on a Standalone Hyper-V Server, because sometimes the failure of either the Hyper-V Cluster or DC VM can cause problem for either of them. I know Im saying for not to make DC VM Highly Available, but at the same time, I also seen from my practice experience, moving primary DC to Hyper-V Cluster will be a problem, when the enter Cluster is down, and when Cluster will try to come up where the DC (primary DNS Server) is not available, you could end-up with the cluster will not come online easily.

Try to virtualize the DC VM as an Additional Domain Controller but not for the primary and preferred DNS Server.

Domain Controllers and DNS Name Resolution Strategy in heterogeneous Domain Controller Environment

• As we said above, try to keep the VM based DCs (VM) as the secondary DNS Servers, because in some circumstances brining a VM based DC come online can cause problem for the entire environment, where brining an Physical DNS Server and DC is relatively handy, because all you need the network connectivity and the server should be up and running.
• From the prospective of bringing entire Datacenter down for some major power maintenance, it would be highly recommended to have Physical Domain Controller for all primary DNS Name Resolution and Active Directory Authentication needs.

I hope with the steps explained in this article, it will greatly help you to fix your DC Authentication and DNS Resolution issues after the failed Live Migration of DC VM, also you can take advantages of the various best practices outlined in this article for DNS Name Resolution Strategy and DC Virtualization for Hyper-V environments.

Cheers!