Managing Time Settings for Domain Members

Time is important, and even more so in a Microsoft Windows network. Incorrect or misconfigured system clocks can wreak havoc on an end user’s experience. When clocks are skewed, Kerberos fails to work properly which can lead to logon and authentication failures; not to mention all the other places where accurate time is critical such as event logs and file time stamps. Sometimes, time related problems are subtle or easy to overlook.

On the other hand, I have to say that Windows 7 is probably one of the most time resilient versions of Windows ever. I remember way back when it was typical to frequently synchronize clients with the domain, usually in a logon script. Fortunately, those days seem to be long gone. In the course of researching this article, I tried many ways to “break” time on a Windows 7 desktop. Let me tell you, it is pretty darn hard. As long as the Windows 7 client can communicate with a domain controller, time stays in synch. Which I suppose is the first critical step here that goes beyond time issues: can the client communicate with a domain controller?

One test you can run is to open a command prompt and run NLTEST.EXE. Specifically, run the command to query the time server for the domain:

C:\> nltest /dsgetdc:Globomantics /timeserv

You should get something like Figure 1.

Figure 1 NLTEST

The result indicates that my Windows 7 client is getting its time from CHI-DC02. Or at least should be. This command doesn’t guarantee that CHI-DC02 is up or reachable. For that I can use a different NLTEST command.

C:\> nltest /server:chi-dc02 /query

As you can see in Figure 2, I can’t reach the domain controller which in the long run could be problematic.

Figure 2 NLTEST Query

Since we’re talking about the domain controller let’s look at its role in timekeeping. Typically, one domain controller, usually the one holding the PDC role, acts as the primary timekeeper for the domain. All clients and member workstations look to it for time synchronization. But where does the domain controller get its time from?

More than likely it is using the default NTP (Network Time Protocol) source of This value should be stored in the registry under HKLM:System\CurrentControlSet\services\W32Time\Parameters as NtpServer. You can query computers using PowerShell remoting:

PS C:\> invoke-command {get-itemproperty HKLM:System\CurrentControlSet\services\W32Time\Parameters | select ntpserver,Type} -comp chi-fp01,chi-win7-22

The result is in Figure 3.

Figure 3 PowerShell Query

Or using the REG.EXE command line tool.

C:\>reg query \hklm\System\CurrentControlSet\services\W32Time\Parameters /v ntpserver

In Figure 4 I’m querying a remote computer.

Figure 4 NTPServer Registry Query

Perhaps you run a small shop and using this default setting is perfectly fine. As long as everyone is using the same clock it shouldn’t make much difference. But, you may prefer to reference another time source. Perhaps you have an internal NTP server, maybe not even Windows based, that you want to use. Or maybe there is a university in town with a publicly available NTP server. What I would do is configure my time keeping domain controller, with this source and then make sure all domain members point to the domain controller.

On the domain controller you will want to make sure the Windows Time service is running and configured to start automatically. The best tool for configuring the time service is the W32TM.EXE command line utility.

From my Windows 7 desktop, logged on with domain admin credentials, I can configure my PDC to use the NTP server from Cornell University. Use the /reliable switch when configuring time sources on a domain controller.

C:\> w32tm /config /computer:chi-dc01 / /reliable:yes /update

Once this is in place I can use W32TM.EXE to monitor my domain.

C:\> w32tm /monitor /domain:Globomantics

Figure 5 has the results.

Figure 5 W32tm.exe Monitoring

Now, I could trust that all my clients and member servers will get the settings they need, or I can use the command line tool to update them using the /resync parameter.

C:\> w32tm /resync /computer:chi-fp01 /rediscover

Figure 6 W32TM Resync

However in my testing, I think you’ll be just fine in a domain environment. By default domain members will synch clocks with domain controllers so as long as your domain controllers are in synch and have an appropriate external source such as, you should be good to go.

Although, even if the time is correct you might still run into clients that are in the wrong time zone. Normally Windows is pretty smart about handling time zone offset but personally I am distracted if a computer has the wrong time zone information.

One way you can identify the time zone is with the W32TM.EXE command.

C:\> w32tm /tz

Figure 7 depicts the result.

Figure 7 W32TM TimeZone Information

Another option is to use the TZUTIL.EXE command line utility.

C:> tzutil /g
Pacific Standard Time

Unfortunately, both of these commands must be run locally. Luckily the same information is also available via WMI and the Win32_TimeZone class. Here’s a PowerShell approach:

PS C:\> get-wmiobject win32_timezone | Select Bias,Caption,*Name

This is handy because now I can easily check multiple computers with one command:

PS C:\> get-wmiobject win32_timezone -computer "CHI-DC01","CHI-DC02","CHI-FP01","CHI-WIN7-22" | Select Bias,Caption,*Name,@{Name="Computername";Expression={$_.__SERVER}}

When I run this in my domain, I can see I have a potential problem.

Figure 8 WMI TimeZone Query

I could also query the Win32_ComputerSystem class and retrieve the current time zone.

PS C:\> get-wmiobject win32_computersystem -computer "CHI-DC01","CHI-DC02","CHI-FP01","CHI-WIN7-22" | select Name,CurrentTimeZone

Figure 9 Win32_ComputerSystem CurrentTimeZone

Clearly, I need to change the setting on CHI-WIN7-22 to -300. But I have bad news. As much as I would like to use WMI and PowerShell, I can’t. For this particular class, WMI can’t make any changes. This brings us back to using TZUTIL.EXE.

The utility doesn’t have any parameters to connect to remote machines. I need to run it at the console.

C:\> tzutil /s "Eastern Standard Time"

This is incredibly easy although you will need admin privileges. If I wanted to do this for a number of computers remotely, I would need to take advantage of PowerShell remoting.

PS C:\> invoke-command {TZutil /s "Eastern Standard Time"} -comp $computers

The variable $computers is an array of computer names, or even a single computer name. Barring an error, you won’t get any result but this command will reset the time zone to Eastern Standard Time for all specified computers.

Another time related item you may wish to check is whether Daylight Savings Time is in effect or enabled. Once again we can query the WMI Win32_ComputerSystem class and check the properties DaylightInEffect and EnableDaylightSavingsTime.

PS C:\> get-wmiobject win32_computersystem -comp $computers | select Name,*Daylight*

Because “daylight” is in both property names I can take a shortcut and use a wildcard. Figure 10 has the result.

Figure 10 Show Daylight Savings Time

The last item on your checklist is probably the easiest and most obvious: what is the time? Of course when you are looking at a desktop, the time is usually right there. But what if you wanted to check a remote machine?

One way would be to use WMI again and query the Win32_OperatingSystem class. This class has a property called LocalDateTime.

Figure 11 WMI LocalDateTime

Unfortunately, the value will be something like 20111118165855.114000-300, which is hardly user friendly. Here’s a situation where PowerShell makes life much easier. All WMI objects in PowerShell include a method called ConvertToDateTime. Using a hashtable with Select-Object we can define a new property.

PS C:\> get-wmiobject win32_operatingsystem -computer chi-fp01 |
>> Select CSName,@{Name="LocalDateTime";
>> Expression={$_.ConvertToDateTime($_.LocalDateTime)}}

The expression uses the current object in the pipeline ($_) and invokes the ConvertToDateTime method, passing the current object’s LocalDateTime property as a value. You can name the custom property whatever you like. I decided to simply reuse the existing property name. But now it has a more user friendly format. Figure 12 illustrates the result.

Figure 12 Converted WMI LocalDateTime

It doesn’t take much more effort to query a group of computers and see if any system has an out of synch clock. As you can see in Figure 13 all the computers in my small sample look pretty good.

Figure 13 Computer Time Query

Because I’m using WMI, the remote computers don’t even have to be running PowerShell or have remoting enabled. Although, remoting offers an alternative approach using the Invoke-Command cmdlet.

PS C:\> invoke-command {Get-Date} -computer chi-dc01

Querying a group of computers could be handled a number of ways. Here’s one approach.

PS C:\> invoke-command {get-date} -comp $computers | select @{Name="Computername";Expression={$_.PSComputername}},Datetime

Figure 14 provides a sample of what you can expect.

Figure 14 Getting DateTime with Invoke-Command

Due to the overhead demands of PowerShell remoting, if you are querying a large number of computers expect to see a time differential between the first and last computer. But as long as the returned times are within a few minutes, you should be ok. Of course, if you run into connection errors with computers you know to be running that in itself could point to an authentication issue that might be time related.

Fortunately, save for possible hardware glitches, most current Windows client and server operating systems seem to do a decent job of keeping clocks in order. From my experience, the only tasks you should have to worry about are configuring the PDC role holder domain controller with a reliable external time source and keeping computers in the correct time zone. Now, if you are responsible for computers in a non-domain environment, then you will most likely need to use some of the tools and techniques I’ve covered. All you need is a little time.