This blog is a technical follow up to blog Microsoft Exchange On-Premise Coexistence Issues Related To Time.
In that blog I described a very specific scenario where a client was having issues in their Exchange environment due to time sync issues and addressed at a high level the way to resolve it. The purpose of this blog is to include the specific steps to check on your environment to see if time sync is set up correctly or not.
You can also see what peers (sources) it is set for by using the command:
w32tm /query /peers
In this instance, its source is “Free-running System Clock”. If it is in this state or “Local CMOS clock” and the machine exists as a virtual machine on VMware ESXi or Microsoft Hyper-V then it may be temporary. Check it again in a minute or two. When the virtual machine guest service restarts or when the machine boots, it may look at the virtualization host if the settings for that are enabled for time sync and it will report this. After giving it a few minutes check back again. If it still has the source as one of those two places you need to make sure either:
You’ve just changed the PDC’s peers to be 4 different reliable time sources. Confirm it took by running:
w32tm /query /peers
If your time was off previously it may take a few minutes for it to become synchronized again. You can watch the status by running:
w32tm /monitor
Now 4.8 seconds off from DC01 (which had the correct time). Also now 38 seconds off from DC04 (which had the original incorrect time).
Now only 0.1 seconds off from DC01 (which had the correct time). However, 43 seconds off from the other DC (which had the incorrect time).
I logged into the DC04 server to verify it had the correct time source using the command:
w32tm /query /status
And it did (DC03 which is the PDC role holder):
Similarly to how DC03 slowly corrected itself to its source’s time, DC04 did it by itself as well.
All other domain joined servers and workstations, or devices set to use the IP of the server running the PDC role would automatically change their time as well.
The obfuscated part on the left is the local time on the machine you are running the command from. The d: value is the internal delay and the o: value is the actual offset between local time and the target computer time. If you’re seeing differences in the 0.00* range for actual offset, you can be highly confident that you have the correct system time. Anything with less than a second offset is reasonably good as well.
Tell us what IT concerns are top of mind for your organization. Have specific need? The Sikich team is here to help.
Step 1 – Find which server is running the PDC role
In every Active Directory environment there exist 5 FSMO roles. FSMO stands for Flexible Single Master Operations and is also commonly referred to as the operations master roles. The purpose of these is to help prevent conflicts when there are multiple domain controllers in an environment. In a single domain controller environment, these roles still exist, but all exist on the single server. The roles are:- Schema master
- Domain naming master
- PDC
- RID pool manager
- Infrastructure master
Step 2 – Check the server’s source for time
Once you know which server is running the PDC role, connect to it and from an elevated Command Prompt or PowerShell run the following commands: To see the source of the systems time. w32tm /query /status
You can also see what peers (sources) it is set for by using the command:
w32tm /query /peers
In this instance, its source is “Free-running System Clock”. If it is in this state or “Local CMOS clock” and the machine exists as a virtual machine on VMware ESXi or Microsoft Hyper-V then it may be temporary. Check it again in a minute or two. When the virtual machine guest service restarts or when the machine boots, it may look at the virtualization host if the settings for that are enabled for time sync and it will report this. After giving it a few minutes check back again. If it still has the source as one of those two places you need to make sure either:
- The host it is running on is polling an external reliable time source
- Have this server set to poll an external time source.
Step 3 – Change the server’s source for time
My recommendation is to have your PDC poll an external time source. To make the change run from an elevated PowerShell:
w32tm /config /manualpeerlist:”0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org 3.us.pool.ntp.org” /syncfromflags:manual /reliable:YES /update
w32tm /config /update
restart-service w32time
You’ve just changed the PDC’s peers to be 4 different reliable time sources. Confirm it took by running:
w32tm /query /peers
If your time was off previously it may take a few minutes for it to become synchronized again. You can watch the status by running:
w32tm /monitor
Step 4 – Monitor environment to make sure it took
I worked this issue in an environment recently that has 3 domain controllers. One in Microsoft Azure with the correct time (DC01), the PDC (DC03) and another DC with incorrect time (DC04). When I made this change the PDC realized that it has the incorrect time it slowly changed it’s time to match its source as closely as it can. Originally DC03 (the PDC) was off by about 43 seconds. I took this screenshot after it had started to correct its time. The screenshot below shows it about 13.6 seconds off from DC01 (which had the correct time). It also shows that is it now 29 seconds off from the other DC that has the incorrect time.
Now 4.8 seconds off from DC01 (which had the correct time). Also now 38 seconds off from DC04 (which had the original incorrect time).
Now only 0.1 seconds off from DC01 (which had the correct time). However, 43 seconds off from the other DC (which had the incorrect time).
I logged into the DC04 server to verify it had the correct time source using the command:
w32tm /query /status
And it did (DC03 which is the PDC role holder):
Similarly to how DC03 slowly corrected itself to its source’s time, DC04 did it by itself as well.
All other domain joined servers and workstations, or devices set to use the IP of the server running the PDC role would automatically change their time as well.
Bonus Parameter with w32tm to Assist in Troubleshooting
Another useful flag to use on the w32tm command is /stripchart. It allows you to compare the time on the local system to a target system (either local or public). To compare the time on your machine to 0.us.pool.ntp.org you would type this from a Command Prompt or PowerShell window: w32tm /stripchart /computer:0.us.pool.ntp.org You would see something similar to this (depending on how closely your machine time is to being accurate):The obfuscated part on the left is the local time on the machine you are running the command from. The d: value is the internal delay and the o: value is the actual offset between local time and the target computer time. If you’re seeing differences in the 0.00* range for actual offset, you can be highly confident that you have the correct system time. Anything with less than a second offset is reasonably good as well.
Tell us what IT concerns are top of mind for your organization. Have specific need? The Sikich team is here to help. 
