In the past two Inside Out columns, I've discussed how to create simple batch files that let you automatically configure machines to set up domain controllers (DCs)—and in the process, domains, trees, and forests. Such batch files are tremendously useful for several reasons. First, a good disaster-recovery plan will mandate this sort of batch file because it lets you start from a freshly installed copy of Windows Server 2003 or Windows 2000 Server. By typing a few commands, you end up with a fully functional forest, rebuilt from scratch. Second, even if you never need disaster-recovery tools, you can still use the batch file to build small test networks that mimic your enterprise network and let you try things out in a safe environment. Third, this batch file effectively illustrates the power of batch automation: On a fresh system, you can type one command, walk away, then return 15 minutes later to find a perfectly configured IP stack, DNS server network, and Active Directory (AD) domain.
So far, I've shown you how to create a batch file that configures an IP stack and a DNS server network. This time, I show you how to use a batch file to create AD domains.
The Answer File
To create a domain, tree, or forest, you simply need to create the first DC in that domain, tree, or forest—and to create a DC, all you need to do is run Dcpromo (aka the Active Directory Installation Wizard). Like all wizards, Dcpromo demands attention, if only to repeatedly click Next. But a script can provide that attention. Microsoft has quietly furnished Dcpromo with full-featured scriptability. You can script Dcpromo in both Windows 2003 and Win2K, although the script commands are a bit different between the two OSs. (I use the Windows 2003 command set for this article's examples.)
To run Dcpromo with a script, you use the /answer option, as follows:
The answer file is simply an ASCII text file that contains answers to a few basic but essential questions. In general, answer files are case insensitive, except for any passwords that you might need to include. (You can build an answer file in Notepad quite easily.) The questions that a Dcpromo answer file needs answers to are
- Will this DC be the first DC in a domain (thereby creating a domain), or will it simply help out in an existing domain (i.e., will it serve as a replica DC)?
- If Dcpromo is creating a domain, what will that domain be called, and how will it fit in the existing forest? Should Dcpromo create not only a new domain but also a new forest?
- If Dcpromo isn't creating a domain, do you have the proper credentials to create new DCs in an existing domain or to create a new domain in an existing forest?
- In what location should Dcpromo place the AD database file ntds.dit, the transaction log files, and Sysvol?
- How should Dcpromo handle DNS errors? If the existing DNS infrastructure is invalid for AD, should Dcpromo create a new DNS structure or simply fail with an error condition?
To create a brand-new forest, you can use the answer file that Listing 1 shows. This answer file creates the first DC in the first domain in a forest. Following the example of the past two columns, we'll call that first domain bigfirm.biz.
In just 13 lines, the answer file provides much functionality. It starts with the \[DCINSTALL\] statement, which starts all Dcpromo answer files. Next is the ReplicaOrNewDomain statement, which specifies whether you're creating a new domain or adding a DC to an existing domain. The acceptable answers are Domain, which creates a new domain, and Replica, which adds a DC to an existing domain. We're creating a new domain rather than a replica DC, so that domain needs a DNS name (e.g., bigfirm.biz), a NetBIOS name (e.g., bigfirm), and a Directory Services Restore Mode (DSRM) password. The NewDomainDNSName, DomainNetBIOSName, and SafeModeAdminPassword statements specify those values.
But where does the new domain fit in a forest? The NewDomain statement has three possible values. Forest tells Dcpromo to create the first domain in a forest, Tree tells Dcpromo to create the first domain in a new tree that's part of an existing forest, and Child tells Dcpromo to create a new child domain in an existing tree (which implies that the tree is a member of an existing forest). In this example, I'm creating the first domain in a forest, so Forest is the correct value.
The next three statements—DatabasePath, LogPath, and SysvolPath—appear in every Dcpromo answer file, no matter what the DC's role, because every DC needs a copy of the AD database (and therefore must know in what location to put the database and log files) and a Sysvol. In this simple example, I've used %systemroot% as the path for each. You almost certainly wouldn't use the same path on a real-world DC; you can dramatically improve a DC's performance by putting the database and log files on separate physical drives. The %systemroot% environment variable simply refers to the drive and directory (e.g., C:\winnt, D:\windows) on which you've installed the OS.
The DNSOnNetwork and AutoConfigDNS statements obviously refer to DNS. DNSOnNetwork tests for a properly configured DNS system on the network. AD simply can't run without a correctly configured DNS infrastructure. Therefore, before trying to create a DC, Dcpromo performs a few tests to ensure that DNS is correctly implemented. You can save a few seconds by setting DNSOnNetwork to No, thereby disabling those tests, but I've set it to Yes in this sample script because double-checking DNS's status doesn't hurt.
What if Dcpromo finds that DNS isn't correctly implemented? In that case, AutoConfigDNS gives Dcpromo the power to automatically set up the DC as a DNS server, with just enough intelligence to serve the needs of this DC. You should always—always—set this value to No. AD won't work without a properly configured DNS infrastructure, and Dcpromo doesn't properly configure DNS. If DNS isn't working perfectly, you want Dcpromo to fail.
The AllowAnonymousAccess and RebootOnSuccess statements finish this answer file. The AllowAnonymousAccess statement answers the Dcpromo wizard's question about whether you have Windows NT 4.0based RAS servers in your network. When Dcpromo configures a new DC to accommodate NT 4.0 RAS servers, it does so by loosening security. Essentially, the statement specifies whether you want to give the Everyone group Anonymous access to this DC. I could write pages about why granting such access is a horrible idea, but to save space, I'll just say that you should set this statement to No unless you have a solid reason for setting it to Yes. The RebootOnSuccess statement instructs Dcpromo to reboot the system after it's finished.
Let's look at an answer file that creates a replica DC for bigfirm.biz. I've arranged the script that Listing 2 shows so that you'll recognize the first nine statements from Listing 1's example. ReplicaOrNewDomain has a different value (Replica instead of Domain), which tells Dcpromo to create a new DC in an existing domain. ReplicaDomainDNSName gives Dcpromo the name of the domain in which to add the new DC. But to create a new DC in an existing domain, you need to be a domain administrator, so Dcpromo requires some credentials. UserName, UserDomain, and Password provide the name, domain, and password of a user account that has the authority to create a new DC in an existing domain.
If you're wondering why the SafeModeAdminPassword value (swordfish) in Listing 1 and the Password value (onceuponatimeinalandfaraway) in Listing 2 don't match, recall that the password you use to run DSRM isn't necessarily the same as the password of the default domain administrator account. The DSRM Administrator password resides in a DC's local SAM, and AD's Administrator account resides in AD. (By the way, Dcpromo includes an interesting security feature: If you run Dcpromo from an answer file that contains a password, Dcpromo modifies that file to remove the password.)
The final statement, CriticalReplicationOnly, lets you choose to replicate only the barest piece of the AD database before rebooting. If you use the Yes option with this statement, the new DC gets most of its copy of the AD database upon first boot. Although this statement is necessary for the answer file, I haven't found much use for it. I suspect Microsoft offered this option in Win2K as a way for very large enterprise clients (e.g., HP, Intel, Microsoft) to initially set up a DC without triggering a lengthy replication of a potentially huge AD database. But now that Windows 2003 lets you run Dcpromo from a backup of an entire AD database, I don't see the practical value of this option.
I can't tell you how useful I've found batch files that use Netsh for IP control, Dnscmd for DNS server setup, and Dcpromo answer files for AD setup. Put them all together and you have an amazing setup and disaster-recovery tool that didn't cost you a dime. For more information about scripting Dcpromo, check out the ref.chm file in the Windows 2003 CD-ROM's \Support\Tools folder.