How do I force a domain controller to sync with the PDC?

Question

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

`There was no opportunity to gracefully demote DC1; it simply disappeared from the domain` - That doesn't quite make sense. How did it disappear? When it disappeared did you sieze the FSMO roles on DC2 and perform a clean up of the previous DC1 before you created a new DC1? — joeqwerty, Dec 27 '18 at 22:36
@joeqwerty Hi again. I had reset DC1's pwd & next I used it it was incorrect. I was not wise enough to have a contingency plan, which I will now, but DC1 was a 'brick'. So I rebuilt DC1 on the same PC using same name & IP. FSMO roles were already on DC2 when I changed them to DC1. Other research I did now suggests DC2 may have garbage DC1 data, which you seem to indicate. I decided to rebuild DC1 again but use a different name & IP, but I don't know how to clean up the old DC1 data. Any links to guide me or help is appreciated. — Alan, Dec 28 '18 at 00:17
@joeqwerty In lieu of cleaning up the previous DC1 at this time, is it possible to bypass the clean up problem for the DC1 that has disappeared by added a new domain controller as DC3 with a different IP? Or will the MAC address also cause a problem? — Alan, Dec 28 '18 at 14:35
@joeqwerty Or regardless of what I do, will that bad data impact replication until it is removed? — Alan, Dec 28 '18 at 14:47
The MAC address has nothing to do with the problem. You could certainly add another Domain Controller, but the existence of DC1 is still going to cause problems. You should clean up DC1. — joeqwerty, Dec 28 '18 at 15:58
`I don't know how to clean up the old DC1 data`. Right-click on the computer object in AD Users and Computers/AD Sites and Services and select Delete. https://blogs.technet.microsoft.com/canitpro/2016/02/17/step-by-step-removing-a-domain-controller-server-manually/ — Greg Askew, Dec 28 '18 at 16:45
@GregAskew Thx for confirming that article. Based on earlier comments I had searched and found it and wondered if that was a good process to follow. Will do that. I had deleted as you say above, but didn't do the rest of that blog article. — Alan, Dec 28 '18 at 17:26

score 0 · Accepted Answer · answered Dec 31 '18 at 20:58

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.

How do I force a domain controller to sync with the PDC?

1 Answers1