Overview of the Windows 2000 Windows Time
service Problems with Windows Time Problems with NET
TIME Windows Time Service (W32Time) and NET TIME
Overview of the Windows 2000 Windows Time
service Problems with Windows Time Problems with NET
TIMEThe Windows 2000 Windows Time (W32Time) service only works on Windows 2000 and XP machines. For a pure-Microsoft solution, customers can use a combination of batch files and logon scripts for WfWG and Win9x machines, and TimeServ or W32Time for NT4 for NT machines. (Do not confuse the W32Time for NT4 with the W32Time that ships with Windows 2000. The original W32Time for NT4 works like TimeServ. The new one for Windows 2000 has additional features.)
However, there are significant drawbacks to using a pure-Microsoft solution. First, the NET TIME command-line tool, required for WfWG, Win95, Win98, and ME, does not meet the requirements for a modern time solution. Second, while the new Windows Time service for Windows 2000/XP addresses some of NET TIME's problems, it has problems of its own (see below).
Domain Time II is much more robust and easier to manage than the native W32Time Time Service, and it is designed to replace it seamlessly. It also has special features to co-exist with the service when necessary. Read more.
Windows Time only attempts to keep the time on each machine synchronized within two seconds of its source. In practice, this yields a 2-4 second consistent variance among machines when everything is configured correctly and working perfectly. The two-second target is not configurable.
By default, SNTP is only used by the PDC (after you've enabled it). Other participating machines use the LAN Manager protocol (the same as NET TIME) to coordinate with the PDC. The maximum accuracy of the LAN Manager protocol is one tenth of a second, but it does not account for LAN/WAN latencies, and can be wildly off. You can set individual machines to use SNTP instead of LAN Manager, but then you lose automatic discovery of servers. When operating in SNTP mode, machines use the servers you specify from the command line on each machine.
By changing a registry setting, you can set Windows Time to function as an SNTP time source for interoperation with other programs. However, the time served is only accurate to the level of accuracy on that machine, which is targeted to two seconds, but often fails to achieve this.
The FSMO PDC can obtain its time via NTP/SNTP (RFC 1769) from a trusted source, such as the US Naval Observatory. But by default, it doesn't use a trusted source at all; it just assumes its own time is correct. You can set the source by using the NET TIME /SNTP:source command in a command window on the PDC.
The trusted source information is not propagated from the FSMO PDC to other Domain Controllers. If a BDC is promoted to PDC, it will begin using whatever trusted source was set on the BDC (by default, nothing).
Each machine, at boot time, nominates an "inbound time partner." For BDCs, this is the PDC. For member servers and workstations, this is the BDC that authenticated the machine onto the domain. This behavior is not configurable, and means that machines that aren't part of a Windows 2000 domain (all Win95/Win98 machines, NT machines in a workgroup, and NT machines in a domain without a PDC running Active Directory) cannot participate in domain-wide time synchronization. They must use the NET TIME command, usually in a logon batch file.
No attempt is made to cascade time changes throughout the domain. If the time changes on the PDC, each BDC will discover the change up to eight hours later. Member servers and workstations follow their own schedule when checking with their designated BDC, so the aggregate lapse between when the time changes on the PDC and when the new time is recognized at a workstation averages eight hours, and can be as large as 16 hours. This means that, at any given time, a pure Windows 2000 domain with each machine running Windows Time could have a system-wide variance of two to four seconds, but still be considered synchronized! In practice, with eight to sixteen hours between checks, the domain will probably have a variance in excess of several minutes. You can use our FREE LMCheck utility to test your system's performance without installing any additional software.
You cannot query the Windows Time service to determine if it is working properly, when the last time set occurred, who the inbound time partner was, or when the next time set is scheduled (although some of this information is usually available from the command-line on each machine using the w32tm program). You cannot determine the amount of adjustment applied, or the variance among machines. You cannot trigger a sync of the entire domain. The only way to trigger a sync for a specific machine is to use the w32tm command-line utility or manually stop and restart the Windows Time service. To know whether or not it worked, you must watch the clock display and see if it changes or examine the event log for errors.
This is also true of most other time products as well. The local system policies must specifically grant the named user time setting rights or the time sync will fail. Setting and maintaining these rights for Windows NT4/2K/XP/2003 workstations is very time-intensive for an administrator.
Some PC clocks (even ones right off the assembly-line) gain or lose several minutes a day. If a machine goes even a weekend without a logged-in user, it can have significant time errors.
Because NET TIME requires a fixed server name in order to use a local server other than the PDC, moving a user to a different office or even network segment can require a reconfiguration of their login or batch files to ensure they get their time from the correct server. Also, see the time zone issues above.
NET TIME uses Lan Manager protocols that do not take network delays and WANs into account. A workstation synchronizing to a remote server over a slow link can be off by several minutes or more.
On Windows NT4/2K/XP/2003, if the server that gets contacted is in a different time zone than the client, the server's time is displayed in the time zone of the client (in other words if I'm in Pacific Time on my NT machine, but I happen to authenticate with a server in the Eastern Time zone, the time on my local machine will be set to Pacific time). However, on Win 3.x,95 and 98 machines in the Pacific time zone syncing to an Eastern time zone server would have their time set to Eastern time.
If you are using the /domain option with NET TIME, any other servers running Domain Time Server can service a time request. However, if using a WAN and a local server becomes unavailable (or just slow) for some reason, machines using NET TIME can get their time changed to a different zone if a server in another time zone answers. NET TIME just doesn't know any better.
NET TIME is a one-server product (with the exception of Domain Time servers running on BDCs). If the server specified on the command-line (i.e. in a batch file) is unavailable, the time synchronization will fail.
When you run NET TIME without the /domain option, the workstation will iterate through the list of time sources on the network, and contact the first one encountered. By default on an NT or 2000 network, only the PDC is a time source. However, if Domain Time Server is installed on any machine, that machine also becomes a time source. Notice that the NET TIME client won't use the nearest time source -- it will use the first one found in the browser list. It also will not move on to the next source if the first one fails.
Regardless of which time source NET TIME uses, it can take an extended period of time for the NetRemoteTOD call to fail or succeed, and NET TIME does not account for network latencies. In addition, if the NET TIME client happens to be Win95 or Win98, and the time source's time zone settings do not match the client's, the client's time will be wrong.
The login script problems mentioned above are magnified dramatically if you're using a laptop or workstation remotely, since the workstation may or may not actually authenticate with an NT domain when dialing in (if you're using a PPP dial-in service, or over the Internet using a third-party VPN, for example).
Also, a workstation with a NET TIME command scheduled to run on a schedule (such as the NT AT command) can cause a system using Dial-Up networking to attempt to dial the remote network when it tries to run.
원본은 이곳에 있습니다.