How to get NTP working properly in windows

[Red Squirrel]

I've always found NTP in windows to be very flaky, and due to it's lack of logging it's very hard to troubleshoot.

How do I go about syncing all the computers of a domain to a certain PC?

I've tried to push a login script "net time /setsntp:[servername]" but it does not seem to work. Also there's no control over WHEN it syncs, seems it only does it when it wants, sometimes never.

So how do I get this working properly? Am I better off using a 3rd party client/server solution?

 

[dphantom]

In a domain, the PCs will sync up to the PDC Emulator by default. The PDC Emulator should be configured to an external time source.

http://support.microsoft.com/kb/816042

I've never had any issues with Windows NTP, ever. Going on 10 years with all size networks from a few servers and PCs to 6000+.

 

[MrChad]

Are your workstations clocks failing on a regular basis? What do you define as "flaky"?

 

[Red Squirrel]

I'd say about 90% of the time, the polling either fails, or does not happen at all, so the clocks start to fall behind or get ahead. I've seen this in multiple environments, not just ours. The NTP server rarely actually successfully connects to the remote ntp server (I tried time.microsoft.com, time.nist.gov etc) this will usually leave warnings in the event log. Here's an example:

Event Type:	Error
Event Source:	W32Time
Event Category:	None
Event ID:	29
Date:		2/2/2010
Time:		5:06:39 AM
User:		N/A
Computer:	TDHDC1
Description:
The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.  No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time. 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:	Warning
Event Source:	W32Time
Event Category:	None
Event ID:	47
Date:		2/2/2010
Time:		5:06:39 AM
User:		N/A
Computer:	TDHDC1
Description:
Time Provider NtpClient: No valid response has been received from  manually configured peer time.nist.gov after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer  with this DNS name.  

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I think the issue is, MS set the connect timeout WAY too low so it fails to connect if there's very slight network load.

 

[Nothinman]

I've never had any issues with Windows NTP, ever. Going on 10 years with all size networks from a few servers and PCs to 6000+.

This.

NTP is something that 99.999999% of the time "just works". And the only two things that I can think of that cause it to fail are network restrictions (i.e. you can't get to that host on UDP port 123) or funky hardware clock that loses time faster than NTP can adjust.

I think the issue is, MS set the connect timeout WAY too low so it fails to connect if there's very slight network load.

How high is the latency on your network?

NTP is UDP based so there's no connection to be made.

The NTP server rarely actually successfully connects to the remote ntp server (I tried time.microsoft.com, time.nist.gov etc)

AFAICT time.microsoft.com doesn't exist and time.nist.gov queries just fine here.

 

[Red Squirrel]

It may of been time.windows.com I forget. I use time.nist.gov at home on my linux server and it works 100% of the time but I've never seen the windows one work properly. Within the LAN it's hit or miss, usually it works, but as soon as I tell it to go out, it fails.

Really I wish NTP was TCP instead of UDP as I'd write my own client, but I know nothing about UDP programming. Suppose it's time to learn.

 

[Nothinman]

Within the LAN it's hit or miss, usually it works, but as soon as I tell it to go out, it fails.

Do you really think that everyone with a Windows domain has the same problem and is just keeping quiet about it? You most likely just have to fix your network latency issues and you'll be fine. If your clients have no latency issues getting to your DC then just fix it and they'll all fall in line.

Really I wish NTP was TCP instead of UDP as I'd write my own client, but I know nothing about UDP programming. Suppose it's time to learn.

No, you really don't want to do that. Writing your own NTP daemon isn't the answer. In fact, just like your MySQL client/header packaging fiasco, it's probably the most wrong answer available.

 

[Red Squirrel]

Do you really think that everyone with a Windows domain has the same problem and is just keeping quiet about it? You most likely just have to fix your network latency issues and you'll be fine. If your clients have no latency issues getting to your DC then just fix it and they'll all fall in line.

"Just fix it" is easier said then done. This is why I'm posting to get help on *HOW* to fix it. I've followed every single online tutorial I could find, but it simply does not work. The issue with the built in client is the lack of diagnostics. I don't even know when or if it even tries to connect. It would also be nice if there was a way to force it like I can with Linux (ntpdate).

 

[Nothinman]

First, is your DC a VM? Because they have their own time keeping issues. They shouldn't cause the timeout eventlog entries you posted but they would probably exacerbate any time keeping issues you do have.

 

[Red Squirrel]

Actually it's physical. It used to be in a VM but has since been moved.

 

[Fardringle]

This will only work when the computers are rebooted or logged out and back in, but you can put this line in the login script to force them to synchronize each time the computer is logged in to the network:

net time \\servername /set

Replace "servername" with the name of the computer that all others will synchronize with. It can be a domain controller or another PC on the network.

It's not ideal and doesn't fix the problem you are having with NTP failing to synchronize properly, but it will help keep the clocks synchronized until you are able to fix the problem permanently.

 

[Red Squirrel]

This will only work when the computers are rebooted or logged out and back in, but you can put this line in the login script to force them to synchronize each time the computer is logged in to the network:

net time \\servername /set

Replace "servername" with the name of the computer that all others will synchronize with. It can be a domain controller or another PC on the network.

It's not ideal and doesn't fix the problem you are having with NTP failing to synchronize properly, but it will help keep the clocks synchronized until you are able to fix the problem permanently.

Perfect that command is what I need, and it seems to work. Only issue is that there is a prompt. Is there a way to make it silent? Our script system allows to also executes scripts on refresh so I could set it to run at least once a day per pc.

 

[Nothinman]

Perfect that command is what I need, and it seems to work. Only issue is that there is a prompt. Is there a way to make it silent? Our script system allows to also executes scripts on refresh so I could set it to run at least once a day per pc.

That also is just a duct tape fix, if your clients are timing out trying to sync via NTP to your DC then you've got much bigger network issues at hand. On a local LAN, that should never happen unless a specific client or your DC is broken.

If it's just your DC that's having problems syncing to an external time source that's a separate issue.

 

[Red Squirrel]

There's no network issues, and even then, there should be a decent time out period. No other network apps are having trouble. Normally the timeout should be about 1-2 secs but seems windows NTP has an extremly low grace period before bailing out. When I type w32tm /resync /rediscover on the DC it works maybe half the time. Unless the network is totally down, there's no reason for such fragile timeout period.

C:\>w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

C:\>w32tm /resync /rediscover
Sending resync command to local computer...
The computer did not resync because no time data was available.

C:\>w32tm /resync /rediscover
Sending resync command to local computer...
The computer did not resync because no time data was available.

C:\>w32tm /resync /rediscover
Sending resync command to local computer...
The command completed successfully.

C:\>

At this point it's both the DC and clients having issues. The clients just outright fail no matter what. I did read that I have to put ,0x1 at the end of the ntp server when configuring so I tried that, and it seems to have semi fixed the DC (it never worked at all, now it's working sometimes) but overall this is not going very well.

 

[Nothinman]

There's no network issues, and even then, there should be a decent time out period. No other network apps are having trouble. Normally the timeout should be about 1-2 secs but seems windows NTP has an extremly low grace period before bailing out.

1-2s is insanely long for a local LAN. You should be seeing <1ms latency on anything local.

When I type w32tm /resync /rediscover on the DC it works maybe half the time. Unless the network is totally down, there's no reason for such fragile timeout period.

What are you trying to sync to on the DC? But regardless, missing a sync or two shouldn't hurt. You prodding it is probably just making it seem like the problem is worse than it is.

At this point it's both the DC and clients having issues. The clients just outright fail no matter what. I did read that I have to put ,0x1 at the end of the ntp server when configuring so I tried that, and it seems to have semi fixed the DC (it never worked at all, now it's working sometimes) but overall this is not going very well.

You shouldn't have even touched the NTP configuration on the clients, they're automatically configured to sync to the PDC Emulator when they join the domain.

 

[Red Squirrel]

I am getting 1ms< but I was just saying, seems the time out is so low that if it happens to hit a tad higher due to increased traffic. And I don't see how I would not need to configure it, I've never seen an environment that does it automaticly. It needs to know what NTP server to sync with. By default it uses time.windows.com but I don't want 500+ computers all going online.

 

[Nothinman]

I am getting 1ms< but I was just saying, seems the time out is so low that if it happens to hit a tad higher due to increased traffic. And I don't see how I would not need to configure it, I've never seen an environment that does it automaticly. It needs to know what NTP server to sync with. By default it uses time.windows.com but I don't want 500+ computers all going online.

All domain joined machines will sync with the PDC Emulator so you won't have 500+ machines going out to time.windows.com unless they're all in a workgroup.

Do you have a router, core switch, etc that you can sync your DC with? Then you can debug NTP on IOS which will probably be easier.

 

[Red Squirrel]

Getting some progress, I think.

On the client I need to put the type as NT5DS and not NTP when editing the registry in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W32Time\parameters\ and the w32time service needs to be off before making that change. It seems that my client clock is syncing now but need to keep testing further making sure it was not just a fluke.

If I can at least get the client part working I'll be happy. I can just occasionally go on the DC and reset the clock as needed if it goes out of sync. Eventually when I learn UDP network programming I'll end up making an app anyway so people don't have to go through this. It's odd that there does not seem to be any decent ntp software out there.

 

[MrChad]

If I can at least get the client part working I'll be happy. I can just occasionally go on the DC and reset the clock as needed if it goes out of sync. Eventually when I learn UDP network programming I'll end up making an app anyway so people don't have to go through this. It's odd that there does not seem to be any decent ntp software out there.

It might be fun as a proof-of-concept, but really there is no practical need for another NTP client app. Most (all) modern OSes have services/daemons that handle it automatically and work reliably. Your experience is definitely not the norm. I suspect that you started messing with options you didn't fully understand and ended up causing more problems than when you started.

 

[Nothinman]

Eventually when I learn UDP network programming I'll end up making an app anyway so people don't have to go through this. It's odd that there does not seem to be any decent ntp software out there.

It's your time to waste, but I'd really advise against going down that road.

All of the NTP software I've used is "decent" in that it "just works". I have no idea how you managed to mangle your network.

 

[dphantom]

Getting some progress, I think.

On the client I need to put the type as NT5DS and not NTP when editing the registry in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W32Time\parameters\ and the w32time service needs to be off before making that change. It seems that my client clock is syncing now but need to keep testing further making sure it was not just a fluke.

If I can at least get the client part working I'll be happy. I can just occasionally go on the DC and reset the clock as needed if it goes out of sync. Eventually when I learn UDP network programming I'll end up making an app anyway so people don't have to go through this. It's odd that there does not seem to be any decent ntp software out there.

Why are you making this so hard? NTP works perfectly in any environment I have ever been in including some pretty messed up networks. How you hosed your setup would be an interesting case study. What you are doing should not ever be necessary.

In ANY Windows domain environemnt, clients automatically sync with the DC. Period. The DC maintains time with itself unless you point it to an external time source which I provided a link on how that is done.

And that is all there is to it.

 

[Red Squirrel]

Why are you making this so hard? NTP works perfectly in any environment I have ever been in including some pretty messed up networks. How you hosed your setup would be an interesting case study. What you are doing should not ever be necessary.

In ANY Windows domain environemnt, clients automatically sync with the DC. Period. The DC maintains time with itself unless you point it to an external time source which I provided a link on how that is done.

And that is all there is to it.

Well when the domain was initially setup, it was never configured that way, hence why I had to do it. It just never became an issue then eventually got brought up because all the PCs had different times. I had it working at some point but when our main DC crapped out we had to move all the PCs to use the other DC and just changing the server value did not seem to work.

But now it seems my reg change worked. I'll push it out to more PCs tomorrow and see.

 

[stash]

Well when the domain was initially setup, it was never configured that way, hence why I had to do it.

I would suggest you read about how Windows Time works, rather than making random changes that you don't know anything about.

An AD domain doesn't need to be configured to sync time. It does it automatically. The only thing you need to do is configure the root domain PDCe to sync with an external source. But even this is not required, and if you don't do this, all domain members will still sync their time to the PDCe.

I'm guessing the reason why the registry value got changed from NT5DS to NTP is because of your changes. NT5DS is the default setting for a machine joined to a domain. Using a script with net time would probably set this to NTP. Net time isn't even the right tool to use. All time configurations should be done with w32tm, and again, the only machine in a domain you even possibly need to use w32tm on is the PDCe.

Since it sounds like you modified all of your clients to NTP instead of NT5DS I would suggest using Group Policy to change it back to NT5DS, rather than a script.

 

[bob4432]

just out of curiosity, how far off do the computers get time wise from each other and what would be considered normal? or is your situation very dependent on time?

 

[stash]

By the way, the command on the DC you need to run is w32tm /config /manualpeerlist:time.nist.gov /syncfromflags:manual /update