Microsoft has several tools to speed the deployment of new systems, such as Sysprep and Remote Installation Services (RIS). But these tools are not designed for duplicating or automatically deploying a domain controller (DC).
There are, however, other options for saving time in the DC deployment process.
We've all been in a situation where we needed a new or additional domain controller, and we needed it yesterday. Unfortunately, without significant planning and investment, there is really no way to circumvent the DC deployment process. If you have to start from scratch, even in an emergency, you must install Windows Server 2003 (or Windows 2000 Server), join the domain, become a domain controller and replicate all relevant data. If your domain is experiencing problems, just the act of deploying a new DC can place an even greater burden on the network.
If you even suspect that you will eventually need additional DCs locally or at branch locations, then you should take steps now to make such deployments possible -- and efficient as well. In order to have a new DC up and running and idling in the background, here's what you should do:
First, you need to get Windows Server 2003 (or Windows 2000 Server) installed onto server hardware. You can do this manually with the CD, which will take up to a day or more to complete -- especially with all the needed service packs, hot fixes, patches, new drivers, custom configuration and installed applications. A better option is to deploy an ideal system and duplicate it via Sysprep and an imaging tool, or via RIS. But remember, it has to be a member server not a domain controller. Every time your real DCs require a significant change, such as adding a new application or service pack, you need to update the ideal system and then re-image it. Once the image or RIS system is running, it should take under two hours to get a new server system running.
Second, once you have a server system running, make it a member of the target domain, upgrade it to a domain controller and allow Active Directory replication to complete. However, I recommend placing these new DCs on a background network rather than your primary network. This will require that one of your production DCs has an additional NIC off of which is connected a small hub. Off this hub, you can keep one or more new DCs idling without really involving them in the production activity of the network.
These background-idling DCs will be up-to-date with all Active Directory materials, but they will not be supporting client connections because they reside on a different subnet -- a subnet that you have not configured nor allowed client traffic to be routed into.
At any moment, you can grab one of these idling DCs and add it to the production network simply by changing the network cable attached and resetting the IP address configuration. To make it even more elegant, consider making these DCs Dynamic Host Configuration Protocol (DHCP) client systems initially. Later you can consider converting them to static IP systems, if needed.
Preloading DCs does require some investment in time and money, but it can be an invaluable recovery or sustainment option in the event of a crisis.
James Michael Stewart has co-authored numerous books on Microsoft, security certification and administration and is a regular speaker at Networld+Interop. Michael holds the following certifications: MCSE, MCT, CTT+, CISSP, TICSA, CIW SA, CCNA, MCSE NT & W2K and iNet+. He can be reached at michael@impactonline.com.
