Domain Controller Not Advertising As A Time Server? (dcdiag)

jemlay
Fixing timesync is different according to the machine type...

If it's a standard Domain Controller then behave as if its a member server (below)
If it's a PDCEmulator then make sure you allow port 123TCP/UDP outbound on your firewall and configure the external microsoft time service by entering this at the command line
NET TIME /SETSNTP:time.windows.com

If it's a mamber server or a standard Domain Controller:

Members of the Active Directory sync with their local DC (local as in local AD site). The DCs then sync with the PDCEmulator, so the PDCE is the root of all time - as it were!

Diagnosis of timesync errors is difficult, but do not be tempted to use NET TIME /SETSNTP: on all machines in the domain (as suggested to many questions like this one, unless it's a PDCE), as it specifically overrides the natural internal operation of the time service within Active Directory.

These commands are written for Windows 2003 and Windows XP. There are some equivalents for windows 2000, use W32tm /? or W32Time /? from the command line to look for alternatives on older OSs.

Use NET TIME /SETSNTP:
to clear any entry and return to the default settings

Use NET TIME /SET /YES
to synch NOW with your authenticating DC and begin the diagnosis:

Start by verifying your domain is synching AD by using REPLMON.EXE in the support tools pack on the Windows installation CD.


If this is OK then run this from the command line:
W32TM /monitor

to ensure that each member server/workstation is actually pointing to a DC.

If this is OK then run this from the command line:
W32TM /resync /rediscover

followed by:
W32TM /resync /nowait

and check the system eventlog for W32TIME errors. This process does a full reset and recheck of the time system as it relates to one member machine on your AD.

Post any errors here

Explaantion of why it doesn't alway instantly set the right time:
Timesync works as follows:

If the local clock time of the time client is behind the current time received from the time server, W32Time will change the local clock time immediately.
If the local clock time of the time client is more than three minutes ahead of the time on the time server, W32Time will change the local clock time immediately.
If the local clock time of the time client is less than three minutes ahead of the time on the server, W32Time will quarter or halve the clock frequency for long enough to bring the clocks into sync. If the client is less that 15 seconds ahead, it will halve the frequency; otherwise, it will quarter the frequency. The amount of time the clock spends running at an unusual frequency depends on the size of the offset that is being corrected.

W32Time will periodically check its local time with the current time by connecting to the time source. This process starts as soon as the service turns on during system start-up. W32Time attempts synchronization every 45 minutes until the clocks have successfully synchronized three times. When the clocks are correctly synchronized, W32Time then synchronizes at eight-hour intervals, unless there is a failure to obtain a timestamp, or a validation failure. If there is a failure, the process starts over from the beginning.

Set it by hand as close as you can and then simply leave it to sort itself out.


Cheers

JamesDS

My DC is Windows 2003.  My mail server is Windows 2000.  It's the 2000 machine I need the test to be completed on.

First I ran:
NET TIME /SETSNTP:
Then I ran:
NET TIME /SET /YES

I received this error:
Could not locate a time-server.
More help is available by typing NET HELPMSG 3912.

(I also tried a WinXP machine and got the same error)

I ran REPLMON.EXE before and could not find anything wrong with any of it's functions.  Was there something specific I should do with it?  I've never used it to any great lengths.

Note:  Currently all my machines sync with, "NET TIME \\APP1 /SET /YES", in thier login scripts.  APP1 runs a time sync program.

Thanks for the help JamesDS!

jemlay

ok, on the DC run this:

NET TIME /SETSNTP:APP1

on the 2000 box run this:

NET TIME /SETSNTP:NameOfDCHere
NET TIME /SET /YES

On any other machine having timesync problems run the same commands as for the 2000 box

On the XP machines after the above run this:

W32TM /resync /rediscover
W32TM /resync /nowait


Cheers

JamesDS

:(

I get the same error after running "NET TIME /SET /YES"

When I right right click the DC server in replication monitor and go to Properties then Server Flags there is an X next to the time service line.  The time service is running and I can stop and start it with no problems.

There seems to be something broken between the AD and the time service?

jemlay
right lets start again

If your time source is APP1 then on the DC run this:
NET TIME /SETSNTP:APP1
W32TM /resync /rediscover
W32TM /resync /nowait

If this doesn't work then APP1 is not a proper SNTP time server OR there is network problems between APP1 and the DC

does this give an error?

Cheers

JamesDS

C:\Documents and Settings\Administrator>NET TIME /SETSNTP:APP1
The command completed successfully.

C:\Documents and Settings\Administrator>W32TM /resync /rediscover
Sending resync command to local computer...
The computer did not resync because no time data was available.

I performed the same commands only with NET TIME /SETSNTP:different domain machine, which is a completly different domain on my network which does work correctly and I receieved the same error.

The machines are all on the same switch so there is no communication problems.  So what you are saying is my Domain Controller is not a proper SNTP time server?  Lets forget about APP1 and maybe even move the time function to FILE.

I never had a reason to check this time function so I dont know how long it's been broken.  However three months ago I had to perform disaster recovery on this domain controller.  I had to reinstall windows 2003.  Then I reinstalled AD with verbatim settings.  Then I restored the system state.

Aside from installing windows and setting up the AD via dcpromo I've never had to "setup a SNTP time servcie".  All my other domains run these commands you are giving me just fine.

jemlay
right then, this tells us that APP1 is not an SNTP timeserver

We need to stay with the DC is the time source as that's how AD is designed to work.

So, on the domain controller run this:
NET TIME /SETSNTP:time.windows.com
W32TM /resync /rediscover
W32TM /resync /nowait

What's the name of the DC?

Cheers

JamesDS

Machine name FILE runs maisto.com

I ran this from FILE:
C:\Documents and Settings\Administrator>NET TIME /SETSNTP:time.windows.com
The command completed successfully.

C:\Documents and Settings\Administrator>W32TM /resync /rediscover
Sending resync command to local computer...
The computer did not resync because no time data was available.

All ports are open outbound however just to be sure I removed my firewall and got the same error.

Side Note:  Also when I run "W32TM /resync /rediscover" from a domain that does work correctly I receieve the same error.  This is a domain where dcdiag passes everything and I've already upgraded the exchange server.

From FILE:

C:\>w32tm /monitor
file.maisto.com *** PDC *** [169.254.2.214]:
    ICMP: 0ms delay.
    NTP: error WSAECONNRESET - no server listening on NTP port

jemlay

time.windows.com resolves to 207.46.130.100 and is listening fine.

The 169 address looks like and APIPA address and suggests that your server FILE cannot see the internet.

Try "NSLOOKUP time.windows.com" and tell me what you get


Cheers

JamesDS

Yeah, that IP trips everyone up.  That IP address is Intels internal IP scheme.  FILE can see the internet just fine.  I can ping that address as well as:

C:\Documents and Settings\Administrator>nslookup time.windows.com
Server:  file.maisto.com
Address:  169.254.2.210

Name:    time.windows.com
Address:  207.46.130.100

jemlay
ok, starting with the DC
We need to make sure that it can see a time source and send/receive traffic on port 123tcp

Once we have sorted the DC (or actually any Domain Controller holding the PDCEmulator FSMO Role) we can fix the rest of the clients (workstations and member servers)

Can you confirm the after setting the time source (NET TIME /SETSNTP:time.windows.com) that the server can access 207.46.130.100 on port 123

You can use a port scanner to scan that IP and Port to check you have access.

Cheers

JamesDS

It is set and I can acces it.  Plus all reg settings look correct.

jemlay
OK, it should be getting the correct time now. If not then you have another problem with your DC

If it is then for all XP and windows 2003 machine that are members of the AD domain you should be able to run:
NET TIME /SETSNTP:
W32TM /resync /rediscover
W32TM /resync /nowait

To get the to sync

For machines NOT members of the domain

NET TIME \\FILE /SET /YES
will sync once and each time you need it

How are we doing so far?

Cheers

JamesDS

Same error after "W32TM /resync /rediscover"

Same error on dcdiag.  FILE is not advertising as a time server.

I dont have any time released errors in my event logs.  All my machine sync time correctly as I do point them to a different machine for time.  APP1.

My only problem is dcdiag fails.  Also I just found out about nltest:

C:\Documents and Settings\Administrator>nltest /dsgetdc:maisto /timeserv
DsGetDcName failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

This fails as well however all other switches complete just fine.  So again something very specific is wrong when it comes to my AD and TIME as you just mentioned.  Even FILE syncs with APP1.  So I guess that explains why my AD actualy works just fine.  However the tests fail because they are DC specific and my Exchange install fails because it wants time specificly from FILE I guess.

Starting from scratch will of course fix it.  However that is of course the last card to be played.

Ok, not sure whats going on here but:

I ghosted the machine and bounced it to like hardware and got it up and running so as to not distrupt my network.  I took the problem machine and started stripping it down.  Removing everything that wasn't essential for the AD to work.  At each step I ran dcdiag.  After one particular change dcdiag worked!

What it was, was the default poilicy, "Default Domain Controllers Policy".  When I remove this policy dcdiag passes.  When I apply this policy dcdiag fails.  To rule out the fact that maybe more then one thing could be wrong I put the ghost image back on the machine and just removed the policy.  It worked!  However I still dont know what is wrong as I NEVER made any changes to this policy.  I also searched through it and EVERYTHING is set to NOT CONFIGURED or NOT DEFINED.  This policy is not being used however when applied all time type tests fail.

But wait.  It gets even odder:

1. Remove "Default Domain Controllers Policy"
2. Create a different policy named, "Test Policy" and apply to FILE (no changes)
3. dcdiag passes
4. Remove "Test Policy"
5. Delete the GPO, "Default Domain Controllers Policy"
6. Create a NEW policy named, "Default Domain Controllers Policy" and apply to FILE (no changes)
7. dcdiag fails

What the heck?  My AD doesn't like GPO's named, "Default Domain Controllers Policy"???

Since I'm not using that policy I guess I dont need it and if I can name a policy whatever I want then I should be fine later on.

jemlay
I have never heard of this issue. You may have found a bug in service application, I can't think of anything else it could be!

If you want to get a refund on your points you can do so in community support.

Cheers

JamesDS

Nah, you helped out a lot and taught me a couple things in diagnosing time issues.

Thanks for all your help, input and time!

JamesDS
Welcome and thanks for the points

Cheers

JamesDS

Is the 2003 domain controller multi-homed (does it have more than one network card?).
If so, please make sure that the bindings in: Network Connections --> Advanced --> Advanced Settings --> Adapters and Bindings --> Connections:
Make sure that your local LAN adaptor is first in this list.

The machine has two NICs however one of them is disabled.

just make sure the enabled one is at the top of this list.

so does the dcdiag now pass all the tests?

See step 3 from 5/4:

3. dcdiag passes

Could you please confirm that you've:
1. Moved the "local area connection" that's enabled to the top of the list: Network Connections --> Advanced --> Advanced Settings --> Adapters and Bindings --> Connections:
2. Have your blank "default domain controllers" policy existing.
3. Rebooted
4. the "nltest /dsgetdc:YOURDOMAIN /timeserv" command returns an OK result? (replace YOURDOMAIN with the actual name of your domain)

The local area connection is already listed at the top.  No change is required.

nltest /dsgetdc:YOURDOMAIN /timeserv = Passes fine.

When I add the default domain controllers policy and reboot then:

nltest /dsgetdc:YOURDOMAIN /timeserv = FAILED

I have removed the policy again and without rebooting it passes.

Where are we going with this?

I had a "similar" problem and the solution I suggested resovled the issue.  I guess in your case you can simply remove the default domain controllers policy.  Maybe this will be fixed in Windows Server 2003 SP1.

Ah, cool. I'll file this away in case I ever come across it again.

Thanks

I've been waiting a long time to answer this problem. I experienced something very similar in my win2k3 AD forest with an empty root and two child domains. Basically, there are two distinct problems:

A. Could not synch PDC Emulator in Forest with external NTP provider. To correct this issue you will need to install the windows 2003 server hotfix on the PDC emulator only: http://support.microsoft.com/?id=832261

B. The other DCs could not synch with the PDC Emulator in the Forest. I had system log events that stated that the DC could not synch with the PDC Emulator because it could not contact or was receiving invalid time data. What we discovered was that our external NTP provider was not a Microsoft NTP service. Instead, we were using TARDIS which uses a different Stratum level then Windows. To clear the issue make sure that your third party NTP provider is using a Stratum level of 7. We discovered this issue after contacting Microsoft and debugging the w32time service. Also, make sure that you can ping the NTP provider first. The Microsoft time service requires ICMP to be enabled in order to synch data.

Good luck

I am having the same problem.  After reading throught this extensive message, I am not sure if the problem was solved and what the solution was.

I am finding the the PDCe is not broadcasting time on UDP 123.  Nothing is using UDP 123.  I have reviewed all the suggestions in the article and have found nothing amis.

Any suggestions or solutions would be greatly appreiciated.

I had the same problem after I demote/promote DCs.

This article might help.
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=39696

http://www.support.microsoft.com/default.aspx?scid=kb;en-us;257623

I am going to try out the solutions this coming week.

Hi jemlay
             Did you resolve this if not can you tell me if I am right the windows time service is set to disabled and not running by default yes/no?

Yes, it was resolved.  You need to read:

Comment from jemlay
Date: 05/04/2004 11:04AM PDT

What exactly do we need to read.. I have this exact issue too.... It is really annoying me ! :) heh

You need to scroll up and find the post dated 05/04/2004.  That is where I describe in detail what I did to fix the problem.  It might not work for you.  Many people use the mentioned policy without fail.

ah sorry because i saw the : after the you need to read, i assumed a link should have been there... q: can you just RENAME the existing default policy, reboot and have everything work? OR do you need to totally remove it... ? I found stuff in the gpo that references the timeserver, and in the default policy it WAS set to be disabled... but I havent had a chance to try it.. hard to bring my PDC down during the day and not have people notice... is there a way to force a reload of the policy without a reboot? I know on an XP client you can do a gpupdate... but when i run that on the DC it hangs! Is there a way to test the policy without a reboot on the PDC ?

ok !!! I solved this !!!! heheh I sorted it out.. i know i cant get any points now.. but here goes... I had SAME isses.. your note to look in the domain controller policy led me to pick through it to find what the REAL problem was and not just to delete the policy.... soo here it is...

go to ..

computer settings --> administrative templates --> system --> windows time service

and configure the obvious settings there! By default i guess sp1 or something disabled this for me as i never had an issue until then! I would set up the server and the policy was blocking it all the long!!! All i did was tell the policy to allow ntp to run as a server on my PDC and rebooted, and oila! I passed all tests now from dcdiag, nltest etc !!!! :) I hope this helps someone still! :)

-Noel

I had a problem with a DC not advertising as a time server and fixed it by chanigng the AnnounceFlag. I documented the process here: http://ben.goodacre.name/tech/Domain_Controller_is_not_advertising_as_a_time_server_Error_in_dcdiag_(Windows)