- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
As you probably already know, the Kerberos authentication protocol has limited tolerance for time skew between client and server. Specifically, the time difference between domain computers needs to be less than five minutes.
Some Windows administrators want to synchronize their Windows Server 2008 system clocks to an external atomic time source. How can we accomplish this goal? Well, read on!
The Windows Time Service: Basic operation ^
The Windows Time (W32Time) service exists in both Windows Server 2008 R2 as well as Windows 7, and is the “engine” that drives system time synchronization within an Active Directory domain.
By default, the domain controller that holds the PDC Emulator FSMO role is the authoritative time source for the domain. More broadly, the PDC Emulator in the forest root domain holds the authoritative time for the entire forest. Check out the following Visio diagram:
Default time sync behavior in Active Directory
In the above diagram, the forest root PDC Emulator (A) serves time for the entire forest. Other domain controllers within the domain (B) synchronize their time with the PDC Emulator. In turn, domain member servers (D) and domain workstations (E) synchronize their time with any available domain controller. PDC Emulators and domain controllers from other domains (C) synchronize their clocks with either forest root domain controllers or the forest root PDC Emulator.
NOTE: You can ascertain the domain controller that holds the PDC Emulator role by opening an administrative command prompt on any domain controller and issuing the command dsquery server –hasfsmo pdc.
All of the previously described behavior happens “out of the box,” with no special configuration required on the part of the Windows systems administrator. A bit of complexity comes in when we want our authoritative server to synchronize its system clock with an external time source. Let’s do that now.
Configuring the authoritative time server for the domain ^
Pointing our domain authoritative time server (the PDC Emulator role holder, recall) at an external time source requires some tinkering with the Windows Registry. To this end, you might want to create a Registry backup before proceeding with this work.
All of the following value changes are stored in the following Registry root path:
First, we must change the server type to NTP by modifying the Type value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type. Change the value data to NTP. This setting reflects use of the Network Time Protocol, an industry standard protocol for time synchronization and management.
Second, we need to set the proper NTP announce flag. Change the AnnounceFlags value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags to 5.
Third, we will enable NTPServer. To do this we must change the value data of the Enabled value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
TimeProviders\NtpServer to 1.
Fourth, we need to specify our external time sources. To do this, we modify the NtpServer value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.
This is where things get a little hairy. Windows expects a space-delimited list of DNS host names with the hexadecimal value 0x1 appended to each one (don’t even ask).
You can obtain a list of candidate atomic clock servers by visiting the NTP Pool Project Web site. The following screen shot shows my own value data:
Configuring external time sources
Fifth, we’ll set the NTP polling interval by modifying the SpecialPollInterval value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\
NtpClient\SpecialPollInterval. The recommended value here (reference from Microsoft) is 900 Decimal.
Sixth and finally, we need to configure time correction settings. Start by modifying the MaxPosPhaseCorrection value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
Config\MaxPosPhaseCorrection; set the value data to a “reasonable” decimal value such as 1800 or 3600 seconds.
You’ll also want to set the corresponding MaxPosPhaseCorrection value to the same value you used for positive time phase correction.
Quit the Registry Editor, open an administrative command prompt, and submit the following command in order to bounce the Windows Time service:
net stop w32time && net start w32time
Pointing domain devices to a time server ^
As I mentioned earlier, as long as your domain member servers and workstations are legitimate domain members and have the Windows Time service running, they will automatically synchronize their clocks with a domain controller.
You can always verify from where a particular Windows box is synchronizing its time by using the “Swiss Army Knife” w32tm command-line tool.
As you can see in the below screen shot, the statement w32tm /monitor gives you the core information at a glance:
Monitoring NTP in Windows 7
The screenshot also references UDP port 123; this is the well-known port that belongs to the Network Time Protocol. Please be sure to allow traffic on UDP 123 in your domain so that you do not inadvertently block NTP communications between your servers and client devices.
Finally, you should now (if you don’t already) that we can fully customize the NTP client behavior by using Group Policy. From the Group Policy Editor, navigate to \Computer Configuration\Administrative Templates\System\Windows Time Service\Time Providers.
As you can see in the following screenshot, you can edit the Configure Windows NTP Client policy to tweak (and enforce) any and all NTP client settings.
NTP client customization via Group Policy
Whew! We certainly covered a lot of ground in this tutorial. I wish that Microsoft made it easier to manage the Windows Time service, don’t you? Please feel free to leave your questions and observations in the comments portion of this post.