Active Directory
Installation and
Deployment
T
his chapter deploys an Active Directory infrastructure.
Working from the deployment plan blueprint described
in this chapter, you will be able to identify and modify
the elements of the deployment plan that will suite your
configuration. You can make changes as you need, be it a
solution for a small network or a WAN connecting multiple
domain controllers and an extensive Active Directory tree.
Getting Ready to Deploy
This chapter takes you through the actual installation of the
domain controllers for an Active Directory domain. We will be
using our fictitious city, Millennium City (MCITY), as the demo.
So far, we have put several structures into place according to
the blueprint we will discuss next. You may take this blueprint
and deployment plan and use it as a template for your own
project, expanding or cutting and pasting to and from it as you
need, or just use the examples to establish your own strategy.
The text in this chapter is abridged, and a more detailed plan
is available in PDF format on the accompanying CD. If the plan
appears to be a real-life example, that’s because it is. This
Windows 2000 network and namespace have actually been
deployed.
What we espouse here is not the gospel on Active Directory
deployment by any means. It works for our environment,
situation, and the diversity of our demo organization. Smaller
companies may find it too expensive to implement some of
our suggestions; others may garner some deep insight. Our
purpose is to show a rich implementation.

Phase I: Install and Test Root Active Directory Domain.
Phase II: Install and Test Child Active Directory Domains.
Phase III: Create Organizational Units.
Phase IV: Create Groups and Users (Chapter 10).
Phase V: Establish and Implement Security Policy (Chapter 11).
Phase VI: Establish Trusts with Windows NT Domains or Domains
in Other Forests (Chapter 11).
Phase VII: Establish Workplace Management Policy (Chapter 11).
Phases IV, V, VI and VII are not included in the actual plan components discussed in
this chapter; they relate to chapters 10 and 11. After consulting these chapters, and
with practice, you can extend this plan with these latter phases according to your
specific needs.
Executive Summary
The following summary describes the deployment specifics for the GENESIS forest
on the MCITY.ORG and GENESIS.MCITY.ORG namespaces (see the MCITY logical
structure in Chapter 7).
Note
4667-8 ch09.f.qc 5/15/00 2:00 PM Page 292
293
Chapter 9 ✦ Active Directory Installation and Deployment
MCITY Network
The MCITY network (MCITYNET) is managed in the Department of Technology and
Telecommunications (DITT). The backbone at DITT connects to a bank of Cisco 4000
series routers that connect MCITYNET to an ATM backbone. The routers and physical
network are provided by and managed by a major long-distance provider that offers
managed network services (MNS). MCITYNET comprises both the Internet services
required by the city and the private wide area network (WAN) and intranet, known as
the GENESIS network.
DITT connects to the CITYHALL and MCPD over a dedicated IP network, and to
smaller departments over an MNS T1 network. Several locations are connected

will be no user accounts in the domain outside of the core administrators, and
no active workplace management — other than what is needed for security,
domain controller (DC) lockdown, and to protect and administer in this domain —
will be put into place. There are several reasons for the need to establish such
a domain.
First, the root domain in any large organization is a target for e-terrorists. If the root
domain contains many user and computer accounts and a lot of information, the
organization could suffer extensive damages if this domain is destroyed either
physically (removal or destruction of the DC servers) or by a concerted network
attack, or if its data is accessed by unauthorized personnel. Naturally, a small
concern might not need such a “bastion” root domain, but any large enterprise
should seriously consider it.
Second, all MCITY first-, second-, and third-level domains are extensively populated by
user and computer accounts (security principals) and many groups (see Figure 8-7 in
the previous chapter, which identifies the levels on the GENESIS domain tree). There
are also numerous OUs in these domains and thus many administrators at various
levels of the domain’s OU hierarchy. We thus deemed it necessary to establish a root
domain with no more than a handful (preferably no more than five) administrators
who by virtue of having accounts in the root domain would have the widest authority
over the city’s namespace, starting from GENESIS down. (This security policy is
discussed in Chapter 11.)
Third, the root domain is critical to the city. It might be feasible — if Microsoft
makes it possible — in the future to disconnect the root domain from the rest of the
domain tree, and graft the tree to another root. However, at present it is not, and
losing the domain root would result in the loss of the entire domain tree, taking
with it all levels subordinate to the root, in fact everything on the tree. To thus
protect the root domain, we will establish partner DCs of the root domain at several
remote locations, primarily for redundancy and to locate the root domain over a
wide area. These locations will initially be as follows (see Figure 8-7 in Chapter 8):
✦ Location 1: DITT’s Network Operations Center (NOC)

are nearby.
✦ Reliable query results. Strong and closely located GCs should facilitate rich
queries, and users must be able to rely on the currency of the data. They must
be able to obtain information on users, groups, and other network services
without any interruption in services or lack of data.
Network specifics of GENESIS
The GENESIS domain will be established on a segment of the physical network on
which the Department of Technology and Telecommunications (DITT) currently
runs. This network currently is supported on a 100Mbps backbone on which the DITT
supports its AS/400, UNIX, and Windows NT systems. GENESIS will be established
on the same network, but on its own IP subnet. This IP address space is a network
supported by Windows 2000 routing services. It can also be supported behind
network address translation services (NAT) running on a Windows 2000 role server.
See Chapter 15 for a discussion of Routing and Remote Access (RRAS) and
Chapter 12 for a discussion of Network Address Translation.
Note
4667-8 ch09.f.qc 5/15/00 2:00 PM Page 295
296
Part III ✦ Active Directory Services
GENESIS site object specifics
In order to support replication to and from other MCITY domains (inter-site) and
between domain controllers belonging to the same domain (intra-site), an Active
Directory site will support GENESIS. This site will be named GEN-ST00-JKIJS09K87, as
illustrated in Figure 8-7 and Table 9-1. The following DC names have been reserved
for this site: MCDC00.GENESIS.MCITY.ORG to MCDC09.GENESIS.MCITY.ORG MCDC50.
The NetBIOS name range of these DCs is MCDC00 to MCDC09.
GENESIS subnet object specifics
The subnet address 100.10.0.0 will be assigned to a subnet object. This subnet
object will be associated with the GENESIS site object described previously.
Domain health and security

support CITYHALL. The main site will be named CH-ST00-J98KIJD654. The following
DC names have been reserved for this site: MCDC10.CITYHALL.GENESIS.MCITY.ORG
to MCDC50.CITYHALL.GENESIS.MCITY.ORG. The NetBIOS name range of these DCs is
MCDC10 to MCDC50.
CITYHALL subnet object specifics
The subnet address 100.45.0.0 will be assigned to a subnet object. This subnet
object will be associated with the CITYHALL site (CH-ST00- J98KIJD654) object
described previously.
Domain health and security
At least three partner or peer DCs will support the CITYHALL domain in the main
DC site. We have decided to locate one DC in the secure server room of the floor on
which the Mayor’s office is located. The remaining two DCs will be located in the
main server room in City Hall’s network operations center (NOC). The DCs will also
house copies of the GCs for the entire MCITY Active Directory namespace.
The administrators in the CITYHALL domain will have administrative authority
over the resources only in the CITYHALL domain. Some administrators in
CITYHALL are also administrators of the GENESIS domain.
The DITT Domain
The DITT domain contains the resources for the Department of Information
Technology and Telecommunications. There will be several hundred user and
computer accounts in this domain. This domain will support the accounts and
network resources for the IT staff and consultants, and the various departments,
that fall directly under DITT.
Network specifics of DITT
The DITT domain is to be established on the network segment 100.50.0.0. See
Table 9-1 for the configuration specifics of DITT.
The MCPD Domain
The MCPD domain contains the resources for the Millennium City Police
Department. According to the configuration, a large number of IP addresses are
required for this network. The IP address range in the DHCP scope will support

6. Build initial OUs
7. Delegate OU administration
8. Secure DC further and follow disaster recovery protocol
Install the DC Machine
Follow the procedures described in Chapter 5 or Appendix B for installing Windows
2000 Server. Ensure the machine is stable. The best way to do this is to keep it
running for about two weeks. You can use Backup/Restore as discussed in Chapter
5 to “burn in” the machine. After several DCs are all built or acquired on the same
Note
4667-8 ch09.f.qc 5/15/00 2:00 PM Page 298
299
Chapter 9 ✦ Active Directory Installation and Deployment
hardware configuration, you might consider reducing the burn-in period to several
days instead of two weeks. If your machine is still running under load after several
weeks, consecutive machines configured on identical hardware will likely run
without problems. But a few days of tests are required to be certain.
You do not need to go to the additional expense of using Advanced Server for a
domain controller. All Windows 2000 Servers can be promoted to a domain
controller. Providing a fail-over service or a cluster for Active Directory is also a
waste of resources and money. A fully redundant server will not only be cheaper,
it will make for a more secure Active Directory deployment.
Server name
Pick a name for your machine from the list provided in the deployment plan. This is
the NetBIOS name you will use to construct your DNS name. This name is going to
be used again when you promote your server to a domain controller. We used the
name MCDC00 for the standalone machine that became the root DC for GENESIS.
When we promoted this machine, we reassigned this name and DNS resolved this
machine as MCDC00.GENESIS.MCITY.ORG. In the case of CITYHALL, the server
name reserved for the first DC in this domain is MCDC10. Its DNS name will thus be
MCDC10.CITYHALL.GENESIS.MCITY.ORG. Remember, in the case of CITYHALL, it is

Leave as many services out of the installation as possible. It is worth repeating here
that it is better to first get a bare-bones machine running before adding additional
services. However, there is one exception, as described next.
Choose a Terminal Services mode
There is one service that we deem to be the most important, and that is Terminal
Services (TS). You will have to select TS from the Windows Components dialog box.
You do not have to select licensing as well; that is only for application server servers.
While choosing services, you will also be asked to choose the mode for TS, so select
Remote Administration mode. This will allow you to attach to the machine remotely
when it is installed in the new location. The machine can be promoted from the
remote location or in the lab, but you should also provide a means to administer it
remotely. This is demonstrated shortly. Remote Administration mode, as discussed in
Chapter 25, allows up to two concurrent sessions to be used for remote administra-
tion without licensing.
Promote to Domain Controller
The steps we take you through in this section demonstrate installing a root domain
and a child domain into an existing domain tree. You would perform these same
steps to install Active Directory for any new domain controller. The only difference
is that you need to choose to create a domain controller according to the choices
outlined in Table 9-2. If you are not sure what you need to be installing, you need to
do some more preparation and planning. Read the fine print on the dialog boxes
until you are sure about your actions, but do not overly concern yourself until the
last step because you can always go backwards and forwards in these dialog boxes
until you are sure.
Table 9-2
Domain Controller Promotion Choices
Action GENESIS CITYHALL DITT MCPD
DC for a Yes Yes Yes Yes
new domain
Additional DC for Yes, at any Yes, at any Yes, at any Yes, at any

to promote it remotely, nor will it be able to join the domain tree. We will now begin
the promotion of the DCs and the creation of child domains. You will need to take
the following steps to complete the promotion:
1. Promote the server using the command DCPROMO or using the Configure
Your Server utility. You can use the DCPROMO command from the command
prompt, which is quicker and easier if you plan to promote many servers.
The Configure utility is illustrated in Figure 9-1. To open the utility, click
Start ➪ Programs ➪Administrative Tools ➪ Configure Your Server.
2. In the Configure Your Server utility, select the Active Directory item in the menu
on the left of the dialog box to switch to the Active Directory page. Scroll down
and click the hyperlink “Start the Active Directory Wizard.” When the Wizard
loads, continue by clicking the Next button.
3. The Domain Controller Type dialog box loads, as shown in Figure 9-2. Make
sure to check the option “Domain controller for a new domain.” This is the
first DC for the domain GENESIS or CITYHALL or any other new domain. The
creation of the root domain from here on is a no-brainer. Without an existing
forest or domain tree, you cannot install anything else. So, we will now
proceed to install a child domain . . . CITYHALL. Click Next.
4667-8 ch09.f.qc 5/15/00 2:00 PM Page 301