I’ve had some problems with dcdiag failing on the advertising check, and this relates back to the DC not getting its time from the PDCE properly.
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 sntp site by entering this at the command line (note: i use pool.ntp.org instead of default microsoft sntp)
NET TIME /SETSNTP:pool.ntp.org
If it’s a member 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. (Note: if you have root domain then sntp requests are sent up the chain to that)
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.
NET TIME /SETSNTP:
to clear any entry and return to the default settings
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.