Windows Time source resets after service/server restart

Question

We have two completely separate domains.  Our main domain has 4 DCs: the PDCe is looking to an outside source for its time source and the other 3 DCs are looking to the PDCe for their time source.  The second domain, our DMZ, is setup the exact
same way.  The PDCe is looking to an outside source for time and the other 3 DCs are looking to the PDCe for their time.  If the Windows Time service is restarted or the server is restarted (during patching, for example), the time source changes
from the outside address to "Local CMOS Clock".  From there, everything else will get thrown off.  And now that I think of it, they might also revert to "Local CMOS Clock" after the service is restarted.
I configured the PDCe using the following command, which completes successfully:
w32tm /config /manualpeerlist:0.pool.ntp.org /syncfromflags:manual /reliable:yes /update
I can then run w32tm /query /status and confirm the setting is correct, but if I do the recommended "net stop..." and "net start..." commands, it will revert to "Local
CMOS Clock".  If I leave it alone and the server reboots, it will again revert.  This problem does not exist in our main domain.  I have the appropriate rights and I don't see anything in the event logs that would indicate what the problem
is.  Thoughts?
Chris

Answer 1

so the first thing is that only your PDCe should be going out to the internet (or another reliable NTP source) to get the time and that's done with:
w32tm /config /manualpeerlist:0.pool.ntp.org /syncfromflags:manual /reliable:yes /update
all your other DCs then go to the PDCe to get their time and we do that with:
w32tm /config /syncfromflags:domhier /update
so when you say you tested it on "test DC", you need to ensure the right settings are being pushed relevant to that DC's role and I'm not really certain about this test environment you have here
reading up on this, it all keeps going back to VMs doing time sync with the host, GPOs, scheduled tasks, or startup scripts
you can check the Systems event logs though, there will be messages in there stating why it reverted back to local cmos. it might do it if it can't reach the time source you specified and that part is normal but you need to check the logs first. even a successful
time sync message will help eliminate some of the causes
I think unregistering/registering the service starting with your PDCe should make it stick, as long as it can actually communicate with "0.pool.ntp.org".  to verify this and to make sure UDP port 123 is open, run "w32tm /stripchart /computer:0.pool.ntp.org"
- if you get a time chart then communication is fine but if you get something else then you may have problems hitting that source and it's reverting back to cmos.