I read with interest an article by Mary Jo Foley recently entitled, “Microsoft offers guidance on Windows Server Year 2000 time-rollback issue.” It seems that the time source at USNO.NAVY.MIL experienced a problem and rolled back the clocks on a number of servers to the year 2000 during the evening of November 19th. I wouldn’t have wanted to be one of the administrators who had to fix that problem, especially if there were time-sensitive processes running at the time. Can you imagine the effect on applications such as billing? Of course, the effects are devastating for time-sensitive server features such as Active Directory.
If your organization has a single server that relies on a single time source for synching purposes, it probably isn’t possible to detect this sort of problem immediately, unless you have a human being observing the synching process. Given that administrators love automation, having someone physically sync the server won’t happen in most cases. However, good advice in this case is not to sync to the time server every day—sync only on days when someone will be there to monitor the servers. At least the administrator can quickly react to errant updates of the sort mentioned in the article.
Larger installations with multiple servers could possibly set up multiple time servers and use an application to monitor them. When the servers are out of sync, the application can notify the administrator about the issue. It’s also possible to use the W32Tm utility to perform time monitoring or to compare the time settings of two systems using a strip chart.
Actually, it’s a bad idea to sync to the time server at times when an administrator isn’t available to monitor the system, such as during the middle of the night or a holiday. The best option is to sync the server immediately before the staff arrives in the morning or immediately after they leave at night, when an administrator is available to quickly fix the problem. My personal preference is to include the W32Tm utility in a batch file that runs when I start my system in the morning. This batch file syncs all of the systems on the network at a time when I’m specifically watching to see the results. Both Administering Windows Server 2008 Server Core and Windows Command-Line Administration Instant Reference provide information on how to use this utility to perform a wide variety of time-related tasks.
If you happened to be affected by this issue, make sure you read the Microsoft blog post entitled, “Fixing When Your Domain Traveled Back In Time, the Great System Time Rollback to the Year 2000.” Even if you have already fixed the problem, the information in the article is useful because it helps define the problem and provides some useful information for avoiding the problem in the future. The vast majority of servers affected by this problem have Windows 2003 installed without time jump protection enabled. I’d actually like to hear if someone has encountered something odd in this particular circumstance so that I get a better feel how this problem manifested itself in the real world.
How do you work through time-related issues in your organization? Have you ever encountered a problem of this sort with your system? Let me know your thoughts at [email protected].