Tài liệu Module 6: Developing a Domain Restructure Strategy doc

„#Identifying Domain Pre-Restructuring Tasks Explain the components of the existing Microsoft Windows NT® version 4.0 domain structure that should be documented prior to migration.. This

Strategy

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, MS, Windows, Windows NT, Active Directory, and Windows 2000 are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Project Lead/Instructional Designer: Sangeeta Garg (NIIT (USA) Inc.) Lead Program Manager: Angie Fultz

Instructional Designer: Robert Deupree (S&T OnSite) Subject Matter Expert: Brian Komar (3947018 Manitoba Inc) Technical Contributors: John Pritchard, Greg Parsons, David Cross, Rodney Fournier, Tony de

Freitas, Christoph Felix, Shaun Hayes, Megan Camp, Richard Maring, Glenn Pittaway, Anne Hopkins, Bob Heath, Jeff Newfeld, Jim Glynn, Paul Thompson (Mission Critical Software, Inc.), David Stern, Lyle Curry, Steve Tate, Bill Wade (Wadeware LLC)

Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T Onsite) Testers: Testing Testing 123

Instructional Design Consultants: Susan Greenberg, Paul Howard Instructional Design Contributor: Kathleen Norton

Graphic Artist: Kirsten Larson (S&T OnSite) Editing Manager: Lynette Skinner

Editors: Marilyn McCune (Sole Proprietor), Wendy Cleary (S&T OnSite), Jane Ellen Combelic

(S&T OnSite)

Copy Editor: Shawn Jackson (S&T Consulting) Online Program Manager: Debbi Conger Online Publications Manager: Arlo Emerson (Aditi) Online Support: Eric Brandt (S&T Onsite)

Multimedia Development: Kelly Renner (Entex) Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T OnSite) Courseware Testing: Data Dimensions, Inc

Production Support: Lori Walker (S&T Consulting) Manufacturing Manager: Rick Terek (S&T Onsite) Manufacturing Support: Laura King (S&T Onsite) Lead Product Manager, Development Services: Bo Galford Lead Product Managers: Dean Murray, Ken Rosen Group Product Manager: Robert Stewart

At the end of this module, students will be able to:

„#Identify and perform the domain pre-restructuring planning tasks

„#Determine the order of moving objects in a restructuring

„#Identify and perform the domain post-restructuring planning tasks

Lab A, Planning a Domain Restructure, is a scenario-based planning lab The students review information on the current domain model, Domain Name System (DNS) infrastructure, and proposed site topology They will then use this information to address design decisions when creating a restructure strategy

Students should work in small groups to complete this lab If students are reluctant to work together, consider leading the class through the first exercise, encouraging discussion, and then have them work in teams for the remaining exercises

Each exercise maps to a step in the restructure planning process Make sure that students understand that the scenario at the beginning of the lab applies to all exercises The table of questions and answers in each exercise is additional information that they may require to address the design decisions for that exercise

Be sure to save 15 minutes at the end of the lab to review their design decisions and address any questions that they may have

0DWHULDOV#DQG#3UHSDUDWLRQ#

This section provides you with the materials and preparation tasks that are needed to teach this module

5HTXLUHG#0DWHULDOV#

To teach this module, you need the following materials:

„#Microsoft® PowerPoint® file 2010A_06.ppt

„#Module 6, “Developing a Domain Restructure Strategy”

3UHSDUDWLRQ#7DVNV#

To prepare for this module, you should:

„#Read all of the materials for this module

„#Read all of the delivery tips

„#Complete the lab

„#Read the technical white paper, Planning Migration from Microsoft

Windows NT to Microsoft Windows 2000, on the Student Materials compact

LY# # 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\#

„#Read chapter 9, “Planning the Active Directory Structure,” of the Windows

2000 Server Deployment Planning Guide on the Student Materials compact

disc

„#Read chapter 10, "Determining Domain Migration Strategies,” of the

Windows 2000 Server Deployment Planning Guide on the Student Materials

compact disc

„#Read the Microsoft Excel spreadsheet, Migration Tool Comparison, on the Student Materials compact disc

0RGXOH#6WUDWHJ\#

Use the following strategy to present this module:

„#Introduction to Developing a Domain Restructure Strategy Provide an overview of the restructure planning process Use the slides and delivery tips to emphasize the planning steps involved in creating a basic domain restructure plan Emphasize to students that if their migration path involves first upgrading and then restructuring, they must create two plans: one for the domains that will be upgraded, and one for the domains that will

be restructured

Clarify for students that this module provides the foundational domain restructure plan Organizations will likely add steps to their restructure plans based on the presence of specific services and applications in their

environments Postpone discussion of how to plan for these until the next module Make the components of each planning step meaningful by relating them to example scenarios or by describing the impact if the planning step is not performed Encourage interaction throughout the module by engaging students in discussion or asking them how a planning step applies to their environments or migration situations

„#Identifying Domain Pre-Restructuring Tasks Explain the components of the existing Microsoft Windows NT® version 4.0 domain structure that should be documented prior to migration Remind students that multiple resource domains are no longer needed to separate administrative control Delegation can provide the same functionality Multiple account domains are no longer needed to provide scalability because there is no practical limit to the number of accounts that a domain can hold

Discuss the methods of restructuring Emphasize that within each method, there are many permutations to domain restructuring Students may be confused by the different ways that they can perform domain restructuring

It is important to take the necessary time here to ensure comprehension Emphasize that restructuring is possible between Windows NT 4.0 and Microsoft Windows® 2000 domains, between Windows 2000 domains in separate forests, or between domains in the same Windows 2000 forest Restructuring instead of upgrading has proven to be the most common among early adopters

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # Y#

Explain how to prepare to deploy the target environment The assumption made throughout this course is that the Active Directory™ directory service design has been completed in an earlier planning stage This particular planning step is only applicable to organizations restructuring between a Windows NT 4.0 source environment and a Windows 2000 target

Make sure that students understand all of the components of creating a recovery plan that allows them to roll back to the pre-restructured Windows

NT domain Be sure to compare the differences between recovering a Windows NT environment and a Windows 2000 source environment Explain the factors to consider when selecting an appropriate migration tool for your restructuring

Explain the security principal details that students must document Make sure that students understand the impact if this information is not comprehensively recorded This topic mentions several Resource Kit utilities that facilitate this documentation for smaller environments Ask students about their knowledge of third-party tools that can help with this process in enterprise environments

„#Determining the Order of Restructuring Within a Domain Explain the recommended order of moving objects in a restructuring Ask students what the impact will be if a different order is used

„#Identifying Domain Post-Restructuring Tasks Make sure that students understand why they may need to redefine resource discretionary access control lists (DACLs) and how they can avoid the

unknown user problem Be sure to mention how the Security Translation

wizard of the Active Directory Migration Tool (ADMT) can be used to facilitate this process They will use this wizard in the lab to redefine a resource DACL You may also want to demonstrate this wizard during your lecture on this topic

Cleaning up sIDHistory is a post-domain restructure step that is applicable only to companies choosing to migrate security principals with their source security identifier (SID) Because most organizations are likely to adopt this process, make sure that students understand that the main reason for doing this is to minimize the size of access tokens At this time, there is no tool to remove the value of the sIDHistory; a simple Active Directory Service Interfaces (ADSI) script can accomplish this Remind students that retaining the sIDHistory is optional during migration The process of sIDHistory cleanup is not required if accounts are not migrated with their original SIDs Converting the target environment to production is one of the last steps in domain restructuring Ensure that students understand the different ways in which the conversion can occur

Decommissioning the source environment is something that all organizations will do Although this process is fairly straightforward, the key to planning domain decommissioning is making sure that all of the objects have been moved to the target environment

At the end of this module, you will be able to:

„#Identify and perform the domain pre-restructuring planning tasks

„#Determine the order of moving objects in a restructuring

„#Identify and perform the domain post-restructuring planning tasks

5# # 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\#

,QWURGXFWLRQ#WR#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#

6WUDWHJ\#

,GHQWLI\#GRPDLQ#SUH0UHVWUXFWXULQJ#WDVNV 'HWHUPLQH#WKH#RUGHU#RI#UHVWUXFWXULQJ#ZLWKLQ#D#GRPDLQ ,GHQWLI\#GRPDLQ#SRVW0UHVWUXFWXULQJ#WDVNV

1 Identify and perform domain pre-restructure tasks to ensure that security principal information can be reconstructed after restructure (if necessary), to roll back to the source environment (if necessary), and to document and make decisions that will ensure a successful migration

2 Determine the order of restructuring within a domain to ensure that the source group membership and resource discretionary access control lists (DACLs) are migrated intact

3 Identify and perform domain post-restructure tasks to ensure that the users retain logon capability and access to resources after the restructure

Depending on the current network environment, additional planning steps may

be required to ensure continuity in the availability of network services and applications

1 2 3

'HYHORSLQJ#D#UHFRYHU\#SODQ

4

'HWHUPLQLQJ#KRZ#WR#PLJUDWH#VHFXULW\#SULQFLSDO#GHWDLOV

5 6 7

When planning a restructure strategy, you need to perform the following restructuring tasks:

pre-1 Examine the existing domain environment to identify obsolete components

in the existing environment, help select a restructure methodology, and ensure that existing network services and resource access are maintained during the restructuring

2 Choose a domain restructure methodology that meets your migration goals and your Active Directory design goals

3 Prepare to deploy the target environment in case you select inter-forest restructuring as the methodology for your migration

4 Develop a recovery plan to prevent accidental data loss during a restructure and to allow rollback to the pre-restructured Microsoft Windows NT®domain

5 Select appropriate migration tools for your restructuring

6 Identify and document source security principal details to ensure that you can reconstruct them after migration if necessary

7 Determine how to migrate security principal details

Examining the current domain model serves the following three purposes:

„#It assists in identifying obsolete components in the existing environment Eliminating outdated domains and security principals will simplify domain management in the new environment

„#It helps select a restructure methodology Achieving the ideal forest may require that existing account domains be upgraded to join a parallel environment while eliminating obsolete resource domains Or, it may require abandoning the whole model and beginning again with an infrastructure that serves the requirements of the business that it supports

„#It helps ensure that existing network services remain intact and that resource access is maintained during the restructure

When examining the existing domain structure, include the following steps:

„#Identify the current domain model

Document the number of domains and the function that they serve

Carefully examine the reasons that a domain was originally created

Companies that previously required multiple account domains for scalability, and multiple resource domains for segregating administrative access, may be able to eliminate those domains in favor of a single Active Directory domain

„#Identify and document all one- and two-way trust relationships

To ensure that migrated users retain access to resources in trusted domains, you must establish trusts on the target domain that mirror the trusts found on the resource domain

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # 8#

„#Identify applications running on domain controllers

Applications running on Widows NT version 4.0 domain controllers that are incompatible with Windows 2000 will prevent the source domain from being decommissioned unless the application is moved or upgraded

„#Identify services running on domain controllers and their configurations

If domain controllers will be migrated to the target environment, the services that they run will not be available during migration Before the domain controllers are migrated, ensure that backups to the services that they provide are in place

Some organizations may choose to upgrade a single account domain to gain quick access to Windows 2000 scalability, and then to perform inter-forest restructuring to merge the remaining Windows NT 4.0 domains into it Others may choose to upgrade all Windows NT 4.0 domains and redesign the Active Directory forest by performing intra-forest restructuring on selected Windows

2000 domains at a later date; this improves long-term manageability of the forest hierarchy

Because performing domain restructuring after upgrading to Active Directory is a two-phased migration project, this migration scenario will require

a two-part strategy that involves more time to plan

,QVWHDG#RI#8SJUDGH#

Companies dissatisfied with the number of domains in their current infrastructure may choose to migrate to a completely redesigned domain model instead of upgrading their existing model This type of inter-forest restructuring

is well suited for organizations that cannot risk interruption in the current production environment or that can only afford a single-step migration

Restructuring instead of upgrading involves designing and building a pristine

forest, which is an ideal Windows 2000 forest isolated from the current

production environment, and then populating it with security principals from an existing domain The existing domains operate normally during migration The Windows 2000 pilot project operation parallels the existing environment and eventually becomes the production environment

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # :#

After the new Active Directory forest has been built, security principals are copied into domains in the new forest Resources such as file and print servers are moved to the forest, and the pilot environment can be transitioned to the production environment The source domain environment can be

decommissioned, and the remaining servers can be redeployed

Post-migration domain restructuring is also possible and can be

performed in an inter-forest fashion, known as cut and paste (or sometimes called prune and graft), to accommodate corporate mergers or acquisitions It

can also be performed in an intra-forest manner, as in the case of forest redesign due to extensive organizational change

1RWH#

If you select inter-forest restructuring as the methodology for your migration,

an additional planning step is required: preparing to deploy the target environment The target environment is defined by the Active Directory design and is the blueprint for an organization’s ideal Windows 2000 environment

If an organization chooses to upgrade all existing domains first, this planning step is not required

In inter-forest restructuring scenarios, it is necessary that the forest proposed by

the Active Directory design be created prior to migration This pristine

environment serves as the target for the domains being restructured It operates

in parallel and should be kept separate from the production environment When all restructure operations are complete, the parallel environment can be

transitioned to production

To prepare to deploy the target environment:

„#Ensure that sufficient hardware is available

At a minimum, all domains that will ultimately hold migrated accounts or resources must be created, requiring more hardware than what is presently used in the current domain model Depending on the domain hierarchy proposed in the Active Directory design, this may require the creation of all domains Additionally, a sufficient number of domain controllers should be installed in each target domain to support fault tolerance during migration

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # <#

„#Ensure that the existing Domain Name System (DNS) namespace or namespaces will not conflict with the one required by the parallel environment

The target DNS deployment must be integrated into the existing DNS infrastructure to ensure that two primary zones do not exist for any of the DNS domains

For more information on how restructuring affects DNS, see module

7, “Minimizing the Impact on Network Operations During a Domain

Restructure,” in course 2010A, Designing a Microsoft Windows 2000

do not have to be moved after migration

„#Verify that the replication schedules between sites will facilitate domain controller redeployment

This is particularly important where a single domain spans multiple sites If domain controllers from the source domain are redeployed to the target environment, sites will help control domain replication traffic over slow links Prior to migration, place at least one domain controller in each location Before the parallel environment is transitioned to production, ensure that sufficient domain controllers are present in each site to provide fault tolerance and reliability

For more information on deployment planning, see module 8, “Planning

to Deploy a Migration Strategy,” in course 2010A, Designing a Microsoft

Windows 2000 Migration Strategy

1RWH#

1RWH#

43# # 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\#

3ODQQLQJ#WR#'HSOR\#6HFXULW\#DQG#$GPLQLVWUDWLYH#)HDWXUHV#

Completely deploying the security and administrative features defined in the Active Directory design may not be possible until security principals are fully migrated to the pristine environment For example, if an organization plans to delegate at the object level—that is, by computer or use—delegation cannot be fully deployed until security principals are migrated To compensate for this and to ensure that the security and administrative features defined in the Active Directory design are fully deployed, your restructure plan must include steps to:

„#Create an administrative transition plan

This plan should identify who will manage what during and after the domain restructure by defining:

• New administrative roles and responsibilities

For example, if Windows NT 4.0 resource domains are being collapsed into Windows 2000 domains, determine whether resource administrators will join the Domain Admins group in the destination domain The combination of restructuring to reduce the number of domains and the deployment of time- and labor-saving administrative features in Windows 2000 may require Information Technology (IT) organizations

to redefine administrative roles and responsibilities

Changes in IT policies, procedures, support systems, roles, and responsibilities should be planned and communicated ahead of time and applied in a way that allows IT to remain focused on the migration without disruption

• When new roles and responsibilities will go into effect

„#Define a process for implementing any remaining security and administrative features at the appropriate time as domains are restructured For more information on developing a security and administrative

plan for Active Directory, see course 1561B, Designing a Microsoft

Windows 2000 Directory Services Infrastructure

,PSRUWDQW#

1RWH#

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # 44#

'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#5HFRYHU\#3ODQ#

Domain Controller

Domain Controller

6HUYLFHV#DQG#$SSOLFDWLRQV#

5XQQLQJ#RQ#WKH#3'&#DQG#%'&V#

61#%DFN#8S#6HUYLFHV#DQG#

$SSOLFDWLRQV#WR#7DSH 71#%DFN#8S#$FFRXQW#'DWDEDVH#DQG#

3HUIRUP#D#7HVW#5HVWRUDWLRQ#

It is important that you develop a recovery plan to prevent accidental data loss

during restructure This plan should include details of how you will back up your domain controllers, applications, and other data before and during the

upgrade

Although a certain degree of recovery is possible by simply maintaining the source domain, having a recovery plan is important in migration scenarios where automatic fallback is not possible:

„#Intra-forest restructure scenarios, where moving objects between domains deletes the source object, preventing automatic fallback

„#Inter-forest restructure scenarios, where domain controllers are moved Reinstalling or demoting domain controllers prior to redeployment to the target environment prevents automatic recovery of service configurations, application information, and Security Accounts Manager (SAM) database objects

To ensure that a domain can be fully rolled back to its pre-restructure state, your recovery plan should, at a minimum, include the following steps:

1 Ensure that all source domains have at least two domain controllers to prevent a domain from becoming orphaned during the migration process

2 Document the configuration of any applications or services running on the domain controllers targeted for redeployment, such as file and print services, Dynamic Host Configuration Protocol (DHCP), or DNS

3 Back up these services and applications to tape, and test the backup tapes by performing a test restoration

You can use the Windows NT Backup tool to back up the SAM database on Windows NT domain controllers You can use the Windows 2000 Backup tool to back up the Active Directory and SYSVOL contents on Windows

2000 domain controllers, by including the System State information in the backup set

Step four is not necessary if the source domain is Windows NT 4.0 In this case, one fully synchronized domain controller can be taken offline and retained until after migration is complete and the production environment is running smoothly

5HFRYHULQJ#D#:LQGRZV#17#713#6RXUFH#'RPDLQ#

If any problems arise during migration, you can remove all computers running Windows 2000 from the production environment, and perform one of the following steps:

„#Promote the offline domain controller to a PDC and then bring it back into your network This new PDC then replicates its data to any remaining Windows NT 4.0 BDCs, returning the domain to its previous state

„#Restore the BDC from tape, then promote it to a PDC This PDC will replicate its data to any remaining Windows NT 4.0 BDCs, returning the domain to its previous state

Carefully consider turning on the protected domain controller to update its directory information Although this will prevent loss of any changes made during the restructure, source accounts may be disabled during restructure operations

5HFRYHULQJ#D#:LQGRZV#5333#6RXUFH#'RPDLQ#

If any problems arise during migration, you can restore the pre-restructure Windows 2000 environment from backup tape by performing an authoritative restore of the system state

For more information on performing an authoritative restore, see the knowledge-base articles Q241594 and Q240363 on the Student Materials compact disc

7LS#

&DXWLRQ#

1RWH#

The primary tool that you use depends on a number of factors, including:

„#A tool’s capabilities in achieving migration goals

Each tool varies in the migration features that it provides You should become familiar with each tool’s capabilities and limitations

„#Administrative preferences

Driven by graphical wizard interfaces, ADMT is easy to use and requires little preparation However, MoveTree and ClonePrincipal as command-line utilities are best used in scripts that enable user accounts, clean up or populate user attributes, or define closed sets

„#Security requirements

Your security requirements may also help to determine your primary migration tool ADMT allows administrators to set cloned user passwords, enable cloned accounts, and disable target and source accounts By default, ClonePrincipal sets cloned user passwords to NULL

When the migration tools are not in use, it is recommended that you disable TCP Client Support on the source domain Additionally, if

ClonePrincipal is installed, deregister clonepr.dll by using the Regsvr32 /u

„#Document registry, share, and NTFS file system permissions on source domain controllers

Whether you choose to migrate the security identifiers (SIDs) or not, this documentation will ensure that resource permissions for migrated security principals can be reconstructed if necessary The Showacls.exe,

Subinacl.exe, and Perms.exe Windows NT 4.0 Resource Kit and Windows

2000 Resource Kit utilities can assist in documenting permissions on a Windows NT 4.0 or Windows 2000 source domain If the source domain is Windows 2000, you can also write a variety of Active Directory Service Interfaces (ADSI) scripts to collect these permissions

„#Document the membership of each source group to be migrated

This information will be useful when validating the membership of cloned

or moved groups and in identifying closed sets for migration operations The Global.exe, Local.exe, Findgrp.exe, Showmbrs.exe, and Showgrps.exe Windows NT 4.0 Resource Kit utilities can assist in documenting groups and their membership for a Windows NT 4.0 or Windows 2000 source domain If the source domain is Windows 2000, you can also write a variety

of ADSI scripts to collect the membership

„#Identify global groups in source account domains that might be combined in the target domain

When multiple account domains exist in a source environment, it is common for global groups of the same name or function to be defined in each domain; for example, domainA\SalesReps and domainb\SalesReps You can merge groups of the same name or function in the target domain, allowing you to simplify group management

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # 48#

„#Identify obsolete and disabled user accounts

You should delete accounts in the source environment that are no longer used or are obsolete prior to migration, so that inaccurate data is not migrated into the new directory service You can use the Usrstat.exe utility

in the Windows NT 4.0 Resource Kit and Windows 2000 Resource Kit to determine when a user last logged on

„#Document special user rights assignments and built-in group membership This documentation will ensure that you can construct user rights and special memberships if necessary

„#Identify empty or obsolete groups

Using the Showmbrs.exe tool in the Windows NT 4.0 Resource Kit and Windows 2000 Resource Kit can identify empty groups You should delete these groups prior to migration

„#Determine whether the membership of source groups should be redefined or migrated intact The membership of most groups is restored after migration Clean up group memberships to avoid migrating inaccurate or obsolete data, particularly for administrative groups on resource domains that will be decommissioned

Global group membership is protected during cloning operations If users are cloned before the groups to which they belong are cloned, membership is restored when the group is migrated If a global group is cloned before its members, the users are automatically placed in the group after they are cloned

„#Determine whether security principals’ sIDHistory will be retained during migration Migrating the sIDHistory ensures that resource access is maintained while domain controllers and resources are split between source and target domains However, access tokens can contain only a fixed number of SIDs Migrated users belonging to many groups may be denied logon if the number of allowable entries in the access token is exceeded

„#Determine the sequence for restructuring security principals Users responsible for performing restructuring will require administrative credentials in the target domain Consider migrating these accounts first After all administrative accounts exist in the target domain, you can deploy the Windows 2000 administrative model You can migrate users and groups independently of one another or simultaneously, in a single migration operation

# 0RGXOH#9=#'HYHORSLQJ#D#'RPDLQ#5HVWUXFWXUH#6WUDWHJ\# # 4:#

You could also create new administrative accounts in the target domain; however, the permissions and user rights associated with these accounts would not be preserved because there is no sIDHistory attribute for new accounts

„#Determine whether SIDs of well-known relative identifier (RID) accounts need to be migrated

You can add the SIDs for Domain Admins, Domain Users, and Domain Guests in the target domain to the sIDHistory of the Domain Admins, Domain Users, and Domain Guests accounts by using either the Group Mapping and Merging wizard in ADMT or the Sidhist.vbs ClonePrincipal script

If any security assignments that include the Domain Admins, Domain Users, or Domain Guests global groups are created in the target domain, you must add the target SID of each group to the sIDHistory for the matching group in the target domain Another strategy is to remove all references to well-known RID accounts in discretionary access control lists (DACLs) in the source domain

„#Identify which migrated objects go into which OUs in the target domain Some organizations may want to segregate all migrated accounts into a single OU, whereas others may prefer to place them in the OU hierarchy according to how they will be administered

„#Identify users in the source domain that belong to more than 500 groups When migration is configured to retain the sIDHistory of cloned or moved users and groups, the size of a user’s access token doubles

In domains with complex group structures or environments with many resource domains, the size of a migrated user’s access token can result in logon or resource access denial If authentication and authorization access tokens contain more than 1,023 SIDs, a user will be unable to log on or will

be denied access to resources

Identify the number of groups to which a user belongs by running the Showgrps.exe utility found in the Windows NT 4.0 Resource Kit and Windows 2000 Resource Kit

To alleviate the problem of large access tokens, you may choose to:

• Minimize the number of groups to which a user belongs in the source domain prior to restructuring

• Migrate certain users or groups without retaining the sIDHistory, which will require the DACLs of resources to be redefined to allow migrated users to have continued access to resources

• Clean up the sIDHistory of these migrated accounts prior to allowing users to log on in the new environment