Steps and checklist when demoting domain controllers ?

Can anyone here please share some steps and the procedure to decommission Windows Server 2012 R2 domain controllers which hold all FSMO role and AD-Integrated DNS servers ?

Is there any outage on the Exchange email flow or the network when doing it ?
I have already commission 2x VMs Windows Server 2016.
LVL 9
Senior IT System EngineerIT ProfessionalAsked:
Who is Participating?
 
BembiConnect With a Mentor CEOCommented:
Hello

- The first step is to move all FSMO roles to a different DC
- You may check, if Exchange is connected to a fixed DC.... (or any available DC)
- Make sure that at least one of the remaining DCs holds the global catalog....
- Take care of all settings, which may point clients/servers to a DC / DNS server, which should be demoted...
--> i.e. DHCP settings, groups policies etc.
- Also take care of manually configured network adapters (usually servers..). You may change the settings to an alive DCs / DNS / WINS etc. before you demote any DC.

While clients may take a configuration change (i.e DNS settings) with the next reboot as long as they are configured by DHCP / GPOs, servers may stay online for a longer time or are configured manually. If you can make sure, that none of your servers is pointing to a DC, which should be demoted, you should be safely able to demote the DC.

These are my thought about this topic.
1
 
Dariusz TykaConnect With a Mentor ICT Infrastructure Specialist Senior Commented:
In addition to above comment before demoting domain controller I would check if replication is in healthy state.
Also dcdiag output from remaining domain controllers would be a good thing to check.  Before really removing DC role I would simply power this server off for some time and check if all is working as it should (DNS, user logons, exchange etc). If all seems to work as it should then you can go ahead and decomission this domain controller.
1
 
Radhakrishnan RConnect With a Mentor Senior Technical LeadCommented:
Hi,

The 2016 VM's are also a DC? If you have other DNS and GC role holder then the impact will be minimal apart from the only other interruption may be seen from OUtlook clients while connected to Exchange.  
Exchange is heavily dependent on the GC role so your users may see pop-ups in OUtlook indicating that OUtlook is waiting on Exchange (30-45 seconds), then Exchange should reconnect with another GC.
1
 
DrDave242Connect With a Mentor Commented:
You should also check to make sure SYSVOL data is replicating before demoting a DC. The SYSVOL replication mechanism is completely separate from the AD replication mechanism, and problems with it can go undetected for a long time in an environment that's relatively static. For this reason, it's easily overlooked.

Just yesterday, I helped out a customer who'd noticed that their newly promoted DC didn't have SYSVOL or NETLOGON shares. When I connected to their old DC and looked through its logs, I found that this was caused by an issue that had been quietly going on for four years (1463 days, to be exact). Fortunately, because they hadn't yet demoted that old DC, the problem was easy to fix. Had they already demoted it, they would've been digging through backups of the old DC (assuming they exist) or recreating their GPOs and logon scripts from scratch.

Problems with SYSVOL replication will appear in either the File Replication Service or DFS Replication event logs of your DCs, depending on which mechanism they're using. Newer domains will use DFSR, but older domains may still use FRS if they haven't been migrated to DFSR yet.
1
 
Senior IT System EngineerIT ProfessionalAuthor Commented:
Thanks guys for your sharing and the great suggestion.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.