Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

NTP and Windows 2003

Status
Not open for further replies.

acl03

MIS
Jun 13, 2005
1,077
US
I want to set my PDC emulator to point to an in-house NTP server (external public ones are not accessible due to firewall).

I have located this MS article, describing registry changes needed to set an authoritative time server:


A few questions...

1) Are these registry changes the correct/acceptable way to do this, or are there commands I can run from CMD to make the change?

2) Assuming my NTP server is not too far off from the current time on my PDC Emulator (meaning within a minute or two), will making this change during the work day cause any issues with authentication or otherwise?

3) Any other advice before I do this that I may not know about?


Thanks,
Andrew

[medal] Hard work often pays off over time, but procrastination pays off right now!
 
I have never been successful using Microsoft's time sync stuff. I have always used a third party app called AboutTime. I have all my servers check/update time to the server once an hour.

It shouldn't hurt to update a minute or two, then when your time sync runs hourly, it will stay typically within a few milliseconds of what your time server is.

 
we have to configure time sync for voice and screen recording. Both servers have to be within +/- 1 second for it to work. The registry method works fine. We set all our internal servers to sync from one server and that server to either sync from the DC or internal CMOS clock.

It's fairly simple once you get your head round it (took me ages to work it out though)

When I was born I was so suprised I didn't talk for 18 months
 
Andrew

Yes that KB works perfect,and the best way to find out is one, going to one of your ntp servers, make sure the DC Server name is first in line.

EX: atlas time.windows.com,0x1

This is under Parameters within W32Time Folder from that Regedit Setup for W32Time.

Once this is configured, set the time back 5 minutes on the server you are trying to sync up with the DC. After that, finally in cmd, type in the net stop w32time && net start w32time command. Once you leave the server and come back you will see that the time is synced.

What is bad would be if you continually have to use this command to keep it sync.

Just a thought
 
drummelhart said:
What is bad would be if you continually have to use this command to keep it sync.
That and the w32time errors in the event logs are what drove me to not use the Windows Time Service, and go with a third party app. Since doing so in the late 90's (NT4 days) I have never once ever had an issue with my server times staying in sync. Obviously YMMV.
 
After SP2 for 2003, I have not had any problems using the internal windows NTP service. There's just a few points you have to understand about Microsoft's view of time.

1) Windows sync hierachy:
A) PDC Emulator FSMO holder syncronizes from internet
B) DC's always sync time from PDC FSMO holder
C) Member servers and workstations sync from their "authenticating DC"

2) Microsoft allows time variation between each stratum of the hierarchy to be up to 20 seconds. The machine generally will not adjust its clock if it is within that limit. So you may see a difference of up to 40 seconds between a member server and the PDC FSMO holder in a single domain forest.

3) The PDC will not sync with a source that is not synchronized with its parent stratum, unless the source is a stratum 1 server. (I had a problem where my internal source was not sync'ing, causing Windows to stop sync'ing)

Keeping those points in mind, you should be fine.

I don't particularly condone directly editing the registry, when there are acceptable CLI commands that will help you check for errors when you are entering data. Examine the "w32tm" command. You will find it easier to use and generally more useful.

Code:
w32tm /config /manualpeerlist:10.10.10.10 /update
w32tm /resync /nowait /rediscover
net stop w32time
net start w32time

With the 4 commands above you should get a solid time sync with your source within about 60 seconds. Be sure to substitute 10.10.10.10 with the IP or host name of your source.

As long as the change is less than 5 minutes (kerberos time window) you should be fine to do this any time.

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers
 
PScottC said:
Microsoft allows time variation between each stratum of the hierarchy to be up to 20 seconds. The machine generally will not adjust its clock if it is within that limit. So you may see a difference of up to 40 seconds between a member server and the PDC FSMO holder in a single domain forest.
Still never been successful with it, believe me, I've spent dozens and dozens of hours trying to get it to work properly, including working with M$ tech support. I just don't like seeing all the errors in my event log saying that it couldn't find the authoritative time server or whatever the error was. My free third party solution works 100% of the time with no errors and keeps the clocks synced within a few hundred milliseconds, usually less than 100 milliseconds.
 
I've never had the issues you are reporting, except under the circumstances I listed above. There were definitely more issues with Windows 2000, which used SNTP instead of NTP. I've had more issues trying to sync with outside sources because of firewall issues, peer authentication requirements, change of IP, and peer changing to version 3.

My point, though, is that if you understand how MS deals with time, you can make an educated decision about which solution to use. (If you need scientific accuracy, then you need to plan appropriately.) Installing a 3rd party NTP server to any DC, let alone every server in your data center is a major decision. You need to justify the reasons for not using a feature that is already built into the product you are working with (especially if most organizations successfully use it).

PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers
 
Thanks for the help, guys. I'll give this a shot.

Thanks,
Andrew

[medal] Hard work often pays off over time, but procrastination pays off right now!
 
PScottC said:
You need to justify the reasons for not using a feature that is already built into the product you are working with
Easy justification for me, and not really a major decision at all. When I inherited this network a year ago, they complained to me about not getting the time sync to work right, I showed them my simple/elegant solution that had $0 cost. My boss thought I was a genius. I sure have him fooled :)

But I did really spend hours and hours trying to get the M$ time sync to work, including working with M$ tech support and after a couple of weeks, the amount of time I had spent on it would have paid for someone to hand code a new solution, not to mention that the one I prefer is free.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top