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.
Senior IT System EngineerIT ProfessionalAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


- 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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dariusz TykaICT 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.
Radhakrishnan RSenior Technical LeadCommented:

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.
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.
Senior IT System EngineerIT ProfessionalAuthor Commented:
Thanks guys for your sharing and the great suggestion.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.