9

There are two schools of thought for the decommissioning process of Active Directory Domain Controllers that are heavily used as DNS servers.

  1. Add the IP address of the outgoing DC to a new DC and ensure that DNS is listening on that address.

  2. Demote the old DC, leave the DNS role on it, and configure a global DNS forwarder to your new server.

Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.

Is there a clear cut best practice here?

  • 2
    Or a third, change any/all references to the old DNS server across the network? – gravyface Sep 7 '13 at 11:15
  • 1
    Of course that's the end-goal, which is why I called it a stopgap. But in some very large environments that's not an option if you want it done in a timely manner. I did say: Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment. right? – MDMarra Sep 7 '13 at 11:16
  • semantics... you're right, but I'd rather just systematically change the DNS configuration of the devices, monitor for activity, starting with DHCP scopes, then work through servers in order of least important to important (member servers to other DCs) than impersonate the old server and/or leave it lingering around longer than necessary. – gravyface Sep 7 '13 at 11:23
  • Of course that's the best option, but when I say "very large" environment, I'm talking globally distributed infrastructure with 300+ DCs and many different IT teams managing different components of the infrastructure. Sometimes, it really isn't possible to ensure that you got every device in the first swing during an upgrade. – MDMarra Sep 7 '13 at 11:25
  • 1
    @gravyface You're not wrong, but in large and geographically dispersed environments whith decentralized management of different components, it's not always feasible to agree on a game plan, get every one in line and work towards a common goal. Sometimes you just have to take a decision to move forward and find a solution or a workaround to ensure it has as few implications for others as possible – Mathias R. Jessen Sep 7 '13 at 11:41
5

I'm hesitant to answer because I think this is more of a "discussion" question than a strictly Q&A question... but it's a lazy Saturday morning so I will anyway.

Is there a clear cut best practice here?

No. (Damn, maybe this was an easy answer all...)

Microsoft provides very generic, easily Googleable Bingable guidance on how to demote domain controllers, and perform migrations of AD and DNS, but I won't bother linking to them nor will I pretend that they address your specific question, because Microsoft obviously can't document every specific case for every different organization's environment.

So systems admins/engineers like us are left to fill in the gaps with our own expertise and experience where Microsoft hasn't written a special script just for us, and that's what makes us valuable.

I can give you an example of something that we've done to address this same issue, since I also work in globe-spanning environments with dozens or more domain controllers, disparate AD forests cohabitating on the same networks, non-Windows devices also consuming DNS services from the same DCs, etc.. Moving into new datacenters and moving out of old ones, needing to migrate to new hardware or new OS versions, and plain old business politics are all possible reasons we'd need to decommission domain controllers that were potentially still being used. And when you have multiple heterogeneous organizations currently using those DC/DNS servers, it's usually a grueling, drawn-out process of reconfiguring every client (many of which may not be under your control) before decommissioning the domain controller, involving project managers, tickets to various other teams that may take days or weeks to get worked, etc..

So that's why I say I don't think anyone can give you the answer to this question. There are a thousand ways you could go about it and some will be better than others depending on your organization's structure and needs.

Something we've done to get in front of this issue is make a VIP for each datacenter, and pool all the domain controllers in that datacenter behind that VIP. (This VIP is for DNS service only for obvious reasons, I'm not talking about load balancing Kerberos and LDAP.) That way, clients can be configured to use that VIP for their DNS resolver, and we are free to add and take away domain controllers behind that VIP whenever and however we please.

But you're not in front of the problem... so given the options you provided:

  1. Add the IP address of the outgoing DC to a new DC and ensure that DNS is listening on that address.

  2. Demote the old DC, leave the DNS role on it, and configure a global DNS forwarder to your new server.

I would choose option #1, because your goal is to decommission the old server as quickly as possible, and option #2 does not help you get rid of the old server. With option #2 the server's existence is still necessary. Nor would I go with Mathias R. Jessen's suggestion of stub zones, because again, you still have to leave the old server in place and in service, which is not conducive to your end goal.

With option #1, ugly as it may be, you can retire the old server, claim cost savings for your company, avoid having to pay another month's rent on that datacenter, and be given an award for being such a good employee.

Edit: Thinking about our chat a little more, I think I may have projected my own requirements onto you, because I do have pull-the-plug-ASAP requirements on some stuff right now, so that was fresh on my mind. It sounds like you do not have as much of an immediate requirement to shut the server off ASAP.

That said, I'm not changing my suggestion, as I would still prefer it. Tacking the extra IP onto an existing domain controller has worked well for me in the past in very similar scenarios, and I would rather that than have a weird vestigial appendage of a server sitting there for an indeterminate amount of time.

| improve this answer | |
  • 1
    I think that this falls under good subjective in the Good Subjective, Bad Subjective post that defined the "discussion questions" rule. At least I hope so. – MDMarra Sep 7 '13 at 16:18
  • @MDMarra I agree. +1 for a thought-provoking and interesting question. :) – Ryan Ries Sep 7 '13 at 16:23
  • Also, just for the record, I typically do the opposite of your suggestion :D – MDMarra Sep 7 '13 at 16:37
5

The road to Active Directory hell is paved with temporary bandages. Assigning the IP address of a decomissioned or to-be-decomissioned DNS server to your new DC and DNS server is a temporary bandage.

As @gravyface noted in the comments, in the ideal scenario you would change all DHCP scopes and static configurations to update the client DNS preference to the new IP instead of the old one, before you decomission the old DC entirely.

I understand that maing sure that all clients have been reconfigured is not necessarily possible on time, but I certainly regard option number 2 (forwarding the entire namespace) as the least objectionable option here.

In addition to letting the old server forward requests even after demoting it, I would recommend enabling Debug Logging for incoming requests on the DNS Server - this makes it a little easier to assess not only if clients are still pointing to the old DNS server but also identifying said clients.

That being said, I think you've missed the obvious third option: Stub Zones!

  • Demote the DC, keep the DNS role and add all the zones it previously held as stub zones - forward everything else. This way, your enforcing the clients to actually contact the Domain Controllers they should be using, instead of doing the work for them
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.