How Windows servers update, or not update, their clocks is something that might not be readily understood by the average hosting customer, but it can be very important if your web applications are time-sensitive. In this article, I’m going to cover time on standalone (or single – couldn’t resist not using this title) Windows servers. A standalone server is one that is not a member of an Active Directory domain. I’ll cover time on domain servers in the another article.
Installed out of the box, every Windows server is set to update its time from time.windows.com, which is an NTP service maintained by Microsoft. But as the number of Windows servers on the Internet increases, this service has rapidly become overloaded. I’ve encountered countless errors in the System Event Log where the server was unable to contact time.windows.com. The key to good timekeeping on Windows, therefore, is to find another reliable time source (short of purchasing your own Stratum 2 time server).
Naturally, the Internet long ago solved this problem with the NTP Pool Project. It describes itself as “a big virtual cluster of timeservers providing reliable easy to use NTP service for millions of clients.” These are systems located around the world acting as highly accurate time servers that allow anonymous connections via the Network Time Protocol (NTP). The load is distributed across all the servers, so every time you connect, it will be to a different pool server. All of which is handled through the magic of DNS.
The host name used for the NTP Pool Project server allows you to use any of the servers located around the world, or to restrict youself to servers located in a particular country or in a particular region. Naturally, there are more servers located in some countries than others (United States, Germany, France, and United Kingdom are the top four, in that order), so in the US or UK, you can safely restrict yourself to your country. But in most other places, you’ll want to use the bigger regional pool or the entire world-wide pool. This is especially true for Africa (15 servers), South America (43 servers), and Oceania (89 servers). The country pools use the two-letter country code in the host name, and the regional pools use the region’s name in the host name. If you exclude the country or region in the host name, all the servers in the world-wide pool are available to you.
Setting a Windows server to use the NTP Pool Project servers (or any other NTP server, for that matter) is best done using the W32TM command. You can set the NTP server from the “Internet Time” tab of the Date and Time applet in the Control Panel, but the W32TM allows to set multiple time servers and configure other options. This command, which works with Windows Server 2003 and higher, will set the server to update time from the NTP Pool Project US servers (this command is one line and broken into two lines here for clarity):
w32tm /config "/manualpeerlist:0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org 3.us.pool.ntp.org" /syncfromflags:manual /update
Here is what the option mean:
/config – queries or updates the Windows Time Service configuration
/manualpeerlist – specifies the NTP servers to use. This is a space-delimited list of DNS and/or IP addresses and must be enclosed in quotes when more than one server is specified.
/syncfromflags – sets what sources should used. Choices are MANUAL (use the manual peer list), DOMHIER (use an Active Directory domain controller), ALL (use both sources), or NO (don’t sync from an NTP server). The DOMHIER option only makes sense on a server joined to a domain.
/update – commits the changes.
After you change the NTP server list, you have to restart the Windows Time service, either from the Services MMC or using the NET commands as shown below:
net stop w32time net start w32time
NOTE: On Windows Server 2008 and higher, the Windows Time service is not set to automatically run on standalone servers. You need to change the Startup Type in the service properties.
You can verify that your server is updating its time from the NTP Pool Project servers by looking for Time-Service events (Event ID 37) in the System Event Log.
Time on standalone Windows servers is not as critical as it is on domain member servers and workstations, as we will see in the next article. But having the correct time makes everything that uses a timestamp (and there are a lot of them) much easier to understand, especially when troubleshooting problems that only happen during a particular time.