Configure domain servers to look to PDC for time server

The servers should all sync time with the PDC emulator by default

Thank you, KCTS, for your reply. They are not syncing with our PDC. Do you know what would cause this? If it helps, I checked the following registry setting to see where each server was getting their time: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters and then the setting for NtpServer. They are all pointing to "time.windows.com,0x1".

The servers should sync to the PDC, but not if the Time Service settings have been changed as it would appear they have from the registry.

On each server, run the following commands to reset the Time Service settings and tell it to take its time from the domain hierachy (i.e. the PDC).

w32tm /config /syncfromflags:DOMHIER
net stop w32time && net start w32time
w32tm /resync /rediscover

-tigermatt

Thank you, tigermatt. before i run those commands, i should probably ask is this the best way to set up time service in a domain? i just assumed that one server should be in charge of that. if there is a better way, i would be open to suggestions.

Yes. The best way is to have the Time Service run on the PDC, which is the usual configuration. It then advertises to the domain that it is a time server, and they will automatically sync with it, except in the case where the configuration has been modified.

Of course, there is no need to actually have the PDC sync its time with an External Source - that is just an optional setting. Windows doesn't need the time to be accurate, the time could be completely and utterly wrong, but provided all the computers can sync it, you don't have issues.

-tigermatt

I just ran the commands on one of the servers and the time is the same. Will it take a few minutes to refresh itself or should it happen right away? BTW, I'm logged in remotely, does that matter?

It could possibly take a few minutes to sort itself out, or there could be some other issues elsewhere.

You can see how far off it is from the PDC by running (on one of the non-PDC servers) the command
w32tm /stripchart /samples:5 /dataonly /computer:PDCName.YourDomainName.Com

Let me know how far +/- the time is.

-tigermatt

This is what I got; still off an hour.
The current time is 10/27/2008 10:14:58 AM (local time).
10:14:58, +00.1590545s
10:15:00, +00.1544465s
10:15:02, +00.1498385s
10:15:04, +00.1452305s
10:15:06, +00.1562229s

and the ntpserver setting is still pointing to: time.windows.com, 0x1. I didn't get any errors when I ran the w32tm commands but maybe i didn't entered something incorrectly?

OK, so what should your time zone be? According to the stripchart, the time is completely synced with the PDC in terms of GMT (it is about 0.1 of a second too fast, which is expected), so it looks to me as if this is a time zone issue.

-tigermatt

Hmm... should be PST. But Mountain Time would actually put it one hour ahead instead of behind, right?

One other thought, we had a consultant help with the upgrade because it was a little complicated: went from SBS2003 SP2 to SBS2003 SP2 R2 to Server 2003 to Server 2008. How is the PDC determined? Is it the first server install in the domain or does it have to be promoted or something?

In Active Directory there are 5 roles which can only ever be held by one DC at any one time. The PDC Emulator is determined by the server which holds the PDC Emulator Operations (FSMO) role. You can determine the PDC by running netdom query fsmo on a DC, or following the first part of the transfer procedure: http://support.microsoft.com/kb/324801 (without actually pressing the 'Change' button!).

The data you posted above basically shows the number of seconds in which the time differs between the PDC and the server which you ran that command from. While you can never get it accurate, I don't think being 0.1 seconds out will make you late for anything?

So, the fact the time doesn't actually show up correctly is merely a time zone issue. Have you actually checked the Time Zone on the servers themselves? This is NOT synced from the PDC (time in GMT is the only data which is synced), so the GMT offset must be set manually on each server, and each workstation for that matter. It is usually not a problem because it is set during installation, but can sometimes come unstuck.

-tigermatt

the netdom command was not recognized but i was able to determine from the kb article that the pdc was as i thought. the time zone does show (GMT- 08:00) Pacific Time (US & Canada); Tijuana.

i thought maybe this issue was related to the dst changes. what if I manually deselect "automatically adjust clock for daylight savings changes". would i at least be able to change the change the time?

OK, it wouldn't surprise me if there was a DST update issue here, however I will say now that changing the time on the main Time/Date page is NOT something I would recommend. If you change the time +/- 5 - 15 minutes (depending on network configuration), you will end up locking yourself out of your server because too great a time difference between the server and the PDCe prevents Kerberos from issuing a certificate for that session.

You said the Time Zone should be Mountain Time, GMT-7? Or is it meant to be Pacific, GMT-8? Say the GMT time now is 19:00, what would you expect your time to be?

-tigermatt

It is meant to be Pacific. So, it it's 7p Mountain Time it would be 6p Pacific time where we're at.

would it help to apply the update from kb951072?: http://www.microsoft.com/downloads/details.aspx?FamilyId=40D82C50-2E93-45A1-AD4C-7F27AA0A0E25&displaylang=en.

Have you tried running Automatic Updates to check there aren't any DST Updates required?

Thought about it but hadn't because I assumed that when the OS's were installed that Automatic Updates was configured to notify automatically; so, when I logged in to the servers, and didn't see any notifications I didn't think there were any needed. I've just checked the server and noticed that Automatic Updates is turned off. Whoops. I will run the updates and see if any DST updates pop up.

Sorry, posted reply before I saw your reply. I'll need to run it when I can restart the server later tonight.

before i turn on to notify about updates, would there be any reason why the consultant would have left it turned off?

Sometimes when I am working on a client's server I will turn off Automatic Updates to save time and prevent from interruptions in my work, but there's no reason to leave it off after work is finished. Automatic Updates are a good thing and should be performed as often as possible, so I would suggest you turn it back on.

-Matt

thank you, matt. i ended up applying the dst update from intelliadmin.com. looks like it worked. thanks again for your help.

You're most welcome, Thanks :)

KB951072 is what you need to fix this - the issue you are seeing is that even though they sync up, Windows will show the adjusted time as being off.  UTC time will be correct, so there should be no real issue beyond things looking wrong.  After applying the patch, DST will be put back on the correct new schedule.  Note that on exchange servers, if it was not already patched then you may need to redo a few calendar items that were in place prior to the patch.

As far as autoupdates - whatever for clients, but for servers most people prefer to patch manually for many different reasons.  It gives you better control over when your servers reboot.  It gives you control over which patches are applied, reducing wasted space and overhead for unneeded patches.  It gives you the ability to test patches prior to applying.  It gives you a couple days to watch the news for problems others have had.  etc etc etc.

Thank you, Paranormastic, for your comments. Thanks, as well, for the heads-up on the Exchange server update; I will keep an eye out. Re: automatic updates: I always manually view, download, and install updates; but, since time goes by faster than I realize and with other projects, if I don't have the nofity setting on, I'll let it go too long. For that reason, I prefer to be notified when new updates are out.