How To Be A Time Lord

As you are hopefully already aware, Daylight Savings occurred yesterday. If all is going according to plan, you should not need to take any extra steps to change the time on your servers or your applications. (e.g. OnBase, which uses the system time on the server where it is hosted. As long as your server updates with the correct time, OnBase will reflect it.) But, what if the server doesn’t have the correct time?

Windows should update the clock automatically for these types of time changes. If it sticks for some reason, a reboot will generally fix it. There is a more insidious problem, however, and that is time drift. Software clocks are good, but they aren’t perfect. Over time, they will drift away from the atomic clock by a second here and another one there. This can make tracking security issues and general troubleshooting a real headache as different servers begin to march to their own times. If left to their own devices in an Active Directory environment for long enough, it will eventually result in an inability to log into servers and applications using AD authentication.

Fortunately, you can prevent this from happening without sitting around micromanaging your server clocks. In short, pick an authoritative time source (or two, in case the first one is unavailable) either by setting up an internal one or using a public source, then point all of your network devices at it. (You can configure a Group Policy Object in AD to make this even easier for your servers and workstations.) The Network Time Protocol service on each device that is used to grab the time from the authoritative source checks in at regular intervals. That way, even if your servers and whatnot drift away from atomic time because your source has drifted, they all drift together and therefore stay in sync with each other, which is the most important part.