[Last Call] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1238
  • Last Modified:

Demoting a 2003 Domain Controller without impacting users

I need to demote a domain controller. We have three sites and two domains in our forest. This server is a DC in the parent domain.

I want to demote it while causing as little impact as possible. I've gone through the process of moving off any FSMO roles and have run dcdiag and netdiag to test everything is okay. No users should be using this DC as a DNS server.

My main concern when demoting the DC is that some users will be looking to it for logon/authentication and it will take time for DNS to correct this. I can do the work out of hours, but will need an estimate of the time required for everyone (that is, clients, AD S&S and other DCs) to acknowledge that the server is no longer a DC. Site replication is set to 1 hour.
2 Solutions

in case the DC you plan to demote is hosting GC for the forest, u need to transfer this role to any other DC. the procedure is given in http://support.microsoft.com/kb/255504

the demotion itself would not take much time, though you would need to force replicate the change pertaining to DC removal to other DC using the site specific links. the procedure to force replication over a connection is as follows:

Open Active Directory Sites and Services.
In the console tree, click NTDS Settings for the server that you want to force replication.
Where Active Directory Sites and Services/Sites/site that contains the connection over which you want to replicate directory information/Servers/server that you want to force replication/NTDS Settings
In the details pane, right-click the connection over which you want to replicate directory information, and then click Replicate Now.
You can also use the repadmin and replmon command-line tools, available on your operating system installation CD, to force replication
jonhicks...even if you do this during hours, the impact should be minimal, if any impact at all. The ONLY way to test if clients are using this DC as an authenticating DC is to go to a CMD prompt and run "set logonservername" (no quotes, of course). This will display the authenticating DC. But even then, they're already logged in, so it wouldn't have an impact. Replication should take about an hour and, if need be (for group policies maybe), at most all your users would need to do is perform a reboot.

Now, if this is your main DNS server, there would be a problem. I assume you have AD-integrated set for your internal DNS and thus have a 2nd'ary DNS server to implement during this demotion? You can make this seamless too by setting your DHCP options (006, I believe) to point to only your 'new' DNS server. And, you say you have replication set to 1hr, you can set this to be lower (I have mine set to 15mins) so things go quicker. The only thing that takes time with doing these kinds of things is just that...replication.

Hope this helps.

jonhicksAuthor Commented:
Thanks both, useful info.
It seems like you already tested that no user will be using this to be demoted DC in your parent domain. As long as this to be demoted DC is not being used by users via DHCP and it is not a primary DNS for any other DNS server including non-DC and/or DC in your chile domain, you should be fine to demote it.
If you have AD site created, your users hould be able to authenticate to any DC by first attempt to authenticate to a DC which is local site to the users subnet which assigned to the same AD site. If no DC available to the client in the local site, it will look for other DCs in the same domain to authenticate. this means, there shouldn't be any worry as long as your parent domain have two or more DCs with GC to service client before demoting this DC. One last thing to check is make sure this DC is not the only DC hosting logon script or roaming profile or related data etc.
jonhicksAuthor Commented:
DNS I took care of a while ago. I even bothered to check the dns log to see if any requests came its way - all I saw was traffic between it and the other dns servers.

We have three other DCs in the parent domain, so that's all good. It's not a GC.

Regarding login scripts - all of ours are found in the netlogon share, which is replicated between all DCs. I've gone through and checked that all our GPOs refer to these by domain name instead of server. Will have to test that they still work...

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now