Windows 2000 and Active Directory Administration

...4 Programming the Script ...5 Assigning the Logon Script ...6 Q 1.4: Does Active Directory support inheritance for permissions on objects in the directory?. Doesn’t that mean placing

and Active Directory Administration

Don Jones

Keep sponsor logos below here

Tips and Tricks Guide Totm

r e a l t i m e p u b l i s h e r s c o m

TM

Note to Reader: This book presents tips and tricks for seven Windows 2000 and Active

Directory Administration topics For ease of use, the questions and their solutions are divided into chapters based on topic, and each question is numbered based on the chapter, including:

• Chapter 1: Daily Administration

• Chapter 2: Domain Controller Administration

• Chapter 3: Replication Management

• Chapter 4: Security Administration

• Chapter 5: Disaster Recovery

• Chapter 6: Tools and Utilities

• Chapter 7: Migration

Chapter 1: Daily Administration 1

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? 1

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? 2

Q 1.3: How can I write a logon script that checks for group membership? 4

Programming the Script 5

Assigning the Logon Script 6

Q 1.4: Does Active Directory support inheritance for permissions on objects in the directory? 9

So…No Inheritance? 10

OK…Some Inheritance 11

Q 1.5: Why should I use the Active Directory Service Interfaces clients for Windows 9x and Windows NT? 11

Supported Functionality 11

Unsupported Functionality 12

Where Can I Get It? 12

Q 1.6: I need to change a lot of information in Active Directory Is there an easy way to manipulate that data other than using the Users and Computers console? 13

Bulk Import/Export 13

Using LDIFDE 14

Breaking It Down 15

Understanding LDIF 15

Scripting 16

Q 1.7: Is there any way to control permissions inheritance in Active Directory? 17

AD’s Default Inheritance Handling 17

Configuring Inheritance for AD Permissions 19

Q 1.8: We’re delegating Active Directory administration to different groups in our organization, but the built-in administrative tools are confusing users because the tools offer so much more functionality than we’re delegating What can we do? 22

Chapter 2: Domain Controller Administration 27

Q 2.1: Where should I place Global Catalog servers, and how many do I need? 27

Deciding Where to Place GC Servers 27

Making a GC Server 28

Q 2.2: Where do I put FSMOs? 29

Deciding Where to Place FSMOs 30

Transferring FSMOs 31

Transferring the RID Master, PDC Emulator, or Infrastructure Master 31

Transferring the Domain-Naming Master 32

Transferring the Schema Master 32

Q 2.3: How do I handle a FSMO failure? 33

What to Do When a FSMO Fails 34

Seizing FSMOs 34

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

Installing the Database Object 37

Domain Controller Performance Tips 38

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

Q 2.6: I want to make sure that my users can always log on Doesn’t that mean placing a domain controller in every location that has users? 42

A History of Domain Controller Placement 43

How Windows 2000 Learned from History 43

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? 45

Lookups with Earlier Clients 45

Lookups with Later Clients 46

Q 2.8: We have a large, multi-domain forest We’re installing a new application that modifies Active Directory’s schema, but we need to document those changes before we allow the application to do so The application doesn’t indicate exactly what changes it will make What can we do? 47

Q 2.9: How should I configure Domain Name System on my domain controllers? 48

Q 2.10: What’s a good first troubleshooting step when I’m having problems with Active Directory? 50

Q 2.11: How can I defragment Active Directory’s database? 52

Offline Defrag 53

Defrag and Replication 54

Q 2.12: We have several sites in our Active Directory domain At some sites, one domain controller in particular seems slower than others What can we do to troubleshoot the problem?54 Chapter 3: Replication Management 57

Q 3.1: After I make a change in Active Directory, the change doesn’t seem to take effect for quite a while What can I do to make this process faster? 57

Faster Replication 58

Making Changes Close to Home 60

Q 3.2: How do I troubleshoot Active Directory replication? 61

Multiple-Master Replication 61

How Replication Works 62

Handling Conflict 62

Replication Loops 62

Replication Topology 63

Managing Replication 64

Solving Problems 64

Q 3.3: How does Active Directory delete records? 64

Modifying AD’s Default Behavior 68

Creating Your Own Site Link Bridges 69

Q 3.5: We have many domains and sites in our organization, and Active Directory replication seems very slow What can we do to improve performance? 70

Q 3.6: We’re having problems configuring Active Directory replication to pass through a firewall Which port should we check first? 72

Chapter 4: Security Administration 74

Q 4.1: I want to distribute the management of the users and groups in my Active Directory What’s the best way to proceed? 74

Q 4.2: We want to delegate new user account creation to our Help desk, but we’re concerned that user information won’t be entered consistently What can we do? 77

Setting Up Policies in Enterprise Directory Manager 79

Working Behind Enterprise Directory Manager’s Back 80

Q 4.3: We’ve organized Active Directory to fit the way we manage it, but that makes our Group Policies very difficult to apply What should we do? 81

When One Organization Isn’t Enough 81

Can’t You Have Two Organizations? 82

So What’s the Best Organization for AD? 82

Q 4.4: I’ve heard that SYSKEY can be used to protect Windows 2000 against several security holes How does it work? 83

What SYSKEY Fixes 83

Using SYSKEY 84

Do You Need SYSKEY? 85

Q 4.5: How can I prevent users from changing their personal attributes in Active Directory? 85

Editing the Schema 86

Reapplying Default Permissions 89

Q 4.6: How do I configure the Kerberos authentication protocol? 89

How Kerberos Works 89

Logging On 90

Accessing Resources 90

Configuring Kerberos 92

Q 4.7: We’re trying to make our domain controllers as secure as possible What ports can we lock down without affecting Active Directory? 94

Default Ports 94

Locking Down Ports 98

Chapter 5: Disaster Recovery 101

Q 5.1: How can I prepare for Active Directory disaster recovery? 101

Don’t Put All Your Eggs in One Basket 101

Backup and Restore 103

Non-Authoritative Restore 104

Authoritative Restore 104

Testing Your Backups 105

Q 5.2: Someone accidentally deleted several users from Active Directory We have a backup, but how can we restore just the missing objects? 106

The Hard Way 106

The Easy Way 107

Q 5.3: Our IT management is centralized, but our domain controllers aren’t We need some way to centralize our disaster recovery operations What can we do? 109

Q 5.4: What is the best overall strategy for backing up Active Directory? 111

Back Up Two Domain Controllers 112

Back Up to Disk 112

Back Up Frequently 112

The Ideal Backup Strategy 112

Q 5.5: One of our domain controllers crashed What’s the easiest way to restore its copy of the Active Directory database? 114

Restoring AD 114

Reinstalling AD 114

Q 5.6: I’ve heard that it’s unsafe to perform a repair installation on a domain controller What should I do instead? 114

Manual Repairs 115

Fast Repairs 115

Be Prepared for Repair 116

Chapter 6: Tools and Utilities 117

Q 6.1: How can I automate the process of adding users? 117

The ADDUSERS Script 117

The ADDUSERS Spreadsheet 120

Q 6.2: What is the ADSI Edit tool? 121

Starting ADSI Edit 121

Using ADSI Edit 122

When You’ll Need ADSI Edit 122

Q 6.3: What is DSACLS? 123

Q 6.4: What’s the difference between REPLMON and REPADMIN? 124

REPADMIN 125

Checking Replication 125

Forcing Replication with a Specific Partner 126

Force Replication with all Replication Partners 127

Display Replication Data 127

Check to See Whether an Object is Up-to-Date 128

REPLMON 128

Q 6.5: What is MOVETREE used for? 129

Q 6.6: How can I use NTDSUTIL to manage the Active Directory database? 130

How NTDSUTIL Works 131

Common Commands 132

Authoritative Restore 132

Files 132

IP Deny List 133

Metadata Cleanup 133

Roles 133

Additional Commands 134

Automating NTDSUTIL 135

Chapter 7: Migration 136

Q 7.1: I need to decide on a name for my new Active Directory domain What name should I use? 136

You Have an Internet Domain Name Hosted by Your Internet Service Provider 136

Examine Your Current Situation 136

Decide What to Do 137

You Already Have an Internet Domain Name That You Host 139

You Don’t Have a Domain Name Registered on the Internet 140

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

SID History and Migration Problems 141

Migrating: Tons of Work 142

Upgrades Make Things Easier 142

Up-to-Date Best Practices 142

Q 7.3: I’m migrating several Windows NT domains into a single Windows 2000 domain The NT domains contain several groups with the same names Is it safe to merge the groups? 143

Merging Global Groups 144

Handling the Merge 146

Q 7.4: We’re trying to migrate multiple Windows NT domains into a single Windows 2000 domain, but management doesn’t want to lose the control they have with multiple domains What should we tell them? 147

The Case for Multiple Domains 147

The Case for Multiple Domain Trees and Multiple Forests 148

Sharing Between Forests 149

Q 7.5: We migrated our user accounts to Active Directory, but users' local computer profile settings were lost What can we do? 150

SID Histories and Local Profiles 150

Local Profiles Don’t Care About SID History 150

Why Migrating Breaks User Profiles 151

Fixing the Problem 151

Q 7.6: We have a lot of Windows NT file servers that have a lot of very specific NTFS

permissions What do we need to do to migrate these permissions to Active Directory? 153

Microsoft’s ADMT 153

Aelita’s Domain Migration Wizard 153

Q: 7.7: What little gotchas should we look out for during a migration to Active Directory? 154

Time Synchronization 154

Run Your Migration Tool on a Domain Controller 155

Password Policy Mismatch 155

Consistency Problems 155

Carefully Migrate Users and Groups from Multiple Domains 155

Cautiously Migrate Groups 156

Q 7.8: Should I upgrade or migrate? 156

Q 7.9: Before we migrate, we’re trying to clean up our Windows NT domain, deleting unused user accounts and groups What is the easiest way to accomplish this task? 157

What the Script Will Do 157

Writing the Script 158

Putting It All Together 159

Q 7.10: We’ve upgraded our Windows NT Primary Domain Controller to Windows 2000, and our Windows 2000 Professional computers are inconsistent about receiving Group Policy Any explanation? 160

If You’ve Already Upgraded Your PDC 161

If You Haven’t Upgraded Your PDC Yet 162

Q 7.11: How can I look up the SID history for migrated accounts? 162

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, non-commercial 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

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: You’ve stumbled across one of the unavoidable problems of a multimaster directory

environment As you’re 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 object—for

example, both administrators reset a specific user’s password at the same time—AD 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 replicating—as 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 you’re making at another site

AD could respond by not creating the group This solution isn’t great, though, because you might

be relying on the group—after all, the administrator who deleted the OU didn’t know the group existed at the time The situation’s 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

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 clicking it, then selecting Move from the resulting pop-up menu

right-LostAndFound isn’t a Recycle Bin! right-LostAndFound will not protect you from accidentally deleting an object For example, when you delete an OU, all the objects within that OU—users, groups, and other OUs—are 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 can’t be removed

Make a backup! Before you even consider modifying the schema in your production domain, make a complete backup of AD That way you’ll 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 you’re 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 aren’t 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 shouldn’t have any trust relationships with any other domains The test domain allows the application to modify the schema without permanently affecting your production domain’s schema

If you decide to keep the application, you can install it in your production domain when you’re ready to begin using it Either way, you can decommission the test domain once you’re done testing the application

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

• The forest’s 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

Can’t find the schema master? If the designated schema master isn’t available, you can seize the schema master role on another DC 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 seized—doing so could corrupt your AD schema

Can't find the schema console? Microsoft doesn't want just anyone to jump into the Schema console

in Windows, so the Schema console isn’t available in the Add/Remove Snap-Ins list by default If this snap-in isn’t listed on your computer, you'll need to register it To do so, open a command-line

window, change to the Winnt\System32 folder, and type

regsvr32 schmmgmt.dll

You should see a message indicating that the registration was successful, and the snap-in should show up in the list

• The forest must be placed into schema-write mode Only members of the Schema

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 Schema Admins group are

actually allowed to change it That means you’ll need to run your application’s setup program while you’re logged on as a member of the Schema Admins group

Protect your Schema Admins Because Schema Admins have complete control over the AD schema and over every domain in a forest, you should ensure that members of the group use difficult-to- guess passwords Never allow an application to use a member of the Schema Admins group as a service account unless you’re absolutely certain that the application requires such powerful

credentials to work properly Finally, never allow any user (even yourself) to use a Schema Admins account for day-to-day work You should only log on as a Schema Admins member when you need to accomplish some forest-wide administrative task, such as modifying the AD schema

Once you’ve 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 Schema 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 logon—and logoff—scripts

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 hasn’t 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 Microsoft’s 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, you’ll need to first set up a VBScript logon script, and second, add that script to a Group Policy

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.1 shows, will determine the user’s 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, you’ll need to customize it First, change the domain name to match your own Next, you’ll 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 user’s 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

Listing 1.1: Example VBScript to determine whether a user belongs to a user group

The following steps walk you through the script’s process:

1 The script creates a reference to the Windows Script Host’s (WSH’s) Network object, which exposes information about the user’s network environment The reference is saved

in a variable named objNetwork

2 The script saves the user’s ID in a variable named strUser The ID is obtained from the Network object

3 The script uses ADSI’s 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

4 The script uses the group’s IsMember method, passing an ADSI reference to the user’s user account in AD The IsMember method returns either a zero or a one, which is stored

in the varMember variable

5 Finally, an If…Then 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 If…Then 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 SDK’s 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 you’ll 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

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

Figure 1.4: Logon Script properties

8 Click Add to add a new script

9 Click Browse to locate your script’s 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 don’t have the ability to load the scripts out

of AD and execute them If your network contains earlier client computers, you’ll have to provide logon scripts that are compatible with them

Q 1.4: Does Active Directory support inheritance for permissions on objects in the directory?

A: The knee-jerk reaction is “of course,” because Microsoft has definitely got us all thinking

that inheritance is great stuff and that Active Directory (AD) is chock-full of it Unfortunately, though, the real answer to this question is “sort of, but not by default, and not like you might think.”

Imagine that you’ve created an organizational unit (OU) named Aelita in your domain Under it, you create two sub-OUs, named East and West By default, the permissions on the Aelita OU will look like the ones in Figure 1.5

Figure 1.5: Default permissions on an OU

To enable the Security tab on an OU’s properties dialog box, you’ll need to enable Advanced Options

To do so, from the View menu in the Active Directory Users and Computers Microsoft Management Console (MMC), select Advanced Options

Notice that the Allow inheritable permissions from parent to propagate to this object check box

is selected in Figure 1.5 This selection means that any permissions that an object can inherit from the OU’s parent will do so The permissions shown, in fact, are the default permissions on a new OU The permissions on the East and West OUs are exactly the same

Now, add a user to the list of permissions on the Aelita OU As Figure 1.6 shows, I’ve manually edited the security permissions to give Cook E Jarr full control over the Aelita OU

Figure 1.6: Adding a user to the OU’s security list

If AD completely supported inheritance by default, the East and West OUs would also include

Mr Jarr’s name on their Security tabs Looking at the properties of the East OU, which Figure 1.7 shows, you can see that such isn’t the case

Figure 1.7: Security properties for the East OU

So…No Inheritance?

AD supports inheritance by default only on the default permissions that AD applies to an object

Any permissions that you add manually do not inherit by default “Now, wait a second,” you’re

thinking, “I used the Delegation of Control Wizard last week, and inheritance seemed to work fine.” True The Delegation of Control Wizard makes inheritance work by changing some of

AD’s default settings When you run the wizard, it manually applies inheritance attributes to the object you’re delegating control over

OK…Some Inheritance

By default, AD supports inheritance-like behavior for group policies A group policy applied to

an OU will also apply to any child OUs, unless one of those child OUs specifically blocks policy inheritance And AD supports permissions inheritance for the permissions applied to objects by default

That AD doesn’t do inheritance by default is actually not a big deal After all, you shouldn’t usually modify permissions on AD objects manually—that’s why the Security tab isn’t displayed

by default You’re supposed to use the Delegation of Control Wizard, which takes care of

inheritance for you

Q 1.5: Why should I use the Active Directory Service Interfaces clients for Windows 9x and Windows NT?

A: Active Directory (AD) introduces a great deal of new functionality To fully take advantage

of that functionality, your client computers need to all be running Windows 2000 (Win2K) Professional or later But you can use a subset of AD’s functionality on earlier clients by using Microsoft’s Active Directory Service Interfaces (ADSI) clients for Windows 9x or Windows NT The ADSI clients install as additional network clients, much like the client for Microsoft

Networking or the client for NetWare Networking Keep in mind that the ADSI clients provide only a portion of AD’s total functionality

Supported Functionality

The ADSI client provides support for important user-interaction and security features The client provides about as much functionality as you can expect to get on the earlier client operating systems (OSs):

• The ADSI clients support site awareness, which includes the ability to log on to the domain controller that is closest to the client in the network Without this capability, Win9x and NT clients will authenticate to a random domain controller, even if they have

to transmit across a wide area network (WAN) to do so Also, Win9x clients normally require access to the Win2K domain controller that is acting as the Primary Domain Controller (PDC) emulator to change passwords The ADSI client allows Win9x clients

to change passwords on any domain controller

• The ADSI client includes the scripting interfaces that provide programmers with a way to access AD That means that you can write logon scripts and other scripts that use ADSI, and run those scripts successfully on your earlier client computers

• Normally, Win9x and NT clients can only access Win2K distributed file system (Dfs) roots that are standalone The ADSI client allows them access to Win2K Dfs fault-

tolerant and failover file shares specified in AD By using these more advanced Dfs shares, you can provide fault tolerance and reliability for your Dfs infrastructure, and the ADSI client allows your earlier client computers to remain compatible

• The ADSI client also provides access to the Active Directory Windows Address Book property pages These pages allow users (if they have permission) to change properties on user objects (for example, phone numbers and addresses) by using the user object pages, which they can access by clicking the Start menu, then pointing to Search and For

People This feature lets users easily modify their own information within AD, if they have permission to do so

• Finally, the ADSI client includes NT LAN Manager (NTLM) version 2 authentication NTLM version 2 offers improvements over the older NTLM protocol used by Win9x and

NT, and corrects many security flaws that exist in NTLM version 1

Unsupported Functionality

Although the ADSI client offers a lot of desirable functionality—especially the address book integration and ability to access fault-tolerant Dfs shares, it can’t change the fact that Win9x and

NT weren’t made to work in the Win2K world The ADSI client has the following limitations:

• The ADSI client doesn’t provide Kerberos support One big reason is that Kerberos tickets on a Win2K computer are cached in a special area of memory that can never be written to disk or even paged to the swap file Win9x and NT don’t provide any area of memory with that capability, raising the possibility of Kerberos tickets being written to unsecured areas of the disk and potentially compromised Providing Kerberos support in the earlier OSs would take a major architectural change, which is why Win2K exists

• The ADSI client doesn’t provide Group Policy or IntelliMirror support This limitation is definitely the biggest disappointment because there’s no technical reason that the earlier client OSs can’t support at least a subset of IntelliMirror’s functionality, such as the ability to deploy new software applications I suspect that Microsoft simply didn’t want

to invest time and money in bringing important new features to an earlier OS when it would be much easier for customers to simply upgrade Nonetheless, most of the

important features in Group Policy and IntelliMirror require functionality that was first introduced in Win2K, and retrofitting those technologies into Win9x or NT would have definitely been a challenge

• The ADSI client doesn’t provide IP Security (IPSec) or Layer 2 Tunneling Protocol (L2TP) support That isn’t a problem for most administrators Very few are using IPSec anyway, and anyone using L2TP to create secure virtual private networks (VPNs) has already purchased a third-party solution to do so

So although the ADSI client doesn’t eliminate the need to upgrade to Win2K (or Windows XP),

it does provide a stopgap solution that allows users of Win9x and NT to interact with your

Win2K network until their computers can be upgraded

Where Can I Get It?

The Win9x version of the ADSI client is included on the Win2K Server CD-ROM You can download the NT client from Microsoft’s Web site at

http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/adextension.asp You’ll need to use the old-fashioned ways of deploying the client to your computers, such as Microsoft Systems Management Server (SMS), logon scripts, or other techniques The ADSI

client supports a silent installation, which makes deploying the client to all your Win9x and NT computers easier

Don’t bother with the client if you don’t need its functionality The biggest features delivered by the ADSI client are site awareness, address book integration, and the ability to use fault-tolerant Dfs shares Decide if you need any of those features For example, on a small network, you might not care about site awareness If you’re not storing user information in AD yet, the address book

integration won’t interest you If you’re not using Dfs, or at least not using fault-tolerant Dfs shares, that capability won’t attract you, either

The ADSI client can’t deliver some of the most important features of Win2K, such as Group Policy and IntelliMirror support and Kerberos authentication If you don’t need the features the client can deliver, don’t bother deploying it to your computers

Q 1.6: I need to change a lot of information in Active Directory Is

there an easy way to manipulate that data other than using the Users and Computers console?

A: You bet Let’s take an example scenario Suppose that the post office has issued a new zip

code to your New York office, and you need to change all the zip codes you’ve stored in Active Directory (AD) The change only affects the users in your New York office, who are

conveniently grouped into an organizational unit (OU) named NewYorkCity The obvious way

to make the change is to open each user profile in the Active Directory Users and Computers Microsoft Management Console (MMC) and make the change one at a time That process would

be time consuming and might keep you away from watching paint dry, which would be just as exciting Fortunately, you’ve got a couple of alternatives: bulk import/export and scripting

Bulk Import/Export

Using AD’s bulk import/export capabilities is the easiest way to make data changes because it lets you use tools you’re probably already familiar with First, you need to get to know the basic import/export tools that Microsoft gives you:

• CSVDE.EXE is a command-line utility that imports and exports data from AD and

Comma Separated Value (CSV) files CSVDE’s biggest weakness is that it can only add new objects to AD—it can’t modify existing ones However, it does use an easy-to-understand CSV format, which you can work with in Microsoft Excel if you want to

• LDIFDE.EXE is another command-line utility This tool works with the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) file format, which is

an Internet draft standard The tool can export data into LDIF files, import new objects from LDIF files, and even modify existing objects based on information in an LDIF file

Using LDIFDE

Obviously, LDIFDE.EXE is the tool of choice in our example scenario We could use CSVDE only to import new users, which isn’t what we’re after To use LDIFDE.EXE, just follow these steps:

1 From a command line, type the following command to extract the required entries:

ldifde -f newyork.ldf -s dc01

-d "ou=NewYorkCity,dc= company,dc=com"-psubtree–

r"(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=company ,DC=com)" –l "postalCode"

2 Use Notepad, or your favorite text editor, to open the newyork.ldf file You’ll see two lines for each user, which look something like the following:

dn: CN=Administrator,CN=Users,DC=company,DC=com

changetype: add

postalCode: 77543

3 Modify the entries in Notepad to contain the correct information Each user’s entry

should look something like this

4 Save the new file Be sure to save it with an ldf file extension, not a txt file extension

5 Run LDIFDE to import the modifications into AD At the command prompt, type the following command, then press Enter:

ldifde –i -f newyork.ldf -s dc01

6 To confirm that the entries have been modified, check the Active Directory Users and Computers console

• The -f specifies the output file to which LDIFDE will write data

• The -s specifies the domain controller to which LDIFDE should connect to obtain data from AD

• The -d specifies the root, or starting point, of the export In this case, the root is the

company.com domain and the NewYorkCity OU

• The -p specifies the scope of LDIFDE’s search Acceptable values are subtree, which instructs the utility to search everything below the specified starting point; base, which searches only in the specified starting point; and onelevel, which searches up to one level below the starting point

• The -r specifies a filter In this example, LDIFDE will only return objects that are of the Person object type, so it won’t return computers and other objects

• Finally, the -l specifies the attributes that LDIFDE should return You can provide more than one attribute by separating them with commas within the quotation marks

The second command is a bit easier to follow:

ldifde –i -f newyork.ldf -s dc01

• The -i parameter indicates an import operation

• The -f and –s parameters specify the import file and the domain controller to connect with

Understanding LDIF

LDIFDE uses the import file as a set of instructions, and you can get pretty complex For

example, to execute multiple commands against a single object, separate the commands with a hyphen on a line by itself:

streetAddress = “123 Anywhere Street”

AD is case-sensitive, so be sure you capitalize attribute names properly

LDIFDE supports the following commands:

• Add, which adds an object

• Replace, which replaces an object’s attribute

• Delete, which permanently removes an object

Don’t guess attribute names Want to find out which names AD uses for the various attributes it stores? Execute a regular export query and omit the -l parameter LDIFDE will automatically return any attribute that has a value, allowing you to see which name AD uses for each attribute

Scripting

Writing scripts that modify AD can be time consuming at first, but it can also be pretty

rewarding You’ll learn more about AD, and you’ll discover ways to make other administration tasks a lot more efficient The following script uses the Active Directory Service Interfaces (ADSI) scripting interfaces to modify the zip code for every user in your NewYorkCity OU:

Set

oContainer=GetObject("LDAP://OU=NewYorkCity,DC=company,DC=com") ModifyUsers oContainer

Set oContainer = Nothing

The ModifyUsers subroutine does the real work First, it accepts the incoming OU and stores it

in a variable named oObject The script then applies a filter to oObject so that only user objects are available Next, the script uses a For…Each loop to examine each user in the OU, one at a time For each user that the script finds represented by the variable oUser, the script uses the Put method to set a new postalCode value The script then calls the SetInfo method to save the new postalCode value back to AD

Scripting is definitely the way to go with complex changes such as this change Although the script would take longer to put together from scratch than the LDIFDE method, the script

executes much more quickly and doesn’t require you to manually edit text files to get the new information into AD Once you know the names AD uses for its attributes, you can use the script

to change any of the attributes to anything you want

Q 1.7: Is there any way to control permissions inheritance in Active Directory?

A: In Question 1.4 of Chapter 1, I showed you how Active Directory (AD) provides inheritance

only for its own permissions, by default The Delegation of Control wizard allows inheritance to work for permissions you add because the wizard works closely with AD’s internal inheritance settings But if you manually edit the access control list (ACL) on an AD container, such as an organizational unit (OU), your changes won’t automatically be inherited the way that AD’s built-

in permissions are

You might be asking yourself “Hey, if the Delegation of Control wizard can do it, why can’t I set

up my manually created permissions to inherit?” Well, you can However, it requires you to dive into AD’s deeper levels of permissions functionality

In this tip, I’m going to show you how to modify some of AD’s inheritance values You should only take these steps if you’re completely comfortable with AD, and if you have a good, recent backup of

AD in case you mess up something Because you’ll be working with AD’s innermost security settings, it’s possible for you to remove AD’s default permissions and render the domain unstable or useless

As a best practice, I strongly recommend that you use the Delegation of Control wizard to modify AD permissions rather than edit AD’s permissions directly However, in some rare circumstances you might need to edit AD permissions and inheritance directly

AD’s Default Inheritance Handling

Figure 1.8 shows that a user named Cook E Jarr has been given permissions to an OU named Aelita That OU contains two other OUs, named East and West

Figure 1.8: Granting permissions to an OU

If you were to examine the permissions for the East OU, however, it hasn’t inherited Cook’s permissions, although it’s clearly marked to allow inheritable permissions from the parent to propagate Figure 1.9 shows the permissions for the East OU

Figure 1.9: As you can see, the manually-applied permissions for Cook E Jarr haven’t been inherited by the East OU

This behavior occurs by default for all manually applied permissions in AD When you use the Delegation of Control wizard, inheritance occurs automatically because the wizard automatically modifies AD’s inheritance properties when the wizard applies new permissions If you’re

careful, there’s no reason you can’t modify those inheritance properties on your own

Configuring Inheritance for AD Permissions

The trick is to click Advanced in AD’s permissions dialog box for the object for which you want

to manually apply permissions In this example, that would be the Aelita OU This OU’s

advanced properties are shown in Figure 1.10

Figure 1.10: Advanced security settings for the Aelita OU

Notice that the permissions for Mr Jarr show up, but the permissions are configured to apply only to this object, or, in other words, only to this OU You can select Cook’s permissions and click View/Edit to modify that setting As Figure 1.11 shows, you can select to which objects permissions will apply

Figure 1.11: Modifying inheritance of a permission

You can determine which types of objects each permission will apply to The common settings include:

• This object only—This setting applies the permission only to the current object,

effectively disabling inheritance for the permission This setting is the default setting for new permissions

• This object and all child objects—This setting turns on inheritance, propagating the permission to any child object that allows inheritance

• Child objects only—This setting causes the permission to be ineffective on the current object but to propagate to any child objects that allow inheritance For example, you might want to give an administrator the ability to create third-level OUs in a hierarchy,

but not be able to create second-level OUs You could apply the Create child objects permission to the top-level OU, and apply the permission to Child objects only The

administrator would be able to create child objects under the second-tier OUs, but not under the top-level OU

After you mark Cook’s permission as This object and all child objects, the security permissions

from the East OU will contain his permissions, as Figure 1.12 shows

Figure 1.12: Child objects inherit user permissions

Notice that the Read check box in the Allow column is selected but grayed That appearance is AD’s way of letting you know that the user has read permissions on this object that were

inherited from a parent object If you were to clear the Allow inheritable permissions from parent

to propagate to this object check box, Cook would lose his permissions to the East OU

Why manually edit inheritance? Most of the time, the Delegation of Control wizard will let you set up any permissions you need to, and will correctly configure inheritance for you If you choose to

manually edit inheritance settings, be careful because they can become very complex very quickly You can set inheritance to apply only to specific object types—such as computers or contacts—thus letting you create very complex, very specific sets of permissions and inheritance for job tasks within your business environment Try to use the Delegation of Control wizard whenever possible, and be careful if you need to manually configure inheritance within AD

Q 1.8: We’re delegating Active Directory administration to different groups in our organization, but the built-in administrative tools are confusing users because the tools offer so much more functionality than we’re delegating What can we do?

A: This situation is fairly common in organizations that choose to delegate Active Directory

(AD) authority For example, suppose you delegate the ability to manage a single organizational unit (OU) to a group of users so that they can create new user accounts If you give them the standard Active Directory Users and Computers console, they’ll be exposed to a lot of additional functionality that they can’t actually use, which can be confusing This problem can occur

whether you’re using Windows’ native administration tools or third-party administration tools There are two solutions to this problem, one using built-in features of the Microsoft Management Console (MMC) and one involving a third-party solution I’ll start with the built-in solution, which is less expensive but involves significantly more steps That solution involves using

taskpads, which can be created for the MMC and for many third-party administration tools Taskpads effectively reduce what your delegated users see through the MMC To continue with the delegated-OU scenario, suppose you only want your delegated users to see the users within their OU and be able to create new users Here’s how you can configure the MMC to meet those needs:

1 Launch the MMC in a blank console by selecting Run from the Start menu, typing

MMC

and clicking OK

2 Select Add/Remove Snap-Ins from the Console menu The MMC will display a list of current snap-ins (this list will be blank because this console is a new console) Click Add

to display a list of available snap-ins, as Figure 1.13 shows Select the Active Directory Users and Computers snap-in, and close the dialog boxes

Users still need the MMC and snap-in on their computer! Your users will obviously need the MMC on their computers, and they’ll also need whatever snap-ins you configure in a customized console

Figure 1.13: Adding the Active Directory Users and Computers snap-in

3 The console will now display the standard Active Directory Users and Computers

snap-in Your next step will be to reduce the functionality displayed by the console Select the

OU that the users will need to work with Then select New Taskpad View from the

Action menu

4 The MMC runs the New Taskpad View wizard, which walks you through the creation of

a new Taskpad View In the first dialog box of the wizard, select the type of view (a horizontal or vertical list) that you want the taskpad to use For this task, a horizontal list will probably work best

5 As Figure 1.14 shows, your next task is choose the target for the taskpad You can have the taskpad view apply to all items, such as the one currently selected (an OU), or just to the item you select In this example scenario, you only want the users to have access on one OU, so choose the option to target only the current tree item

Figure 1.14: Selecting the taskpad’s target

6 Provide a name and description for the new taskpad in the wizard’s next dialog box The New Taskpad View Wizard will complete, and the New Task Wizard will prompt you to add a new task to the taskpad You’ll be creating a task that lets users create a new user account in the OU

7 As Figure 1.15 shows, the New Task Wizard lets you select the type of task you want to create You can have the task run a menu command that’s available in the snap-in, launch

a command-line task, or navigate to a specific location within the snap-in In this case, the user will need to run the New User command, which is a menu command

Figure 1.15: Choosing the command type for the task

8 As Figure 1.16 shows, select the menu command to which the task will link Select the appropriate OU in the Console Tree window, and the Available commands window will display the menu commands associated with that OU Locate the New->User menu command and select it

Figure 1.16: Selecting a menu command

9 The next two dialog boxes in the wizard let you provide a name, description, and icon for the new task; provide the appropriate information After the wizard has finished, the MMC will display your new taskpad view

10 The taskpad is almost perfect, but it’s still showing the console tree From the Console menu, select Customize View As Figure 1.17 shows, clear the check boxes for items in the Customize View dialog box to hide everything but the taskpad from the console

Figure 17: Customizing the console view

11 Now your taskpad is the only thing shown within the console Next, prevent your users from changing the console back to its original appearance To do so, select Options from the Console menu, and configure the console for user mode, as Figure 1.18 shows This configuration restricts the user to a single window—your taskpad—and prevents the user from changing the console’s options

Figure 1.18: Configuring console options

12 Save the console and distribute the resulting MSC file to your users As Figure 1.19 shows, there will be no confusion about what functionality the users have, because the taskpad only displays what the users need

Figure 1.19: A stripped-down console with only a taskpad to work with

You can configure the MMC to provide almost any level of functionality within a taskpad, letting you create custom consoles that make your delegated users’ jobs easier Taskpads can also make your day-to-day administration easier by letting you focus on common jobs and

displaying just the information and tasks needed for that particular job

Taskpads are not a security mechanism! Taskpads don’t prevent users from doing things, they simply restrict a user’s ability to see other parts of snap-ins If a user is able to obtain a complete copy of

Active Directory Users and Computers, for example, they’ll be able to perform any task they have permission to perform

Thus, don’t rely on taskpads to restrict users’ permissions Instead, use the Delegation of Control Wizard to give users permissions to accomplish the tasks they need Taskpads only provide a way to simplify the user interface (UI) users see, making it less confusing for them to perform limited tasks You may even want to remove any default console icons, such as the one for Active Directory Users and Computers, to make sure that your users launch the correct console for their task

Another solution for this problem is to use a third-party AD management solution, such as Aelita’s Enterprise Directory Manager (EDM) or NetIQ’s Administration Suite For example, in the case of EDM, you could solve the problem by limiting the objects that users see and manage by creating what the utility refers to as Managed Units Managed Units are special administrative containers that can contain objects from one or more forests To limit what users can do, you can create and apply Access Templates and Policy Objects, which are rules that help you define management roles within the context of the utility To limit the functionality that users can see, you can customize both EDM’s MMC interface and the utility’s Web interface

Chapter 2: Domain Controller Administration

Q 2.1: Where should I place Global Catalog servers, and how many do

• 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 domain’s 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 aren’t using Exchange 2000 Server or later, you don’t usually need any additional GC servers That’s because clients don’t use a GC to look up information in their own domain—they use a domain controller instead

• Avoid having the domain controller holding the infrastructure master role also act as a

GC server The Infrastructure Master can’t operate on a server that hosts the GC If all

your domain controllers host the GC, you don’t need the Infrastructure Master because the domain infrastructure information is included in the GC

• 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 isn’t using Exchange 2000 Server, don’t 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

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

• 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 don’t 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 forest’s administrators These roles receive fairly little use and won’t significantly affect network operations if their servers fail, so placing them on a single server isn’t a bad idea

Don’t orphan your FSMOs! If you’re 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

• 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