Most of the time we recommend for customers and partners not to virtualizes the AD server. the explanation we give for this is due to the time sync issue there might be problem. So what is this time sync issue and why we should give more consideration about this too much? In this article I’m going to talk about it little bit and explain a solution for that. As a thumb rule I’ve to update you’ll this is according to my 2 cents knowledge 🙂
Normally Active Directory heavily depend on the accurate time for various services (Eg: Authentication, replication, records updates..etc) When the AD is in a physical machine it will use the interrupt times set by the CPU clock cycles. Since it have the direct access to this time can be accurate.
When you try to virtualized the main problem you face is the virtualized environment behavior. Virtual PC’s are created to save the CPU clock cycles and when one OS is idling then CPU cycles send to that VM will be reduced. Since AD heavily depend on this CPU cycle missing them randomly means the time won’t be accurate. This problematic behavior is same either you’re using VMware, HYPER-V or any other third party virtualization technology. Once the clients and server having mismatch of time sync more than 5 minutes authentication and network resource access will be difficult. (Windows AD environment uses Kerberos authentication and by default time difference allowed is 5 minutes)
So one method is allowing the PDC emulator service holder AD server to sync time with an external time source instead of depending of the CPU clock cycles. To do that you have to edit the registry on the PDC emulator holding server. (As usual I assume you guys will take the necessary precautions like backing up server, registry…etc)
1. Modify Registry settings on the PDC Emulator for the forest root domain:
In this key:
• Change the Type REG_SZ value from NT5DS to NTP.
This determines from which peers W32Time will accept synchronization. When the REG_SZ value is changed from NT5DS to NTP, the PDC Emulator synchronizes from the list of
reliable time servers specified in the NtpServer registry key.
• Change the NtpServer value from time.windows.com,0x1 to an external stratum 1 time source—for example, tock.usno.navy.mil,0x1. More time servers information can be found over here.
This entry specifies a space-delimited list of stratum 1 timeservers from which the local computer can obtain reliable time stamps. The list can use either fully-qualified domain
names or IP addresses. (If DNS names are used, you must append ,0x1 to the end of each DNS name.) In this key:
• Change AnnounceFlags REG_DWORD from 10 to 5. This entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change the REG_DWORD value from 10 to 5 here.
2. Stop and restart the time service:
net stop w32time
net start w32time
3. Manually force an update:
w32tm /resync /rediscover
(Microsoft KB article # 816042 provides detailed instructions for this process.) Apart from that you can refer to this link as well.
As a thumb rule test this before applying for the production network. This is recommend if your organization preparing to move to 100% virtualization environment. If not at all cost try to have one DC in a physical server 🙂
Update: I found out Microsoft has already released an article about running Domain controller in HYPER-V. You can download the document from here.