Windows 2000 Time(Windows 2000 时间)

Windows 2000 Time
 
  Robert McIntosh
Windows 2000 Ready
InstantDoc #20195
Web Exclusive 
Time plays an important role in Windows 2000. Compared with Windows NT 4.0, Win2K is more dependent on domain workstation time synchronization because workstation time is part of the Kerberos authentication ticket generation process. To prevent time synchronization problems, Microsoft included the Windows Time Synchronization service (W32Time) with Win2K. You might discover that the W32Time service is the source of many of the events that appear in the system log on the first domain controller (DC) you installed in your Active Directory (AD) forest. Let's look at how the W32Time service works to discover why most of these error messages appear.

When a Win2K Professional machine or a member server boots, it contacts a DC as part of its authentication process and compares its local time against the time on the DC, which is known as the target time. In most cases, if a difference exists between the local time on the client and the target time on the DC, the client system resets its local time to match the target time. However, when the local time is less than 2 minutes ahead of the target time on the authenticating DC, the system slows the local clock over a period of 20 minutes until local time converges with target time. After you boot the Win2K Pro machine or the member server, it checks back with the DC at intervals to verify that its time has remained synchronized. This interval is initially 8 hours, but it can increase to as often as 45 minutes if W32Time encounters a reoccurring time difference. In these situations, W32Time halves the interval until it resolves the problem.

To ensure that all the authenticating DCs remain synchronized, W32Time synchronizes the time of all the DCs in the domain with the DC that serves as the PDC emulator operations master. Operations masters are DCs that play specific roles that are so vital that one master must assume these roles—a departure from AD's multimaster model. Kerberos time synchronization is a good example of such a role. One PDC emulator exists in every domain in your forest, and it synchronizes with the other PDC emulators throughout the forest hierarchy, which in effect makes the PDC emulator the authoritative time source for your entire AD. The first Win2K DC that you installed in your forest is the DC that plays the role of PDC emulator for your root domain, assuming that you haven’t transferred or seized the role. As your AD's authoritative time server, that DC is the machine on which W32Time system log error messages will appear.

All your Win2K machines receive their system times from the PDC emulator, so you should configure it to synchronize with an outside time source. You can read about the process, which is called setting the authoritative time server, in Microsoft article Q216734. Setting an authoritative time server should eliminate the W32Time error messages in the system log. One word of caution: Make sure you set the authoritative time server correctly, or you might create more problems than you solve. If a machine that you have set as the authoritative time server isn't available, then time synchronization between DCs stops. Once the time difference between DCs becomes greater than what Kerberos allows, authentication between DCs fails, causing replication to fail along with it. Troubleshooting such failures can be difficult because W32Time doesn’t generate any error messages in the system log when specific hosts become unavailable. Instead, look for an error message such as "the RPC server is unavailable." If you see this message and you haven’t configured time synchronization with an outside time source, the likely cause is your DNS configuration.

Time Marches On
In Win2K, time also serves to resolve replication conflicts. For example, suppose an administrator changes an attribute such as a phone number on DC1. Before replication occurs, another administrator enters a different phone number for the same user object. Because these two changes would begin replicating throughout the domain with different information but the same update sequence number (USN), the change with the most recent timestamp would become the authoritative change. In other words, the last write wins.