locked
Re-Promote DC taken down a month ago RRS feed

  • Question

  • I have a windows server 2019 I stoof up a couple months ago as the newest DC in our AD infrastructure. I took it down because I mistakenly thought we were still using FRS for file replication. Now that my research is done and because we are in fact using DFSR, I want to re-promote it. When I demoted this server, I never took it out of service completely, so there should be no problem with duplicate ad computer objects, etc.

    I noticed though that even though the demotion was successful , and as far as I can tell all meta data in AD is clean, there still exist a SYSVol folder, and who knows what else.

    Should I / Can I remove the SYSVol file (and anything else) prior to re-promoting this DC?

    Are there any known problems with re-promoting a DC that never left AD?

    Should I just delete this VM and create a new one with a new Hostname?

    Thanks in advance for the advice

    Tuesday, February 11, 2020 7:45 PM

Answers

  • Dave,

    Specifically, should I delete the existing SysVol file before I promote it again? The link you gave me is for meta data cleanup in AD, not the server itself.

    I'd leave it alone. It shouldn't be a problem to just promo it, if there are errors then you can also check if cleanup were necessary.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    • Marked as answer by mmurphy58 Tuesday, February 11, 2020 8:41 PM
    • Edited by Dave PatrickMVP Tuesday, February 11, 2020 8:43 PM spelling
    Tuesday, February 11, 2020 8:37 PM

All replies

  • Shouldn't be a problem to promo it again. If you think there might be some remnants you could check and cleanup here.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup

     or post the errors here for additional.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    Tuesday, February 11, 2020 7:57 PM
  • Correct - you should make sure first that any orphaned AD object representing the demoted domain controller have been removed. For details refer to https://blogs.msmvps.com/acefekay/2010/10/04/complete-step-by-step-to-remove-an-orphaned-domain-controller/

    This needs to be done whether you use the same VM or create a new one.

    hth
    Marcin


    Tuesday, February 11, 2020 8:03 PM
  • I'm not sure what you are referring to. This is not an orphaned DC. It was demoted successfully.
    Tuesday, February 11, 2020 8:32 PM
  • Then it shouldn't be a problem to promo it, if there are errors then you can also check if cleanup were necessary.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Tuesday, February 11, 2020 8:34 PM
  • Dave,

    Specifically, should I delete the existing SysVol file before I promote it again? The link you gave me is for meta data cleanup in AD, not the server itself.

    Tuesday, February 11, 2020 8:35 PM
  • Dave,

    Specifically, should I delete the existing SysVol file before I promote it again? The link you gave me is for meta data cleanup in AD, not the server itself.

    I'd leave it alone. It shouldn't be a problem to just promo it, if there are errors then you can also check if cleanup were necessary.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    • Marked as answer by mmurphy58 Tuesday, February 11, 2020 8:41 PM
    • Edited by Dave PatrickMVP Tuesday, February 11, 2020 8:43 PM spelling
    Tuesday, February 11, 2020 8:37 PM
  • The re-promotion seems to have gone well. Just one final question about the NTDS topology (auto connections);

    We now have a total of 4 domain controllers in 1 domain(for the moment). The auto connections for any given DC is only 2 of the other DC's even though there would be 3 available. It seems to be well distributed in that every DC is connected to 2 others, but I would like to know if this is normal?

    Why wouldn't NTDS want to make a connection to every DC for each server?

    Tuesday, February 11, 2020 11:13 PM
  • Yes, it is normal and is also my experience.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Tuesday, February 11, 2020 11:19 PM
  • Hello,

    Thank you for posting in our TechNet forum.

    I am so glad that our problem has been resolved.

    Meanwhile, here are my reply about our questions.

    According to your description, there are two questions. As for the first question about the re-promotion, it seems to be well done as you mentioned. 

    For demoting DC, we will use the following two methods:

    Usually, we demote a domain controller from our Active Directory domain by using Dcpromo.exe. 
    If we can demote it successfully based on the demotion wizard, that means the DC is demoted by us successfully.

    If we cannot demote a domain controller from our Active Directory domain by using Dcpromo.exe successfully;
    Firstly, we need to perform the metadata clean for this DC. 
    Secondly, we also need to check if there is any entry related to old DC in DC.

    For example:

    1.Domain Controllers OU in Active Directory User and Computer.
    2.Delete the server object associated with the failed domain controller In Active Directory Sites and Services.
    3.Remove the failed server object from DNS records in DNS manager.

    At last, we can run DCdiag /v, repadmin /showrepl and repadmin /replsum to ensure that there is error message and there is no failed domain controller entry.

    For our second question about the NTDS topology, we agree with Dave that this is normal for the connection. There is a built-in process running on all domain controllers which is called Knowledge Consistency Checker (KCC). The Knowledge Consistency Checker (KCC) creates connection objects automatically.

    The connection object is a child of the NTDS Settings object on the destination server. For replication to occur between two domain controllers, the server object of one must have a connection object that represents inbound replication from the other. All replication connections for a domain controller are stored as connection objects under the NTDS Settings object. The connection object identifies the replication source server, contains a replication schedule, and specifies a replication transport.

    The KCC creates separate replication topologies depending on whether replication is occurring within a site (intrasite) or between sites (intersite). The KCC also dynamically adjusts the topology to accommodate the addition of new domain controllers, the removal of existing domain controllers, the movement of domain controllers to and from sites, changing costs and schedules, and domain controllers that are temporarily unavailable or in an error state.

    For more information, please refer to: 
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc961781(v=technet.10)?redirectedfrom=MSDN

    Hope the information is helpful. If you still have problems, please contact with us.


    Best regards,
    Hannah Xiong

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 12, 2020 9:36 AM
  • Thanks for all the information. Yeah, I have most of everything working as desired.

    I've discovered that when NTDS creates a connection object, you can not edit the SysVol replication schedule with out agreeing to allow the NTDS connections to become non-automatic (not - advised). This means I can not pause the replication schedule in the middle of the night to allow for Windows Server Backups to occur on the Domain Controllers. This in turn creates a "warning" in the DFSR log every night, which causes the DCDIAG report to show a DFSR failure any time I run it(because a warning was created within the last 24 hours in the log file).

    I tried to schedule the backups so they triggered in between replication schedule points, but it doesn't work, which tells me the stated replication schedule for SysVol on auto-generated NTDS connections is not accurate.

    It states once per hour, but it does not necessarily run at the instant the hour begins.

    Any advice on a workaround for this would be cool. This is most likely a bug or at least a feature request.


    • Edited by mmurphy58 Tuesday, February 18, 2020 8:13 PM
    Tuesday, February 18, 2020 8:12 PM
  • Hello,

    You are welcome and thank you so much for your feedback.

    The KCC creates connection objects automatically. Besides, we could manually create the connection objects. By default, the replication topology is managed automatically and optimizes existing connections. However, manual connections created by an administrator are not modified or optimized. So if possible, we suggest to make no change to the replication topology. 

    And please confirm the following information:

    1. According to “I've discovered that when NTDS creates a connection object, you can not edit the SysVol replication schedule with out agreeing to allow the NTDS connections to become non-automatic (not - advised).”, how do we edit the SysVol replication schedule?
    Is our SYSVOL replication OK? 

    2. According to “This means I can not pause the replication schedule”, do we mean we cannot edit replication schedule? If no, what do we mean?
    We can back up Domain Controller during the AD running time.



    3. From the above description, I am sorry, I cannot understand what actual problem/issue we have. Would you please tell us in details?

    Meanwhile, would you please tell us if our AD environment is healthy? We can check as below:

    1.We should check if all DCs work fine by running Dcdiag /v on every DC.
    2. And check if AD replication is working properly by running repadmin /showrepl and repadmin /replsum on every DC.
    3. Check if we can run gpupdate /force successfully on every DC.
    4. Check if the SYSVOL and Netlogon are shared by running net share on every DC.

    Hope the information is helpful. Please let us know if you would like further assistance.


    Best regards,
    Hannah Xiong    

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 19, 2020 10:51 AM
  • I think you might have just solved my problem!

    I was going all the way down to the specific domain --> servers and trying to access the NTDS settings for each connection:


    You can not adjust the schedule from here for automatically generated connections. I've made the changes where you illustrated and it worked. Now I just need to see if my DC diag has no DFSR errors tomorrow. Thank You!

    Wednesday, February 19, 2020 11:01 PM
  • Hello,

    You are welcome. So glad to hear that our problem might have been solved. We could check whether all the problems have been solved. Please let us know if you would like further assistance.

    Thank you so much for your time.


    Best Regards,
    Hannah Xiong

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, February 20, 2020 3:02 AM
  • Well....

    I still have the same result in dcdiag. Perhaps I'm trying to solve the wrong problem. I'm trying to eliminate the warning in the DFSR log (for SysVol replication) which occurs every night during the windows Server Backups. I believe this is different than AD replication, correct?

    Perhaps this replication schedule setup in NTDS is referring to something different. I'm tempted to undo the change.

    Thanks

    Thursday, February 20, 2020 4:28 PM
  • This should be more informational than anything. I think what you might have been looking at was inter-site replication settings which would be more like different cities or along that line.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Thursday, February 20, 2020 4:34 PM
  • Hello,

    You are welcome and thank you so much for your feedback.

    According to “I'm trying to eliminate the warning in the DFSR log (for SysVol replication) which occurs every night during the windows Server Backups.”, what warning do we see? After we run Dcdiag /v, do we receive any error message?

    Q: I believe this is different than AD replication, correct?
    A: Yes, AD replication is different from SYSVOL replication.

    AD replication keep all the DC in the same domain / in the same forest synchronize.
    SYSVOL replication keep all the policies in sysvol folder in the same domain synchronize.






    Best regards,
    Hannah Xiong



    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, February 24, 2020 9:42 AM
  • It Looks like things are working good enough;

    Here is the "Warning" from DCDIAG /v; 

          Starting test: DFSREvent
             The DFS Replication Event Log.
             There are warning or error events within the last 24 hours after the SYSVOL has been shared.  Failing SYSVOL
             replication problems may cause Group Policy problems.
             A warning event occurred.  EventID: 0x80001396
                Time Generated: 02/26/2020   00:30:24
                Event String:
                The DFS Replication service is stopping communication with partner DC5 for replication group Domain System Volume due to an error. The service will retry the connection periodically.

                Additional Information:
                Error: 9036 (Paused for backup or restore)
                Connection ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
                Replication Group ID: YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY
             A warning event occurred.  EventID: 0x80001396
                Time Generated: 02/26/2020   00:38:05

    I believe DFSR replication of the SysVol file system is a special case where the schedule is handled automatically and can not be edited, so this may be the best we can do.



    • Edited by mmurphy58 Wednesday, February 26, 2020 10:10 PM
    Wednesday, February 26, 2020 10:02 PM
  • Hi,

    Concerning DFS-R replication , check if there is no network issue between impacted domain controllers, if it is not the case , you can perform a non-authoritative restore for SYSVOL replication.

    How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    Wednesday, February 26, 2020 11:01 PM