To keep pace with competitors, businesses must keep employees productive, and that means providing them with the latest technology. This document provides the tips and tricks you need to help you migrate an outdated PC fleet to new desktops, laptops, and tablets.
Course Of The Month
11 days, 14 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
How to diagnose time issues in a large 2003 domain?
Posted on 2012-12-26
Hello,
We have a large (5500+) mixed OS (mostly Win7, a few WinXP) environment, with 6 Server 2003 DCs, running at a 2003 Functional Level. These DC's are housed in four separate locations, all 'direct' connected to our home office via fiber.
We've noticed a time discrepancy in the past month or two with workstation time. Initial diagnosis showed us that there are varying times between the six domain controllers.
The DC setup seems consistent and correct (as far as I know it... I don't have much experience with Server 2003). DC2 has the PDC Emulator role, and is configured to use 0.north-america.pool.ntp.o
The odd thing is that even though we currently have a discrepancy of more than 3 minutes between DC1 and DC2, there are no (that I can find, anyway) NTP errors being reported on either server.
Can someone assist me in troubleshooting this?
Thank you.
Scott
We have a large (5500+) mixed OS (mostly Win7, a few WinXP) environment, with 6 Server 2003 DCs, running at a 2003 Functional Level. These DC's are housed in four separate locations, all 'direct' connected to our home office via fiber.
We've noticed a time discrepancy in the past month or two with workstation time. Initial diagnosis showed us that there are varying times between the six domain controllers.
The DC setup seems consistent and correct (as far as I know it... I don't have much experience with Server 2003). DC2 has the PDC Emulator role, and is configured to use 0.north-america.pool.ntp.o
The odd thing is that even though we currently have a discrepancy of more than 3 minutes between DC1 and DC2, there are no (that I can find, anyway) NTP errors being reported on either server.
Can someone assist me in troubleshooting this?
Thank you.
Scott
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
5
4
9 Comments
I would check the interval time is checked on your Main DC and setup a manual task on the other DC's to sync their time with the Main DC every hour or two. Then monitor them all a few times a day to see if they stay synced.
Hi TG-TIS,
Thanks for the response.
I'm not sure exactly how you meant I should 'check the interval time on my main DC', but we may have a handle the issue now.
I ran 'w32tm /monitor' and found all six DC's reporting in were showing that they were syncing with DC2 (our PDC Emulator), but 4 of the six were 195 seconds off. Also, the RefID in the results from the /monitor command referenced a forest root server, not the PDC Emulator.
I wasn't even aware that we had a forest root server (we have only one domain... it is a legacy server that was never removed from the network), but it was also set to pull it's time from an external time source.
To resolve, I left the FR server alone and configured the PDC Emulator's NtpServer registry setting to point to the FR server, rather than an external source.
I then went to each DC and verified (and in some cases reset) their NtpServer entry to the PDC Emulator, and their 'type' to NT5DS.
Afterward, I restarted the W32Time service on each, and then resync'd using w32tm /resync /rediscover.
So far, so good... each server is within 2 one-hundredths of the PDC. I'll check again tomorrow.
sm
Thanks for the response.
I'm not sure exactly how you meant I should 'check the interval time on my main DC', but we may have a handle the issue now.
I ran 'w32tm /monitor' and found all six DC's reporting in were showing that they were syncing with DC2 (our PDC Emulator), but 4 of the six were 195 seconds off. Also, the RefID in the results from the /monitor command referenced a forest root server, not the PDC Emulator.
I wasn't even aware that we had a forest root server (we have only one domain... it is a legacy server that was never removed from the network), but it was also set to pull it's time from an external time source.
To resolve, I left the FR server alone and configured the PDC Emulator's NtpServer registry setting to point to the FR server, rather than an external source.
I then went to each DC and verified (and in some cases reset) their NtpServer entry to the PDC Emulator, and their 'type' to NT5DS.
Afterward, I restarted the W32Time service on each, and then resync'd using w32tm /resync /rediscover.
So far, so good... each server is within 2 one-hundredths of the PDC. I'll check again tomorrow.
sm
Sorry for the late response...
The DC's are all keeping time correctly (3 weeks and counting)... however, some workstations in the domain are reporting being a few minutes off, even after multiple logoffs/reboots.
Any ideas how to troubleshoot this?
The DC's are all keeping time correctly (3 weeks and counting)... however, some workstations in the domain are reporting being a few minutes off, even after multiple logoffs/reboots.
Any ideas how to troubleshoot this?
I've seen this before on older servers. what I did was add a scheduled task to the PDC to resync time with it's internet time server twice a day at specific times line 6AM and 6PM.
Add a scheduled task to all the uther servers to resync with the DC and different times so they al don't request time updates together. if this does not resolve the problem, let me know.
Add a scheduled task to all the uther servers to resync with the DC and different times so they al don't request time updates together. if this does not resolve the problem, let me know.
Our problem isn't with the DCs at this point, but with some workstations in our environment.
I could potentially add w32tm /resync to the logon script for the workstations, if that's what you mean...
I could potentially add w32tm /resync to the logon script for the workstations, if that's what you mean...
Yes, that should wok fine. you might have some Pc's that are loosing time due to hardware or other issues. Adding a schedule task to resync should resolve the problem on those Pc's.
You can probably put this in a batch file and add it as a scheduled task on the workstions
w32tm /resync
w32tm /resync
Featured Post
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
by Batuhan Cetin
Within the dynamic life of an IT administrator, we hold many information in our minds like user names, passwords, IDs, phone numbers, incomes, service tags, bills and the order from our wives to buy milk when coming back to home.…
Setting up a Microsoft WSUS update system is free relatively speaking if you have hard disk space and processor capacity.
However, WSUS can be a blessing and a curse. For example, there is nothing worse than approving updates and they just have…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month11 days, 14 hours left to enroll
623 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.