Time synchronization on a Windows network?
October 27, 2008 9:53 AM Subscribe
What's the correct way to set things on a Windows server (SBS 2003) and our client computers so the time is synchronized properly?
We are having an issue in our office with the time on our computers drifting out of sync. We have a server running Windows SBS 2003 and all the clients are using XP (although not necessarily all on the same SP).
As talented-amateur-IT-guy-without-real-training, what I'm hoping to get is a canonical answer about the correct way to set the server to synchronize its time with some centralized authority, and the canonical way to have client computers synchronize with the server (upon logging in?). I've read a million technotes and blog posts and newsgroup entries about various ways to tweak and perfect this, but I don't know the basic way to start this from scratch.
My first attempt at getting this right was to check these registry keys on the server (in the section on "Configuring the Windows Time service to use an external time source").
I took a look at the server logs and it appears the server DID synchronize its clock one time after I changed those settings. That was four days ago, though, and there haven't been any other notes in the logs about w32time since then, so I have no idea if this working correctly.
That's all I've done so far, really. I didn't want to make any more changes until I really understood what the Best Practices were in this area.
In terms of synchronizing client computers, I did try one thing...on my own client machine I tried the command "net time /domain:DOMAINNAME" and got a response showing the server time (which is four minutes ahead of my computer), but my local clock was not updated.
I should note in closing that we don't care about issues of "perfect accuracy" (based on my reading so far I see that OMG MILLISECONDS are a concern for many people, but we just want things matching within tolerances to keep authentication & SQL Server happy, and to get us to meetings within a minute of one another) and I don't want this to be something that requires going from computer to computer making changes or installing software; there must be a way to have this all handled upon login, right? Any advice? Thanks folks!
We are having an issue in our office with the time on our computers drifting out of sync. We have a server running Windows SBS 2003 and all the clients are using XP (although not necessarily all on the same SP).
As talented-amateur-IT-guy-without-real-training, what I'm hoping to get is a canonical answer about the correct way to set the server to synchronize its time with some centralized authority, and the canonical way to have client computers synchronize with the server (upon logging in?). I've read a million technotes and blog posts and newsgroup entries about various ways to tweak and perfect this, but I don't know the basic way to start this from scratch.
My first attempt at getting this right was to check these registry keys on the server (in the section on "Configuring the Windows Time service to use an external time source").
I took a look at the server logs and it appears the server DID synchronize its clock one time after I changed those settings. That was four days ago, though, and there haven't been any other notes in the logs about w32time since then, so I have no idea if this working correctly.
That's all I've done so far, really. I didn't want to make any more changes until I really understood what the Best Practices were in this area.
In terms of synchronizing client computers, I did try one thing...on my own client machine I tried the command "net time /domain:DOMAINNAME" and got a response showing the server time (which is four minutes ahead of my computer), but my local clock was not updated.
I should note in closing that we don't care about issues of "perfect accuracy" (based on my reading so far I see that OMG MILLISECONDS are a concern for many people, but we just want things matching within tolerances to keep authentication & SQL Server happy, and to get us to meetings within a minute of one another) and I don't want this to be something that requires going from computer to computer making changes or installing software; there must be a way to have this all handled upon login, right? Any advice? Thanks folks!
Best answer: To be clear, that's just to get your clients to sync to your DC. To get the DC to sync with an external time server, you can do this.
posted by tracert at 10:41 AM on October 27, 2008
posted by tracert at 10:41 AM on October 27, 2008
Best answer: SBS: net time /setsntp:[hostname of a nearby time server]
XP: net time /setsntp:[IP of SBS]
Run `net help time` at a command prompt for more.
posted by rhizome at 10:46 AM on October 27, 2008
XP: net time /setsntp:[IP of SBS]
Run `net help time` at a command prompt for more.
posted by rhizome at 10:46 AM on October 27, 2008
Response by poster: Thanks tracert. I don't think this is related to a DST issue with a service pack or anything like that; the whole system just appears to be misconfigured and all of the time synch stuff isn't set up.
Our client computers are all members of the same domain and all the clients are on SP2 so I expect that now that I have the right command for the batch file I should be able to get everybody synching to the server at login. The pages I had found about the net time command didn't mention the set and yes flags at all, grumble grumble.
I ran w32tm /config /manualpeerlist:ipaddress /syncfromflags:MANUAL and it worked; how do I know that it's going to continue to check in with that IP periodically to keep itself at the right time? I thought that's what I was doing when I set the registry keys up last week but it only checked with the NTP server once.
[BTW, the bigger issue that I still don't understand is why one article from Microsoft would direct me to hand edit some registry keys, while another would direct me to run a command line argument, and neither one really explains what it is said changes will actually do. But maybe I should just get used to that.]
Thanks for the help so far. Assuming the server will continue to check that its clock is correct, I think this problem is licked.
p.s. to Rhizome: what's the benefit of doing this the way you listed vs. the way tracert did? I went with the first answer because it was first but I will change my settings if your way is better.
posted by bcwinters at 12:04 PM on October 27, 2008
Our client computers are all members of the same domain and all the clients are on SP2 so I expect that now that I have the right command for the batch file I should be able to get everybody synching to the server at login. The pages I had found about the net time command didn't mention the set and yes flags at all, grumble grumble.
I ran w32tm /config /manualpeerlist:ipaddress /syncfromflags:MANUAL and it worked; how do I know that it's going to continue to check in with that IP periodically to keep itself at the right time? I thought that's what I was doing when I set the registry keys up last week but it only checked with the NTP server once.
[BTW, the bigger issue that I still don't understand is why one article from Microsoft would direct me to hand edit some registry keys, while another would direct me to run a command line argument, and neither one really explains what it is said changes will actually do. But maybe I should just get used to that.]
Thanks for the help so far. Assuming the server will continue to check that its clock is correct, I think this problem is licked.
p.s. to Rhizome: what's the benefit of doing this the way you listed vs. the way tracert did? I went with the first answer because it was first but I will change my settings if your way is better.
posted by bcwinters at 12:04 PM on October 27, 2008
The benefit is that once you setsntp you don't have to run a timeset at every login, XP will do it on its own automatically. Net time /set is just a one-time thing so it has to be repeated either manually or via batch, but timeclients have been automated in XP for years now.
posted by rhizome at 12:33 PM on October 27, 2008
posted by rhizome at 12:33 PM on October 27, 2008
Response by poster: Ah, got it! What's the best way to issue the setsntp command one time to all the client computers? (And who wants to come be our IT guy for free?)
posted by bcwinters at 12:38 PM on October 27, 2008
posted by bcwinters at 12:38 PM on October 27, 2008
Best answer: In terms of synchronizing your clients with your server, it should be done automatically as long as the server is your PDC emulator. As newb IT guy in the office, I was having the exact same problem as you - I'd manually change the time on the PDC and run a "net time" command, but it wouldn't change immediately. What I found was that the time would sync eventually, though, whether after a reboot or just over a period time.
I'll be trying some of the advice above so that I don't have to reset the PDC manually anymore.
posted by cimbrog at 12:41 PM on October 27, 2008
I'll be trying some of the advice above so that I don't have to reset the PDC manually anymore.
posted by cimbrog at 12:41 PM on October 27, 2008
cimbrog is correct if the XP machines are members of the SBS domain, but you'll still have to set a server for SBS itself. more info
posted by rhizome at 12:45 PM on October 27, 2008
posted by rhizome at 12:45 PM on October 27, 2008
Just followed rhizome's advice - our PDC server now matches my cell phone, fwiw, and my desktop (on the domain) followed shortly thereafter. Go for it, bcwinters.
It wasn't my question, but thanks!
posted by cimbrog at 12:55 PM on October 27, 2008
It wasn't my question, but thanks!
posted by cimbrog at 12:55 PM on October 27, 2008
Best answer: rhizome, I had just kind of assumed that all my domain workstations were getting their time from the DC, but I just checked a few of them with
So I added
The thing is, though, I just checked the system event log on one of those workstations for messages from w32time, and I see informational messages that they've been synchronizing their time with curricserver.curric.local since well before I made this change. So it looks like the explicity
While we're here: have you any idea what the ,0x1 thing on the end of time.windows.com,0x1 actually achieves?
bcwinters, as a newbie W2k3 sysadmin, you'd be well advised to look into the things that you can do with Group Policy. One nifty thing you can do with it is run startup scripts, as opposed to logon scripts. Startup scripts run before logon, using the credentials of the workstation's local SYSTEM account, which allows you to use them for stuff like silent software installs that your users may not have the privileges to do if you try to run them in logon scripts.
posted by flabdablet at 7:24 PM on October 27, 2008
net time /querysntp and that reported time.windows.com,0x1 instead.So I added
net time /setsntp:curricserver.curric.local to my startup script, in addition to the net time \\curricserver /set /yes that's been in the logon script since we ran Windows 98 here, and now net time /querysntp shows curricserver.curric.local as expected.The thing is, though, I just checked the system event log on one of those workstations for messages from w32time, and I see informational messages that they've been synchronizing their time with curricserver.curric.local since well before I made this change. So it looks like the explicity
net time /setsntp:ip.of.dc isn't necessary for domain workstations.While we're here: have you any idea what the ,0x1 thing on the end of time.windows.com,0x1 actually achieves?
net time /querysntp on my DC reports ntp.vicceo.schools.net.au (which is the only NTP server accessible from inside our little walled garden) without a trailing ,0x1 and everything appears to be working.bcwinters, as a newbie W2k3 sysadmin, you'd be well advised to look into the things that you can do with Group Policy. One nifty thing you can do with it is run startup scripts, as opposed to logon scripts. Startup scripts run before logon, using the credentials of the workstation's local SYSTEM account, which allows you to use them for stuff like silent software installs that your users may not have the privileges to do if you try to run them in logon scripts.
posted by flabdablet at 7:24 PM on October 27, 2008
Response by poster: Thanks everybody; I marked a couple of answers best because I learned a ton from each of you. And hey, maybe everyone will show up for staff lunch on time today!
posted by bcwinters at 6:39 AM on October 28, 2008
posted by bcwinters at 6:39 AM on October 28, 2008
So it looks like the explicity net time /setsntp:ip.of.dc isn't necessary for domain workstations.
Correct. If the machine is a member of a domain it will sync with the PDC automatically. You can still setsntp to whatever you want and querysntp will correctly report what you set, but it will be ignored in a domain context. The DC sync takes precedence over your `net time` settings.
0x1 denotes a DNS name, presumably distinct from NetBIOS names or something.
posted by rhizome at 12:32 PM on October 29, 2008
Correct. If the machine is a member of a domain it will sync with the PDC automatically. You can still setsntp to whatever you want and querysntp will correctly report what you set, but it will be ignored in a domain context. The DC sync takes precedence over your `net time` settings.
0x1 denotes a DNS name, presumably distinct from NetBIOS names or something.
posted by rhizome at 12:32 PM on October 29, 2008
This thread is closed to new comments.
Run as batch at login. But if your clients are all members of the same domain, they should be already doing this. This is a shot in the dark, but are the clients all patched to the same level? I remember having some trouble when daylight savings dates changed.
posted by tracert at 10:32 AM on October 27, 2008