realtimepublishers.

com

tm

Tips and Tricks Guide To

tm

Windows 2000
and Active Directory
Administration

TM

Don Jones
Sean Daily

Chapter 1
Chapter 1: Daily Administration ..................................................................................................... 3
Q 1.1: I just created a new group, and both the new group and the organizational unit I put in the
new group are gone! What should I do? ......................................................................................... 3
Q 1.2: I tried to install an application that needs to modify the Active Directory schema, but the
installation failed. What should I do?.............................................................................................. 4
Q 1.3: How can I write a logon script that checks for group membership?.................................... 6
Programming the Script ...................................................................................................... 7
Assigning the Logon Script................................................................................................. 8
Chapter 2: Domain Controller Administration.............................................................................. 11
Q 2.1: Where should I place Global Catalog servers, and how many do I need? ......................... 11
Deciding Where to Place GC Servers ............................................................................... 11
Making a GC Server.......................................................................................................... 12
Q 2.2: Where do I put FSMOs?..................................................................................................... 13
Deciding Where to Place FSMOs ..................................................................................... 14
Transferring FSMOs ......................................................................................................... 15
Transferring the RID Master, PDC Emulator, or Infrastructure Master ............... 15
Transferring the Domain-Naming Master............................................................. 16
Transferring the Schema Master ........................................................................... 16
Q 2.3: How do I handle a FSMO failure? ..................................................................................... 17
What to Do When a FSMO Fails ...................................................................................... 18
Seizing FSMOs ................................................................................................................. 18
Q 2.4: How can I tell whether I need to add a domain controller? ............................................... 19
Installing the Database Object........................................................................................... 21
Domain Controller Performance Tips ............................................................................... 22
Q 2.5: How many domain controllers do I need for optimum performance? ............................... 23
Q 2.6: I want to make sure that my users can always log on. Doesnt that mean placing a domain
controller in every location that has users? ................................................................................... 26
A History of Domain Controller Placement...................................................................... 27
How Windows 2000 Learned from History...................................................................... 27
Q 2.7: We use Exchange 2000 Server, and users complain that Address Book lookups take too
long. The Exchange server looks fine. What can I do?................................................................. 29
Lookups with Earlier Clients............................................................................................. 29
Lookups with Later Clients ............................................................................................... 29
Chapter 3: Replication Management............................................................................................. 31

Chapter 1
Q 3.1: After I make a change in Active Directory, the change doesnt seem to take effect for
quite a while. What can I do to make this process faster? ............................................................ 31
Faster Replication.............................................................................................................. 32
Making Changes Close to Home....................................................................................... 34
Chapter 4: Security Administration............................................................................................... 36
Q 4.1: I want to distribute the management of the users and groups in my Active Directory.
Whats the best way to proceed?................................................................................................... 36
With a well-designed OU hierarchy, careful use of the Delegation of Control Wizard, and
occasional checkups on your OUs permissions, you can safely delegate a variety of AD
administrative tasks to the users in your organization. ................................................................. 39
Chapter 5: Disaster Recovery........................................................................................................ 40
Q 5.1: How can I prepare for Active Directory disaster recovery?............................................... 40
Dont Put All Your Eggs in One Basket ........................................................................... 40
Backup and Restore........................................................................................................... 42
Non-Authoritative Restore .................................................................................... 43
Authoritative Restore ............................................................................................ 43
Testing Your Backups........................................................................................... 44
Chapter 6: Tools and Utilities ....................................................................................................... 45
Q 6.1: How can I automate the process of adding users? ............................................................. 45
The ADDUSERS Script .................................................................................................... 45
The ADDUSERS Spreadsheet .......................................................................................... 48
Chapter 7: Migration ..................................................................................................................... 49
Q 7.1: I need to decide on a name for my new Active Directory domain. What name should I
use?................................................................................................................................................ 49
You Have an Internet Domain Name Hosted by Your Internet Service Provider ............ 49
Examine Your Current Situation........................................................................... 49
Decide What to Do................................................................................................ 50
You Already Have an Internet Domain Name That You Host ......................................... 52
You Dont Have a Domain Name Registered on the Internet........................................... 53
Q 7.2: Should I perform an upgrade or a migration? .................................................................... 53
SID History and Migration Problems................................................................................ 54
Migrating: Tons of Work .................................................................................................. 54
Upgrades Make Things Easier .......................................................................................... 55
Up-to-Date Best Practices ................................................................................................. 55
Copyright Statement...................................................................................................................... 57
2

Chapter 1

Chapter 1: Daily Administration

Q 1.1: I just created a new group, and both the new group and the
organizational unit I put in the new group are gone! What should I do?
A: Youve stumbled across one of the unavoidable problems of a multimaster directory
environment. As youre aware, any administrator can modify Active Directory (AD) by
connecting to any domain controller in a domain. AD replicates changes to all domain
controllers so that, eventually, they all contain the changes the administrator made. The key
word, of course, is eventually.
Two administrators could possibly connect to two different domain controllers and make
conflicting changes at the same time. When those changes involve the same objectfor
example, both administrators reset a specific users password at the same timeAD keeps the
change that occurred last. If they occurred at precisely the same time, AD picks one change to
keep.
That type of situation is confusing but fairly rare. More common are changes made to two
different dependent objects. For example, imagine that your domain contains an organizational
unit (OU) named Houston. Bob, an administrator in Houston, connects to a Houston-based
domain controller and creates a user group named HoustonAdmins. A few minutes earlier,
however, Jerry, an administrator in New York, connected to a New York-based domain
controller and deleted the Houston OU entirely. When AD replicates these two changes, they
conflict. Suddenly, AD has to create a group named HoustonAdmins in an OU that no longer
exists. The same scenario can happen with newly created user accounts: The target domain was
deleted on another domain controller, but the changes have not yet replicated completely to all
domain controllers.
You can configure replication between sites to wait quite a long time before replicatingas long as
several hours. While a longer replication interval will reduce the amount of replication traffic on your
network, it will also increase the possibility of replication conflicts because administrators at one site
will have more time to make changes that might conflict with changes youre making at another site.

AD could respond by not creating the group. This solution isnt great, though, because you might
be relying on the groupafter all, the administrator who deleted the OU didnt know the group
existed at the time. The situations even worse with user accounts because users access depends
on the existence of their accounts. So AD responds by creating the user or group in the
LostAndFound container, a special OU-like folder within AD. You can view the contents of the
LostAndFound container by using the Microsoft Management Console (MMC) Active Directory
Users and Computers snap-in, which Figure 1.1 shows.

Chapter 1

Figure 1.1: The LostAndFound container in AD.

Once you locate the user or group in LostAndFound, you can restore it to another OU by rightclicking it, then selecting Move from the resulting pop-up menu.
LostAndFound isnt a Recycle Bin! LostAndFound will not protect you from accidentally deleting an
object. For example, when you delete an OU, all the objects within that OUusers, groups, and other
OUsare lost forever. Instead, LostAndFound acts as a repository for objects whose containers (that
is, OUs) were deleted as the object was being created.

Q 1.2: I tried to install an application that needs to modify the Active

Directory schema, but the installation failed. What should I do?
A: First, make darn sure that you really want to modify the Active Directory (AD) schema.
Modifying the schema can have some serious consequences:

All Global Catalog (GC) servers in your forest will completely rebuild their catalogs.

Schema changes are forest-wide, so your changes will replicate to every other domain
within the trust boundaries of your forest.

Schema changes are irreversible. If you decide to uninstall the application later, its
schema changes cant be removed.

Chapter 1

Make a backup! Before you even consider modifying the schema in your production domain, make a
complete backup of AD. That way youll be able to perform an authoritative restore, which I discuss in
Question 5.1 in Chapter 5, to undo the schema changes if necessary. Also, make sure that no other
administrators attempt to modify any AD objects while youre modifying the schema. That way if you
have to restore AD to undo the schema changes, no object changes will be lost.

In a large AD environment, just rebuilding the GC servers catalogs can take hours and a great
deal of network bandwidth. Try to plan schema changes for hours when the GCs arent urgently
needed for user logons and Exchange 2000 Server clients, such as late at night. And always
remember that schema changes are permanent across your entire forest.
Use a pilot domain to make sure that you want to make the changes. If you need to test an
application, and the application will modify your AD schema, install the application into a standalone
test domain. That test domain shouldnt have any trust relationships with any other domains. The test
domain allows the application to modify the schema without permanently affecting your production
domains schema.
If you decide to keep the application, you can install it in your production domain when youre ready to
begin using it. Either way, you can decommission the test domain once youre done testing the
application.

If youre sure that you want to modify your schema, several things have to be in place first:

The forests schema master must be online. The schema master is a special Flexible
Single Master Operations (FSMO) role held by one of the domain controllers in your
domain. As Figure 1.2 illustrates, you can use the Microsoft Management Console
(MMC) Active Directory Schema snap-in to determine which server currently has the
schema master role.

Figure 1.2: Identifying the current schema master.

Chapter 1

Cant find the schema master? If the designated schema master isnt available, you can seize the
schema master role on another domain controller. See Question 2.1 and 2.2 of Chapter 2 for
information about seizing FSMO roles. Be aware that the old schema master should never be
returned to the network after its role has been seizeddoing so could corrupt your AD schema.

The forest must be placed into schema-write mode. Only members of the Enterprise
Admins group can make this change. To make the schema writable, use the Active
Directory Schema snap-in. Right-click the Active Directory Schema item, and select
Operations Masters from the pop-up menu. In the resulting dialog box, select The Schema
may be modified in this Domain Controller check box, which Figure 1.2 shows.

Once the schema is in write mode, only members of the Enterprise Admins group are
actually allowed to change it. That means youll need to run your applications setup
program while youre logged on as a member of the Enterprise Admins group.

Protect your Enterprise Admins. Because Enterprise Admins have complete control over the AD
schema and over every domain in a forest, you should ensure that members of the group use difficultto-guess passwords. Never allow an application to use a member of the Enterprise Admins group as
a service account unless youre absolutely certain that the application requires such powerful
credentials to work properly. Finally, never allow any user (even yourself) to use an Enterprise
Admins account for day-to-day work. You should only log on as an Enterprise Admins member when
you need to accomplish some forest-wide administrative task, such as modifying the AD schema.

Once youve finished installing the application and modifying the schema, put the schema into
read-only mode by clearing The Schema may be modified in this Domain Controller check box
in the Active Directory Schema snap-in. That check box serves as a kind of master safety switch,
preventing even Enterprise Admins from changing the schema when the check box is clear.

Q 1.3: How can I write a logon script that checks for group
membership?
A: Active Directory (AD) offers wonderful new flexibility for logonand logoffscripts
because the scripts can be written in powerful languages such as JScript and VBScript.
Unfortunately, most administrators still use command-line scripts (batch files) because Microsoft
hasnt released much documentation about how to really use scripting in logon scripts.
Microsoft has complete references for its scripting languages at http://www.microsoft.com/scripting.
However, you may still need to hunt around for ways to perform common logon script tasks, such as
mapping drives. A good place to start is Microsofts Platform Software Development Kit (SDK)
documentation, available online at http://msdn.microsoft.com/library.

Common tasks such as checking for group membership are pretty easy. To do so, youll need to
first set up a VBScript logon script, and second, add that script to a Group Policy.

Chapter 1

Programming the Script

VBScript allows you to use the Active Directory Service Interfaces (ADSI) to query information
from domain directories. ADSI is included with Windows 2000 (Win2K) and includes providers
that allow you to access both Windows NT domains and AD domains. The AD provider actually
uses the Lightweight Directory Access Protocol (LDAP) to access information in AD. The
following VBScript, which Listing 1 shows, will determine the users username, look up that
user account in AD, then determine whether the user is a member of a group named
OfficeAdmins.
This script makes some assumptions about your domain. To use this script in your environment, youll
need to customize it. First, change the domain name to match your own. Next, youll need to make
sure that the groups that the script refers to exist in your domain or the script will generate an error.
Either create the groups before running this script, or modify the script to use group names that
already exist in your domain.
' create a network object
dim objNetwork
set objNetwork = WScript.CreateObject("WScript.Network")
' determine the users ID
dim strUser
strUser = objNetwork.UserName
' get a reference to the domain group
set objGroup = GetObject("LDAP://Domain/OfficeAdmins,group")
' determine if user is a member of group
varMember = objGroup.IsMember("LDAP://Domain/" & strUser & ",user")
take action based on group membership
If varMember = 0 Then
is not a member
Else
is a member
End If
Listing 1.1: Example VBScript to determine if a user belongs to a user group.

The following steps walk you through the scripts process:

1. The script creates a reference to the Windows Script Hosts (WSHs) Network object,

which exposes information about the users network environment. The reference is saved
in a variable named objNetwork.
2. The script saves the users ID in a variable named strUser. The ID is obtained from the

Network object.
3. The script uses ADSIs LDAP provider to get a reference to the OfficeAdmins group.

The reference is saved in the objGroup variable. Note that the GetObject command is
used with ADSI calls rather than the CreateObject command normally used to create
object references.

Chapter 1
4. The script uses the groups IsMember method, passing an ADSI reference to the users

user account in AD. The IsMember method returns either a zero or a one, which is stored
in the varMember variable.
5. Finally, an IfThen construct is used to take some action based on whether the user is a

member of the OfficeAdmins group. You can replace the comment lines in the IfThen
construct with code that maps drives, maps printers, or takes some other action.
Learn more about ADSI scripting. Microsoft publishes the ADSI documentation in the Microsoft
Platform SDK. As I previously mentioned, you can access the SDKs documentation online at
http://msdn.microsoft.com/library. Look under Microsoft Platform SDK, then under Directory Services.

Save your script to a text file, then youll be able to use Group Policy to assign the script to users
and computers.
Use the correct file extension! Windows will automatically recognize your script if you use the correct
file extension: .VBS for VBScript files and .JS for JScript files.

Be careful about double-clicking! If you double-click .VBS and .JS files, they will run automatically and
can potentially do almost anything on your system. Never run a script file unless you look at it first
and determine what it does. You can look at a script in Notepad by right-clicking the file, and selecting
Edit from the pop-up menu.

Assigning the Logon Script

You use Group Policy to assign logon scripts to domains, organizational units (OUs), and sites.
To create a new Group Policy that includes a logon script, follow these steps:
1. Launch the Microsoft Management Console (MMC) Active Directory Users and

Computers snap-in.
2. Right-click the OU or domain to which you want to apply the policy, and select

Properties from the pop-up menu.

3. On the Group Policy tab, click New.
4. Type a name for the new policy, and press Enter.
5. Select the new policy, and click Edit.
6. Windows displays the Group Policy window, which Figure 1.3 illustrates. To locate the

Script (Logon/Logoff) section, expand the Windows Settings folder under User
Configuration.

Chapter 1

Figure 1.3: The Group Policy window.

You can use the appropriate configuration section of a Group Policy to assign logon and logoff scripts
to both users and computers. Windows processes computer logon scripts when the computer starts,
then processes user logon scripts when a user actually logs on to the computer. Logoff scripts are
processed in reverse order: User logon scripts are processed first when the user logs off, and
computer logon scripts are processed last, just before the computer shuts down.
Computer scripts must run without a graphical user interface (GUI) because no user is logged on
when the computer scripts execute.
7. In the right pane of the Group Policy window, double-click Logon or Logoff. Windows

will then display the properties for the item you selected, as Figure 1.4 shows.

Chapter 1

Figure 1.4: Logon Script properties.

8. Click Add to add a new script.

9. Click Browse to locate your scripts text file, select the file, then click OK.
Multiple scripts can be used! Unlike earlier versions of Windows, Win2K lets you assign multiple
logon and logoff scripts to users and computers. Windows will execute all the scripts at the
appropriate time. Use the Up and Down buttons on the dialog box to place the scripts into the order in
which you want them to execute.
10. Click OK to save the new Group Policy.
Logon and logoff scripts are for Win2K and later only. AD-based logon and logoff scripts work only on
Win2K and later client computers. Earlier OS computers dont have the ability to load the scripts out
of AD and execute them. If your network contains earlier client computers, youll have to provide
logon scripts that are compatible with them.

10

Chapter 2

Chapter 2: Domain Controller Administration

Q 2.1: Where should I place Global Catalog servers, and how many do
I need?
A: To answer these questions, take a moment to review what Global Catalog (GC) servers are
used for:

If youre using Microsoft Exchange 2000 Server or later, GC servers provide address
book lookups and email address resolution to your Outlook 98 Service Release 2 (SR2)
and later email clients. Older email clients use an Exchange Server for this function, but
that Exchange Server needs access to the GC server rather than the email clients needing
access.

GC servers are also used by Active Directory (AD) clients who need to look up
information about AD objects in other domains. For example, if a server needs to look up
the membership of another domains global group, the server uses the GC to locate a
domain controller in the other domain.

GC servers contain the membership list of all universal security groups and are used by
servers and clients who need to check the membership of a universal security group.
Remember, universal security groups can be used only in a native-mode domain.

AD clients use GC servers when the clients log on, to build a list of groups that the client
is a member of. This feature is used only in a multi-domain environment, in which a user
can be a member of groups in more than one domain.

Understanding how GC servers are used on your network helps you narrow down how many you
need and where they should be placed. You also have to understand the negative impact
additional GC servers can have on your network. GC servers contain a subset of the AD
information for an entire forest. That means GC servers must replicate with one another
throughout a forest. AD automatically configures the GC replication topology based on your AD
site information, but a large number of GC servers on a network can introduce a great deal of
additional network traffic, especially when a large number of changes are made to the
information a GC contains (such as user names, email addresses, and so forth).
Deciding Where to Place GC Servers
You can follow these general rules to determine where to place GC servers on your network:

If you have one only domain and arent using Exchange 2000 Server or later, you dont
usually need any additional GC servers. Thats because clients dont use a GC to look up
information in their own domainthey use a domain controller instead.

Avoid having the domain controller holding the infrastructure master role also act as a
GC server. The Infrastructure Master cant operate on a server that hosts the GC. If all
your domain controllers host the GC, you dont need the Infrastructure Master because
the domain infrastructure information is included in the GC.

11

Chapter 2

If you have Exchange 2000 Server, place a GC server in each site that contains more than
a handful of users. In larger sites, you may want to place two GC servers to provide some
load balancing and fault tolerance.

In a multiple-domain environment that isnt using Exchange 2000 Server, dont place
more than one GC per site. Users will need to access a GC server when they log on to
build a complete list of groups the user is a member of. Smaller sites can do without their
own GC server if they have great Wide Area Network (WAN) connectivity to a site that
has a GC server (great usually means T1 or better).

Making a GC Server
Any domain controller can act as a GC server, although only the first domain controller in a new
domain will act as a GC server by default. You can use AD Sites and Services to tell a domain
controller to act as a GC server:
1. Connect AD Sites and Services to the domain that contains the domain controllers you

want to work with.

2. Click on the site container that contains the domain controller you want to work with, and

expand the Servers folder to display a list of servers in the site.

3. Expand the domain controller to display the NTDS Settings item, as Figure 2.1 shows.

Figure 2.1: Working with AD Sites and Services.

12

Chapter 2
4. Right-click NTDS Settings, and select Properties from the pop-up menu. Windows will

display the NTDS Settings Properties dialog box, which Figure 2.2 shows.

Figure 2.2: The NTDS Settings Properties dialog box.

5. Select the Global Catalog check box to make the domain controller a GC server; clear the

check box to make the domain controller stop acting as a GC server.

Adding a new GC server can be time consuming! In a large forest or domain tree, the GC can contain
a lot of information. Telling a domain controller to start acting as a GC server requires that domain
controller to replicate the entire forestwide GC, which can take quite a bit of time. For example,
replicating the GC in a single domain with about 10,000 objects can take as long as half an hour.

Q 2.2: Where do I put FSMOs?

A: FSMO stands for Flexible Single Master Operations and is pronounced fiz-mo. FSMOs are
tasks performed by specific domain controllers within a domain or forest. Unlike normal Active
Directory (AD) operations, which are performed by all domain controllers in a domain, only one
domain controller performs the special FSMO tasks. The FSMO tasks, or roles, are

13

Chapter 2

The schema master is responsible for handling all changes to the AD schema. Only one
domain controller in a forest acts as the schema master. If a trust relationship is
established between two domain trees (thereby establishing a forest), two schema masters
will exist in the forest (one from both domains). One of them will automatically stop
acting as schema master.

The domain-naming master is responsible for ensuring the uniqueness of domain names
throughout a forest and for adding domains to or removing them from the forest. Only
one domain controller in a forest acts as the domain-naming master.

The relative ID (RID) master is responsible for issuing RIDs within a domain. Only one
domain controller in a domain acts as the RID master.

The infrastructure master is responsible for updating group-to-user references whenever

the members of a group are renamed or changed. Only one domain controller in a domain
acts as the infrastructure master. The infrastructure master checks a Global Catalog (GC)
server to see when changes have been made.

The primary domain controller (PDC) emulator is responsible for updating any Windows
NT backup domain controllers (BDCs) in your domain. The PDC emulator also processes
password changes from non-Windows 2000 (Win2K) client computers, just as an NT
PDC would do. Only one computer in a domain acts as the PDC emulator.

Deciding Where to Place FSMOs

In a single-domain environment, place your FSMOs on domain controllers that are centrally
located to all the sites on your network. Try to place each FSMO on a different domain controller
to avoid having a total single point of failure for your FSMOs. If your network includes a
concentration of NT BDCs in a single site, place the PDC emulator FMSO on a domain
controller in that site.
In multiple-domain environments, follow these tips for placing your FSMOs:

Assign the infrastructure master role to any domain controller that is not a GC server but
that has high-bandwidth connectivity to a GC server.

Place the PDC emulator so it is closest to any concentrations of pre-Win2K client

computers or NT BDCs.

Place the RID master on a domain controller that has high-bandwidth connectivity to the
PDC emulator in your domain. If you dont mind having a single point of failure for both
FSMOs, and if the load on your PDC emulator is fairly light, you can place both FSMOs
on one domain controller.

Microsoft recommends placing the domain-naming master and schema master roles on
the same domain controller. That domain controller should be well connected to the client
computers used by the forests administrators. These roles receive fairly little use and
wont significantly affect network operations if their servers fail, so placing them on a
single server isnt a bad idea.

14

Chapter 2

Dont orphan your FSMOs! If youre planning to decommission a domain controller (by running
DCPROMO.EXE to uninstall AD, for example), make sure you transfer any FSMOs that the domain
controller was hosting before decommissioning it.

Transferring FSMOs
You have complete control over which domain controllers host the various FSMO roles. You use
one of three Microsoft Management Console (MMC) snap-ins to transfer the roles:

Active Directory Users and Computers allows you to transfer the RID master, PDC
emulator, or infrastructure master FSMO roles.

Active Directory Schema allows you to transfer the schema master FSMO role.

Active Directory Domains and Trusts allows you to transfer the domain-naming master
FSMO role.

Transferring the RID Master, PDC Emulator, or Infrastructure Master

Launch Active Directory Users and Computers, connect to the appropriate domain controller,
then right-click Active Directory Users and Computers, and select Operations Masters from the
pop-up window. Windows displays the Operations Master dialog box, which Figure 2.3
illustrates.

Figure 2.3: Operations Master dialog box in Active Directory Users and Computers.

15

Chapter 2
On one of the three tabs, click Change to transfer that FSMO role to the domain controller you
are currently connected to.
Transferring the Domain-Naming Master
Launch Active Directory Domains and Trusts, connect to the appropriate domain controller, then
right-click Active Directory Domains and Trusts, and select Operations Masters from the pop-up
window. Windows displays the Change Operations Master dialog box, which Figure 2.4 shows.

Figure 2.4: Change Operations Master dialog box in Active Directory Domains and Trusts

Click Change to transfer that FSMO role to the domain controller youre currently connected to.
Transferring the Schema Master
Windows doesnt include a predefined MMC console for Active Directory Schema, so youll
have to make your own. To do so, follow these steps:
1. Select Run from the Start menu.
2. Type MMC and click OK. Windows will launch an empty MMC console.
3. Select Add/Remove Snap-in from the Console menu.
4. Click Add.
5. Double-click Active Directory Schema, then click Close, and click OK.

Use the console to connect to the appropriate domain controller, then right-click Active
Directory Schema and select Operations Master from the pop-up window. Windows displays the
Change Schema Master dialog box, as shown in Figure 2.5.

16

Chapter 2

Figure 2.5: Operations Masters dialog box in Active Directory Schema.

Click Change to transfer that FSMO role to the domain controller youre currently connected to.

Q 2.3: How do I handle a FSMO failure?

A: The impact of a Flexible Single Master Operations (FSMO) failure depends on which FSMO
role failed and what youre trying to do with your network. Keep in mind that all FSMOs, by
their very nature, represent a single point of failure in your domain. Heres what happens when a
FSMO fails:

If the schema master fails, you wont usually see an immediate impact. The schema
master is needed only when the schema needs to change or when two domain trees
establish a trust between one another.

The domain-naming master is needed only to add and remove domains from a forest, so
its failure doesnt usually create an immediate impact.

If the relative identifier (RID) master for a domain fails, you wont usually see an
immediate impact. The RID master issues RIDs in blocks, so youll be able to create new
objects in the domain until it runs out of RIDs and needs the RID master to issue more.
When that happens, youll be unable to create new objects in the domain.

The loss of the primary domain controller (PDC) emulator is noticeable if you still have
NT backup domain controllers (BDCs) or pre-Windows 2000 (Win2K) client computers.
BDCs will stop receiving updates to users and groups, and pre-Win2K client computers
wont be able to process password changes for their users.

17

Chapter 2

The infrastructure master is needed only when you change group membership or rename
the members of groups. If the infrastructure master fails, youll still be able to perform
those tasks, but AD may seem to ignore your changes until the infrastructure master is
online again.

None of the FSMOs have any kind of automatic failoverif the domain controller hosting the
FSMO fails, the FSMO stays offline until you do something about it.
Avoid a single point of total failure. Because FMSOs represent a potential single point of failure for
some network operations, avoid placing all your eggs in one basket by having all FSMOs on a single
domain controller. By default, the first domain controller in a new forest will have all the FMSOs;
relocate the FSMOs so that no more than one FSMO is running on any given domain controller.

What to Do When a FSMO Fails

You have three basic options when you notice that a FSMO has failed on your network:

Return the domain controller to active service. This option is the easiest choice if the
domain controller hasnt suffered a hardware failure or complete operating system (OS)
crash. Most of your network operations can survive a brief unavailability of any of the
FSMOs.

Temporarily return the domain controller to active service, and transfer the FSMOs to a
more stable domain controller. This option is a good bet if you can boot the affected
domain controller, but it wont stay running for very long.

Seize the FSMOs with another domain controller. This option is the most drastic
approach and requires that you be very careful when bringing the original domain
controller back on the network.

Make sure you know when FSMOs fail! Win2K doesnt flash lights or sound buzzers when a FSMO
fails. Instead, the OS dutifully logs an event to the event logs on the affected domain controller.
Unless youre careful, youll never know that a FSMO has failed.
Stay on top of the situation by documenting which domain controllers host FSMO roles, and regularly
monitor the event logs on those domain controllers to spot any problems occurring with the FSMOs.

Seizing FSMOs
If the domain controller hosting a FSMO fails, you can use another domain controller to seize the
FSMO role. Be aware that seizing the role may have a potentially adverse affect on your network
if the original domain controller is brought back online:

If you seize the schema master, domain-naming master, or RID master, you must never
bring the original domain controller back online. If you need to recover files from that
server, keep it disconnected from your network.

If you do somehow wind up with two schema masters, domain-naming masters, or RID masters,
remove one of them as quickly as possible. If you dont, the two FSMOs can corrupt AD, requiring
you to restore from a backup tape.

18

Chapter 2

If you seize the PDC emulator or infrastructure master roles, you can safely return the
original domain controller to your network. It will automatically detect the role change,
and no conflict will be created.

To seize any of the FSMOs, youll need to use the ntdsutil utility, which you run from a
command line. Follow these steps:
1. From a command line, run ntdsutil.
2. At the main ntdsutil prompt, type
roles
3. At the fsmo maintenance prompt, type
connections.
4. At the server connections prompt, type
connect to server

followed by the fully qualified name of the domain controller you want to move the
FMSO role to.
5. At the server connections prompt, type
quit
6. At the fsmo maintenance prompt, type the appropriate command to seize a FSMO role.

The available commands are:

seize pdc
seize infrastructure master
seize rid master
seize domain naming master
seize schema master
7. At the fsmo maintenance prompt, type
quit
8. At the ntdsutil prompt, type
quit
Never return the original domain controller to your network! If you seize the schema master, RID
master, or domain-naming master, the domain controller that originally hosted those roles must never
be connected to your network again. You will need to remove AD from the domain controller, making
it into a standalone server before it can be safely reconnected.

Q 2.4: How can I tell whether I need to add a domain controller?

A: Domain controllers can take a beating on your network. Often, theyre used to run more than
just Active Directory (AD). Many administrators treat domain controllers as utility computers,
and install Dynamic Host Configuration Protocol (DHCP), Domain Name Service (DNS),
Windows Internet Naming Service (WINS), and many other services.

19

Chapter 2
Although theres no problem in asking a domain controller to run those other services, it can
make determining when the domain controller is becoming overloaded with AD-related tasks a
difficult task. No matter whats running on your domain controllers, System Monitor is the tool
that can help you determine when its time to add a new domain controller.
Go easy on your domain controllers. I dont recommend that you use your domain controllers as
application servers (and neither does Microsoft). Using them as full-time Web servers, Exchange
servers, or to run other applications makes a difficult task of determining whether the computer is
overworked from the load on AD or the load created by the application.

System Monitor includes several counters that can help you determine whether a domain
controller is overworked or nearing its limit:

The % Processor Time counter, part of the Processor performance object, shows how
hard each of the computers processors are working. On a multiprocessor computer,
select the _Total instance to view an average of all installed processors. % Processor
Time is affected by all tasks running on the domain controller and should not exceed a
sustained average of 80 percent, although it may sometimes peak to 100percent, as Figure
2.6 shows.

Figure 2.6: Processor performance peaks high but maintains a low average value.

20

Chapter 2

Kerberos authentications per second, part of the NTDS performance object, shows how
many logons the domain controller is processing. The maximum value for this number
depends on the domain controllers hardware. Use this counter along with other counters
to determine if logon traffic alone is causing a performance problem. For example, if both
this counter and % Processor Utilization are high, its an indication that another domain
controller is needed to help handle logon traffic.

NTLM Authentications per second, also part of the NTDS performance object, shows
how many legacy logons (Windows 9x and Windows NT clients) the domain controller is
handling. Add the value of this counter to the Kerberos authentications per second
counter for an accurate picture of logon processing workload.

LDAP Bind Time, part of the NTDS performance object, shows how long the domain
controller took to bind the last LDAP request. This counter should be as low as possible.
If it shows any significant activity, this activity usually indicates a hardware bottleneck
time for an additional domain controller to help out.

Cache Page Fault Stalls per second, part of the Database performance object, should
always be zero. If it is consistently higher than zero at any value, its an indication that
the domain controller needs more memory, or that an additional domain controller is
needed to help pick up the load.

Keep your domain controllers total performance in mind. If a domain controller is running DNS,
DHCP, or other services, its processor utilization or other counters may be high, even though its AD
counters are low. In those cases, the other services are probably overloading the computer, not AD.

Installing the Database Object

The Database performance object contains a number of other counters that help you determine
what kind of load ADs database engine (called the Extensible Storage EngineESE) is under.
Unfortunately, Windows doesnt install the Database object by default. To install the database
object
1. Copy Esentprf.dll from %SystemRoot%\System32\esentprf.dll to a different directory.

For example, create a directory named C:\Performance, then copy the DLL and paste it in
the new directory.
2. Run Regedit.exe, then create the following registry subkeys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Perfor
mance
3. Under the new Performance subkey, create the following String Value entries (all are

type REG_SZ):
Create an entry named Close and set its value to ClosePerformanceData
Create an entry named Collect and set its value to CollectPerformanceData
Create an entry named Library and set its value to
C:\Performance\esentprf.dll
Create an entry named Open and set its value to OpenPerformanceData
21

Chapter 2
4. Open a command-line window and change to the Windows System32 folder.
5. Run
Lodctr.exe Esentperf.ini

The Database object should now be visible in System Monitor.

Domain Controller Performance Tips
Here are some general tips to help maximize the performance of your domain controllers:

AD-integrated DNS zones provide fault tolerance for the DNS zone files, but they also
reduce the number of simultaneous dynamic name registrations the DNS server can
process. In very large environments, consider using standard zones instead and run the
DNS service on servers that are not domain controllers.

Use the Active Directory Sizer tool, available as a free download from Microsoft
(http://www.microsoft.com/download), to help determine the optimum number of domain
controllers for your environment. The Sizer uses a wizard to collect information about
your environment, then produces a report like the one shown in Figure 2.7. The report is
interactive, allowing you to configure it to reflect your real-world site configuration. The
report automatically adjusts itself as you configure sites, reflecting the number of domain
controllers youll need. The Sizer even takes into account the performance capabilities of
various types of processor, and it can handle multiprocessor domain controllers. Rerun
the Sizer periodically as your organization grows to see how its recommendations
change.

Figure 2.7: The Active Directory Sizer tool.

22

Chapter 2
As much as possible, reduce the number of extra services your domain controllers run. Many
administrators like to place a domain controller in each of their sites, which is often a good idea.
However, they also like to place DNS, WINS, and DHCP on each domain controller, which isnt
always a good idea: Carefully consider the additional burden to your domain controllers before
loading extra services on them.

Q 2.5: How many domain controllers do I need for optimum

performance?
A: Thats a big question, and it requires you to think about a lot of variables. Try to answer the
following questions:

What kind of hardware are your domain controllers running on?

Whats the maximum level of processor and memory utilization that you want Active
Directory (AD) to consume on your domain controllers? For example, if your domain
controllers will serve no other purpose than to be domain controllers, letting AD consume
85 percent processor and memory utilization might be reasonable. If your domain
controllers will also be intranet Web servers, then 50 percent might be a more reasonable
figure.

How many users will your domain contain? About how many new users will you add
each month, and about how many will you delete?

Approximately how many object changes will administrators make each day? Object
changes include changing passwords, names, and other user attributes as well as changing
group policies and other administrative tasks.

How many additional user attributes and other AD objects will you add to the AD
schema? For example, Exchange 2000 Server adds about 1,000 new objects and
attributes, which significantly increases the size of AD.

Will you use AD-integrated Domain Name System (DNS) zones or standalone zones?
Standalone zones dont have the fault-tolerance of AD-integrated zones, but ADintegrated zones place more burden on domain controllers because the DNS information
is stored in AD, then replicated to all domain controllers.

How heavy will your logon traffic be? For example, a domain with 10,000 users is no big
deal if only 100 of them will try to log on at any given point. Unfortunately, most domain
users try to log on within a very short period of time, such as from 8:00 A.M. to 9:00
A.M. every weekday morning. Heavier logon traffic means more domain controllers are
necessary to keep up with the demand.

How many groups will the average user belong to? The answer affects the performance
of domain controllers, which have to keep track of the group membership and build a list
of groups each time a user logs on.

How often will your passwords expire? If your domain controllers have to keep up with
new passwords every 10 days, youll need more of them than you would need if your
passwords lasted for 30 days.

23

Chapter 2

Will you use Exchange 2000 Server? Remember that Exchange 2000 Server doesnt
contain its own directoryit uses AD instead. Every outgoing message gets matched
against AD to resolve recipient email addresses, creating additional burden on your
Global Catalog (GC) servers.

Microsoft provides a handy tool called the Active Directory Sizer (Adsizer.exe), which you can
download for free from http://www.microsoft.com/windows2000. The tool consists of a wizard,
which asks you for answers to many of the considerations I just outlined. The tool generates a
report indicating how many domain controllers youll need, as Figure 2.8 shows.

Figure 2.8: A sample Active Directory Sizer report.

The final report is interactive, allowing you to customize the number of sites you have and set up
the site links you plan to use. The sizer automatically recalculates the report, as Figure 2.9
illustrates, adding bridgehead servers and additional domain controllers as necessary to meet
your configuration. You can even add domains, reflecting the final structure you plan to use in
your organization. You can also distribute your user population accurately across your sites, and
the sizer will automatically redistribute your domain controllers to match.

24

Chapter 2

Figure 2.9: Modifying the sizers interactive report.

When youre finished, the report will tell you:

How many domain controllers youll need at each site. This number includes only
domain controllers that arent acting as bridgehead or GC servers.

How many bridgehead servers youll need at each site. These servers are responsible
for connecting to other sites, keeping a copy of the GC, and authenticating users.

How many GC servers youll need. These servers are also responsible for
authenticating users.

All you have to do is deploy the appropriate number of domain controllers, in the appropriate
roles, and you should be fine. As your organization continues to grow, revisit your sizer report
(you can save it for later reference), and modify your domains properties to reflect your
organizations current number of users, rate of growth, use of AD, and so forth. The sizer will
recalculate your report, allowing you to add, remove, or redeploy domain controllers as
necessary.

25

Chapter 2

Revisit your sizer report every 6 months, if not more often. Todays businesses change pretty quickly.
To make sure youre keeping up with the demand on your domain controller, revisit your sizer report
at least twice a year. Update the report to reflect your organizations size and growth trends, and
youll be able to quickly determine when and where domain controllers are needed.
Also, dont forget to continue using tools such as System Monitor to check your domain controllers
actual performance. Doing so can help validate the accuracy of the sizer in your environment, and
make sure your domain controllers are performing as expected.

Q 2.6: I want to make sure that my users can always log on. Doesnt
that mean placing a domain controller in every location that has
users?
A: Not necessarily. Consider the network shown in Figure 2.10. This network has four offices,
which are connected by 512Kbps and T1 lines. Two of the offices, Philadelphia and Phoenix,
have a small number of users, while the New York and Houston offices have hundreds of users
each. Although not shown in the figure, all the offices belong to a single Active Directory (AD)
domain.

New York
200 users

s
bp
2K
51

Philadelphia
10 users

2K
bp

T1

51

Houston
400 users

Phoenix
8 users

Figure 2.10:An example distributed network.

Most administrators would agree that from a workload standpoint theres no need to have
domain controllers in the Philadelphia and Phoenix offices. These offices have only a few users
each, and the users can authenticate over the wide area network (WAN) connection to New
York. This design philosophy is the same as that used by administrators of Windows NT
domains, in fact.

26

Chapter 2
However, those same administrators will usually place a domain controller in Philadelphia and
Phoenix for the same reasons they would have placed a Backup Domain Controller (BDC) there
in the NT days: They want to ensure that users can log on to their workstations even if the WAN
connection is down. Under NT, that was a valid design decision; under AD, its not. For more
information about why this decision isnt valid under AD, see the sidebar Redundancy and
WAN Links.
Redundancy and WAN Links
Domain controller placement shouldnt be affected by a concern that your WAN links will go down
sometime. After all, many more network services will probably be affected by a WAN outage, and
additional domain controllers wont help things such as Dynamic Host Configuration Protocol (DHCP),
Windows Internet Naming Service (WINS), or Domain Name System (DNS) when the WAN links are
down.
Instead, build redundancy into your WAN links. Use routers that are capable of establishing an Integrated
Services Digital Network (ISDN) or dial-up connection to remote offices when the primary WAN
connection goes down. Cisco, Nortel, and other manufacturers offer routers with this capability, allowing
you to configure backup connectivity using analog or ISDN technologies, which carry low monthly fees
when youre not actually using them. When your primary T1 or other connectivity fails, the router
automatically brings up the spare connection, ensuring a lower-bandwidth connection until your service
provider can restore your primary link.

A History of Domain Controller Placement

Under NT, client computers that couldnt contact a Primary Domain Controller (PDC) or BDC
couldnt access their local computers because the computers required a domain logon account.
So if the only BDCs were across a WAN link, clients couldnt even access files on their
workstations unless an administrator ran around creating local user accounts for them (and even
then, access to NTFS files would depend on whether the local account had been granted
permissions on the files). Administrators countered by placing a BDC in every remote office,
ensuring that users there could log on and access at least their local servers if the WAN link to
the head office went down.
How Windows 2000 Learned from History
Microsoft recognized the logon problem and countered it in Windows 2000 (Win2K) with
cached logon credentials. By enabling logon caching, you can ensure that your domain users can
log on to the domain even when no domain controller is present.
Logon caching is enabled by default on Win2K Professional and later client operating systems
(OSs), and by default, the OSs will cache ten logons. You can control the feature by defining a
Group Policy in your domain:
1. Create a new Group Policy, or edit an existing policy.
2. Expand Computer Configuration in the policy.
3. Expand Windows Settings, then expand Security Settings.
4. Expand Local Policies, and select Security Options.
5. In the right pane, select the Number of previous logons to cache policy, and double-click

it.

27

Chapter 2
6. As Figure 2.11 shows, configure the policy to meet your needs. If you configure the

policy with a setting of 0, you will disable logon caching.

7. Save the policy.

Figure 2.11: Configuring logon caching using Group Policy.

Once logon caching is enabled, Win2K and later client computers will start caching domain
logons. After a logon is in the cache, Win2K can authenticate that user to the domain without
contacting a domain controller. The users group membership and other settings will remain as
they are in the cache, even if changes have been made on the domain controller. Each time the
user authenticates against a domain controller, the cache is updated.
Logon caching allows users to access their local computers even when a domain controller isnt
present. Because caching is partially integrated with Kerberos (Win2Ks security authentication
protocol), it can even allow users to access local domain servers when the domain controller is
unavailable. Most importantly, logon caching means you dont have to place domain controllers
in every single office, allowing you to reduce AD replication as well as administrative overhead.

28

Chapter 2

Q 2.7: We use Exchange 2000 Server, and users complain that

Address Book lookups take too long. The Exchange server looks fine.
What can I do?
A: The trick with Exchange 2000 Server is that it doesnt do Address Book lookups. In fact,
Exchange 2000 Server doesnt even have an Address Bookit relies totally on Active Directory
(AD) to provide the Address Book.
AD does a great job of acting as an Address Book because AD was developed from the
foundation of Exchange 5.5s own Directory Store. To performance tune Address Book lookups,
you have to understand how Exchange clients perform those lookups.
Lookups with Earlier Clients
Outlook 98 Service Release (SR1) and earlier email clients dont know how to use the
Lightweight Directory Access Protocol (LDAP) to talk to AD. They always submit their Address
Book lookups to their Exchange server. Exchange 2000 Server doesnt have an address book, so
it proxies the request and sends the request to a domain controller that is acting as a Global
Catalog (GC) server. The GC responds to the Exchange server, which then sends the reply to the
client. This process is illustrated in Figure 2.12.

Outlook 98 SR1
and earlier clients

Address book request

Address book request

Address book reply

Address book reply

Exchange
2000
Server

Global
Catalog
(DC)

Figure 2.12: Address Book lookups with earlier clients.

This method places a lot of overhead on your Exchange and GC servers, which must work
together to perform Address Book lookups. If your network includes a lot of these earlier email
clients, make sure your Exchange server computers have a high-bandwidth connection to GC
servers.
Upgrade your email clients! Outlook 98 SR1 and earlier email clients dont really take advantage of
Exchange 2000 Servers new multitier architecture. Youll continue to experience various
performance and operational problems until you upgrade to at least Outlook 98 SR2.

Lookups with Later Clients

Microsoft added LDAP capabilities to Outlook in Outlook 98 SR2, and all later versions of
Outlook include LDAP. In an LDAP-based lookup, Outlook is aware of AD and performs its
queries directly against a GC server, as Figure 2.13 shows.

29

Chapter 2

Figure 2.13: Address Book lookups with later clients.

This new behavior takes the burden of Address Book lookups completely away from the
Exchange server, but dumps it squarely on your GC servers. Client computers must have access
to a GC server, and large environments will need to provide multiple GC servers to handle client
demand.
The Active Directory Sizer tool takes Exchange 2000 Server into account when recommending GC
servers. For more information about this tool, see Question 2.5 in Chapter 2.

With Exchange 2000 Server, you probably wont need as many Exchange servers as you did
under Exchange 5.5. Many organizations that placed Exchange servers in all their remote offices
are now able to centralize the servers. However, they do need to deploy additional domain
controllers configured to act as GC servers to meet the Address Book demands of their user
population.
Plan to place at least once GC server in each location that has more than a handful of users. Plan to
add one GC server for about every 700 email users in addition to the GC servers you may need for
normal domain operations such as logging on and searching AD. GC servers require quite a bit of
processor power and memory and a fast disk subsystem, which means dedicating small- to midsized
servers as GC servers isnt a waste of resources at all!

30

Chapter 3

Chapter 3: Replication Management

Q 3.1: After I make a change in Active Directory, the change doesnt
seem to take effect for quite a while. What can I do to make this
process faster?
A: The most common scenario for this behavior is resetting a users password. Bob calls in from
the branch office and asks for his password to be reset. You do it, and Bob says he still cant log
on. You reset his password over and over, and eventually it takes. What gives?
This behavior can crop up in any environment that has more than one domain controller and is
likely to occur in environments in which domain controllers are spread across wide area network
(WAN) links. For example, consider the network in Figure 3.1:

New York

Frame Relay

DC1

Houston

DC3

Philadelphia

DC2

Phoenix

DC4

Figure 3.1: Distributed network with four domain controllers.

This network includes a single domain, four office locations connected by frame relay lines
(which are only about a tenth as fast as a slow local area networkLAN), and a domain
controller in each office. Imagine that New York is the main office and that Philadelphia,
Houston, and Phoenix are branch offices. The domains Microsoft Management Console (MMC)
AD Sites and Services snap-in is probably configured, as Figure 3.2 shows, with a separate
subnet defining each site.

31

Chapter 3

Figure 3.2: Sample AD Sites and Services configuration.

Keep in mind that clients will almost always connect to a domain controller in their local site, if
one is available. So when Bob tries to log on in the Phoenix office, DC4 authenticates him. If
Bob calls you in the New York office to reset his password, youre most likely resetting it on
DC1. AD replication occurs almost immediately within a site, which means the domain
controllers within a site almost always contain exactly the same information. Between sites,
however, replication happens on a defined schedule.
Until replication occurs, DC4 will continue to use Bobs old password. Once replication occurs,
the password reset you performed on DC1 will be copied to DC4, and Bob will be able to log on.
How can you make that happen faster? There are two ways, depending on exactly what you want
to happen faster.
Faster Replication
If you want replication between sites to occur faster, you need to adjust the replication schedule.
You do so in AD Sites and Services:
1. Locate the Inter-site Transports container in AD Sites and Services.
2. Select the transport that links your sites. Some transports can link multiple sites, while

other transports might only link a pair of sites.

3. Double-click the transport to display its property page, which Figure 3.3 shows. You can

adjust replication frequency on this page. The default setting is every 2 hours.

32

Chapter 3

Figure 3.3: Inter-site transport properties.

4. On the property page, click Change Schedule. Replication will occur only during the

times you permit no matter which replication frequency you specified on the property
page. The default replication schedule is 24 hours a day, 7 days a week; you can change
that schedule as shown in Figure 3.4.

Figure 3.4: The replication schedule.

33

Chapter 3

Be careful when adjusting replication times and frequency! If you specify a very low frequency for
replication (less than about 100 minutes), you may significantly increase the traffic on your WAN
connections. If you specify too high of a replication frequency (more than about 200 minutes), the
changes you make may take so long to replicate that users become frustrated.

You can adjust your replication frequency and schedule to fit your needs. However, consider that
replication (or lack of it) isnt usually the cause of problems for your users. Instead, problems are
usually caused because the domain controller that users are trying to use doesnt have updated
information. Sound like doubletalk? Read on.
Making Changes Close to Home
Bobs password problem isnt with replication, exactly. Bobs problem is that DC4 doesnt have
his password. Now, if youre changing Bobs password on DC1, then replication is the only way
for that password change to make its way to DC4but theres no reason you have to change
Bobs password on DC1. DC1 just happens to be the closest domain controller to you. Instead,
make the change on the domain controller closest to BobDC4.
When you use the MMC Active Directory Users and Computers snap-in, it connects by default
to the domain controller closest to you (which would be DC1 in our example network). You
dont have to settle for that, though; you can tell the application to connect to a specific domain
controller, and any changes you make will be made on that domain controller. To do so,
1. Right-click your domain name in Active Directory Users and Computers.
2. Select Connect to Domain Controller from the pop-up menu.
3. In the resulting dialog box, you can select any domain controller in your domain, or you

can select the default Any Writable Domain Controller, as Figure 3.5 shows. Select the
domain controller closest to the user for whom youre making a change, and click OK.

Figure 3.5: Connecting to a specific domain controller.

34

Chapter 3
Your changes will be made on the users domain controller, allowing the user to immediately
take advantage of the change without waiting for replication. Replication will eventually occur,
so your change will be propagated to all domain controllers in your domain.
You can use the same trick when youre writing an administrative script. VBScript allows you to
use the Active Directory Service Interfaces (ADSI) to connect to a domain and make changes.
By default, ADSI paths usually look something like the following example:
LDAP://DC=Domain,DC=Com,O=Internet

Your client computer will automatically connect to the nearest domain controller, just as it does
when you use Active Directory Users and Computers. However, you can specify a specific
domain controller by including its server name and organizational unit (OU) in the ADSI path:
LDAP://CN=Server,OU=DCs,DC=Domain,DC=Com,O=Internet

Specifying a domain controller allows you to ensure that your script runs against the domain
controller on which the changes are needed.

35

Chapter 4

Chapter 4: Security Administration

Q 4.1: I want to distribute the management of the users and groups in
my Active Directory. Whats the best way to proceed?
A: The ability to delegate control of Active Directory (AD) objects is definitely one of the best
reasons to start using AD to begin with. However, you cant just plop your users and groups into
AD and start delegating control. First, you have to plan.
Start by deciding exactly what capabilities you want to delegate, and to whom you want to
delegate them to. For example, users often forget their passwords and have to call the Help desk
to have the password reset. In most organizations, this activity can generate a lot of Help desk
calls, especially during the time when users are required to change their passwords. Requiring
the Help desk to reset passwords all day long is a waste of resources, so many organizations like
to delegate this task to administrative personnel.
For example, imagine a company with offices in New York, San Francisco, and Houston. An
administrator in each office is available to reset passwords, so giving those administrators the
ability to do so makes sense. AD makes delegating this ability easyjust use the Active
Directory Users and Computers Microsoft Management Console (MMC) snap-in to perform
these basic steps:
1. Create a domain global group for each office (in this case, Houston, New York, and San

Francisco).
2. Place the appropriate administrators user accounts into each group. Youll actually

delegate control to the groups rather than the users.

Always grant permission to groups. If you grant permissions to individual users, youll spend a lot of
time managing permissions whenever additional users need the same permissions, or when users no
longer need those permissions. If you assign permissions to groups, you can just move user accounts
into or out of the groups as necessary, which is much faster.
3. Create organizational units (OUs) in AD. These OUs will represent each office, and will

contain all the user accounts for users at each office. Creating your OU structure is the
most important aspect of managing AD. For more tips about an effective OU design, see
the sidebar Organizing Your Directory.
4. Move the user accounts from each office into the appropriate OUs.
5. Right-click each OU, and select Delegate Control.
6. Click Next on the Delegation of Control Wizards welcome screen.
7. Select the appropriate domain global group, and click Next. The group you select will

receive delegated control over the OU you right-clicked.

8. Select the task you want to delegate to the group. If the task you want to delegate isnt

shown, select Delegate a Custom Task. To delegate the ability to reset passwords, you
simply have to select that task from the list, as Figure 4.1 shows, and click Next.

36

Chapter 4

Figure 4.1: Selecting a task to delegate with the Delegation of Control Wizard.

9. Click Finish on the last screen of the Wizard.

Organizing Your Directory
Creating an effective OU hierarchy will simplify controlling your domain and let you delegate authority
over the directory to meet your administrative needs. The trick is to create OUs that represent the security
boundaries of your users. Security boundaries are theoretical lines that divide users and computers that
have different security needs. For example, if you have two groups within your company who manage
user accounts, a security boundary separates the users managed by each group, and you would create
two OUs to contain those user accounts.
OUs are a great way to separate users who need different group policies, who will be managed by
different individuals or departments, and so forth. Also remember that you can nest OUs within one
another. For example, imagine that your company has two divisions, Research and Operations. A central
IIS department creates all user accounts, but the two divisions require different group policies. Within
each division, users personal information in the AD is controlled by local administrative personnel.
Organizing AD is easy in this case. Create an OU for each division, then create sub-OUs for each office.
You can apply group policies to the divisional OUs, and the policies will flow down to the user accounts
through inheritance. You can delegate control over the users attributes to the office OUs within each
division. If a user switches offices or divisions, you simply need to drag them into the correct OU, and the
correct policies and permissions will be automatically applied to their account.

The Delegation of Control Wizard is a powerful way to assign very specific AD permissions to
users and groups. After running the wizard a few times, you may want to view the permissions
on your OUs. Unfortunately, the wizard doesnt help you view the permissions on an OU. In
fact, the Active Directory Users and Computers tool doesnt provide a way to view permissions
by default. To view permissions on an OU, use Active Directory Users and Computers, and
follow these steps:
37

Chapter 4
1. Select Advanced features from the View menu.
2. Right-click an OU, and select Properties.
3. Select the Security tab. As Figure 4.2 illustrates, Ive selected the appropriate

administrators user group, but no permissions are displayed because the group has a very
specific set of permissions (the ability to reset passwords) that cant be displayed on the
default permissions list. The dialog box does display a warning, which tells you that
additional permissions are present but not displayed.

Figure 4.2: Security permissions on an OU.

4. Click button. As Figure 4.3 shows, the Access Control Settings dialog box shows the

exact permissions that have been granted on the OU to the administrators user group.

38

Chapter 4

Figure 4.3: Advanced permissions for an OU.

With a well-designed OU hierarchy, careful use of the Delegation of Control Wizard, and
occasional checkups on your OUs permissions, you can safely delegate a variety of AD
administrative tasks to the users in your organization.

39

Chapter 5

Chapter 5: Disaster Recovery

Q 5.1: How can I prepare for Active Directory disaster recovery?
A: It does my heart good to see you asking this question rather than Help! My only domain
controller crashed! What do I do? because at that point, of course, its too late. Active Directory
(AD) disaster recovery is all about planning. The AD documentation and the Windows 2000
(Win2K) Server resource kit offer a number of suggestions for preparing your AD domain for
the worst. Ill let you peruse these suggestions at your leisure, and instead tell you what everyone
really does in the real world.
Dont Put All Your Eggs in One Basket
Domain controllers are inherently fault tolerant if you have more than one in a domain. All
domain controllers contain exactly the same information, so if one fails, the others continue to
operate. ADs Flexible Single Master Operations (FSMO) roles provide a single point of failure,
but you can recover from those failures easily enough if you have a spare domain controller on
hand.
I discuss FSMOs and how to recover from a FSMO failure in Question 2.2 and Questions 2.3 in
Chapter 2.

Here are some tips for ensuring fault tolerance in your domains:

Make sure every domain has at least two master domain controllers. Those two domain
controllers should have no tasks other than being domain controllers, and they should be
physically fault tolerant (for example, redundant server hardware, on separate power
feeds, in separate server racks, and so on). For full fault tolerance, make sure the two
domain controllers are connected to the network using separate switches and other
network hardware to prevent a single point of failure in the network infrastructure. Figure
5.1 shows a sample infrastructure.

40

Chapter 5

Domain
controller

3Com

Domain
controller

Switch/hub

3 Com

3Com

Switch/hub

Dual routers
connected for
fault tolerance

User
network

Figure 5.1: Sample fault-tolerant domain controller and network infrastructure.

Use AD-integrated DNS zones, which store zone information in AD rather than in zone
files. AD-integrated zones allow any domain controller to become a DNS server simply
by installing and starting the DNS service on the domain controller.

Always have at least one domain controller that doesnt host the Global Catalog (GC) or
any FSMO roles. That domain controller will then be available to pick up the GC or seize
any FSMO roles associated with a failed domain controller.

Avoid running non-AD services, such as the Dynamic Host Configuration Protocol
(DHCP) or Windows Internet Naming Service (WINS), on your master domain
controllers. That way the failure of a master domain controller wont take critical network
services offline. If you run these additional services on a domain controller, make sure
you have another computer on the network capable of serving as a backup for those
services.

Should one of your master domain controllers fail, simply take a few basic steps to transfer any
associated services to the other master domain controller:

If the failed domain controller was also a DNS server, install and start the DNS service.

Seize any FSMO roles the failed domain controller was hosting.

If the failed domain controller hosted the GC, make the remaining domain controller a
GC server.

41

Chapter 5

I explain how to seize FSMO roles in Question 2.3 in Chapter 2 and how to make a domain controller
a GC server in Question 2.1 in Chapter 2.

When the failed domain controller has been repaired, simply return it to the network. It will
automatically begin replicating any changes that occurred while it was offline.
Be careful if you seized FSMOs from a failed domain controller. If you seized the RID master, schema
master, or domain-naming master roles from a failed domain controller, do not return that domain
controller to service. Doing so will cause an AD failure on your network.
Instead, start the repaired domain controller while it is disconnected from the network. Use Dcpromo
to demote the computer to a standalone server, then reconnect it to the network and run Dcpromo
again to make it a domain controller. It will automatically replicate the current AD settings, then you
can safely transfer FSMO roles back to it if desired.
If you accidentally return a server to your network after seizing a FSMO role from it, remove it
immediately as it can corrupt your AD and require you to restore from a tape backup.

Backup and Restore

Sometimes, a disaster doesnt mean a domain controller failed. Some disasters can take the form
of a corrupted AD that is replicated to all domain controllers, or an inadvertent AD operation
(such as deleting a block of users or groups) that is replicated to all domain controllers. In those
types of operational disasters, having a good backup on hand is the only way to recover.
BACKUP! BACKUP! BACKUP! You should regularly back up AD, and you should back it up again
after any major operation like extending the AD schema or adding a bunch of users. You should
periodically test your backups by restoring them to a domain controller that isnt connected to the
network. Dont wait until you need a backup to think about making one or to discover that the ones
youve made dont work.

Performing an AD backup is fairly straightforward. You can use the Win2K backup utility or any
Win2K-compatible backup application.
Many organizations prefer to use third-party enterprise-backup solutions because they simplify
backing up a large number of servers. Make sure your solution is fully Win2K-compatible and that it
supports AD backup and restore.

To back up AD, simply back up the System State of a domain controller. You need to back up
only one domain controller to get the entire AD, but youll probably want to back up all your
domain controllers on a regular basis just to be safe. Here are some tips for performing backups:

Back up a domain controllers System State as frequently as possible. A backup is

usually fairly small, so you should be able to perform a full backup every day. Attach a
separate tape drive to a domain controller for this purpose, if necessary. If youre making
a lot of changes to AD every day, back it up more frequently than once a day.

Keep as many days worth of backup tapes as possibleat least a months worth, if you
can. Doing so will allow you to more easily restore the AD databases to any particular
state.
42

Chapter 5

Anytime you make major changes to the AD database, such as extending the schema,
adding or changing a large number of users, and so on, make an AD backup immediately
before and immediately after the changes. Document the change that was made so you
know the difference between the two backups.

If you work in a large organization and your AD database is constantly being changed,
consider making more frequent backups. Some large organizations have a single domain
controller that they treat as the master domain controller. That domain controller has its
own tape drive, and its System State is backed up several times each day.

If you need to restore the AD, you have two choices for doing so: An authoritative restore and a
non-authoritative restore. In either case, you must use your backup software to restore the
domain controllers System State to its original location. If you restore the System State to an
alternative location, the AD database and support files wont be restored.
The Win2K Backup utility is limited. Unlike many third-party backup solutions, which can back up a
domain controllers System State over the network, Win2K Backup can back up and restore only the
System State of the local computer. This limitation means that you need to attach a backup device
(such as a tape drive) to the local computer to back up the System State to tape. You shouldnt store
backups on the domain controllers hard drive because they wont be usable if the hard drive fails.

Non-Authoritative Restore
Use a non-authoritative restore when a single domain controller has become corrupted, but the
other domain controllers in the domain still contain an accurate copy of the AD database. The
restored domain controller will immediately pick up changes made since the date of the backup
through replication with the other domain controllers.
Non-authoritative restores do not affect the contents of AD. When you perform a non-authoritative
restore on a domain controller, the domain controller will realize that it has an older copy of AD once
the restore is completed. Normal AD replication will overwrite the restored domain controller with
more recent changes to the AD database.

You dont need to take any special steps to perform a non-authoritative restore; simply restart the
domain controller in Directory Services Restore mode (press F8 at the operating systemOS
selection screen to locate this special startup mode), then use the normal restore method
associated with your backup software. Restart the computer when you finish the restore
operation, and normal AD replication will kick in and take care of the rest.
Authoritative Restore
An authoritative restore allows you to return your entire domains AD database to an earlier
point in time, which you might need to do if someone accidentally deletes several AD objects
that you cant easily re-create. An authoritative restore starts out just like a non-authoritative
restore: Start the domain controller in Directory Services Restore mode and perform the restore.

43

Chapter 5
After the restore operation completes, you must tell the server to treat the restore as authoritative.
To do so, follow these steps:
1. From a command line, run
ntdsutil
2. At the ntdsutil prompt, type
authoritative restore
3. Follow the prompts to confirm your choice.
4. At the ntdsutil prompt, type
quit
5. Restart the server.

Ntdsutil goes through the entire AD database that you restored and marks each object with a
version number that is much higher than any version number already in the database. When the
server restarts, normal AD replication kicks in. Because the server has a higher version number
for each object than the other domain controllers on your network, it will be treated as the source
for AD replication, and its version of the AD database will begin to overwrite the other domain
controllers databases.
Performing an authoritative restore causes the restored AD database to completely overwrite the AD
database on all domain controllers. Take the time to document your AD backups, and be certain the
AD database you restore is the one you want all your domain controllers to use.

Testing Your Backups

If youve taken the time to create a regular backup schedule, you should also create a regular
backup test schedule. In a backup test, you take a domain controller off your network and
perform an authoritative restore. After restarting the server, check its AD directory to ensure that
the restore completed successfully.
Dont reconnect your test domain controller. If you do, it will overwrite all other domain controllers with
its copy of the AD database. After performing and validating an authoritative restore, perform a nonauthoritative restore. The domain controller can then be safely reconnected to your network, and AD
replication will bring the non-authoritative AD database up to speed with the rest of the domain.
It should go without saying that you should never perform a test restore to a production domain
controller because youll overwrite your production AD database with the backup copy.

I recommend performing a test backup as frequently as possible. At a minimum, test one out of
every five backup tapes you create. Bad backup tapes are the most common cause of failed
restores. Also, replace your backup tapes with new ones after every few uses to prevent worn
tapes from causing a failed restore.

44

Chapter 6

Chapter 6: Tools and Utilities

Q 6.1: How can I automate the process of adding users?
A: Adding a whole bunch of users to Active Directory (AD) at once can be time consuming.
However, because Microsoft makes AD completely accessible through the Lightweight
Directory Access Protocol (LDAP), you can use the Active Directory Service Interfaces (ADSI)
LDAP provider to programmatically add objects to AD.
The easiest way for administrators to utilize ADSI is in a VBScript. Windows 2000 (Win2K) and
later computers all include the Windows Script Host (WSH), which automatically executes
VBScript and JScript files (which have a .VBS or .JS file extension, respectively) when you
double-click them. Just save your VBScript in a text file with a .VBS extension, double-click the
file, and the script will execute.
You can also download the WSH from http://msdn.microsoft.com/scripting. The download
version of WSH includes a number of sample scripts, including one named ADDUSERS.VBS.
The ADDUSERS script is designed to read user information from an Excel spreadsheet (also
helpfully included as ADDUSERS.XLS) and add those users to a Windows NT domain. Ill
reprint the script here, with modifications to make the script work with AD instead of NT.
The following section is a line-by-line walkthrough of the script. Ill walk through every line of the script
and tell you what each line does. If you want to use this script yourself, just use the lines printed in the
monospaced font and remove my comments.

The ADDUSERS Script

The first few lines of the script contain instructions for using it. For example, you have to
provide a parameter to the script to tell it where the Excel spreadsheet is located:
'To add users, run ADDUSERS.VBS with %windir%\"Your Samples
Directory Here"\AddUsers.XLS.
'To Delete users, run DELUSERS.VBS with %windir%\"Your Samples
Directory Here"\DelUsers.XLS.

Next, the script defines a number of variables that it will use:

Dim oXL, u, c, root
Dim ou, TextXL, CRLF, oArgs

The script then uses the Arguments object to retrieve the parameter you provided, which contains
the location of the Excel spreadsheet. Notice that the CRLF variable is assigned to special
character codes, which equate to a linefeed and carriage return. The CRLF variable can then be
used to add an end of line when necessary:
set oArgs=wscript.arguments
CRLF = Chr(13) & Chr(10)
TextXL = oArgs.item(0)

45

Chapter 6
Like any good script, this one checks to make sure that you provided the necessary parameter,
and stops if you didnt:
If TextXL = "" Then
WScript.Echo "No input file provided. Stopping now."
WScript.Quit(1)
End If

The script sets the ou variable to null, preparing the variable to be used to control a loop:
ou = ""

Next, the script starts Excel and makes it visible to the user so that you can see whats going on:
Set oXL = WScript.CreateObject("EXCEL.application")
oXL.Visible = True

The script now activates the workbook you specified in the scripts parameter, and activates the
page named Add:
oXL.workbooks.open TextXL
oXL.sheets("Add").Activate

The script uses Microsoft Office automation commands to put the cursor in the starting cell of
the spreadsheet, which contains the ADSI path to the directory service (in this case, AD). Later,
Ill cover how you can modify the spreadsheet to match your environment:
oXL.ActiveSheet.range("A2").Activate

The script saves the ADSI path into the root variable, then moves to the next row in the
spreadsheet:
root = oXL.activecell.Value
oXL.activecell.offset(1, 0).Activate

The script now begins a loop that will continue until the script encounters an empty cell in the
spreadsheet. In other words, all the code between the Do and Loop statements will repeat until all
the information in the spreadsheet has been processed:
Do While oXL.activecell.Value <> ""

Within the loop, the scripts first action is to pick up the name of the destination organizational
unit (OU). The script reads the OU name only if the name is different from the last OU that the
script used. After picking up the OU name, the script adds the OU name to the root variable for a
complete ADSI path, then uses GetObject to obtain a reference to that OU:

46

Chapter 6
If oXL.activecell.Value <> ou Then
ou = oXL.activecell.Value
s = "LDAP://" + ou+"," + root
Set c = GetObject(s)
End If

Now the script retrieves the users first and last name from the spreadsheet to form the user
accounts common name:
uname = "CN=" + oXL.activecell.offset(0, 1).Value + " " + _
oXL.activecell.offset(0, 2).Value

The script then creates the new user object. The new object is referenced by the variable u after
object creation completes:
Set u = c.Create("user", uname)

The script then uses the u variable to set the properties of the new user, based on the information
in the spreadsheet:
u.Put "givenName", oXL.activecell.offset(0, 1).Value _
'givenName
u.Put "sn", oXL.activecell.offset(0, 2).Value 'sn
u.Put "mail", oXL.activecell.offset(0, 3).Value 'Email
u.Put "sAMAccountName", _
oXL.activecell.offset(0, 4).Value

'Sam Acct

u.Put "telephoneNumber", _
oXL.activecell.offset(0, 5).Value

'Phone

Finally, the script enables the account, requires the account to change passwords at next logon,
and saves the information to AD:
u.Put "userAccountControl",16
u.SetInfo

The script now discards the reference to the user object, moves the cursor in the spreadsheet to
the next row, and continues the loop:
Set u = Nothing
oXL.activecell.offset(1, 0).Activate
Loop

When the script finishes the loop, it closes Excel:

oXL.application.quit

47

'Next row

Chapter 6

The ADDUSERS Spreadsheet

Figure 6.1 shows the ADDUSERS.XLS spreadsheet that comes with the WSH samples.

Figure 6.1: The ADDUSERS spreadsheet.

The first row of the sheet contains column names. The second row contains only one column, the
DS Root. This row must contain the ADSI root path to your domain. In this example, the domain
name is ArcadiaBay.com. Change the domain controller parameters to match your environment.
For example, if your AD domain name is MyCompany.com, then your DS Root path would be
DC=MyCompany,DC=Com,O=Internet.
The remainder of the spreadsheet contains the user information in six columns:

The OU in which the user account should be created

The users first name

The users last name

The users email address

The users user ID or username

The users phone number

Extend the spreadsheet and the script! You can populate AD with additional user information. Just
include that information in the Excel file, then expand the script to save the additional information to
AD.

Scripts are a great way to automate many time-consuming day-to-day administrative tasks. By
combining technologies such as ADSI and Office automation, you can easily store information in
Office documents, then use a script to add objects or information to AD from those documents.

48

Chapter 7

Chapter 7: Migration
Q 7.1: I need to decide on a name for my new Active Directory
domain. What name should I use?
A: Pretty much everyone already has a domain name associated with his or her company, if for
no other reason that to have a public Web site. Active Directory (AD) names and Internet
domain names are the same thing (unlike Windows NT domain names, which were quite
different from Internet domain names). The domain name you choose for your AD domain needs
to recognize the existence of your Internet domain, and the name you select depends on your
exact situation and goals. Ill discuss several different situations, and you can pick the one that
most closely matches your situation.
Try to use a registered domain name for your AD domain. Whenever possible, your users domain
should match their public email addresses. For example, if Joes email address is
joe@company.com, Joe should log onto an AD domain named company.com. Making your AD and
Internet domain names the same is usually easy, and Ill show you how in the next two sections.

You Have an Internet Domain Name Hosted by Your Internet Service Provider
Most organizations probably fall into this category. Your Windows NT domain was named
something like COMPANY, and you registered a domain name like company.com for use on the
Internet. Your goal should be to use company.com as your AD domain name, as well.
Examine Your Current Situation
Make sure you understand your current situation. Most likely, it looks something like this:

Your ISP has two or more Domain Name Service (DNS) servers that are authoritative for
your domain name. The authoritative status means that the public looks to those domain
servers as the one and only source for resolving host names in your domain.

Your ISPs DNS servers are not running on Windows 2000 (Win2K) or Windows .NET
Server. Generally, theyre running on a UNIX-based server.

You have a few host records you want the public to see, such as www. Most of your host
names are internal, and you dont want the public to have access to them.

Your internal users need to access your public Internet-based resources, such as your
public Web servers.

You want to continue using your ISPs DNS servers for public host records. However,
youll need to deploy DNS servers on your private network for ADs use.

49

Chapter 7

Decide What to Do
In your scenario, theres no reason not to use your public Internet domain name as your AD
domain name. Heres what you need to do:

Do not change your Internet domain name registration. The public will continue to use
your ISPs DNS servers to resolve host names in your domain.

Deploy Win2K (or compatible) DNS servers on your network for ADs use. These DNS
servers should be told that theyre authoritative for your domain name, which means their
database will contain a Start Of Authority (SOA) record.

Configure your users computers to use your internal DNS servers for name resolution.

Set your authoritative internal DNS servers to forward DNS requests to your ISPs DNS
servers. This step will allow your users to access the Internet normally.

Because your internal DNS servers believe theyre authoritative for your domain, they
will never forward requests for that domain name. This behavior can result in your own
Internet-based resources (such as Web servers) being inaccessibly to your own users.
Correct the situation by obtaining a list of host records from your ISPs DNS servers,
then making static entries in your internal DNS servers for each host on the list.

Plan for fault tolerance. Always use at least two DNS servers so that the failure of a single server
wont adversely impact your networks operation.

The end result of these steps is that your users will be able to access all Internet resources, your
AD and Internet domain names will be identical, and only the host names entered in your ISPs
DNS server will be accessible to the public. The public will continue using the ISPs DNS
servers for name resolution, and your users will use your internal DNS servers for name
resolution. This configuration is shown in Figure 7.1. The lightning bolts indicate which DNS
server internal and Internet users utilize for name resolution. (However, if you dont want to use
your Internet domain name, see the sidebar But I Dont Want to Use My Internet Domain
Name!)

50

Chapter 7
Contains A
records only
for public
hosts, such as
www.
Internet
users

ISP
DNS Server 1

ISP
DNS Server 2

Internet

Uses dynamic DNS to

include internal hosts;
has static A records
for public hosts such
as www.

Internal
Internal
DNS Server 1 DNS Server 2
Internal
network

Internal
computers

Figure 7.1: Using your ISPs and your own DNS servers.

But I Dont Want to Use My Internet Domain Name!

Ive worked with a lot of people whove registered a domain name on the Internet and dont want to use it
as their AD domain name. Many times, they cite security as the reason. As Ive described in this section,
security isnt an issue so long as you dont use the same DNS servers for your internal and external host
names.
The biggest reason you do want to use your Internet domain name as your AD domain name is to prevent
user confusion. Keep in mind that AD allows users to log on using their fully qualified user name, which
looks a lot like an email address (for example, user@domain). Users will have difficulty understanding
why they have to log on using something like john@company.local, when their email address is
john@company.com. The confusion is bound to cost you time and money in support issues.
However, if you are absolutely certain that you dont want your Internet and AD domain names to be the
same, make sure you either register your AD domain name with an Internet domain name registrar or use
a top-level domain (TLD) that isnt used on the Internet, such as .local. If you dont take at least one of
these steps, your AD domain name might eventually conflict with an Internet domain name registered by
someone else, which can cause no end of name resolution and other technical support issues on your
network.

51

Chapter 7
You Already Have an Internet Domain Name That You Host
If your DNS servers are running on UNIX servers or on other non-Windows servers, youre in
pretty much the same situation as if your ISP hosted your domain name. Read the previous
section for details about how to proceed.
If your DNS servers are running NT, youll need to start by upgrading them to Win2K because
the NT DNS software doesnt support the features that AD requires (namely, support for special
SRV DNS records and dynamic DNS updates). After youve accomplished that step, you need to
decide on security goals for your domain name. You really have two choices:

You dont want your internal host names accessible on the InternetIn this
situation, youll need to deploy additional internal DNS servers as if your domain name
was hosted by your ISP. Follow the steps in the previous section for configuring your
domain name and the internal DNS servers. Treat your publicly accessible DNS servers
as if they belonged to your ISP.

You dont care about internal host names being accessed from the InternetIn this
situation, you can simply use your DNS servers for everything. This situation is much
simpler to deal with but dont underestimate the security risk of making your internal host
names and IP addresses available to the Internet. Half the battle in hacking someones
network is discovering their IP addresses and host names, and anyone with an Internetconnected computer can easily use the NSLOOKUP utility to list all the host names in
your DNS server. Consider using one set of DNS servers for the Internet and another set
for internal use, as I described in the previous section.

If you decide to use two sets of DNS servers (a strategy I heartily recommend), your network
will look similar to the one shown in Figure 7.2. The lightning bolts indicate which DNS server
internal and Internet users utilize for name resolution.

52

Chapter 7
Contains static
A records
only for public
hosts, such as
www.
Internet
users
External
DNS Server 1

External
DNS Server 2

External
network

Internet

Firewall

Internal
network

Internal
computers

Uses dynamic DNS to

include internal hosts;
has static A records
for public hosts such
as www.
Internal
Internal
DNS Server 1 DNS Server 2

Figure 7.2: Hosting two sets of DNS servers.

You Dont Have a Domain Name Registered on the Internet

This is perhaps the easiest situation. First, you need to decide if you will ever want to have an
Internet domain name associated with your company. If you dont (which is unlikely), you can
use any AD domain name you want, so long as it ends with .local. The special .local TLD
ensures that the domain name you choose will never conflict with a registered Internet domain
name.
The likelihood is much greater that youll want to register a domain name for use on the Internet
as well as for use as your AD domain name. After registering the domain name, decide if youll
host the domain name on your own publicly accessible DNS servers, or whether youll have your
ISP host the domain name on their DNS servers. In either case, just refer to the previous two
sections for specific details about how to use that domain name with AD.

Q 7.2: Should I perform an upgrade or a migration?

A: This question is one of the biggest questions associated with the move from Windows NT to
Windows 2000 (Win2K). First, a couple of definitions:

53

Chapter 7

An upgrade involves converting an existing NT domain to a Win2K Active Directory

(AD) domain by upgrading the NT Primary Domain Controller (PDC). No user or group
accounts need to be changed or moved.

A migration involves the creation of a new AD domain and the process of moving user
and group accounts from the old NT domain into the new AD domain. Once the
migration is complete, the old NT domain is decommissioned.

When Win2K was first introduced, Microsoft strongly recommend that companies migrate their
domains whenever possible. Microsofts feeling was that the old NT domains would have too
many old, unused user accounts and groups, and that the migration would be more successful if
companies started from scratch with a fresh AD domain.
Unfortunately, migrations proved to be more difficult than Microsoft had originally expected.
One major problem is security ID (SID) history. (For more information about SIDs, see the
sidebar Who is SID?)
Who is SID?
SIDs are used in both NT and Win2K to uniquely identify users and groups. When a server checks to see
whether you have access to a file, the server doesnt check whether the files access list includes your
user name. Instead, it checks to see whether the files access list contains your account SID or the SID of
a user group you belong to.
Because SIDs are the real ID for a user or group account, you can rename accounts without causing
problems because the SID doesnt change.

SID History and Migration Problems

When you migrate accounts, they lose their original SID and take on a new SID in the AD
domain. Most migration tools, including Microsofts Active Directory Migration Tool (ADMT),
copy the original SID from the NT domain into a special SID history attribute in AD. The SID
history allows AD user accounts to access file server resources using the original NT-based SID.
ADMT and other migration tools also provide the ability to scan an entire file server and change
all the SIDs on the servers access control lists (ACLs) to the new AD-based SIDs. Once you
finish updating your servers ACLs, you can delete the SID history from AD because its no
longer necessary.
Unfortunately, companies often use NT servers for file sharing, and those servers can contain
millions of fileseach with its own ACL and list of SIDs. Migrating all those servers is a timeconsuming, costly process. Worst of all, the process isnt always perfect, and when it fails, it
results in files that nobody can access.
Migrating: Tons of Work
Another problem with migrating is the sheer effort involved, especially when youre migrating
multiple NT domains into a single AD domain. NT domains can have as many as 40,000 users
and computers, and they must often be migrated in small groups so that any errors can be dealt
with easily. If you have just a few large NT domains, the migration process can suddenly stretch
into a major life-long project, which you have to complete in the middle of the usual daily fires
and technical support issues.

54

Chapter 7
Upgrades Make Things Easier
Upgrading seems to offer the best approach. Initially, many customers were leery of upgrading
because the process requires that you upgrade your PDC firstpretty much putting all your eggs
in one basket. But upgrading offers significant advantages:

All your user and group accounts upgrade immediately, and their SIDs remain the same.
You dont have to do anything special with your file servers.

The upgrade process doesnt take much longer than a typical Win2K installation, so its
over quickly.

One of the advantages of upgrading is also a potential disadvantage. If your NT domain contains
a number of old, unused user and group accounts, the mess will be carried right into your new
AD domain. And upgrading definitely presents risks that migrating does not. If you mess up a
migration, you just turn off the new AD domain and continue using the old NT domain, starting
over with a new migration if necessary. If an upgrade goes wrong, youve trashed your PDC.
Newly developed best practices, however, minimize the risk of an upgrade, allowing you to take
advantage of an upgrades easier path to Win2K and AD.
Up-to-Date Best Practices
To alleviate the risks that an upgrade presents and to provide the easiest possible path to a
completely AD environment, follow these best practices:

Make a new PDC, and upgrade it. Perform a clean installation of NT, and create a new
Backup Domain Controller (BDC) in your NT domain. Promote that computer to be the
domains PDC, and perform the Win2K upgrade on the newly promoted PDC. This step
ensures that the computer you upgrade is in the best possible condition.

Keep a BDC offline during the upgrade. If all else fails, you can take your failed-toupgrade PDC offline, bring your spare BDC back online, and promote it to PDC. Within
just a few minutes, youre back at square one and operating normally. Make sure the
spare BDC is up-to-date before taking it offline and starting the PDCs upgrade.

If you choose to keep a BDC offline during your upgrade, use NTs Server Manager to force the NT
domain to replicate. That will ensure the BDC has an accurate copy of the domain, making it a useful
backup.

Clean up your domain before upgrading. Delete old user accounts and group accounts,
and get everything into tip-top shape. Most especially, use the Server Manager
application to delete any old computer accounts. Youll help speed the upgrade process
and ensure a cleaner AD domain when the upgrade is complete.

Upgrade all NT domains, then merge them. If you have multiple NT domains, upgrade
each domain into a separate AD domain. Then move all the users and groups into your
root AD domain and decommission the other domains.

55

Chapter 7
The last tip is the toughest one to architect. Ideally, the first NT domain you upgrade should
become a new AD root domain. Subsequent NT domains should be upgraded into child domains
of that root. This process makes an easy task of migrating the child domain users and groups into
the root domain and collapsing the structure into a single root domain. If there are political
reasons that prevent you from taking this approach, migrate each NT domain into a separate AD
root domain. Create trusts between those roots to form a forest, then move users and groups from
domain to domain until everythings where you want it to be. You can then decommission any
empty, unused domains.

56

Chapter 7

Copyright Statement
2001 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are
protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web
site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtimepublishers.com, please contact us via e-mail at
info@realtimepublishers.com

57