Save to My DOJO
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:
Time Options in DHCP
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.
Hyper-V VM Time Synchronization
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.
New GPO
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):
GPO to set NTP Client settings
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.
Linking a GPO
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.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Eric Siron
48 thoughts on "Configuring Time Synchronization for all Computers in a Windows domain"
Hi Eric,
Fantastic job, been having a challenge for some time now with time sync on my domain and it has been like frustrating and your came at (just about) the right time.
I have set it up as per your article but i am sticking with my PDC as the authoritative time server for my domain.
Given that the PDC is a Virtual server, should i go ahead and disable it from syncing with its host machine?
Thanks to your feedback.
Regards
Hi Abiodun,
Thanks for your comments!
Yes, you should alwyays disable time synchronization for a virtualized domain controller whether it is the PDC emulator or not.
Hi Eric
Thanks for all the great articles, yours are always the easiest to understand.
After new server versions are released its difficult to determine which info still applies.
My only DC is physical, running 2008R2. I am adding a 2nd DC, virtualized, 2012R2.
In this case on the new DC should time synch from the host be turned off in Hyper-V settings?
Thanks
thanks
Hi Shane,
Thank you for the kind words!
I do not disable time sync on my domain controller VMs. What I do instead is partially disable it. See #6 on this blog post for instructions. This way, the domain controller can still receive from the proper authoritative time source, but if it is ever saved or paused for some reason, its clock won’t drift any farther than its host has drifted. With the limits set by the skew settings, if your clock goes too far astray it will never automatically resynchronize.I have received reports of some people having problems with this, but it’s worked for me every time I’ve tried.
MUCH later edit: this no longer works.
Very good article! Thx!
Erik, very informative article! However I would like to advise w32time alternative (for networks where time precision is required) is NTS server & client http://nts.softros.com We got 0-1ms precision at 1Gbps network around 3 Amsterdam sites
i have an Active Directory Domain, and as per MS all clients synchronize with the PDC that has the master roles, which i can verify by going to cmd and typing “w32tm /query /status” on the clients, now i want that this server synchorinizes with outside sources and i followed all the registry steps bit still when i run “w32tm /query /status” from the server i still get “ReferenceId: 0x4C4F434C (source name: “LOCL”)
Last Successful Sync Time: 27/01/2014 12:33:21 PM
Source: Local CMOS Clock” so it is still synchronizing with the local CMOS clock. Furthermore when i run “w32tm /resync /rediscover” from the server it returns “Sending resync command to local computer
The computer did not resync because no time data was available.” i would appreciate if you can provide any help regarding this issue.
Thank you in advance
I’m probably not much help. This happened to me once and I just kept poking at it and it eventually started working. I don’t really know that I did anything. Sorry.
I’m a tad stump by something a client has done in the domain. With group policy they have configured all of their clients to use NTP time source instead of the domain hierarchy. But what is odd is that the first ntp time source they use is the dns domain name for the domain. In essence a round robin dns result would be returned with all the dc’s listed and then the client has the computers looking the the dc’s for time as a pure NTP source.
My first thought is if you are going to do this then why not just use domain hierarchy to get time from the domain controllers?
My second thought is … did MS build the time service in a way that will even allow the domain controllers to respond to this request for time in this manner from the clients? In other words … are the dc’s really acting like real ntp servers?
Regarding the first thought, if you are just going to the dc’s for time anyway just let domhier be the method. I understand configuring clients for alternative methods especially if these are primarily machines that aren’t contacting the domain regularly. I understand giving a client two means of connecting for time … but if you are just going to have them go to the local dc’s for time what is the purpose of having that go to the dc’s in a fashion different than domhier?
Any perspective on any of that … of course that assumes I made it clear enough for you to understand.
Thanks
John
Hi John,
If absolutely everything requesting time synchronization is a Windows system that is a member of the domain, then there probably is no benefit to using anything but the domain hierarchy.
That changes when you have unauthenticated computer systems (non-Windows or non-domain-joined Windows), switches, printers, etc. Since you have to choose the mode that your internal time servers run in, it seems like NTP would be the preferred choice.
Of course, this position could change if it was published how exactly a Windows time server configured in NT5DS mode responds when a standard NTP client makes a request. The not-in-depth documentation that exists only says that NT5DS is intended for domain-joined clients. On the flip side, we know that NTP mode works for everyone and doesn’t impede Windows domain operations in any way.
Thanks for taking the time to reply … In my example I was indeed just dealing with domain joined machines. It just seemed odd to me to tell clients to go to an ntp time source and just point that to the very same dc’s you could have used with domhier.
When I first saw it, I began to have that smoke coming out of my head from trying to compute the logic. Kind of like the old tv shows or movies where they would ask the all knowing computer the simple question … Why?
Thanks again for your insight.
John
I can understand that.
In my unscientific experience, it seems that NT5DS doesn’t seem to be as reliable as NTP mode. I’ve run across a handful of computers that would drift off into another century in the default configuration, even though they were domain members and authenticated daily. NTP mode enforced through DHCP options and GPO set them to right. It could be that the individual who set up your client had similar experiences.
I am trying to figure out a way to create a custom time zone for our network. Our building operates on UTC-6:05 so that our clocks are set five minutes faster than the actual time. This has not been a problem until this week. Everyone knows to add five minutes to the time on their computers. But when we upgraded our time clocks this week they keep resetting their time to the actual time.
Use TZedit to create a custom time zone with any offset that you want. Every computer will need the generated registry changes and need to be set to use that time zone.
Do you know what? You have saved me a shed load of issues with this article. So many people complicate the hell out of this process. Thanks for making it so simple. Wish I found this article ages ago.
Thank you so much!
Great article, couple of comments. First off, every domain member in a domain is automatically configured to use the PDC FSMO holder as their time source. I don’t see why you need to complicate things by adding in GPO rules and such to force this. I can understand wanting to manually sync non domain members and such though. I typically will use the same external NTP source as I configure on my PDC role holder.
The only caveat to this, as you have pointed out, is to make the Hyper-V host use this PDC server, or the same external source, so they have the same time.
One very confusing thing in the MS article is it says to set the AnnouceFlags to value 5. Ok. But then immediately goes on to say if you use the SpecialPollInterval setting, which the article has you set later on, then don’t use type 5 but 0xA? Huh? So what am I supposed to use?
BTW – instead of registry settings I have been using the following commands on the DC with the PDC role. Any comment on these commands? Are they doing the same thing? Not good?
w32tm /config /manualpeerlist:0.ca.pool.ntp.org /syncfromflags:MANUAL
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover
Cheers!
Even though the default is for all domain members to use the PDC, enforcing it is still a good idea. For one thing, I’ve seen machines slip out of sync for no reason that I could ever discover (hence the “really convince” language). For another, time sync could be considered a security setting, so keeping it enforced is a good thing. Are you aware of any harm that results from enforcing it?
On the AnnounceFlags, the two different settings are in two different solutions. AnnounceFlag “A” is if the system is to use an internal hardware clock. “5” is if it is to use an external source. I use “5” since my PDC emulator is virtualized and relies on the ntp.org servers.
Have you checked your registry to see if the commands you’re entering aren’t actually updating those values? As long as they work for you, I see no reason to not use them.
we have disabled the time sync for the domain controllers in the environment and I wanted to know will there be a problem when we take snapshot for the VM’s when we restore??
Yes. But you should not be snapshotting a virtual domain controller anyway.
Hello, Eric,
First – thank you for the many great articles on the topic of virtualization and time sync as it relates to VM hosts and guests.
Two questions:
1) I just noticed for the first time the weekly Scheduled Task of “Time Synchronization” that appears to be default for Windows Server installs. It calls %windir%system32sc.exe start w32time task_started on a weekly basis. Any insight on what that does, and if it should remain enabled for DCs?
2) Your reply to Pradeep’s question in November about snapshotting virtual DCs. I thought Hyper-V guests are snapshot-aware with the VM gen ID (XML file) and therefore can handle a restore from snapshot (especially since Hyper-V 2012 and later).
Thanks again for your time and extremely useful articles!
Steve
1) I had not noticed that task, either. The command “%windir%system32sc.exe start w32time” is equivalent to “net start w32time”. All that does is start the time service. I’m not certain what the parameter “task_started” does. From a bit of tinkering, it seems that if the w32time service is not running and is set to Manual when the task is initiated, it is started, time is synced, and then the service is stopped again.
2) Hyper-V 2012 exposes the VM Generation ID to WMI within the guest. ADDS in Windows Server 2012 is capable of requesting it. In the abstract,this is a cooperative thing; you are depending on the host to provide it and on the guest to check for it. The stated purpose of VM Generation ID is to check for time drift, and in order to do that, the software performing the VM Generation ID must have a reference point from which to validate the current ID. (As a side note, perhaps this is why partial time sync doesn’t work anymore, maybe the Hyper-V time sync service relies on VM Generation ID instead.) If the VM is reverted to a checkpoint, there is no way for the VM to know what the VM Generation ID should be. Having not studied this much, I assume then, that ADDS is storing the VM Generation IDs somewhere in the directory. If that’s the case, you’re now relying on ADDS synchronization to have been up to date when the checkpoint was taken and for nothing to have gone sour in the interim. In fair weather, sure, I have no doubts that it will work. What I don’t understand is what goes on with anyone’s domain controller that makes a checkpoint desirable at all, much less worth any level of risk of directory corruption.
please I need help on how to add a particular settings to all the PC in my organization, there is this new settings that my company wants on all the pc on the company domain..
I need help on how I can set all the pc from just one pc..
I mean not going to all the computers to set them individually…
its urgent please I need to get it done ASAP..
thanks in anticipation
[email protected] is my mail
https://technet.microsoft.com/en-us/library/hh147307(v=ws.10).aspx
I’m setting up a Sharepoint 2013 farm on Server 2012r2 VMs and the recommendation is to disable Hyper-V Time Synchronization. Of course it doesn’t say exactly how to do it. Google has a log of good reasons not to do that. At this point I do not think any of those reasons apply to a Sharepoint farm. Before reading all of this I’d already looked at your “This does not work anymore” link and after checking through the Server 2012 registry decided that was not going to work. After disabling Hyper-V Time Synchronization on one of the farm servers and rebooting its time source is now PDC. Thanks for the article. Wish I’d hit it first. Though I learned a lot today.
Hi Eric,
Please can you assist, I’ve got 2 virtual domain controllers running on Server 2012 R2 64bit. The Hyper-V hosts are running Server 2008 R2 Standard. I’ve transferred all the FSMO roles to one of the virtual DC’s and I want to synchronize it with an external time source.
I followed your advise and removed the Time synchronization under Integration Services.
I then ran the following command below which completed successfully
w32tm /config /manualpeerlist:”tick.meraka.csir.co.za” /syncfromflags:manual /reliable:yes /update
I then ran w32tm /query /status and I’m getting Local CMOS Clock
C:UsersAdministrator.AVROY>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference – syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: “LOCL”)
Last Successful Sync Time: 2016-05-18 01:57:15 PM
Source: Local CMOS Clock
Poll Interval: 6 (64s)
I’m pinging the time source successfully
Pinging tick.meraka.csir.co.za [146.64.58.41] with 32 bytes of data:
Reply from 146.64.58.41: bytes=32 time=38ms TTL=48
Reply from 146.64.58.41: bytes=32 time=8ms TTL=48
Reply from 146.64.58.41: bytes=32 time=96ms TTL=48
Reply from 146.64.58.41: bytes=32 time=99ms TTL=48
Please advise if there is anything else I can try?
Regards,
Guy
Hi Guy,
Your problem is right here:
This has happened to me before, so I can confirm that your pain is real. In all honesty, I don’t know what’s going on. I started rebooting and resubmitting the same commands and whatnot and it finally worked. I cannot tell you what I did differently between the beginning and the end.
What I would suggest is verifying that all of the related registry entries are being changed. Go through the manual portion of the referenced Microsoft article rather than through w32tm switches. Your primary goal is to get it switched over from the Local CMOS Clock to your manual peer list as a source.
Oh, and don’t forget to restart the time service after making changes!
I had this same issue. I was getting Source as Local CMOS Clock. Rebooting didn’t resolve. What I did to resolve this issue was :
w32tm /resync /force
My Question is now, is how do I get all the other servers in my domain to point to my main DC for the clock source? OR will the domain take care of this on it’s own?
Thanks in Advance
Domain guests should automatically get their time from the domain.
w32tm /query /sourceSorry – a little off topic – but I have a weird issue.
I have a physical DC (holds all roles) and a virtual DC. The virtual DC replicates every 5 minutes to a server in another building for disaster recovery. The virtual DC uses an Internet time source.
If I perform a test failover of the virtual DC (using the Hyper-V Test Failover option), the clock is always exactly one hour slow. In Test Failover mode the virtual DC cannot see the PDC or the Internet.
I can fix the clock manually, but by that time NTFRS has thrown away the contents of SYSVOL – I think because it thinks time has moved backwards…
The clocks on the HyperV hosts are correct and the regions are set OK. I can’t seem to track down why the clock is always exactly one hour adrift.
Would you be to offer any insights, oh Hyper-V time guru?
Thanks!
I think I would challenge the architecture itself. Active Directory replication blows Hyper-V replication out of the water. You need a license for the source DC and for its replica. So, unless you used SA, you can’t use replica to save money. If you have SA, I don’t think that another license for a DC on the replica host is too much to ask. I’m also not entirely convinced that this isn’t a USN rollback waiting to happen. Furthermore, if you have an authentic failure and the replica host can’t access any DC at all, failover may not work. So, if it were me, I would stop replicating the DC. Replace the replica with an always-on domain controller. That would make your problem go away.
If you want to keep this setup, I would check time zones on every single system first to see if anything is out of order there.
After that, I would consider allowing the replica domain controller to synchronize time with its host. I realize that we just don’t do that for DCs, but restoring to replica is sort of a special case. You can always turn it off after it wakes up and gets the correct time.
Thank you for your suggestions. The DC is currently being replicated because it is also the main file server (I inherited that, but it is quite common in smaller solutions).
I think I will do as you recommend and have a non-replicated DC at each site and remove the DC function from the existing combined DC / fileserver. I will need to shift DNS and DHCP etc. but that is no trouble.
Thanks again – I appreciate your input.
Thanks regarding providing such awesome content.