W32TM keep pointing to CMOS clock instead of the NTP servers assigned in registry after service is restarted

Hello Folks,

I manage a very time sensitive environment of 2008 R2, 2012 R2, standalone (as in not domained) physical servers which need to sync to internal GPS provided NTP servers.  However I am running into an issue where the servers are not referencing the data for the NTP servers even though the details are located in the W32TM registry location.  

I have tied the Windows Time service to the Network service so the Time service does not stop using sc triggerinfo w32time start/networkon stop/networkoff

Changed the following reg values
AnnounceFlags to 5

w32tm /configure /syncfromflags:manual /manualpeerlist:ntp.internal.server.com,0x1 /update
w32tm /resync /rediscover

Before running "net stop w32time && net start w32time"
C:\Users\admin>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0319977s
Root Dispersion: 7.8016621s
ReferenceId: 0x0A3C810E (source IP:
Last Successful Sync Time: 8/11/2014 10:52:54 PM
Source: ntp.internal.server.com,0x1
Poll Interval: 10 (1024s)

After running "net stop w32time && net start w32time"
C:\Users\admin>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name:  "LOCL")
Last Successful Sync Time: 8/11/2014 10:34:58 PM
Source: Local CMOS Clock
Poll Interval: 10 (1024s)

I feel like I am missing something here but I am not seeing what it is... PLEASE HELP!!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I think that's an artifact of you using the /rediscover option with the /resync switch.
If your environment is really time sensitive (i.e. it requires high precision), then you're going to have to move away from using the W32time service.  One we use in our environment is NetTime.  http://www.timesynctool.com/

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Daz19Author Commented:
Thank you for responding footech,

I will review NetTime and give it a go to see how it works..

If you consider moving away from W32time (a good idea, because it's a crappy source of annoyance in NTP mode whenever I used it that way) you should try the real thing for NTP applications: A Windows port of the classic Unix NTP daemon.

A really mature thing (around for decades and still maintained), simple to install, easy to configure, works like a charm with the performance footprint of an ant and is stable as a rock.

See my article on NTP for details and don't hesitate to ask me if I left something unclear ..
Daz19Author Commented:
Thanks folks for giving me feedback on how to correct this.  I figured out the issue was a shaky DNS resolution of the NTP host names because of the restrictions on the the network associated on one of the NICs.  A persistent routing rule cleared up the sync issues for me.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.