Optimizing Active Directory Topology for Group Policy

By Roger Jennings

This is Chapter 2 of Admin 911: Windows 2000 Group Policy, published by Osborne/McGraw-Hill. For more information about this book and to order, please go to https://www.osborne.com .

The design of your organization's AD domain structure is your most important task as a Windows 2000 system admin. A substantial part of Microsoft's Windows 2000 Server documentation on Microsoft's Web site, the online help, and the Windows 2000 Server Resource Kit is devoted to optimizing your AD topology. Microsoft's design methodology takes into account geographical, organizational, political, networking, and Internet namespace constraints but devotes relatively little attention to the influence of AD topology on the effectiveness of Group Policy implementation.

On This Page

Adapting Group Policy Implementation to Migration Strategy
Implementing the Internal Domain Structure

Adapting Group Policy Implementation to Migration Strategy

Your Group Policy implementation strategy and, to a lesser degree, your final AD topology depends on your Windows 2000 migration strategy. The majority—probably 90 percent or more—of current Windows 2000 Server installations are upgrades to existing Windows NT networks. Microsoft's success in marketing Windows NT as application, file, and print servers means that upgrades probably will predominate over new Windows 2000 network installations through 2002 or later. A few courageous organizations began deploying Windows 2000 Server on an enterprisewide basis with release candidates. Most firms aren't willing to play the pilgrim role, so they delay migration to dramatically altered networking operating systems for a year or two after the initial release. The relatively slow initial acceptance of Windows NT Server 3.x followed by a very rapid increase of version 4.0 sales (and a corresponding decline in NetWare's market share) is indicative of the conservatism of IT departments of large organizations.

Note Microsoft's release in July 2000 of Service Pack 1 for Windows 2000 is indicative of the power of the "wait for the first service pack" dictum of respected industry analysts, such as GartnerGroup. It remains to be seen if fast-tracking SPs overcome IT departments' "if it ain't broke, don't fix it" policy for their existing Windows NT networks.

In the unlikely event that you're creating a Windows 2000 domain structure from scratch, for instance, for a new firm with no existing network (other than workgroup file and printer sharing), skip to the "Designing the Internal Domain Structure" section. If you've moved or intend to move NetWare users, groups, OUs, and other containers from a NetWare domain, start at the "Domain Restructure or Consolidation" section. For more information on migration strategies for NetWare, download Microsoft's NetWare to Windows 2000 Server Migration Planning Guide from https://www.microsoft.com/windows2000/techinfo/planning/incremental/netmigrate.asp .

Planning Client Migration to CCM

In contrast to the slow initial uptake of Windows 2000 Server licenses for production networks, Windows 2000 Professional is gaining corporate converts at a fairly rapid rate. Early adopters of Windows 2000 Professional fall into the following three migration categories:

• Installation on newly purchased PCs only The average three-year useful life span for existing desktop and laptop workstations results in a relatively long transition to a fully managed Windows 2000 environment. Up to two-thirds of the new clients might connect to Windows NT networks when adoption of Windows 2000 Server is delayed.

• Clean installs on new and some existing PCs Most business PCs purchased since early 1999 have the hardware horsepower to run Professional. This approach provides considerably faster migration to CCM-enabled clients, but doesn't solve the interim Windows NT networking problem. Microsoft recommends de novo installation where feasible and so does this book. If you've convinced your users to maintain all their local files under My Documents and, better yet, have desktop users storing My Documents in their home folder on a file server, clean installs on existing PCs are straightforward. Otherwise, backing up and wiping users' local disks, followed by a partial restore of user files, is a costly and chancy process.

• Clean installs on new PCs and upgrades to existing PCs This process usually results in a heterogeneous mix of CCM-enabled clients and unmanageable PCs beset with application and local file system anarchy. If you can avoid upgrading Windows NT and 9x clients, do so. The move to Windows 2000 Professional is the ideal time to convince users accustomed to desktop and laptop autonomy (or anarchy) that centrally administered CCM will make their lives easier and more productive. It's virtually impossible to fully CCM-enable upgraded PCs that haven't been subject to a tightly controlled application configuration by system policies, such as Run Only Allowed Windows Applications.

  Tip Use of the term personal computer within a corporate environment leads users to the mistaken belief that the computers they use and the files they store are their personal property. It's not uncommon to find local disk drives or file servers filled with MP3 files downloaded from the Internet. Placing new restrictions on client PCs leads to user bickering and, in some cases, revolts reminiscent of those that occur when replacing Macintoshes with Wintel machines. Before you begin your Windows 2000 migration, make sure that executive management understands that CCM is necessary to achieve any return on the upgrade investment. You also need top-management backing to alter users' understanding of who owns and is responsible for the configuration of and content stored on the firm's computers. Implementing CCM offers a once-in-a-decade opportunity to minimize potential legal liability for unauthorized or improper use of client computers.

A typical Windows NT network has between 25 and 100 clients per server, so the decisions you make for migrating clients to Windows 2000 have a more profound effect on total network management costs than decisions about server upgrades. Synchronizing the timing of client and server upgrades, however, also is an important factor in gaining the maximum return from your investment in deploying Group Policy.

Note The term users in this chapter applies to ordinary and power users, not admins, help desk technicians, and software developers.

Choosing the Server Migration Approach

There are two approaches to migrating from a Windows NT to 2000 network: in-place upgrade and domain restructure, which also is called domain consolidation. The choice you make between these two approaches, or how you combine them, has a major influence on the effectiveness of Group Policy deployment.

The first rule of AD topology is "simpler is better." A single domain for internal network users and computers in one tree of a forest is the optimal design, if your DNS namespace requirements permit. If not, consider changing your internal DNS namespace. Windows 2000's hierarchical OUs, and the ability to delegate administrative responsibility for OUs, takes the place of separate Windows NT domains created to distribute managerial tasks.

If your Web servers run under one or more ICANN-assigned (public) domain names, put them into separate domain trees that don't include the domain used for internal user and computer accounts. The "simpler is better" rule applies primarily to internal, not external, networks, where DNS namespaces and IP addresses are under your control, not that of ICANN or your ISP.

Note An exception to the single-domain rule might be justified if you have a geographically disperse organization with several thousand clients and a large number of Security Groups whose membership changes frequently. In this case, intersite AD replication traffic over slow (128 kbps or less) WAN links can consume a significant part of available bandwidth.

In-Place Windows NT Server Upgrade

Microsoft calls in-place upgrade the "easiest, least-risky route" to Windows 2000 networking, because you retain the existing domain structure, its user and computer accounts, and all security groups. Home folders, logon scripts, and other files (hopefully) aren't affected by the upgrade. Least-risk endeavors, however, traditionally return low dividends, and in-place upgrades are no exception. Your Windows 2000 domain structure mirrors that of the upgraded Windows NT domains, including any resource domains you've established. If your clients have fixed IP addresses, which was common in early Windows NT networks, your new Windows 2000 network inherits them. You're also stuck, at least temporarily, with the Windows NT DNS namespaces you've implemented, if any.

It's a common practice to conduct incremental in-place upgrades in the following stages:

1. Upgrade the account domain PDC to a DC. The first PDC you upgrade becomes the initial root domain DC, a Global Catalog (GC) server, and the PDC emulator for downlevel clients. As with a PDC, all additions and changes to user accounts (and computer accounts not in a resource domain) occur on the PDC emulator and replicate to Windows NT BDCs. Trusts with other Windows NT domains remain nontransitive.

2. Designate subnets connected by WAN links to the PDC emulator's subnet as Windows 2000 sites in preparation for upgrading remote account BDCs and resource domains.

3. Upgrade account domain BDCs to Windows 2000 DCs and place them in the appropriate site. Each site needs at least one DC for each domain the site contains; two DCs per domain per site are necessary for redundancy. Each site must have at least one DC designated as a GC server.

   Tip It's a good practice to designate all DCs as GCs, except the DC that handles the Infrastructure Flexible Single Master Operations (FSMO) role. Doing this improves logon redundancy for Windows 2000 clients at each site where you install multiple DCs, and it doesn't have a significant effect on intersite replication traffic.

4. Upgrade each resource domain PDC to a DC and assign the DC to its site; then upgrade resource domain BDCs.

5. When all PDCs and BDCs are upgraded to Windows 2000, convert the mixed-mode domains to native mode, which lets you nest Global groups and take advantage of Universal groups, plus a few other native-mode-only features.

   Tip In each of the preceding steps, a full, known-good current backup is critical, and two backups are better than one. In-place upgrades are a one-way process. Although upgrade failures are rare, they usually are fatal, especially if the failure occurs during promotion of the server to a DC. Protect against extended domain downtime by adding a temporary BDC, synchronizing it with the PDC just before the upgrade, and removing it from the network. If the PDC upgrade fails, you can promote the BDC to a PDC and reconnect it to the network.

In-place upgrades of account and resource domains dump all user accounts and security groups in the Users container and computer accounts in the Computers container. Security Ids (SIDs) of groups and users don't change during the upgrade. Neither User nor Computers are OUs, so it's up to you to move the individual user and computer accounts into the OU hierarchy you create for classification and delegation of management. If computer accounts are in an upgraded resource domain, users and their computers remain in different domains. This isn't a problem for system policy, which depends only on the user account, but it does complicate application of Group Policy, because Computer Configuration comes from the upgraded resource domain and User Configuration from the account domain. You can create in the resource domain a cross-domain link to the Default Domain Policy GPO in the user domain, but doing so causes a significant slowdown of user logons.

Note What does cause a problem with system policy is changing the group membership of a user subject to group-based system policy, which includes Windows 2000 clients whose user accounts are in Windows NT domains. If the user moves to a group with a different system policy (or no policy), the Registry of the user's computer is tattooed with the previous group's settings. Removing the spurious settings requires manual editing of the client's Registry.

Once you've converted the domains to native mode, you can consolidate the resource domains with the account domain by using Microsoft's Active Directory Migration Tool (ADMT) or a third-party Windows 2000 migration utility. Moving the computer accounts from resource domains into account domain OUs eliminates the need for individual domain GPOs or cross-domain GPO links. After the move, you decommission the upgraded resource domain by demoting the DCs to member servers and placing them in the account domain.

Note Microsoft describes the Computers container as the "Default container for upgraded computer accounts." In fact, it's the default container for all computer accounts, upgraded or not, unless you use RIS, RIPrep, or SysPrep to install Windows 2000 Professional on client PCs. Only automated installation lets you create Windows 2000 computer accounts in specified OUs. For reasons unknown, Microsoft didn't include a text box for a computer account OU in the installation dialogs. Unless you pre-create user accounts in OU(s), either individually or by scripts, manually added users fall into the Users container.

Domain Restructure or Consolidation

The alternative to in-place upgrade is to design your own domain and OU structure and use ADMT to import user and computer accounts into the structure. Domain restructure by cloning Windows NT directory objects in AD, called interforest migration, has the following advantages over in-place upgrade:

• You don't inherit the convoluted domain structure forced upon you by Windows NT's flat domain namespace.

• You can create and test your Group Policy and IntelliMirror implementations before you migrate users and computers to the new domain. This is an especially important feature of domain restructure. Altering desktop configuration and lockdown policies and adding or changing other features after new Windows 2000 users have joined the domain results in user dissatisfaction and a dramatic increase in help desk support cost.

• You can import user accounts directly into OUs by their group membership. This ability is contingent on your having a set of Windows NT security groups that correspond to your OUs for user accounts.

• You also can import computer accounts into OUs to selectively apply Computer Configuration policy, including security policies. Windows NT doesn't support security groups for computer accounts, but AD does. The Computer object is a subclass of the User object in Windows 2000, so you can treat Computer objects similarly to User objects.

  Note "Underclass of the User object" is a more apt description of the Computer object. Although you can assign individually named computer accounts to a Security Group from the Member Of page of the ComputerNameProperties dialog, you can't select sorted or filtered computer accounts in Active Directory Users and Computers' pane for the Computers container and use the Adds the Selected Objects to the Group You Specify button to establish group membership. The button is disabled, and there's no Add Members to a Group context menu choice when you select the Computers container. If you try to add all computer accounts to a group by selecting the Computers container in the tree-view pane, the operation fails. Chapter 3 deals with this issue.

• You can import user, computer, and service accounts, plus security groups from multiple Windows NT domains, to perform domain consolidation, which also is called domain coalescence or collapse. For instance, you can move computer accounts from resource domains into OUs of the account domain.

• The final selling point of domain restructure is that cloning user and computer accounts and security groups creates duplicates in the Windows 2000 domain that retain their Windows NT identities. If users have difficulty logging on or have other problems with the Windows 2000 domain, they can simply log on to their old Windows NT domain. Moving the computer account back to the original domain requires opening the computer's System Properties dialog and clicking properties to change domain membership in the Identification Changes dialog. In this case, however, the user gets a new local profile that doesn't contain settings for Internet Explorer, Outlook, or other messaging clients. Loss of long-established configuration settings is a serious inconvenience for most users.

  Tip The ability to move users and computers to and from the new domain is especially important when pilot-testing Group Policy with a small group of typical users of a particular category, such as Knowledge Worker or Mobile Worker. If your policies are too restrictive or cause users problems, you can return the user, computer, or both accounts to the original Windows NT domain until you fix the problems.

When you create a new User or Group object in AD (or in the Windows NT directory), it gets a new SID. The cloned user accounts, however, retain access to all resources in the Windows NT domain, and you can assign users and groups additional permissions for resources in new Windows 2000 domains. The attribute responsible for this magic is SIDHistory, which holds a copy of the SID of the user and groups from the Windows NT (source) domain. When users log on to a native-mode domain, the access token contains both the Windows 2000 SIDs and those in the SIDHistory attribute of the user's account.

The Windows 2000 domain must run in native mode to support SIDHistory.

Code Blue To clone accounts from a trusted Windows NT domain to a native-mode Windows 2000 domain that was upgraded from a Windows NT PDC, you must re-create the DCs' trusts with other Windows NT source domains before using ADMT to migrate user accounts. Windows 2000 upgraded DCs have downlevel trusts with other Windows NT domains; downlevel trusts don't support SIDHistory. Use the DC's Active Directory Domains and Trusts tool to delete and re-create the trusts with other Windows NT domains before running ADMT. For more information on this issue, refer to Microsoft Knowledge Base article 256250, "ClonePrincipal and ADMT Require Uplevel Trust to Migrate Objects Between Windows 2000 Domains."

Note Appendix C describes how to use ADMT for interforest domain migration. Microsoft offers an 11-chapter "Domain Migration Cookbook" that you can download from https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookintr.mspx . The "Cookbook" uses ADMT for domain migration and restructuring.

Interforest domain migration isn't limited to cloning Windows NT directory objects. You also can move AD objects between trees in two AD forests, but the move is subject to incomplete object migration if the schemas of the forests differ. Intraforest migration permits you to move objects between domains in the same forest of domain trees. It's the latter capability that lets you restructure multiple Windows NT domains you upgrade in place, assuming you adopted the standard practice of upgrading all domains into a single forest.

Domain Restructure Issues

Following are the primary problems you're likely to encounter when consolidating multiple domains with a large number of clients:

• Duplicate user logon IDs It's possible to duplicate account names in different domains, because the DOMAINNAME\LogonID combination identifies the specific account. User logon IDs within a domain, however, must be unique. ADMT offers an option to rename duplicate accounts by adding a prefix or suffix (see Figure C-15 of Appendix C). You can apply an LDAP filter in Active Directory Users and Computers to search for the prefix or suffix to find which logon IDs are duplicates.

• Identification of user accounts for classification by OU If security groups don't mirror OU membership, you need a method of identifying which users belong in a particular OU. Few admins take advantage of Windows NT's Description property of user accounts, and those who do aren't likely to have had OU membership in mind when adding the Description value. Consider adding a Description value with the OU name at the beginning or end of the field. LDAP filters have Begins With (*string) and Ends With (string*) conditions, but not an "Includes" (*string*) condition. This omission is the subject of many complaints that have gone unanswered by Microsoft.

• Identification of computer accounts for OU classification The situation here is worse than for user accounts. Windows NT has a Description property for Computer objects, but AD doesn't. Even if you've added a description that can be used to classify computers, it doesn't propagate to the AD Computer object's Description attribute. This is another unsolved mystery of object migration from Windows NT to 2000. Create a worksheet with columns for NetBIOS names and the names of their target OUs.

  Note Duplicate computer account names should never occur, because computer NetBIOS names must be unique within the entire network.

The Windows 2000 Resource Kit includes a Deployment Scenarios foldout map that illustrates implementation of a child or grandchild domain at each site and use of a site-domain-function-number code (SEA-RK-DC-01, for example) for naming servers. This naming convention is quite satisfactory for servers, but isn't suitable for clients. A better approach for naming new clients is to use a prefix to uniquely identify the OU to which the computer belongs, followed by a serial number and, optionally, a suffix to identify the site, type of computer (such as desktop or laptop), or both. The examples in this book use three prefixes, FAC, NFS, and STU, to identify faculty member, nonfaculty staff, and student computers, respectively. A nine-digit ID number (the Employee ID of the user to which the computer is assigned) follows the prefix. When you run the Admin911: GroupPol application under Windows 2000, the program associates computer accounts with user accounts. The only location in which the association appears as ComputerName (UserPrincipalName) is in Active Directory Users and Computers' Select Users, Contacts, or Computers dialog (see Figure 2-1).

Figure 2-1 Creating Windows 2000 computer accounts with the GroupPol application associates computer accounts with the User Principal Name (UPN). The disabled computer accounts (having a superimposed "X") represent Windows 9x computers that will be upgraded to Windows 2000 Professional.

Application of Group or System Policy to Windows 2000 Clients

If you install Windows 2000 Professional on clients in a Windows NT domain that implements system policies, the system policies are applied to Registry keys other than the protected keys that hold values set by Group Policy. The Registry tattooing occurs the first time the user logs on. Registry settings applied to Windows NT and 9x clients that you upgrade to Windows 2000 Professional remain in place. In either case, you're likely to find it difficult or impossible to reset the system policies by explicitly disabling them with the System Policy Editor. If you can't perform a full system policy reset from Poledit.exe, you must manually correct the errant Registry settings.

Tip You can avoid tattooing the Registry of new Windows 2000 clients by installing the computers and their user accounts in a new Windows 2000 domain, rather than the production Windows NT domain. To accomplish this, you use ADMT to clone Windows NT groups in the new domain, but don't add existing Windows NT and 9 x user or Windows NT computer accounts. Users gain access to resources in the Windows NT domain through the SIDHistory of the migrated security groups to which you add the user accounts. Be sure to establish Group Policy settings that emulate the existing system policy before you add production user accounts.

If you can't avoid having Windows 2000 user, computer, or both accounts managed by a Windows NT domain that implements system policy, or the clients already have their Registries tattooed, here's what you can expect:

• If both computer and user accounts are managed by a Windows NT domain, Local Security Policy is followed by computer and user system policy when the user logs on.

• If only the computer account is managed by the Windows NT domain, Local Security Policy is followed by computer system policy and the User Configuration class of Group Policy when the user logs on.

• If only the user account is managed by the Windows NT domain, Local Security Policy is followed by the Computer Configuration class of Group Policy and User System Policy when the user logs on.

The upshot of the preceding list is that Group Policy prevails over system policy when the Registry.pol file for computers or users is accessible to a Windows 2000 client.

Implementing the Internal Domain Structure

Using a single domain to hold all internal user and computer accounts, as mentioned earlier in the chapter, simplifies life for system and network admins. It's far easier to alter users' and computers' OU membership with the Move menu choice than to move these objects between domains with ADMT or another migration tool. The ability to apply specific policies to OUs is critical to client management in a single domain. The option to delegate management of client computer and user accounts to individuals who aren't members of the all-powerful Domain Admins group relieves the workload of network admins.

Tip In several documents, Microsoft suggests using multiple domains if domains require different security policies. A domain can have only one set of Account Policies, but other security policies can differ. Placing computer accounts in OUs lets you easily apply more stringent security settings or other Computer Management policies to particular sets of computers. The default Domain Controllers OU, into which Dcpromo.exe automatically places the computer accounts, is an example of applying security policies (in the Default Domain Controllers Policy) to computer accounts in an OU. You also can apply less stringent policies by blocking inheritance from the Default Domain Policy and applying a new set of security-related policies. Blocking Group Policy inheritance, however, isn't a recommended practice.

The pragmatic approach to AD domain design is to start with a single domain for internal users and computers and then determine—preferably in production—whether it meets the functional requirements and performance standards of your organization. If you're worried about DC replication traffic between sites, you can determine the extent of potential WAN bandwidth problems only after you've achieved a steady-state production environment. The compression of intersite traffic is very efficient and, after you've added the bulk of your users and computers to the domain, quickly tapers off. You can use Network Monitor or a network sniffer to determine the percentage of intersite bandwidth consumed by AD and Group Policy change replication.

Don't let the number of physical sites interconnected by WANs influence your domain design. Windows 2000's Knowledge Consistency Checker (KCC) uses a very sophisticated least-cost algorithm to optimize the routing of intersite traffic between sites, but the KCC bogs down with a large number of sites and DCs. If you're considering a multiple-domain model, bear in mind that each site requires a minimum of one DC—preferably two or more—per domain to enable local logon to each domain. Increasing the number of domains can lead to a dramatic increase in the total number of servers in the network. If you have a very complex configuration with many DCs, you might find it necessary to configure your replication topology manually.

An Example of Single-Domain Topology

The ability to classify users and computers within a hierarchy of OUs is the primary feature that distinguishes Windows 2000 domains from those of Windows NT. OUs make single-domain structures feasible, even for very large organizations. In most cases, you base the upper levels of the OU hierarchy on the organizational chart for the enterprise, rather than geographic location. Classification of user accounts by region is better accommodated at the lowest OU level, but grouping computer accounts by physical location lets you delegate computer management and help desk assignments on a per-site basis. The complexity and size of your organization is the primary determinant of the depth of the OU hierarchy. One of your OU design goals should be to limit OU membership to a manageable set of user or computer accounts; a few hundred accounts per OU is a good target.

Tip Active Directory Users and Computers sets a default 2,000-object limit for the right pane's list. To increase the number of viewable objects, you can choose View | Filter Options to open the Filter Options dialog. Type the maximum number of objects in the OU with the largest membership in the Maximum Number of Items Displayed per Folder text box. Browsing a large number of AD objects, however, consumes a substantial amount of server resources and, when conducted from a client, generates a large amount of network traffic. Use filters to generate LDAP queries that reduce the number of objects returned to a manageable value, such as 50 or fewer, to avoid swamping DCs with browse operations.

Most of the examples in this book use domains populated with AD objects by running the GroupPol application under Windows 2000. By default, GroupPol generates a single-domain (oakmont.edu) structure for Oakmont University, a fictional four-year institution in the Southwest. Oakmont U has 2,275 employees, of whom 1,448 are faculty members, and 25,344 full- and part-time students. If you don't have an existing test domain with numbers of user and computer accounts sufficient to emulate your anticipated production environment, you can use GroupPol to quickly create more than 27,500 user accounts and, optionally, the same number of computer accounts. Working with a large number of AD objects demonstrates the capabilities and pitfalls of Windows 2000's initial coterie of AD management tools.

Oakmont U classifies employees first as faculty members and nonfaculty staff and then by department, such as Anthropology and Information Technology. Students have their own top-level OU and are further classified by academic year—freshmen, sophomores, juniors, and seniors. Thus, employees and students both require a two-level OU structure. GroupPol adds optional computer accounts for employees and students in a Computers OU under each first-level OU. The program also installs 50 Computer Science laboratory computer accounts under the Lab Computers OU. Lab computers fall in the Public Computing Environment (PCE) category of the Microsoft Group Policy Scenarios discussed in Chapter 1. Figure 2-2 illustrates the structure of oakleaf.edu's three first-level OUs and their second-level OU members. Figure 2-3 shows Active Directory Users and Computers displaying the Non-Faculty Staff OUs and 10 of the 13 Security Groups in the top-level OU. Putting Security Groups in related OUs simplifies group management.

Note Leicester University ( https://www.leicester.ac.uk/ ) is an example of a very large organization (8,500 full-time students) that has implemented Windows 2000 with a single domain having multiple-level, nested OUs for organizing accounts. You can read an interview with Alistair Loew-Norris that describes Leicester University's Windows 2000 deployment at https://www.microsoft.com/windows2000/professional/evaluation/casestudies/ . The resemblance between the oakleaf.edu and le.ac.uk domain architecture is purely coincidental. Loew-Norris spearheaded Leicester's early Windows 2000 migration, which began during the beta-testing stage.

Figure 2-2 The oakleaf.edu domain example has a two-level OU hierarchy for classifying employees by department and students by academic year.

Figure 2-3 The Non-Faculty Staff OU contains second-level departmental OUs and Security Groups for staff members.

You use Security Group, not OU, membership to filter application of specific GPOs, as well as to control access to domain resources, including file shares, printers, scanners, CD burners, and the like. For example, faculty membership in five Security Groups (Deans, Chairpersons, Professors, Lecturers, and Teaching Assistants) is based on academic pecking order. Figure 2-4 illustrates group membership of a teaching assistant in the Anthropology department. If you were to use third-level OUs to classify faculty members by title, you'd end up with four sub-OUs for each of 14 academic departments, or a total of 71 OUs to manage. Of these OUs, 56 would require links to GPOs having policies suited to academic rank. Simplifying OU and GPO structures by applying Security Group filtering is the primary subject of Chapter 3.

Figure 2-4 Oakmonts U's faculty users are members of four Global groups, two of which reflect OU membership. The rank-based group (Teaching Assistants in this example) enables precise filtering of OUs by the users' authority levels.

Delegating Management of OUs

By default only Enterprise and Domain Admins and the System account have Full Control privileges for OUs. Local Administrators of DCs have Read, Write, and Create Child Objects permissions, but can't delete sub-OUs. Authenticated Users have only Read permission. After you've added user accounts, you can delegate management of the OU to an individual user or group with the Delegation of Control Wizard. To give the Wizard a test run, using oakleaf.edu's Anthropology OU as an example, do this:

1. Right-click the OU in the tree-view pane and choose Delegate Control to open the Wizard. Click Next to bypass the Welcome dialog.

2. In the Users or Groups dialog, click Add to open the Select Users, Computers, or Groups dialog.

   Note One incentive for the creation of multiple domains is the inane behavior of the Select Users, Computers, or Groups dialog. The dialog's Name list includes all security groups, and every member of the Domain Users andDomain Computers groups. Including computer accounts in the list more than doubles the number of objects loaded. In a domain with a very large number of users, populating the list takes forever. What's worse is that the list has no easily discernable order. Why one would even consider delegating control of an OU to a computer account is another Windows 2000 unsolved mystery. One explanation is an attempt by Microsoft to discourage browsing and encourage admins to type names in the text box and then click Check Names to run an LDAP query to find the desired object. Browsing a long list of AD object names is a very resource-intensive process for DCs and generates heavy network traffic.

3. Scroll to select or type the name of the user or group to whom you want to delegate control. You can add more than one user or group if you want. If you type the user names, separate multiple names with semicolons and click Check Names to verify your entries. Click OK to close the dialog and add the names to the Wizard's Users and Groups dialog (see Figure 2-5).

   

   Figure 2-5 Add the user or group accounts to assume management of the OU in the Delegation of Control Wizard's second dialog. In this example, Gary Almgren is the chairperson and Greg Allen is the dean of the Anthropology department.

   Tip You can type a first name in the Select Users, Computers, or Groups dialog and then click Check Names to display the Select Matching Items dialog, which lists accounts containing the name. Typing last names doesn't work, because the search is left to right against the users' display names. Select the user from the list and click OK.

4. In the Tasks to Delegate dialog, mark the check boxes of the permitted tasks for the delegates. Ordinarily, the Create, Delete, and Manage Groups and Manage Group Policy Links tasks should be reserved for Domain Admins (see Figure 2-6).

5. Click Next to display a summary of your selections in the Completing the Delegation of Control Wizard dialog; click Finish to dismiss the wizard.

6. To confirm the preceding wizardry, right-click the selected OU, choose Properties to open the OUName Properties dialog, and click the Security tab. Surprisingly, selecting a delegated OU administrator, listed here by the full display name (including the prefix), doesn't display the task permissions you set in step 4 (see Figure 2-7). Permissions don't appear on this page, because they apply to objects contained in the OU, not to the OU itself.

   

   Figure 2-6 The Delegate the Following Common Tasks option lets you choose the tasks to delegate. Selecting Create a Custom Task to Delegate and clicking Next leads to a dialog with a laundry list of more than one hundred AD objects that you can delegate.

   

   Figure 2-7 The Security page of the OUName Properties dialog adds the delegate names to the list, but doesn't display expected permissions for specific tasks.

   Note OUs inherit permissions from upper members of the hierarchy. The Allow Inheritable Permissions from Parent to Propagate to This Object check box, which is enabled by default, in this example inherits permissions from the Faculty Members OU and the oakleaf.edu domain.

7. Click the Advanced Button to open the Access Control Settings for OUName dialog, which displays the task permissions assigned to each delegate you selected in step 4 (see Figure 2-8).

   

   Figure 2-8 The Access Control Settings for OUName dialog gives you an overview of administrative permissions delegated for objects contained in the OU, in this case Group and User objects. The truncated Create/Delete permission applies to User objects only.

8. Double-click the permission entry or click View/Edit to open the Permission Entry for OUName dialog, which displays a list of additional tasks that you can delegate to the selected user or group (see Figure 2-9). Entries you make in this dialog apply directly to the Discretionary Access Control List (DACL) for the object(s), in this case group membership. The msExch... objects appear in the list only if you've installed Exchange 2000 or installed the Active Directory Connector (ADC) for Exchange 5.5+.

   

   Figure 2-9 You can apply or deny permissions for additional tasks in the Permission Entry for OUName dialog. Opening the Apply Onto list displays a long list of AD objects to which you can assign permissions.

   Tip Even if the Apply These Permissions to Objects and/or Containers within This Container Only check box is marked, delegated OU administrators can't alter users' Security Group membership if the group isn't contained in the OU. The check box affects only sub-OUs. In this example, attempting to add a new user account to the Faculty Members or any rank-based group fails because these groups are in the Faculty Members container, not the Anthropology container. You must explicitly delegate prerequisite task permissions in other OUs. For this example, select the Faculty Members OU and use the Wizard to assign Greg Allen and Gary Almgren Modify the Membership of a Group permission only. You can save considerable time and effort by assigning the permission to the Deans and Department Chairpersons groups, which also prevents cluttering the Security page's list with a large number of individual users.

9. Click OK or Cancel three times to return to Active Directory Users and Computers.

You can verify the task permissions you delegated by logging on as the delegate and attempting each task. If you verify task permissions at a DC, you must give the Authenticated Users group Log On Locally permission under the \Windows Settings\Security Settings\Local Policies\User Rights Assignment node of the Domain Controller Security snap-in. Confirm that task permissions are limited to the selected OU by attempting the same operations in a different OU. Remove the Log On Locally permission for Authenticated Users after completing the tests on a DC.

Setting the Managed By Attribute and Finding OUs by Attribute Value

Delegating management of an OU doesn't set the Managed By attribute of the OU, because you can delegate management to groups or multiple users, and Managed By is a single-valued attribute. If you delegate management of a significant number of OUs, set the Managed By property to the user account of the person directly in charge of the OU. Doing so enables you to use Active Directory's Find feature to list, for instance, all OUs that have been assigned (or not assigned) managers.

To set the Managed By attribute, try the following:

1. Open the OUName Properties dialog and click the Managed By tab.

2. Click Change to open the Select User or Contact dialog.

3. Scroll the list, which has a totally random sort order, select the manager entry, and click OK to add the attribute values.

To find all managed OUs in the domain, do this:

1. Select the DomainName node to specify the starting point for the search.

2. Click the Find Objects in Active Directory toolbar button to open the Find Users, Contacts, and Groups dialog; click the Advanced tab.

3. Select Organizational Units in the Find list, which changes the dialog name to Find Organizational Units.

4. Click the Field button and select Managed By from the list.

5. Open the Condition list, select Present, and click Add to add the condition to the list box. If you want to find undelegated OUs, select Not Present as the condition.

6. Click Find Now to display the OUs that meet your search criteria (see Figure 2-10).

   

   Figure2-10 Active Directory Users and Computers' Find feature lets you use an LDAP query to search for OUs or other objects that have (as shown here) or are missing attribute values.

   Note The GroupPol application has an option to add the Managed By, Manager, and Direct Reports values to objects contained in the Faculty Members OU, plus those in the Computers OU of the Non-Faculty Staff OU. The option adds the dean of the department as the OU manager; members of the Information Technology OU's Helpdesk Technicians group become managers of individual computers. You must add all 2,275 employees before the message box for this option appears in GroupPol's main window.

Relocating an Object to an OU with the Move Command

As mentioned earlier, relocating objects from one OU to another is much easier than moving them between domains. For instance, you might want to move the Lab Computers OU from the domain root to the Computer Science OU, because members of the Computer Science department are responsible for managing these computers.

To move a single object between OUs, run this drill in Active Directory Users and Computers:

1. Right-click the object—Lab Computers for this example—and choose Move to open the Move dialog.

2. Expand the tree to display the destination OU: \Faculty Members\Computer Science in this case.

   

1. Click OK to move the object to its new location.

Filtering Objects to Move Objects by LDAP Attribute Value Strings

You can use custom LDAP filters to specify a subset of objects in a container to move to an existing or newly created OU. For example, the Faculty Members, Computers OU contains 1,635 computer accounts, which exceeds the recommended "few hundred" objects. The GroupPol application adds a Description attribute value to Computer objects, which conveniently includes a (DepartmentName) suffix that you can use as a filter criterion.

Note Online help for Active Directory Users and Computers has only a single topic ("To select view filter options") on filtering objects, but the topic doesn't explain how to apply custom filters.

If you had the foresight to prefix or append a filterable criterion value to the objects you want to filter for movement to a new OU, you can do the following in Active Directory Users and Computers:

1. Create the new OU to contain the objects: in this case Anthro Computers under the Anthropology OU.

2. Select the source container—Faculty Members\Computers for this example—and click the toolbar's Set Filtering Options button (with the funnel icon) to open the Filter Options dialog.

3. Select the Create Custom Filter option and click Customize to open the strangely named Find Custom Search dialog. Select any existing criteria in the list and click Remove to delete them.

4. Click Field and choose Computer | Description to specify Description as the filtering attribute for computers.

5. For this example, select the Ends With condition, type (Anthropology) in the Value text box, and click Add (see Figure 2-11).

6. Click OK twice to close the two boxes and apply the filter to all objects except containers displayed in Active Directory Users and Computers.

   

   Figure 2-11 Custom filters let you select objects to move by attribute text values, but the Value string must be located at the beginning or end of the attribute value string.

7. Select the source container, which now displays only the objects meeting the filter criterion you specified in step 5 (see Figure 2-12).

8. Multiselect all objects in the list (click the first entry and then SHIFT-click the last entry), right-click the selection, and choose Move to open the Move dialog.

9. Expand the OU node to which you added the new OU in step 1, select the new OU, and click OK to move the selected objects. The Moving message box displays a progress bar during the move operation.

10. Click the Set Filtering Options button, select the Show All Types of Objects option, and click OK to remove the filter.

11. Verify the move by selecting the destination OU and checking its membership.

    

    Figure 2-12 When you apply a standard or custom filter to objects in Active Directory Users and Computers, the header of the right pane includes a [Filter Activated] message. Microsoft's developers should have made [Filter Activated]'s color red and applied the flashing attribute.

    Tip Always remove the filter immediately after you move the selected objects. One of the primary sources of administrative confusion after filtering operations is accidentally leaving the filter in place when its job is done.

Filtering Objects to Move by Security Group Membership

Security Group membership is the most common criterion for selecting user accounts to move into a new OU. Group membership is ADMT's only criterion for assigning users to OUs during domain restructuring. It's reasonable to assume that the process of filtering by group membership be essentially the same as that for filtering by attribute value strings—so you select User, Group Membership, use Is Exactly as the condition, and type the group name in the Value text box. Unfortunately, this approach fails. It's ironic that Microsoft provides no online help topic or, when this book was written, no Knowledge Base article on this issue.

Note Help topics for Advanced (LDAP) searches also are missing from online help and the Knowledge Base. Advanced searches use an obscure LDAP query dialect that's defined by RFC2254, "The String Representation of LDAP Search Filters," which you can read at https://www.cis.ohio-state.edu/htbin/rfc/rfc2254.html . If you're interested in learning more about LDAP queries, which the GroupPol application uses to set the Managed By attribute of OUs and Computer objects, download the Active Directory Service Interfaces (ADSI) 2.5 help file from https://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/adsilinks.asp .

Filtering by group membership, which searches Member Of attribute values, requires you to supply the Distinguished Name (DN) of the group as the filter value. The DN specifies the LDAP path to an object in AD. You can use the ADSI Edit support tool to display the DN of each AD object in the default domain (see Figure 2-13) or any other accessible Windows 2000 domain. Choose Programs | Windows 2000 Support Tools | Tools | ADSI Edit to open the application, and expand the container that holds the Security Group by which to filter. CN is the LDAP abbreviation for Common Name, in this case the name of the group, followed by the OU in which the group is located and the two Domain Components (DCs) of the oakmont.edu domain.

Note The GroupPol application displays the DNs of objects in the domain you specify in the startup dialog (see Figure B-6 in Appendix B). The LDAP:// prefix is a part of the full LDAP path to an AD object but is not a component of the DN.

Figure 2-13 ADSI Edit displays the DN of each object in the AD hierarchy in the Distinguished Name column. The Professors group (CN=Professors,OU=Faculty Members,DC=oakmont,DC=edu) is used as the example for filtering by group membership.

Do the following to move accounts filtered by group membership:

1. Create the new OU to contain the objects: in this case Anthro Profs under the Anthropology OU.

2. Click the toolbar's Set Filtering Options button to open the Filter Options dialog, select the Create Custom Filter option, and click Customize to open the Find Custom Search dialog. Delete existing criteria from the list.

3. Click Field and choose User, Group Membership from the context menus.

4. For this example, select the Is Exactly condition, type the DN in the Value text box, and click Add. For this example, the DN is CN=Professors,OU=Faculty Members, DC=oakmont,DC=edu, because the Faculty Members OU contains all faculty-specific groups.

5. Click OK twice to close the two boxes and apply the filter.

6. Select the source container, which now displays only the objects meeting the filter criterion you specified in step 4 (see Figure 2-14). If you've provided values for an attribute that corresponds to the group, horizontally scroll to the attribute's column to verify that the selection met your objectives. For this example, "Professor" in the Job Title column confirms membership in the Professors group.

   Tip If the attribute you need to use to confirm the filtered list isn't present in the Name pane, choose View | Choose Columns to open the Modify Columns dialog. Double-click the column name in the Hidden Columns list to add it to the Displayed Columns list and then click OK. You can change the new column's location by selecting its title bar and dragging it to the left or right.

   

   Figure 2-14 In the oakleaf.edu sample domain, successful filtering by Group Membership displays only users with membership in the Professors Security Group.

7. Multiselect all filtered objects in the list (excluding groups or OUs), right-click the selection, choose Move to open the Move dialog, select the new OU, and click OK to move the selected objects.

8. Click the Set Filtering Options button, select the Show All Types of Objects option, and click OK to remove the filter.

   Tip You can narrow membership in a filtered set by adding multiple filter criteria. For example, you can limit the filtered set to users who are members of two or more specified Security Groups (that is, members of Group1 andGroup2). Unfortunately, Microsoft developers didn't implement a logical or feature (members of Group1 or Group2).

Multidomain Topology

Circumstances might dictate a multiple-domain design, either at the start of the design process or during development and testing. For instance, you might not want to mix special external and internal user accounts in a single domain because of security issues. You might have become frustrated with the Users, Computers, and Groups dialog's slowly generating a list of 2,000 AD objects each time you open it. You can add new domains as children of the first (parent) domain you created or as the first member of a new tree in the initial forest. Administrative costs are the primary factor in the decision between adding child domains or new trees in the forest.

If you decide to split a domain after adding user and computer accounts, you usually perform an intraforest migration of selected user and computer accounts into the added domain. For example, Oakleaf U's system admin might decide that students should have their own domain, students.oakleaf.edu, for security purposes or to apply a significantly different set of policies to students. Following are the basic steps for adding a new child domain and then using ADMT to move or copy selected user groups and accounts to the new domain:

1. Add the new domain by running Dcpromo.exe on a Windows 2000 member server.

2. Create a set of Global groups containing the members of each user account OU you intend to migrate, if such groups don't exist.

3. Create a corresponding set of OUs in the new domain to hold the user accounts.

4. Use ADMT to migrate (copy) Global groups to which users belong, but don't determine user membership in OUs. This step is required for users to maintain their group memberships during migration.

5. Migrate the Global groups created in step 2 and their user accounts to the OUs you added in step 3.

6. Migrate computer accounts.

   Note You can use the Movetree.exe command-line program, a member of the Windows 2000 Support Tools, to move objects between domains in a forest, but using ADMT is much easier.

Adding a New Child Domain

The process of creating a child domain is quite similar to that which you used when promoting your first Windows 2000 member server to the initial root domain for your network. To add a child domain, do this:

1. If you have an OU in the parent domain with the same name as the child domain you intend to create, change the OU's name.

   Note You receive a misleading "Directory service is busy" error message during the server promotion process if a parent domain OU has the same name as the child domain. A similar error message appears if you attempt to create a new OU in the parent domain with the same name as that of a child domain. The problem is a duplication of Relative Distinguished Names (RDNs), which Knowledge Base article 240147, "Cannot Create an Organizational Unit in the Parent Domain with the Same Name as a Child Domain in Windows 2000," explains. For this example, you can rename the Students OU in the oakmont.edu domain to Student. Changing the Students OU name prevents adding more student accounts with GroupPol. Alternatively, specify Student as the child domain name in step 7.

2. Verify in the DNS page of the Internet Protocol (TCP/IP) Properties dialog of your network connection that the Preferred DNS Server text box contains the IP address of the parent domain's DNS server.

3. Run Dcpromo.exe to start the Active Directory Installation Wizard and click Next to bypass the Welcome dialog.

4. In the Domain Controller Type dialog, select the Domain Controller for a New Domain option and click Next.

5. In the Create Tree or Child Domain dialog, select the Create a New Child Domain in an Existing Domain Tree option and click Next.

6. In the Network Credentials dialog, type your user name and password for your Domain Admins account in the parent domain and change the Domain entry, if necessary. Click Next.

7. In the Child Domain Installation Dialog, accept or change the Parent Domain value and type the Child Domain name. As you type, the Complete DNS Name of New Domain text box displays the full childdomain.parentdomain.ext value: students.oakmont.edu for this example. Click Next.

8. In the NetBIOS Domain Name dialog, accept the default or change the NetBIOS name (STUDENTS) used by downlevel clients; then click Next.

9. In the Database and Log Locations dialog, accept the default folders, unless you have a reason to change them, and click Next.

10. In the Shared System Volume dialog, again accept the default unless you want to put Sysvol on another drive. Click Next.

11. If you don't need to support Windows NT Remote Access Service (RAS) on servers or assignment of Windows 2000 users to Windows NT resource server groups in a mixed-mode domain, select the Permissions Compatible Only with Windows 2000 Servers option. Otherwise, accept the default Permissions Compatible with Pre-Windows 2000 Servers option, which grants the Everyone group permissions for specific folders and other objects that ordinarily restrict access to members of the Authenticated Users group. Click Next.

    Tip Don't select the Permissions Compatible Only with Windows 2000 Servers option until you've upgraded all Windows NT resource servers to Windows 2000. Knowledge Base articles 257988, "Description of Dcpromo Permissions Choices," and 257942, "Error Message: Unable to Browse the Selected Domain Because the Following Error Occurred...," describe the consequences of selecting this option. You can't change the option you select in this dialog without demoting the DC and starting over.

12. In the Directory Services Restore Mode Administrator Password dialog, type and confirm the password to use to remove the domain or administer it with the Ntdsutil.exe command-line utility; click Next.

13. In the Summary dialog, review your settings and then click Next to start the AD installation and child domain creation process, which takes more than the advertised "several" minutes on moderate-speed servers.

14. Reboot the new DC for the child domain and log on with Enterprise Admins credentials.

15. Launch Active Directory Domains and Trusts, click to expand the parent domain node, right-click the child domain node, and choose Properties to open the childdomain.parentdomain.ext Properties dialog. The target (child) domain must run in native mode, so click Change Mode to make the domain ready for the move with ADMT.

16. Install ADMT on the DC for the child (target) domain. Download instructions are in the "Easing Restructure and Migration with ADMT" section of Appendix C.

17. On the child DC, launch the Domain Security Settings snap-in from Administrative Tools and navigate to and select the Windows Settings\Security Settings\Local Policies\Audit Policy node.

18. Double-click the Audit account management policy to open the Security Policy Settings dialog. Mark the Define These Policy Settings, Success, and Failure check boxes and click OK to apply the policy.

19. Repeat steps 17 and 18 on the parent domain DC. Account management auditing is required for ADMT operations on user accounts in both domains.

Adding a child domain automatically adds a Dynamic DNS (Active Directory-integrated, DDNS) primary forward lookup zone for the child domain to the parent domain's DNS server. When users move to the child domain, DHCP doesn't need to assign their Primary DNS Server to the child domain server's IP address.

Preparing the Domains for the Intraforest Move

Before you begin the migration process, in the parent domain add a Security Group containing all members of each OU you want to move, if such groups aren't present. Then add OUs in the child domain to contain the migrated Global groups and their users. For this example, the five sub-OUs of the Students OU (Freshmen, Sophomores, Juniors, Seniors, and Computers) don't have associated security groups, but you need only the four academic-year groups to define OU membership. ADMT requires Security Groups to place user accounts in designated OUs. You use the temporary groups discussed in the later section "Moving Groups and Their Users to Designated OUs" to regenerate OU membership by adding the user accounts based on group membership. After you complete group and user migration, you move all computers from the Students, Computers OU to the default Computers container of the child domain.

To add selected users to a temporary Security Group in the parent domain, do this:

1. Right-click the domainname node or any OU that doesn't have objects that duplicate the group names you create and then choose New, Group to open the New Object –Group dialog.

2. Type the name of the group in the text box, accept the default Global and Security options, and click OK to add the new group.

3. Select the OU to display its members and then multiselect all user objects only; don't include OU's or groups.

4. Right-click the selection, choose Add Members to a Group to open the Select Group dialog, type or scroll to and select the temporary group name, and click OK to perform the addition.

   Tip If the OU doesn't include objects other than users, right-click the OU node in the tree-view pane and choose Add Members to a Group. After you specify the group name, a message box opens to request confirmation that you want to add all users. Click Yes to All and wait for "The Add to Group operation was successfully completed" message to appear; then click OK. There is no user feedback during the Add to Group process.

5. Repeat steps 1 through 4 for each temporary group you created.

6. Add the OU to hold the other security groups for the user accounts being moved (Major Subject Groups).

To verify temporary group membership, right-click the GroupName node, choose Properties to open the GroupName Properties dialog, and click the Members tab.

Note If you use student accounts created by GroupPol in these procedures, delete the Students Domain Local group before the migration. This group is applicable only to a single domain.

Adding Target OUs in the Child Domain

After you've added the necessary temporary groups, do the following to create required Ous in the child domain:

1. Log on to any DC or workstation that has ADMT installed with your Enterprise Admins account.

2. Launch Active Directory Users and Computers, right-click the domain name node, select Connect to Domain to open the dialog of the same name, type or browse to the child domain, and click OK.

3. Right-click the domain name node again, choose New | Organizational unit to open the New Object-Organizational Unit dialog, type the name of a first-level OU in the text box, and click OK. Repeat this step for each first-level OU for the first domain.

   Note For this example, the second-level OUs of the parent domain's Student(s) OU (Freshmen, Sophomores, Juniors, Seniors) become first-level OUs in the child domain, because only student accounts exist in the child domain. There's no need to have a Student OU in a domain named Students.

4. If you have second-level OUs, add them to the first-level OUs you created in the preceding step.

5. Also add an OU for migrating the first set of groups without user accounts. For this example, a Major Subject Groups OU will hold copies of the 14 Global groups, which contain student accounts by major subject.

Copying the First Set of Groups

When you migrate groups without their user accounts, ADMT copies the groups from the source to the target domain. Copying prevents users being denied access to these groups' resources while the migration is in process. Do the following to copy groups without their user accounts:

1. Launch ADMT, right-click the Active Directory Migration Tool node, and choose Group Migration Wizard. Click Next to bypass the Welcome dialog.

   Tip Appendix C has detailed instructions for using the Group Migration Wizard, including figures showing the wizard boxes. There are differences between the interforest migration from a Windows NT domain to a Windows 2000 domain and an interforest move between Windows 2000 domains, but most of the steps are similar.

2. In the Test or Make Changes dialog, select the Migrate Now? option if you want to perform the move without testing. If you select the Test the Migration Settings and Migrate Later option, you must repeat all migration steps to effect the migration. Click Next.

3. In the Domain Selection dialog, select the NetBIOS names of the source and target (child) domains (OAKMONTU and STUDENTS for this example) and click Next.

4. In the Group Selection dialog, click add to open the Group Selection dialog and double-click each Global group to which the users you're migrating belong, but not the groups that correspond to OU memberships. For instance, don't add the temporary security groups you added in the preceding set of steps. You add these groups later along with their users. For this example, you add the 14 DepartmentName Majors groups, but not the temporary Freshmen, Sophomores, Juniors, and Seniors groups (see Figure 2-15). Click OK to add the groups to the Group Selection dialog's list and then click Next.

   

   Figure 2-15 You migrate all Global groups to which the migrated users belong except those groups that you use to move user accounts from source OUs to target OUs.

5. In the Organizational Units dialog, click Browse to open the Browse for Container dialog, select the special OU you created for groups or the domain container, and click OK to add the full LDAP path to the group in the Target OU text box. For this example, the path is LDAP://STUDENTS/OU=Major Subject Groups,DC=students, DC=oakmont,DC=edu. Click Next.

6. In the Group Options dialog, accept the defaults and click Next.

7. In the User Account dialog, type your Enterprise or Domain Admins credentials for the child domain, change the downlevel domain name for your account, if necessary, and click Next.

8. In the Naming Conflicts dialog, accept the defaults and click Next.

9. In the Completing the Group Account Wizard dialog, click Finish to open the Migration Progress dialog and begin the group migration process.

10. When the Status value in the Migration Progress dialog changes to Completed, click View Log to open the Migration log for the groups (see Figure 2-16).

11. Close the Migration log and click Close in the Migration Progress dialog to return to ADMT's snap-in.

Moving Groups and Their Users to Designated OUs

The process of migrating groups with users to the child domain OUs you created previously is quite similar to that for copying groups without users. To migrate groups and users by copying accounts, do this:

1. Repeat steps 2 and 3 of the preceding section. In step 3, the Wizard adds the fully qualified DNS names of the source and destination domains you originally specified with NetBIOS names.

2. In the Group Selection dialog, click Add and type or select the group to move in the Select Group dialog (the temporary Freshmen group for this example). Click OK to return to the Wizard; then click Next.

3. In the Organizational Unit dialog, click Browse to open the Browse for Container dialog, select the OU in the source (parent) domain that contains the users you want to migrate, and click OK to add the full LDAP path of the OU to the Target OU text box (LDAP://STUDENTS/OU=Freshmen,DC=students,DC=oakmont,DC=edu for this example). Click OK.

   

   Figure 2-16 The Migration log for the first set of groups detects that user accounts haven't been migrated and copies (instead of moves) the groups. StuAnthro, StuBio, and other Stu... entries are the downlevel names of the groups assigned by GroupPol.

4. In the Group Options dialog, mark the Update User Rights and Copy Group Members check boxes and accept the default Do Not Rename Accounts option. Click Next. A message warns you that if Global groups weren't migrated previously, users lose their membership in the unmigrated groups. Click OK.

5. Repeat steps 7 through 11 of the preceding section.

6. Launch Active Directory Users and Computers on the child domain DC and verify migration of the groups and user accounts (see Figure 2-17). Also check the Members page of the Properties dialog for each Security Group you migrated to verify that the group contains the appropriate user accounts.

   

   Figure 2-17 Active Directory Users and Computers running in the child domain verifies that user accounts you move based on their group membership migrate to the designated OU.

   Tip If the child domain's Active Directory Users and Computers snap-in was open during the migration process, choose View | Refresh to update its contents. If you don't see migrated objects, close and reopen the snap-in.

Migrating Computer Accounts

ADMT's Computer Migration Wizard lets you move Windows 2000 and NT computer accounts between domains. During the migration process, ADMT dispatches "agents" to automatically change the domain affiliation of the computer accounts and reboot the computer after a specified interval. One potential hitch in the process when migrating non-owned computer accounts is that the account you use to generate the computer migration agents must be a member of the local Administrators group of the client machines.

The Domain Admins group of the source domain is a member of the local Administrators group of Windows 2000 clients, but using an Enterprise Admins account is the safer option. The "Migrating Computer Accounts" section of Appendix C shows you how to move computer accounts to a new domain.

The above article is courtesy of Osborne/McGraw-Hill .

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.