共用方式為

NET TIME and w32time

  • 發行項

It seems there is a bit of ambiguity out there regarding the relationship between w32time and the NET TIME command. Well, here are the answers, straight from the horse's mouth.

Taking it from the top 

As all of you know (or at least should) know by now, w32time is the Windows Time Service, which is an independent service that runs on nearly all Windows computers from Windows 2000 onward. It is comprised of the time service (aka w32time) and the w32tm.exe user-mode application for management and troubleshooting. The service communicates on port 123 via UDP for time synchronization using the NTP protocol. Communication between w32tm.exe and the time service uses a custom RPC interface.

In contrast, NET TIME (or more appropriately, the net.exe application) is a user-mode tool for verifying the time on a remote computer using a totally separate mechanism. The net.exe application lives in the System32 directory and is a jack-of-all-trades tool for changing various configuration elements of the operating system. 

How the NET TIME command works 

The net.exe application has been around for a long time, perhaps even pre-Windows 2000. All of the functionality in the net.exe application revolves around the Net* functions exposed in the NetApi32.dll library. This includes a number of really powerful functions such as NetUserAdd, NetUserChangePassword, NetJoinDomain, and other such functions. Among the list of functions is the NetRemoteTOD function, which is exposed via NET TIME. This function can be called locally on a computer to get the time on a remote system using RPC. Now, you may be saying "Ryan, why would I use the NET TIME command when I can call 'w32tm.exe /stripchart' and get essentially the same information, but more accurately?" I'm glad you asked!

Let's take a moment and read a sentence from that last paragraph again. The NetRemoteTOD function can be called locally on a computer to get the time on a remote system using RPC. The important part is that this communication occurs using RPC, not NTP, which is why the NET TIME command is still useful today. Let's say that for some reason the time service wasn't running on a particular computer, perhaps because it had (gasp!) crashed or (double-gasp) was mis-configured and was not running. Well, if you need to check the time on that system, you are out of luck with w32tm.exe. Because w32tm.exe uses NTP to check the time on a remote system, the time service needs to be running on that remote system in order for the time check to work. By comparison, since the NetRemoteTOD facility uses RPC, the remote system only needs to have the RPC service running on a remote system in order to check the time. This is the power of NET TIME.

The NET TIME command is however not perfect. In a typical environment, domain controllers (which are the typical target of a NetRemoteTOD call) might not be accessible from every machine on the domain. On the other hand, UDP 123 which is used by the time service is rarely blocked.

How to use the NET TIME command

The net.exe application the following syntax:

 C:\>net
The syntax of this command is:

NET
    [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
      HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
      STATISTICS | STOP | TIME | USE | USER | VIEW ]

We are particularly interested in the 'TIME' argument, which has the following syntax (note that this is the output according to Windows7):

C:\>net help time
The syntax of this command is:

NET TIME

[\\computername | /DOMAIN[:domainname] | /RTSDOMAIN[:domainname]] [/SET]

NET TIME synchronizes the computer's clock with that of another computer
or domain, or displays the time for a computer or domain. When used without
options on a Windows Server domain, it displays the current
date and time at the computer designated as the time server for the domain.

\\computername  Is the name of the computer you want to check or
                synchronize with.

/DOMAIN[:domainname]  Specifies to synchronize the time from the Primary Domain
                      Controller of domainname.

/RTSDOMAIN[:domainname]  Specifies to synchronize with a Reliable Time Server
                         from domainname.

/SET            Synchronizes the computer's time with the time
                on the specified computer or domain.

The /QUERYSNTP and /SETSNTP options have been deprecated. Please use w32tm.exe
to configure the Windows Time Service.

NET HELP command | MORE displays Help one screen at a time.

As you can see, there are a number of options here, all of which deserve some explanation. By default, when you run the NET TIME command without any arguments, it will attempt to locate a domain controller (using DC Locator) and then use NetRemoteTOD to get the time on that DC.

The NET TIME command exposes three switches which can be used to control it's behavior. The /DOMAIN option can be used to specify the name of a domain in which to locate a domain controller to talk to by requesting a domain controller with the TIMESERV flag set in NetLogon.  The /RTSDOMAIN option works the same way, except that it requests a domain controller with the GTIMESERV flag set instead. The /SET command can be used to update the clock on the local computer to match the time stamp returned by the remote computer.

Finally, you can call the NET TIME command with the name of a machine on your network to force NET TIME to get the time of that machine, rather than locating a domain controller.

You may also notice that the /QUERYSNTP and /SETSNTP flags are also included with the NET TIME command. Prior to the days of w32tm.exe, these commands were used to configured the server that w32time would synchronize with. Since w32tm.exe handles this work now, the /QUERYSNTP and /SETSNTP arguments have been deprecated.

Putting it in practice

By calling the NET TIME command without any arguments, we will get the time according to a domain controller in the domain. The domain controller that is chosen is completely arbitrary - there is no guarantee that you will get a specific DC, only that it will have the TIMESERV flag set, saying that it is a time server for the domain.

C:\>net time
Current time at \\DC-01.mydomain.com is 8/7/2009 10:01:42 AM

If we use the /DOMAIN flag, we can specify the domain that we want to query:

C:\>net time /DOMAIN:mydomain.com
Current time at \\DC-01.mydomain.com is 8/7/2009 10:04:12 AM

Additionally, we can query the domain controller directly:

 C:\>net time \\DC-01.mydomain.com
Current time at \\DC-01.mydomain.com is 8/7/2009 10:06:01 AM

In fact, the machine that we query doesn't need to be a domain controller. I could just as easily query my local machine using the NetRemoteTOD facility:

C:\>net time \\localhost
Current time at \\localhost is 8/7/2009 10:12:11 AM

Note: Keep in mind that unless you explicitly specify the name of the machine you want to query, the NET TIME command will locate a time source using DC Locator. If the time service has failed for one reason or another, the TIMESERV flag will likely NOT be set for that machine. However, you can still query the machine explicitly and you will still be able to check the time on that machine.

Conclusion

As always, I try to anticipate any questions you might have regarding the content here. However, if you do have any questions or feel that I have missed something, please post a comment below. If you have a general question about the time service, I encourage you to ask it in the forums.

Comments

  • Anonymous
    August 12, 2009
    Very good, very informative post. Thanks! :)

  • Anonymous
    January 07, 2010
    Could you elaborate security aspects of using net time to get the time from a remote computer (two standalone computers - local system account does not seem to be sufficient).

  • Anonymous
    January 08, 2010
    I believe that the NET TIME command will only work in domain-based scenarios, so I don't think two standalone mahines will be able to use the NET TIME command.

  • Anonymous
    January 27, 2010
    That was great! just what I´m looking for. Thanks a lot! Best regards

  • Anonymous
    February 17, 2010
    This answers one of those questions that always floated around my brain but never really got answered so thanks very much! twitter.com/thommck

  • Anonymous
    February 22, 2010
    Thank you for that explanation, it was the most thorough I've come across.   I still have an issue that I'm trying to work out however.   I have several non-domain PCs running software that requires the times to be synchronized.   For the life of me I cannot figure out how to get them all to synchronize.   I get "Access Denied" when I try to net time to one of the other computers.  I'm even willing to have them all call an internet resource for the time, but I can't find one of those that will work either.   Thanks in advance...

  • Anonymous
    February 23, 2010
    Hi Ralph, If you post your question in the Windows Forums (http://social.technet.microsoft.com/Forums/en-US/winserverDS/threads), someone should be able to help. I will keep an eye on the forum for your question.

  • Anonymous
    March 18, 2010
    Great Info!  Easy to understand.  Thanks a ton.

  • Anonymous
    May 12, 2010
    How does this function when you have machines in different time zones? For example, let's say that the DC is in Eastern Time Zone and you have different offices that authenticate to the DC that are located in the Central and Mountain Time Zone. Will all machines be forced into using Eastern time?

  • Anonymous
    May 12, 2010
    All communication regarding timestamps uses Coordinated Universal Time (UTC), which is timezone-agnostic. This allows you to have computers in multiple timezones in time synchronization, even though the time (according to the clock in the system tray) is hours apart.

  • Anonymous
    December 18, 2013
    I have some applications that are extremly time critical. The article 'How Windows Time Service Works" (technet.microsoft.com/.../cc773013(v=ws.10).aspx) suggests that the WindowsTime service does not meet time-sensitive application needs. I have found some of the information contained within the following page useful for describing the configuration of the time service: www.timetoolsglobal.com/.../how-to-synchronize-microsoft-windows-to-a-ntp-server-1 However, I can't help but think that the best solution is to consider a windows port of the full-blown network time protocol application.

  • Anonymous
    April 03, 2014
    I've been using net.exe since the days of LANMAN under DOS, Windows for Workgroups 3.1 and OS/2, so your suggestion that it predates Windows 2000 is correct.

  • Anonymous
    July 14, 2016
    Nicely written, I send links to this article to colleagues quite often. Your statement about net.exe makes me smile, because it pre-dates not only Win 2000 but Win NT as well. I first used it on a Microsoft LAN Manager 2.0 domain with Microsoft OS/2 v1.3 servers and DOS and Windows 3.0 and 3.1 clients, back in '92. Net.exe was also part of Windows for Workgroups 3.11. I'm pretty sure net.exe and the most basic command options date back to the first version of 3Com 3+Share, which was the original name of the LAN Manager NOS.