Microsoft operating systems and server applications have become increasingly dependent on proper time synchronization. A skewed system clock can affect your ability to log on, can cause problems with mail flow in Exchange, and be the source of a great many difficult-to-locate problems. To compound matters, the default method of handling time synchronization within a Windows network isn’t exactly reliable or even predictable. If a Hyper-V host’s clock becomes out of sync, it usually affects all of its virtual machines, sometimes catastrophically. Fortunately, it doesn’t take a lot of work to get everything in sync.
Pick a Computer to Server as the Authoritative Internal Time Source
The first thing you want to do is decide what machine you want to serve as the authority on time within your domain. In most cases, I choose the domain controller that holds the PDC emulator role. According to Microsoft’s documentation, that’s supposed to be the highest authority on the matter anyway, although it doesn’t seem to work out that way in practice. The machine that you choose will be regularly consulting Internet sources, so if you’re in a high-security facility you might consider delegating this role to a different computer. You could have multiple machines serving as authoritative time sources, but more than one per site is generally unnecessary. You could also have one machine pull external time and have your PDC emulator use that as its source while still serving as the authoritative server for the rest of the computers in your domain.
Firewall Information
Time synchronization traffic travels on UDP port 123. Your authoritative server will need that port open inbound. All clients, including the server, will need it open outbound, at least to the authoritative host’s IP.
Configure the Authoritative Computer
You can use any computer or device that runs an NTP server. This post will only discuss how to set it up for a Windows Server computer. The steps are well-documented in Microsoft Knowledge Base entry 816042. Scroll down to the section titled “Configuring the Windows Time service to use an external time source”. There is a “Fix it for me” button, but I recommend that you go to the “Let me fix it myself” section and click on “Click here for directions about how to resolve this issue yourself”. This will show you exactly what you’re doing and where. Be advised that this involves registry editing which is always something to be done cautiously and even moreso when it is on your PDC emulator. In step 4c, when it asks for peers, I use the following:
0.pool.ntp.org,0x1 1.pool.ntp.org,0x1 2.pool.ntp.org,0x1 3.pool.ntp.org,0x1
Once you’ve done this, the changed computer will periodically “announce” that it is an authoritative time source. In reality, this “announcement” probably won’t be received by most of your domain computers.
Configure DHCP
If you’re using a Windows domain, I always recommend using Windows DHCP. Since you really only need a single source, it is easiest to set this as a server option, although you certainly could establish it on each individual scope as a scope option. Set options 004 and 042:
With DHCP entries, you can only use IP addresses. You can type the name of the server in and click “Resolve”, but it will always insert an IP address.
If you’re serving DHCP using a Cisco device, inside the configuration for the DHCP scope enter the following commands: “option 4 ip 192.168.25.5” and “option 42 ip 192.168.25.5“. Obviously, substitute your actual NTP server for the IPs in those commands. For other NTP servers, consult the manufacturer’s documentation.
Now, all DHCP devices will pick up the internal NTP server configuration at their next refresh. Unfortunately, a lot of Windows units won’t pay much attention to that, although most DHCP client devices will.
Configure Static Devices and Non-Windows Computers
Most devices, such as NAS and SAN equipment, have a place to enter NTP server information. For most Cisco IOS devices, enter “ntp server 192.168.25.5” at a config prompt. For non-Windows computers, consult the operating system’s documentation. In general, this type of equipment won’t be as concerned with the accuracy of its clock as Windows computers, so you may opt to skip this.
Determine How You Wish to Handle Virtualized Guests
All modern hypervisors have the ability to provide time synchronization to guest machines through that hypervisor’s integration tools. If enabled, guest machines will draw time from the physical host they are running on. In most cases, you’ll want to disable this feature for Windows Server guest machines that are serving as domain controllers. For all other guests, it’s a judgment call. I have personally not encountered problems using time synchronization, provided that the host’s clock was properly maintained, but other administrators have found it necessary to disable synchronization. However you choose to handle this, the important thing is to ensure that you are consistent.
For a Hyper-V guest, open its Settings dialog box and open the “Integration Services” tab. Clear or set the check box for Time Synchronization as desired. For other hypervisors, consult the manufacturer’s documentation.
For virtualized domain controllers, especially on Hyper-V Server 2012 R2 and later, you must disable the Time Synchronization service. While you will find references to partially disabling the service, it is no longer effective.
[optin-monster-shortcode id=”gaua0qrhzreh818c”]
Set Group Policy
To really convince your Windows computers to use your authoritative time server, you’ll want to use group policy. First, if your domain is not already configured to use specialized organizational units (OUs) for its computers, set them up now. You cannot link a group policy object to the default “Computers” OU. There is no “right way” to set these up, so devise a scheme that makes sense for your organization. There is no benefit to being overly complicated, so aim for simplicity. You can always reorganize and expand later if you determine that you weren’t complex enough. For this post, your general aim is to segregate computers that need to have a defined time server from those that don’t. For instance, if you have laptops that will primarily be used at sites not controlled by you, you might wish to not set any time servers for them at all, or you might wish to have them rely on the same Internet sources as your authoritative system. You may need to set up different time servers for different physical sites and ensure their local computers refer to the local source. If you’ve decided to let your virtual machines receive their time through synchronization, you definitely want to ensure they are not conflicting with group policy. Use the Active Directory Users and Computers tool to create these OUs. You can drag and drop computer accounts from one OU to another or you can right-click on them and select “Move”. Warning: Never move a domain controller from the “Domain Controllers” OU. This will cause all sorts of problems, and not all of them are easy to troubleshoot.
To set the policy, open the Group Policy Management tool (on a domain controller or on a computer running Remote Server Administration Tools). Expand your domain. Right-click on “Group Policy Objects” and click “New”. Give your new policy a name that indicates what it will do, such as “NTP Client: Main Site”. Click OK.
Right-click on your newly created GPO and click “Edit”. This will launch a new window with the group policy editor. Navigate to Computer Configuration->Policies->Administrative Templates->System->Windows Time Service->Time Providers. In the right pane, double-click “Enable Windows NTP Client”. Set it to “Enabled” and click OK. Next, double-click “Configure Windows NTP Client”. Configure the options similar to the following image (there is an error in the image: append ,0x1 to the NtpServer field so that it reads yourdc.yourdomain.tld,0x1):
After saving this GPO, close the policy editor. This will return you to the main group policy management console window. If your domain has a large number of policies, right-click on the new policy and navigate to GPO Status->User Configuration Settings Disabled. This will speed up policy processing a tiny bit. Now, right-click on an OU that you want to apply this policy to and click “Link an Existing GPO”. Highlight your new policy and click OK. Repeat for other OUs as necessary. Remember that a nested OU will inherit from its parent unless inheritance is blocked or unless a it has its own linked GPO with conflicting settings. These are general guidelines; a complete discussion of GPO inheritance and application rules is beyond the scope of this post.
Other Domain Controllers
In general, domain controllers behave better than most other Windows computers just by using the default settings. However, they can misbehave as well. If you’ve gone through the steps above to properly set your domain clients, it’s unlikely to be as problematic as it could be otherwise, since you’ve all but guaranteed that the other Windows computers in your domain will be working with an authoritative time server. Because of all that, you could just leave the other domain controllers alone. If you wish to ensure that they are correct, the best thing to do is use the local group policy edit. Go to Start and Run and enter “gpedit.msc” at the prompt and click OK. Then just use the same settings as you would have in the domain group policy editor. If the domain controller you want to operate on is running Server Core, you can perform this remotely if its firewall permits. Just run “mmc.exe” on a GUI computer, go to File->Add/Remove Snap-In, double-click “Group Policy Object Editor”, browse to the computer you want to work on, and once you’ve acknowledged all the dialogs you’ll be modifying the group policy on that computer.
Check Your Work
If the group policy change was made recently, your computer may not yet have received it. At an elevated command prompt, run “gpupdate”. At an elevated command prompt, enter “w32tm /query /source”. On the authoritative server, this should return one of the time servers you entered in the Peers registry key. For a domain computer, it should list the authoritative domain server you specified. For a Hyper-V virtual machine with time synchronization enabled, you should see: “VM IC Time Synchronization Provider”. If the setting is the local CMOS clock, your setting did not work.