Keeping Time in Windows 2000
The Windows Time Synchronization service ensures that all your machines stay—tick for tock—on the same clock.
- By Michael Chacon
- May 01, 2001
Does anybody really know what time it is? Does anyone really care? Well,
you do if your network authentication system depends upon a network-wide
concurrent time stamp. With Windows 2000, the default authentication protocol
is Kerberos—that cross-platform, triple-headed hound of security. One
of the components of that authentication method is the granting of tickets
that are time-stamped. This time stamping is partly used to verify the
legitimacy of the ticket. And these time-stamped tickets are your entry
into the resources of your network. For this reason alone, a time service
on a Win2K network is essential. I’m not going to go into the gory details
of Kerberos here, but—trust me—time is important. It’s also important
for many other applications and, if nothing else, it’s quite convenient
to know when a file was created or modified.
Get In Synch
Win2K uses the Windows Time Synchronization service to ensure that all
of the Win2K machines in the enterprise share a common time. This service
is run as W32Time by default on every Win2K machine. W32Time is an implementation
of Simple Network Time Protocol (SNTP), described in Informational RFC
SNTP is an adaptation of the Network Time Protocol (NTP) described in
Standard RFC 1305. NTP is used to provide a level of accuracy of 1 to
50 ms between connected computer clocks across the Internet, taking into
account latency, jitter and other internetwork anomalies. This is fine
for major backbones, but the same accuracy, complexity and overhead isn’t
required for simple LAN purposes. SNTP is quite sufficient. SNTP operates
in either a unicast or multicast mode. Unicast is preferable, since you
can specify the server from which you’re requesting service and ignore
attempts from unknown parties that could distort or misdirect your timeserver.
The multicast mode, which finds anonymously available timeservers, isn’t
a good idea.
The W32Time SNTP service needs to access an NTP server to use as its
authoritative time-setting source, and there are three connection methods.
One is via radio, accessed via a specialized piece of hardware that’s
essentially a radio that listens in at the MHz listed. You won’t find
this in most organizations. The U.S. Bureau of Standards broadcasts the
time at 5MHz, 10MHz, 15MHz, 20MHz, and 25MHz, which can be tuned into
with a special receiver. This is probably overkill for most facilities,
but available if microsecond accuracy is important to your network.
Using a modem to directly dial into an NTP server is another method.
This necessitates dialing repeatedly into an NTP server and brings potential
modem difficulties into play that are best avoided.
Both of these methods provide direct connections to the NTP server, eliminating
latency when setting the clock.
The third and easiest way to obtain time from an NTP server is to connect
through the Internet. There are many NTP servers that can be reached on
a regular basis. As with all Internet connections, there are latency issues,
so it’s best to pick a few NTP servers that are consistently available.
A simple way to determine reliable and available time service is to locate
candidate NTP servers, PING them periodically over a period of several
hours and days, and analyze the replies for the shortest consistent round-trip
Set Up the Service
After determining which NTP servers to use as the authoritative timeserver,
you can use that source to set the W32Time SNTP service with these commands:
NET TIME \\W2KSERVER.DOMAIN.COM //SETSNTP:
NET TIME \\W2KSERVER.DOMAIN.COM //SETSNTP:
As you can see, the NET TIME command can use either a DNS host name or
an IP address. The host name is somewhat self-documenting, but an IP address
removes any name-resolution problems when obtaining the time.
Cover your Bases
Regardless of your approach, you should enter several servers’ addresses
in the command line in case an NTP server fails to respond or is otherwise
unavailable. If one isn’t available, W32Time will query the next server
in the command line. For this reason, it’s also a good idea to list servers
in different physical locations in case of Internet brownouts or other
Another consideration is the rank of the NTP server you’re connecting
to as the authoritative server. This layered ranking of the NTP hierarchy
to which a server belongs is called a stratum. Stratum 1 is an NTP server
that’s directly synchronized with the Coordinated Universal Time (UTC)
through a radio, satellite or modem connection. UTC is an international
cooperative effort to pinpoint an agreed-upon world time. The United States
uses atomic clocks managed by the National Institute of Standards and
Technology (NIST) and the U.S. Naval Observatory to establish the time
and provide our contribution to the worldwide UTC effort. An NTP stratum
2 server obtains its time from an NTP stratum 1 server, a stratum 3 server
gets its time from a stratum 2 server, and so on. Thus, the higher along
the stratum food chain you obtain your time, the more accurate the time
on your network.
Set the Pecking Order
So now, which server on your Win2K network do you make authoritative?
You’re probably aware that the multimaster model of Active Directory is
still dependent upon several single master domain servers in the directory.
These are called Flexible Single Master Operations (FSMO) servers and
they perform various functions for maintaining AD and provide backward
compatibility with Windows NT.
Since W32Time synchronization uses the AD domain hierarchy to maintain
time synchronization, the PDC Emulator FSMO in the root domain of the
Win2K AD forest is the authoritative timeserver for the Win2K network.
This server should have the time from the NTP stratum 1 server using the
NET TIME command. Other domain controllers in other domains will synchronize
from this one, and any child domains of these DCs will get their time
from their parent DCs. As workstations are authenticated, they’ll obtain
their time from the authoritative DC . In this manner, all Win2K machines
will have a consistent time based upon the time obtained from the authoritative
When the Win2K workstation client boots SNTP, packets are exchanged with
the authenticating DC, and W32Time determines the correct time from its
authoritative server. If the client time is behind the server time, it’s
immediately changed to the correct time. However, if the client time is
ahead less than two minutes, the client clock is slowed down until the
time is synchronized.
After this initial synchronization, the client performs a time check
in eight hours. If the time is off by more that two seconds, the next
check is performed in four hours. If the time is off by more than two
seconds, it’s checked again in two hours. The minimum amount of time between
checks is 45 minutes, with a maximum of eight hours. These default checks
are also configurable for periods of a week, every three days or every
two days by editing the registry. This usually isn’t necessary, as the
defaults work fine in most instances.
The most important factor is to make sure the PDC Emulator FSMO in the
AD root domain is configured to get its time from an accurate, reliable
and authoritative NTP source.
The Windows Time Synchronization service isn’t the most complex service
in a Win2K environment, but a mistake here can have irritating and unnecessary
repercussions. Take a quick look at your timeserver and make sure the
pieces are in place.