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.
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:
Domain naming master
RID pool manager
While you certainly can use the GUI to find and change which DCs hold which roles, it is significantly easier to use a command prompt or PowerShell using:
netdom query fsmo
Its possible to just get the name of the server running the PDC role by running via PowerShell:
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:
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:
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.
This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.
SIGN-UP FOR INSIGHTS
Join 14,000+ business executives and decision makers
Craig Schellenberg is a Senior Network Consultant at Sikich that works with businesses to improve their IT. Being detail oriented assists in his ability to design and deploy new solutions as well as troubleshoot complex issues. His primary areas of focus are virtualization and storage on premise (whether through VMware vSphere or Microsoft Hyper-V), Microsoft Cloud services such as Azure and Office 365, Microsoft SQL design and administration, backup/DR/Business Continuance, and network route/switch/firewalls.
Craig holds many certifications including his MCSE (Microsoft Certified Solutions Expert) in Productivity, Messaging, and Cloud Platform and Infrastructure. Craig also holds multiple certifications of his VCP (VMware Certified Professional) including version 3, 4 (Data Center Virtualization), 5 (Data Center Virtualization), 5 (Desktop), Cloud, and 6 (Data Center Virtualization).
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.