DC2 (a VM) is not syncing to DC1 (a physical server). On DC2 I get:
PS C:\> w32tm /query /source Local CMOS Clock
What must I do so that DC2 syncs to DC1 as its time source?
Background: I had to replace DC1 and it was my operations master. There was no opportunity to gracefully demote DC1; it simply disappeared from the domain. When I successfully re-created DC1, DC2 was the operations master. AD DS replicated correctly, I transferred the fsmo roles to the new DC1 and I set DC1 to "0.us.pool.ntp.org". DC1 returns a good stripchart. I've confirmed again that all the fsmo roles are set to DC1. I have confirmed the Hyper-V Integration Services for DC2 has Time Synchronization unchecked.
I've spent some time researching this, but so far haven't found the w32tm sequence/command for moving DC2 off of it's CMOS Clock. At this point I need a little help or a reminder of how to do this.
Added after initial post: I did find the following DC2 dcdiag errors:
Starting test: Advertising Warning: VSVR-WBC-DC02 is not advertising as a time server. ......................... VSVR-WBC-DC02 failed test Advertising A warning event occurred. EventID: 0x00000081 Time Generated: 12/27/2018 14:50:05 Event String: NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The entry is not found. (0x800706E1) Running enterprise tests on : wbc.local Starting test: LocatorCheck Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355 A Primary Domain Controller could not be located. The server holding the PDC role is down. Warning: DcGetDcName(TIME_SERVER) call failed, error 1355 A Time Server could not be located. The server holding the PDC role is down. Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, A Good Time Server could not be located. ......................... wbc.local failed test LocatorCheck
And the DC1 dcdiag errors:
Starting test: Advertising Warning: DsGetDcName returned information for \\vsvr-wbc-dc02.wbc.local, when we were trying to reach SVR-WBC-DC01. SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE. ......................... SVR-WBC-DC01 failed test Advertising Starting test: NetLogons Unable to connect to the NETLOGON share! (\\SVR-WBC-DC01\netlogon) [SVR-WBC-DC01] An net use or LsaPolicy operation failed with error 67, The network name cannot be found.. Starting test: SystemLog A warning event occurred. EventID: 0x0000002F Time Generated: 12/27/2018 14:56:32 Event String: Time Provider NtpClient: No valid response has been received from manually configured peer 0.us.pool.ntp.org after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. The error was: The peer is unreachable. Running enterprise tests on : wbc.local Starting test: LocatorCheck Warning: DcGetDcName(TIME_SERVER) call failed, error 1355 A Time Server could not be located. The server holding the PDC role is down. Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355 A Good Time Server could not be located. ......................... wbc.local failed test LocatorCheck
This answer solved my problem, but it is not necessarily a direct answer to the posted question for others. I am providing this answer because another individual may get here with the same question when, in fact, the issue is significantly different, as the first comment by Greg Askew indicates.
The real problem for me was that the SYSVOL and NETLOGON shares were not present on the new domain controller, which I should have checked for early on - dumb mistake. That can be seen in power shell with:
PS C:\>net share
When those volumes are not present there are bigger problems. In my case, DCDIAG reported failed Advertising which is too general to pinpoint the problem.
My particular problem was resolved by forcing an authoritative sync for DFSR-replicated SYSVOL according to this Microsoft support page.
For me, in the past failed Advertising was caused because the PDC time source was not working correctly. That experience caused me to jump to a conclusion about the nature of the problem in this case, but that conclusion was incorrect.
If a PDC time source is an issue, this ServerFault post may be of value.
Because I had an abrupt removal of one of my domain controllers without a graceful demotion, I also needed to clean up metadata. Although I did that correctly in Active Directory Users and Computers, and also Active Directory Sites and Computers, I had failed to do that in DNS. My experience in cleaning up DNS was that the lost domain controller was present all over DNS, and I had to go through every subtree to find references to the old controller, sometimes just by IP or some other numerical identification because the old domain server name had been lost in certain DNS entries.
Thanks to those who commented above to point me in the right direction.
User contributions licensed under CC BY-SA 3.0