Even if you lack a Windows 2000 lab, you can still map out the process of directory service installation.

Active Directory Install, Step by Step

Even if you lack a Windows 2000 lab, you can still map out the process of directory service installation.

• By Michael Chacon
• 07/01/2000

I’ve covered quite a few abstract directory service issues in previous columns while waiting for the final arrival of Windows 2000. I’ve talked about how you should consolidate your current NT domains with an eye toward mirroring your existing DNS domains, and about making sure your hardware CPU, memory, and peripheral compatibility is up to snuff. Now that, according to Microsoft, over a million and a half copies of Win2K have shipped, it’s time to go into the specifics of preparing, installing, and managing the Active Directory. As you know, AD is really the heart of Win2K.

Name Resolution Revolution

But before you slap that CD into the drive and run dcpromo.exe, take a step back to the whiteboard and think through a few of the following issues. First and foremost is how your DNS and DHCP services are going to affect your Active Directory test environment, let alone an actual implementation in a production environment. I know we’ve talked about the symbiotic relationship of DNS and Active Directory in the past, but you need to make some final decisions before you install AD. Are you going to use Microsoft’s DNS or another vendor’s version of DNS? Are you going to use DHCP to allocate your address space? Before you make those decisions—both of which may be largely political—let’s briefly review the roles DNS and DHCP play in the Win2K environment.

When an Active Directory Domain Controller is created in a fully functional Win2K environment, the DC contacts its DNS server and creates a Service (SRV) record to list its IP address. That’s so clients can locate the DC when necessary. When a Win2K dynamic client initializes its IP stack, it obtains its IP address and other configuration information, such as the DNS IP address, from the DHCP server. A static client, on the other hand, has this information recorded in the registry; it’s available on initialization.

Regardless of whether the client is dynamic or static, it registers itself with the DNS server by creating an Address record. Then the client looks in the DNS for an Active Directory Domain Controller. When the client receives the IP address of the DC, it sends its request for authentication to the DC, and all is well with the world. (For more details, see my column titled "DNS Dichotomy” in the January 1999 issue.)

If this sounds familiar, it should, because the behavior is similar to WINS. The difference, beyond the protocols and backend services, is that you’re now participating in a resolution service routinely used by systems that don’t care about Windows 2000—or any other Windows for that matter. With WINS, you had to worry about the Windows environment only; if you caused a problem, it affected the Windows environment alone. Now, messing up the name resolution process can cause problems for the entire enterprise, so you can’t simply go forward without settling the DNS issue.

You have three choices, one of which is the most likely scenario. You can go 100 percent Microsoft and use the DNS that comes with Win2K, making life simple. However, most shops have an existing DNS, which isn’t something anyone will replace in the near future. Another option is for Win2K to rely completely on the existing DNS service. This is also unlikely, since most DNS systems today don’t support the dynamic updates that Win2K relies upon to record and update SRV and Address records so other clients can find them.

An existing or non-Microsoft DNS will work fine so long as it’s BIND version 8.1.2 or later, which supports the SRV records and the dynamic updates necessary for Win2K functionality. A traditional static DNS will work; but thinking that you can update DNS records manually—even for servers alone—is unrealistic and the process is prone to error. To update Address records for clients is essentially impossible.

This, of course, leaves the hybrid model as the most likely scenario for your Win2K environment. In this scenario you use the existing DNS as the authority for the entire enterprise; it sub-delegates zones that the Win2K DNS is authoritative for; clients can use it for a domain controller and other services can use it for name resolution. For name resolution beyond the Win2K world, such as Internet browsing, requests can be forwarded to the enterprise DNS servers in your environment. Regardless of the option that you choose, there must be cooperation, however contentious, in order for the entire name resolution to perform properly.

To fully appreciate the DNS role in your new Win2K environment, I highly recommend that you first install AD in a pure test environment, without any production involvement. Once you get everything working properly in this test environment and are comfortable with the DNS role, you can then make realistic decisions regarding how to proceed with DNS. With that in mind, I also recommend that you start your Win2K testing with the Microsoft DNS. Let the operating system install and configure the initial DNS as you create your first Active Directory Domain Controller.

Choosing a Domain Name

We’re almost ready to load that first CD, but what are you going to use for a domain name? Since the machines involved will exist in their own little world for now and won’t need to browse the Internet yet, choose whatever you prefer. Just remember that you’re probably going to tear down this entire environment; don’t get too ambitious and create something that you’ll need in the future. If you have the extra machines handy, I advise you to create a couple of domains so you can learn how updates are transferred, permissions are determined, and AD queries are resolved across domains. And if you can manage it, I would also throw at least a multi-homed machine into the mix, if not real routers, so you can test replication and other issues in a simulated multi-geographical location. The adage remains true: The pocket you don’t check is the one with the hole in it.

Now that we’ve decided on the easy way out—to use the automatically installed Win2K DNS—we’re almost ready to go with dcpromo.exe. One last thing to check is the file system you’re using. Yes, Active Directory requires NTFS 2000—oops, that’s NTFS 5.x. If you’re not sure, you can check by going to Programs | Administrative Tools | Computer Management and selecting the Disk Management object, which brings up the information shown in Step 1.

Step 1. Before you install Active Directory, make sure your system is running NTFS 5.x. (Click image to view larger version.)

If you don’t see NTFS under the File System heading, then you’ll have to convert the current File System to NTFS, using the old tried-and-true convert.exe with the appropriate switches:

C:\>convert c: /fs:ntfs

At Last! AD Installation

There are two roads to beginning the Active Directory installation process. One choice is to go through the menu, following Programs | Administrative Tools | Configure Your Server. You then choose the Active Directory option on the left side of the screen (see Step 2).

Step 2. One route to Active Directory installation takes you through the menus, landing you at the Active Directory Installation Wizard.

This is useful at first because it provides background information that explains the various options available. To get the installation running, select the install option at the bottom of this screen.

The second method is simply to type “dcpromo” at the command line to bring up the installation wizard. Regardless of the method you use, press the Next button to reach your first decision in the installation process as shown in Step 3.

Step 3. At this point you can add another DC to an existing domain or create a new domain.

This screen presents the option to add another DC to an existing domain or to create a completely new domain. When you create a new domain, any existing local accounts will be incorporated into the directory intact. If you create an additional domain, be aware that any existing local accounts will be removed, since the new DC will bring over any accounts from the other DCs. Since this is the beginning of our test network, there are no other DCs from an existing domain. Therefore, you’d select the radio button for a domain controller for a new domain and press Next.

The next screen gives you the option to either create a new child domain of an existing domain, such as business.newman.com, or to create a new domain tree—such as newman.com—and start a new tree, which is what we want to do here. The Next button brings you to the Create or Join Forest decision shown in Step 5. These domain names should follow your DNS namespace decision.

Step 4. Now you can create a new child domain of an existing domain (business.newman.com) or create a new domain tree (newman.com).

Step 5. Next, you designate whether the new tree you've started should be placed in an existing forest or become the start of a new forest.

For now, we’re going to create a new forest because we’re building an isolated Win2K environment. In an existing environment, this has big implications in terms of the global catalog and schema. To share the schema and global catalog, all domains must exist within the same forest. Press Next to bring up the screen in Step 6.

Step 6. Now you name the new domain, which will be entered into the DNS, which maps to the DC name.

This screen--where you specify what to call the new domain—-sets the name that’s going to be entered in the DNS, which maps to the DC name. I’ve entered adlab.org; since I haven’t installed a DNS server yet, this name will be used during that process. In addition, as shown in the next step (Step 7), the first portion of the domain name—or at least the first 15 characters—is also used as the NetBIOS domain name used for a mixed node DC, which will support down-level clients.

Step 7. The first part of the domain name will be used as the NetBIOS domain name in a mixed-mode DC, to support down-level clients.

The next screen allows you to choose the Database and Log locations. As with any transaction-type database, it’s best practice to keep the logs on a different physical drive than the database—for both performance and recovery purposes. These files can reside on any partition type supported by Win2K.

Step 8. Next, designate the location of the database and logs for AD. Best practice: Keep them on separate physical drives.

The next screen is the shared system volume. This is a shared area replicated to all the other domain controllers created in the same domain. You can change the path but it must reside on an NTFS 5.x partition.

Step 9. The wizard looks for the DNS--currently conStepd--in the IP stack on this machine for support of dynamic updates. (Click image to view larger version.)

When you press the Next button, the wizard looks for the DNS—currently conStepd—in the IP stack on this machine to see if it supports dynamic updates.

Since no DNS is available, you can choose to install a DNS server or have the Active Directory installation wizard do it for you, as shown in Step 10.

Step 10. Now it's time to install a DNS server yourself or have the wizard do it for you.

Since we’re going to use the automated DNS installation, we select the Yes radio button and move on to Step 11.

Step 11. Next, you designate permissions on user and group objects. If you're using a mixed-mode DC, you can set them to be compatible with previous versions of NT.

The installation process needs to set permission on user and group objects. This gives you the option to create permissions that are compatible with previous versions of NT for use in a mixed-node DC. While this allows other NetBIOS connections to the DC, it also has the same security problem that anonymous connections caused with previous versions of Windows NT.

The next screen (Step 12) asks you to enter the password for the default administrator account, which, of course, you need in order to log into the DC. The password is also used for the Directory Services Restore mode, a special startup option that allows you to work with the directory service files. Since they’re opened exclusively when the server is in operation, this screen allows you to configure a password to be used when an administrator needs off-line directory database access on this server.

Step 12. In order to gain access to the Directory Services Restore mode, which provides off-line access to the directory database, you set an Administrator password at this stage.

The Next button finally brings you to the Summary screen. Here, you can to go back and make any corrections to the configuration information that will be used for the installation process.

This is your last chance to verify the series of decisions you’ve made. If you hit Cancel, nothing happens and you’ll be right back where you started. When you’ve reviewed the options, click Next and the configuration process begins. You’ll get a screen that warns you about potential delays, depending on the options you’ve selected.

Step 13. In the Summary screen, you get a chance to check over your choices and return to modify them.

This portion of the installation can take a long time. When it’s done, you get the penultimate screen shown in Step 14. (Because, of course, what would Windows be without the ubiquitous reboot option?)

Step 14. The last of your wizard installation steps: click Finish.

Step 15. Of course, what's Windows without a final reboot?

A Look at the Files

After the installation is complete and you’ve rebooted the machine, you might want to take a look at where the Active Directory files are located on the machine, as shown in Step 16.

Step 16. Take a quick tour of drives C and D to see the Active Directory files you've just loaded. (Click images to view larger version.)

As you can see, the log files are on the D: drive and the actual NTDS.DIT, which contains the Directory Information Tree, is on the C: drive in this installation. EDB.CHK is a checkpoint file that points to the location of the last committed checkpoint in the log file. The EDB.LOG file is always the name of the current log file and is for the NTDS.DIT transactions. RES1.LOG and RES2.LOG are reserve log files used only when the drive containing the log files is full. Note that each log file is always 10M in size.

With the installation complete, the next step is to verify that the system works properly and to take some time to explore your new environment. Since I used up so much space with screen shots, we’ll take that step next month.