Todd's Blog

Todd's Tips for System Adminstrators

Connect

Time Change Tonight – Setting the Time Source in Linux

posted on

Just a reminder to everyone (at least in North America) that time changes tonight. We fall back an hour and gain an hour of sleep.  Always check your systems tomorrow to ensure they changed correctly.

Last spring I made a post on on Windows Server 2008.  Nothing has changed, so no need to rehash it. Just remember, if you need to set a time source for your Windows Domain, run the commands on your Windows Server with the PDC emulator role.

If  you are using Linux, some versions have a command named ntupdate to update against a time server. This command also works in FreeBSD and probably other *nix environments.  The command line  to update against a server (in this case the NRC) is:  ntpdate time.nrc.ca. If you want it to update automatically, add the command as a cronjob. 

Finally, if you are using ntpd, change the servers by editing the /etc/ntp.conf file.  Add the line server time.nrc.ca to add the time server at the NRC.

Setting the Time Source for the Domain on Windows Server 2008

posted on

I upgraded my domain controllers to Windows Server 2008 and am now in the process of decommissioning the old servers. Since moving the FSMO roles over to the new server, the new server started warning me that the time source was not set on this machine. Okay, I know in Windows Server 2003 I had to make some registry settings, but surely to goodness Microsoft has since corrected this in Windows Server 2008.

I hit the Internet and did a search and found a good source on Microsoft Technet on this very topic.

http://technet2.microsoft.com/windowsserver2008/en/library/92a73b00-12b7-49d0-b6be-007e626f387d1033.mspx?mfr=true

If you transfer or seize the PDC emulator role to another server, you will need to repeat this on the machine you move the PDC Emulator role to. Here are the steps that I performed on the server holding the PDC emulator role.

  1. At the elevated command prompt enter the command: w32tm /stripchart /computer:time.nrc.ca /samples:3 /dataonly 
  2. Ensure that UDP traffic on Port 123 is allowed through the firewall. 
  3. At the elevated command prompt enter the command: w32tm /config /manualpeerlist:time.nrc.ca /syncfromflags:manual /reliable:yes /update

 

What this does is set my PDC emulator to use the Canadian National Research Council’s NTP server which is a stratum-2 server. For a list of public NTP servers you can use, the NTP Public Services Project has a good list of public NTP servers.

Shared Computer Toolkit and the Fall Time Change

posted on

I arrived to work last Monday, normal day to start. I got a call around 2:00 in the afternoon from one of the larger library branches that the computers were constantly rebooting every hour and that the time was off by a bit. When I got there I found the machines showing somewhere between 2:00 – 3:00am, October 29, 2006.

Here is some information on the computers:

  • The computers were set to reboot for administrative purposes at 3:00am. This is the only time disk protection is turned off.
  • The computers are not part of a domain.
  • The computers update their clocks with time.windows.com once a week.

Here is what I figured was happening. The time change happened at 2:00am, EDT which put the time back to 1:00am EST. This change wasn’t noted to the operating system as disk protection was on.  At 3:00am, the machines reboot for maintenance. The computer reboots and the operating system, thinks it hasn’t changed the clock back so it does so at 3:00am, changing the time to 2:00am. Here is what I don’t quite understand, the rollback doesn’t seem to get written to disk. The machine reboots and shows 2:00am, October 29, 2006 and the time only syncs once a week so that never got corrected. In an hour at 3:00am the whole process repeats itself.  Dave who I car pool with to Ottawa for the study group with, commented it was like the movie Groundhog’s Day.

When someone does log on to the computer which was Monday, the time could not sync if it tried because the computer was out by a day. The date has to be correct in order for a time sync to happen.

Here is what I had to do to fix the problem.

  • Reboot the computer and clear any changes to the disk.
  • Log in as the toolkit admin and change disk protection to save changes on reboot.
  • Adjust the clock so the correct time and date were shown. Change the tab to Internet time and I changed the server to time.nrc.ca (National Research Council’s time server.) and synchronized.
  • Rebooted the computer
  • Changes were saved to disk and machine booted back up
  • Logged in again as toolkit admin to confirm changes were done correctly.

I suppose I didn’t have to change the time server to time.nrc.ca but it seems to sync faster and I might as well make use of the resources my tax dollars fund.  If you want to use it too, use time.nrc.ca in the Internet time field and don’t follow the instructions on National Research Council website to call the phone number.

As it turns out all the computers I rolled out using the toolkit all had the problem except for computers in one branch because they turned the computers off for the weekend. Their clocks were only out by an hour and the time sync fixed the time when it happened next.

Well I should be free of this problem in the spring, the time will only flip forward, which should fix the rebooting every hour issue. Before then though, I will be looking at adding a time sync script to the admin reboot process which should fix this problem. I still haven’t had an opportunity to play with Version 2 of the shared computer toolkit, so it might be fixed there too.