1

So we had a user complain about the clocks being a minute out on her desktop and how she always misses her train as a result. Despite my incredulous reaction to such a thing it did prompt me to investigate the time sync in our domain and it has highlight a lack of understanding on my part I think.

At present the results of my "w32tm /monitor" command produces this:

C:\Users\TAlexander>w32tm /monitor
NCCDC1.xxxxxx.xx.xx[10.168.50.32:123]:
    ICMP: 0ms delay
    NTP: +2.4042293s offset from RHDC1.xxxxxx.xx.xx
        RefID: firewall.xxxxxx.xx.xx [10.168.xxx.xxx]
        Stratum: 4
NCCDC3.xxxxxx.xx.xx[10.168.50.36:123]:
    ICMP: 0ms delay
    NTP: +2.4122098s offset from RHDC1.xxxxxx.xx.xx
        RefID: firewall.xxxxxx.xx.xx [10.168.xxx.xxx]
        Stratum: 4
NCCDC.xxxxxx.xx.xx[[fe80::d1e0:8675:36c1:acba%14]:123]:
    ICMP: 0ms delay
    NTP: -0.0916479s offset from RHDC1.xxxxxx.xx.xx
        RefID: RHDC1.xxxxxx.xx.xx [10.168.50.35]
        Stratum: 2
RHDC1.xxxxxx.xx.xx *** PDC ***[10.168.50.35:123]:
    ICMP: 0ms delay
    NTP: +0.0000000s offset from RHDC1.xxxxxx.xx.xx
        RefID: 'LOCL' [0x4C434F4C]
        Stratum: 1
ICMDC1.xxxxxx.xx.xx[10.168.50.31:123]:
    ICMP: 0ms delay
    NTP: +2.4229719s offset from RHDC1.xxxxxx.xx.xx
        RefID: wwwco1test12.microsoft.com [65.55.21.20]
        Stratum: 3
ICMDC2.xxxxxx.xx.xx[10.168.50.33:123]:
    ICMP: 0ms delay
    NTP: +0.1387203s offset from RHDC1.xxxxxx.xx.xx
        RefID: RHDC1.xxxxxx.xx.xx [10.168.50.35]
        Stratum: 2

RHDC1 is our PDC so my thinking from what I have read is that RHDC1 should have RefID of a different time source (in this case it would be our firewall) and that other DCs should then look to the PDC for their time and as a result show RHDC1 in the RefID. The clients (servers and workstations) should then sync at the running of the NETLOGON process.

As it is we have a bit of a mishmash of different sources and configs. Am I correct in my assumption that our DCs are not syncing in the traditional Domain Hierarchy fashion? And if so is there a GP or command that can force them to return to this state?

3 Answers3

3

Part of the problem with a DC in virtual is it wants to get it's time from PDC, but the "virtual drivers" are set by default to sync time with host. This will cause a tug-of-war if the host and PDC are not the same time. Most people will just disable the VM time-sync feature but this would cause an issue if the VM is ever saved vs. shutdown.

In Hyper-V world for the PDC: The following steps set the VM to use Host on boot, sleep/awake, and snapshot recovery but once OS is up, it will use the manualpeerlist for time sync. You should also have the host syncing time with the same sources so your host/guests are only 5-10 seconds apart max.

Open an Admin prompt and type the following commands:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

(answer yes to overwrite and disable this time source)

w32tm /config /syncfromflags:MANUAL /reliable:YES /manualpeerlist:"us.pool.ntp.org,0x1" /update

net stop w32time & net start w32time

w32tm /resync /force

(should complete successfully)

w32tm /query /source

(should show NTP server IP/name)

I pulled this together from TechEd and a great virtualization post at Microsoft after helping several clients overcome time issues with DC's/PDC being in virtual. http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx

jharrell
  • 183
  • 1
  • 8
Bret Fisher
  • 3,973
  • 2
  • 21
  • 25
  • thats very interesting. I think all our vms are set with sync to the host disabled under VMTools. Will your steps be similar in a VMWare ESXi environment or should I make that a separate question? –  Mar 19 '12 at 13:18
  • The VMWare tools will be a different time provider I suspect, so your reg key will be different in the first line, but the rest should be the same. Also, VMWare may have their own way of solving this problem so it wouldn't hurt to ask that question specifically for VMWare. – Bret Fisher Mar 19 '12 at 16:17
2

It does look like things are out of whack regarding the time source some of the non-PDC emulator DC's are using. I would suggest running the following on all DC's, with the exception of the PDC emulator:

w32tm /config /syncfromflags:domhier /update. Then restart w32time.

As far as syncing the PDC emulator to an external source, such as the firewall, my question would be is it neccessary? Time is relative. It's perfectly acceptable to have a "closed system", unless you need true, accurate time from an external source for auding, legal, etc. reasons. If you do, then you probably need to sync to something other than the firewall.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • @Tim_Alexander I recommend having your PDC emulator role sync with the NTP Pool (us.pool.ntp.org) because any "closed system" will drift until you get more user complaints because "all time is off x minutes". Users just expect their PC clock to be similar to their smartphones (which are centrally synced usually). – Bret Fisher Mar 13 '12 at 07:11
  • @Tim_Alexander if time config on a box seems screwed up, you can always "Restore Windows Time Service to Default Settings" http://technet.microsoft.com/en-us/library/cc738995(WS.10).aspx * net stop w32time * w32tm /unregister * w32tm /register * net start 232time – Bret Fisher Mar 13 '12 at 07:12
0

Ok, Doamins sync from the PDC EMULATOR ROLE - only.

And windows time sync is made to keep computers "close enough for kerberos to work" which is within a 5 minute delay fro the server.

Anything else is not what the time service is made for and requires a high resolution time server.

Yor employee was bad to even think it should be that close. It never was made for it.

TomTom
  • 51,649
  • 7
  • 54
  • 136
  • Still, if I saw two computers on a domain with time 60s difference (as user claims) I would find it unusual. FYI a domain member will sync it's time to a DC every 8 hours. A DC to the PDC every 2 minutes, so unless you got a bad clock on the mobo, I would consider 60s drift from PDC unusual. It looks as though Tim only has 2.4s drift, so he's good :) – Bret Fisher Mar 13 '12 at 07:08
  • BUt IIRC they ONLY syn when the difference is larger than X and I think X is like... 30 seconds or so ;) – TomTom Mar 13 '12 at 10:16
  • Hmph I didn't know of that limitation, and it's not been my experience. When I've tested time changes it *always* changed the local time even if just a second offset. @TomTom do you happen to have documentation on that? – Bret Fisher Mar 13 '12 at 15:05
  • No, and it is moer something i remember picking up somewhere. It MAY be wrong. – TomTom Mar 13 '12 at 15:13