Revisiting DCPromo in Active Directory: what's changed?

DCpromo has been around since the early beta of Windows 2000, and while it has been improved with some bells and whistles, it has remained largely the same. There are a number of options (some undocumented) that has made DCPromo a valuable tool (in fact, the only tool) in building an AD domain or forest. DCPromo’s lot in life is to promote a domain controller. It is a local program that could be run from a Windows Server (in 2000 and 2003) and from Server Manager in Windows Server 2008 and later.
Beginning in Windows Server 2008, Active Directory Domain Services role had to be installed prior to running DCPromo, but it still needed to run to make the server a DC.
One of the tricks DCpromo plays on you is lulling you into false security.  When the install finished and the server rebooted, you thought it was promoted and ready to roll.  What isn’t obvious is what happens after the reboot; an outbound connection is made, AD Replication and file replication service (FRS) connections are made to complete the sync and get group policies and Netlogon and Sysvol shares are created.
To determine if a DC is really a DC do a Net Share command from a command line and see if these two shares show up. If not, the replication failed.  AD replication forced a sync with the other DCs where only a single sourcing DC was involved prior to the reboot. In Windows 2000, getting each DC to do a full sync was a serial process. Windows Server 2003 got smarter and synched updates from the other DCs.
 If you wanted to add a DC from a newer Windows version, such as adding a Windows 2008 DC into a Windows 2003 domain/forest, it was a complicated process.  This required a few things to happen.
The first was the raising the domain and forest functional levels. All domain controllers had to be raised to the Windows 2008 level, the domain level and the forest level. But a major problem with doing this was the changes being irreversible.
The second was running ADPrep. This required schema administrator privileges because it had to contact the Schema Master. Because there was a fear of messing up the Schema, this was usually done prior to promoting a new DC.
The one missing element was that you had to be on the machine, physically or via remote desktop, and there was not a way to mass deploy DCs until Windows Server 2012.
Other highlights include:
Manual demotion of a DC in 2003: DCPromo /ForceRemoval. This was not documented, but it is handy in demoting a DC when it wasn’t replicating, if it was the only DC with the problem and if it would take more than a couple hours to fix.   This required cleaning AD objects of that server via NTDSUtil and Sites and Services snap-in.
Doing a forceful removal has serious consequences, which include removing the server from the domain, putting it into a work group and breaking applications that depend on AD association. Use it only if there is no other way to recover.
Install From Media (IFM).  First introduced in Server 2003, IFM permitted a DC to be promoted off line using backup media. It also got around the issue of a GC with a large DIT file having to replicate across the WAN to be rebuilt. I know of a company that used to take anywhere from three to five days to replicate. When they went to IFM, the time was reduced to less than one hour. IFM was implemented in 2003 with the DCPromo /ADV option, (Figure 1) and moved into the NTDSUtil tool in 2008 and included the ability to create snapshots without a separate backup tool.  IFM is also improved in Windows Server 2012.

Figure 1. IFM was implemented in Windows Server 2003
Windows 2003 tweaked DCPromo to make DNS easier to install, though they did introduce a few problems initially.
Windows 2008 made a radical departure in the implementation of AD by stuffing AD into a service (Figure 2). Beginning in this version the Active Directory Domain Services role had to be installed on a server before running DCPromo.  This allowed stopping AD without rebooting to the old DSRM mode.

Figure 2. In Windows Server 2008, AD was moved into a service, which meant ADDS needed to be installed before running DCPromo.
DCPromo also plays a vital role in disaster recovery of a domain or forest DC. You may think that losing an entire domain or multiple domain forest is a remote possibility, but I have seen it happen. Having recently given a presentation on what can require a forest recovery repair, I was surprised how easily a forest disaster can happen.
In its forest recovery whitepaper, Microsoft recommends restoring a domain from backups. You can do this by restoring one DC, preferably a DNS server, from media. Then, use DCPromo to create replica DCs.  You will bump up against the performance issue on the wire and slow other operations on the network.
Microsoft also recommends a forest recovery in a similar manner. Its recommendation includes restoring one DC from media for each domain, creating a replica DC in each domain before restoring another domain.
This can be done, and I have recovered a forest this way, but it is very slow and inefficient.  I recommend using a third-party tool, such as Quest’s Recovery Manager for Active Directory Forest Recovery Module. These kinds of tools offer a number of advantages:

• Backup and management of backups of DCs 
• Scheduled backups
• Management of all DCs in a single console
• Recovery of all DCs simultaneously

 You can do a disaster recovery of a domain or forest by following the steps in Microsoft’s forest recovery whitepaper, but you don’t want to do this when the disaster strikes and you are following steps in a whitepaper with the CIO looking over your shoulder. Invest in a good third party recovery tool and be able to sleep at night.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for HP in Global Solutions Engineering. He has authored or co-authored several books, including Windows 2000: Active Directory Design and Deployment and Windows Server 2003 on HP ProLiant Servers.