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
- July 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
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
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
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
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
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
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
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
|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
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
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.