Time drift on Virtualized Domain controller

We have a virtual server acting as the domain controller that cannot seem to be set to use any external NTP servers.  Below is the set of commands we tried using:

w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org",0×8 /syncfromflags:MANUAL

w32tm /config /update
net stop w32time
net start w32time

they all complete successfully but when I try to run w32tm /resync /force we get "The computer did not resync because no time data was available." Also, when we try w32tm /query /source it comes back with "local CMOS clock" on the DC.

We have also tried opening udp port 123 on our firewall with no luck.

Any advice is greatly appreciated.
Who is Participating?
Cliff GaliherConnect With a Mentor Commented:
Cliff GaliherCommented:
When it comes to virtualized DCs, my recommendation is to enable integration services and let the parent set the time on the DC. Then configure NTP on the parent to point to your preferred timesource and set the flag so that it is authoritative. That way the parent will *not* use the DC as a timesource (if your parent is domain joined) and keep the DC in sync. Then other machines can safely use the DC to get their time and the usual VM time drift issues are mitigated.
menreeqAuthor Commented:
we seem to have the same issue on the Host/hyper-v server, except it will start to show source is the local cmos clock but then flips back to the source being the virtual DC.  Any ideas?
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Cliff GaliherCommented:
That happens when the host is domain-joined and since the VM drifts, the host will drift. EVen worse, when integration services are enabled, you get this chicken and egg scenario where the VM starts to drift, the host gets the drifted time from the DC, the integration service syncs the DC to the slightly drifted host, and round and round. The drift actually *accelerates* in these scenarios.

Which is why you want to specifically configure NTP on the host to use an outside timesource  and set the flags to it knows the time source is authoritative. Make sure that sticks. You can even disable the time sync integration service temporarily and let the DC drift a little, but make sure the host time remains accurate regardless of the DC. Once you are comfortable that NTP is doing its job on the host, you can enable the time sync into the guest again and your DC will remain in sync with the host now, and the rest of the machines will, in turn remain in sync with the DC.
menreeqAuthor Commented:
I completely get that. The problem we are having now is that we cant get the host nor the dc to point to an external ntp server. I am not opposed to setting the host to point to an ntp.org pool but the host will simply not retain the settings manually set by the commads that were mentioned in the body of the question.
Cliff GaliherCommented:
Well, your set command is a little strange. My overall thoughts are as follows:

1) I noticed you are only specifying 0x8 on one timesource. That is odd. If you want to specify 0x8, you'd usually want to do it on *all* time sources.

2) Since your initial post was about setting this on your DC VM, 0x8 is indeed necessary. For a member server, such as the hyper-v host, it is not. I'd drop it altogether.

3) I'm also curious why you are specifying multiple ntp.org pools. You could just specify pool.ntp.org and actually get better resiliency. It is also easier to maintain as ntp.org can make back-end changes and pool.ntp.org will still be available. That isn't always true when specifying specifc sub-pools.

You can /update at the end of your config command. No reason to run those two separately.

As your system clock is reasonably close, no reason to use /force

If after all of that /resync still throws an error, my next suspicion would be that a group policy was configured to manage time settings across the domain. I'd look to make sure something isn't interfering there. I recall a KB article on the subject. I'll see if I can drum that up.
menreeqAuthor Commented:
I configured the windows ntp client policy under the domain controllers policy to enabled and pointed it to pool.ntp.org,0x8, and changed the type to NTP . I ran gpupdate /force then ran w32tm /query /source and got pool.ntp.org,0x8 .   Thanks for pointing me in the right direction!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.