ntpd and windows server 2003 sp1 w32time

Today is the day of lots of uneducated information on the internet while researching.

I’m trying to get ntpd to sync off a Windows Server 2003 SP1 box that has the PDC role. There’s a lot of information out there about how w32time between 2000 and 2003 are different, as well as possible 2003 SP1. Complaints from the open source people about how w32time is a crappy SNTP server instead of an NTP server, however a lot of it sounds like their education on the matter is out of date.

This bit here looks close. What follows is what I did, with an attempt made to make it clean looking.

rem pretend we’re reliable
w32tm /config /reliable:yes
rem someone said this being too high was a problem
w32tm /config /localclockdispersion:5
rem changes to ntp from nt5ds or whatever
w32tm /config /syncfromflags:manual
rem use an external server ( NEEDED! )
w32tm /config /manualpeerlist:pool.ntp.org
rem tells w32time to reread it’s config
w32tm /config /update
rem just for kicks
net stop w32time && net start w32time

It’s worth noting that this didn’t work until I synced ntp with something. Apparently w32time doesn’t fake its stratum in such a way that ntp believes. It’s working though. Tomorrow I’ll play more.

update: things seem good now. Wanted to through in this link which had good information about some of the registry keys associated with w32time. This tech article at Microsoft was [surprisingly] the best article I found regarding integrating ntpd + w32time. This blog post has much of the same information as mine and makes more sense in the aftermath. And this article is microsoft’s registry key reference.

7 thoughts on “ntpd and windows server 2003 sp1 w32time

  1. btm

    theres talk here on the ntp list about dispersion, but it appeared to not really matter. The values I got for a synced server from the rv command in ntpq for dispersion were higher than the ones coming from the rejected 2003 server from the same method.

    I did pull dispersion down to 5 using the command in the post on the PDC role carrying DC, but yeah. I’m not sure it matters.

    w32tm /config /reliable:yes
    w32tm /config /update

    on a a DC that did not have the PDC role was enough to make it it come up as a “candidate” instead of “reject” in the ntpq “associations” command. I double checked the registry and HKLM\System\CurrentControlSet\Services\W32Time\Parameters\Type was still set to NT5DS where as the other changes on the PDC switched this to NTP.

    Which is good, as I don’t want to make/manage a Microsoft Time Server system. I just want to get a couple boxes without access to the internet through the firewall to maintain the correct times.

  2. btm

    Right now the non-pdc is going “reject” again. Page 31 of this powerpoint slide has a little useful information about the flow of deciding candidacy. There may me more information hidden in there.

    the flash variable in ‘rv’ in ‘ntpq’ (showpeer in ntpdc brings a numeric equivalent) comes up “00 ok” on the sys.peer (PDC), and “800 peer_loop” on the reject (DC). I’ve checked the refid (‘peers’ in ‘ntpq’) as synch loop is supposed to be when two peers are syncing off each other. I may point this DC out at pool.ntp.org as well and see how that goes. This is getting messy.

  3. btm

    the likelihood of the non PDC DC of being rejected seems to be based on rootdispersion. the localrootdispersion flag has been set to 1, but I feel like this only matters if we’re using the local clock as a source (such as the way the PDC comes by default).

    I’m getting “400 peer_dist” in ‘ntpq’ ‘rv’ but I’m not sure it’s related even after chatting in #ntp on freenode about it for a bit.

    Rootdispersion seems to hang aroubnd 3000-7000, and when it comes down below 100 it’s alright. I’m currently assuming this is the cause of the peer (the DC) being rejected by ntp. I’ve run:

    w32tm /config /manualpeerlist:”0.us.pool.ntp.org 1.us.pool.ntp.org”

    On the box. I can’t find a better way to monitor ntp on server 2003 besides w32tm /monitor, which has no information compared to ntpq/ntpdc which has too much information that isn’t explained. I’m hoping it will act ntpish and sync with more servers, bringing down the rootdispersion, thus being more friendly. This is kind of moot as the PDC is working still, but I’m wary at this point that latency fluctuations will too regularly make both the DC and the PDC unusable time sources as far as ntp is concerned.

  4. btm

    So the first two vm guests went fine, but the next two on another host kept having really high jitter.

    I researched a bit more after seeing this:

    syslog.0:Nov 9 06:25:01 vmware04 kernel: rtc: lost some interrupts at 512Hz.

    Apparently timing on guest os’s is complicated and I shouldn’t be installing ntp. Oh well. I noticed the difference between the two host boxes was the lack of a 64bit kernel on the one not working correctly. I also noticed weird networking issues on it like double outbound packets, but I’m going to pretend that was a dream. There are bits out there on fixing this by hand, but the new amd64 kernel (linux-image-2.6.18-5-amd64) works whereas the other one (linux-image-2.6.18-4-686) didn’t.

    On the new host kernel, ntp on the guest os has reasonable jitter and seems to be working right. (i still see weird network stuff, still pretending it doesn’t exist).

    Later I’ll worry about not running ntp.

  5. Sam Liddicott

    Sounds like you might want msntp which is more for slaving clocks than tracking a reliable time source (which you possibly don’t have – I noticed you having to lie about it to get partial success).


    To slave my clock, I’ll be playing with a loop something like:

    while :
    # step-sync at bootup and before samba starts
    msntp -r –P no $DC
    # now run in adjtime mode forever
    msntp -a -x $DC
    # if msntp quits, we are either shutting down
    # or something horrid happened so step-sync and try again

  6. Chris Madden

    I learned that to allow other NTP servers to sync with a Windows w32time server that is NOT connected to an external time source you just need to reduce localclockdispersion to 0 and reload the config:

    w32tm /config /localclockdispersion:0
    w32tm /config /update

    The result is now your rootdispersion is basically 0 + actual from CMOS clock, or well below 1 sec. As such other NTP peers will sync OK instead of giving the rejecting with the “flash=400 peer_dist” error.

  7. Chris Lott

    Thank you Chris Madden! Using w32tm /config /localclockdispersion:0 (plus restart etc.) was the magic adjustment needed. We have a lab in a, ahem, room with no connectivity. The win 2008 server domain controller runs w32time, lies thru its teeth and claims stratus 1. Windows clients were syncing to it fine, but not ntpd on our many Centos6 machines. Before the adjustment, linux ntpd simply rejected that source with a flash code of 400, “peer_dist”. After the adjustment, ntpd accepted the DC time source and synchronized to it, but only after about 5 minutes of warm-up time using a 64s poll interval.

    I also found this very helpful in teaching me how to gather info about the ntpd current status on linux:


Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.