As time passes, the business value derived from a company's IT infrastructure continues to expand. Usually, along with this, the 'interconnectedness' of the infrastructure expands, too.

One of the goals of an IT Pro is similar to a paraphrase of Hippocrates: "First, do no harm."

When we DCPROMO a Domain Controller (DC) out of Active Directory (AD), it is a very easy wizard-driven process. However, without proper forethought and a few precautions, that easy process can possibly have a far reaching and substantial negative impact on production IT Operations. I like to help my customers avoid those situations with good proactive advice and meaningful lessons-learned.

Personally, I love checklists – they are always more complete than my memory, they can be templatized and re-used. Checklists can serve as a paper trail for Change Control audits or histories and they can often help you cover your butt if things go south.

Here are few items for a DC decommission checklist.

Prior to DCPROMO

Before we yell BANZAI! and kick off a DCPROMO, what should we check?

  • Do we need to modify any DHCP scopes?
    • Are we providing this server's IP address as a DNS server for DHCP clients?
  • Do we need to modify any member servers or other static systems?
    • Are we pointing any systems to this server for DNS, LDAP, etc?
    • SCCM is an awesome tool to inventory these sorts of settings, but if you don't have SCCM, another great way to inventory the IP configurations for your systems is via script.  PowerShell has some handy 'export to CSV' functions built right in.  A peer PFE and PowerShell wiz is putting the final polish on a post with some script code samples to do just that...stay tuned!
  • Are there startup/logon/other scripts that hard-code this system and need to be modified/edited beforehand?
  • Are there any shares, applications, printers, scheduled tasks or other 'services' on the target system? Check for any additional or unexpected Roles or Features (i.e. WINS – which is far down in the GUI; be sure you scroll!)
    • Those may or may not be affected after you remove AD from a server
    • If the goal is to decommission the server, those services may need to be moved or decommissioned with the target server
  • You'll want to know what you should set for the local Administrator account's password once AD is removed and the server becomes a member server
    • Beware that by default, the username will be "Administrator" but if you've redirected the default COMPUTERS container in AD to another OU, there might be a GPO that renames the local Administrator account
  • You'd be wise to obtain/verify (or reset) the local Directory Service Recovery Mode password just in case you need it on this system
    • This is often a weak spot in an AD deployment
      • "Who knows the DSRM password? I've tried the 8 that I thought it might be and none of them work."
      • On 2008 and newer versions, this can be sync'd to a domain account to make it a bit more easily managed.
  • Obtain and verify ILO/DRAC/KVM/VM console or other 'out of band' access to the system in the event the system doesn't reboot properly (sitting at an F1 prompt because someone unplugged the keyboard to a server across the country on a Sunday at 2:00 am is no fun).
  • You'll need the AD Site information for the DC so you can clean up the server 'object' from AD Sites after the DCPROMO
    • That still needs to be manually removed even in Server 2012 (at least in the Release Candidate)
  • Make sure you have your approved and communicated Change Control Request
  • Make sure the Helpdesk is aware
  • I recommend verifying the AD FSMOs can all be reached from the target system
    • From CMD: DCDIAG /TEST:FSMOCHECK <enter>

Starting DCPROMO

  • Logon to the target Domain Controller
    • Verify you are actually logged on to the proper server.
      • Name resolution can be flaky
      • Names of VMs in the VM console can be wrong
  • Check the NIC settings and verify/set a valid setting for the DNS entries OTHER than itself
  • When ready, kick off DCPROMO
  • If you are decommissioning the domain, select the checkbox stating that this is the last DC in the domain
    • This will clean up the domain from the AD Forest, if applicable
  • After the system reboots from the DCPROMO, you'll likely need to remove the Role itself via Server Manager
  • Remember, by default, the computer account gets moved into the COMPTUERS container in AD after DCPROMO. If you've redirected the default container to another OU, the computer object will be placed there.
    • You may need to move the computer account object into a more desirable OU to ensure proper policies get applied (if the server isn't going to be decommissioned right away)
  • Remember to go into AD Sites and Services MMC and delete the server 'object'
    • Sometimes AD replication takes time and you'll notice there is still an NTDS Settings object under the server object.
    • If this is the case, allow time for AD Replication to "spread the news" of the recent DCPROMO and check back later to delete the server object.
    • WARNING!! DO NOT delete the NTDS Settings object manually or attempt to delete the server object if there is an NTDS Settings object underneath it
  • If you are decommissioning the server, be sure you delete the computer account from Active Directory to help "keep AD clean."
  • If required – depending on the situation:
    • Delete the AD Site, Site Link and subnet(s) entries from AD
    • Delete any DNS entries
      • A, PTR, CNAME, etc
      • Don't forget to check for any glue or delegation-related records
      • Don't forget to check any NS records where the DC was a secondary DNS server for one or more primary DNS zones hosted elsewhere
      • Don't forget any forwarders/conditional forwarders on other DCs which may have pointed to the target system
    • Delete the record(s) from WINS
    • Delete the "other side" of any external or shortcut trusts if this was a domain decommission in addition to a DC decommission
    • Edit any GPOs that set this domain as a DNS suffix entry
    • Remove the server from any backup, management or monitoring tools
    • Mark the system as appropriate in any asset tracking tools
    • If it was a VM, inform the VM team to delete the VM
    • If it was a physical server, remove it from the rack    
      • Remove the rails, network, power and other cables from the rack
      • Update any documents which track datacenter space/ports/rack allocations
  • When you're all done, inform the proper people that your change control request is complete
  • Sign off on your 'checklist' and file it away

For me, there is always a period of time where I'm still 'waiting' for the phone to ring or pager to go off but once you get past that time, usually a few hours during the business day, have a Coke and smile J

Hilde