Export (0) Print
Expand All
Expand Minimize

Chapter 4: Restructuring Tools

Section 1:
Migration Concepts

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

On This Page

Introduction
Microsoft Restructure Tools
Which Tool Should You Use?
Description of Restructuring Tools

Introduction

The task of restructuring domains can range from routine and straightforward to complex, depending on the size and number of account domains and the number of resource domains involved.

Microsoft provides a number of tools to assist with domain restructure. The Active Directory Migration Tool (ADMT) is a powerful graphical tool that can perform all tasks. Besides ADMT, additional command line tools are available. This chapter will discuss:

  • The different migration tools available.

  • The ways in which you can use them.

  • How to use the command line tools.

Microsoft Restructure Tools

Microsoft provides the following tools to assist in domain restructure:

Active Directory Migration Tool (ADMT)

ADMT is a Microsoft Management Console (MMC) snap-in that provides graphical support in the form of wizards to automate migration tasks such as moving users, groups, and computers (between or within forests), migrating trusts, and performing security translation.

ClonePrincipal

Used to clone user and group accounts from a Microsoft Windows NT 4.0 source domain or a Microsoft Windows 2000 source domain in a separate forest to a native mode Windows 2000 target domain.

Netdom

Often used in the same scenarios as ClonePrincipal to move computer accounts from a Windows NT 4.0 or Windows 2000 source domain to a Windows 2000 target domain. Netdom is also used to recreate trusts, typically in migration scenarios between the target domains and any domains trusted by or trusting the source domain.

MoveTree

Used for moving users, groups, and organizational units (OUs) between Windows 2000 domains in the same forest.

While Microsoft provides a range of powerful tools to aid domain restructure as a part of domain migration, in some instances customers will prefer to use third-party tools. Microsoft has worked closely with the major third-party tool vendors in this area to ensure that they have been able to capitalize on features such as sIDHistory, cloning, and moving objects within the same forest.

There are three major differences between ClonePrincipal or Active Directory Migration Tool for cloning users and MoveTree:

  • ClonePrincipal is nondestructive, meaning it leaves the original account intact, allowing users to roll back in the event of a problem, whereas MoveTree is a one-way function with no contingency options.

  • ClonePrincipal only operates between domains in separate forests (interforest) and MoveTree can be used only between domains in the same forest (intraforest).

  • MoveTree migrates the user's password. ClonePrincipal requires the administrator to preset a new initial password.

Which Tool Should You Use?

The tools described above have been designed to work in specific contexts, so the choice of tool depends on the migration scenario you wish to use.

Broadly speaking, you can divide user and group migrations into two categories: interforest, and intraforest.

Interforest Migration

A migration can be described as being interforest when it takes place between two separate Windows 2000 forests. Since a Windows NT 4.0 domain cannot be part of a Windows 2000 forest, migration from a Windows NT 4.0 domain to a Windows 2000 domain is considered an interforest migration.

Advantages of Interforest Migration

Interforest migration is the primary migration scenario when migrating from Windows NT 4.0 to Windows 2000 without upgrading the domain. It has a number of advantages over intraforest migration, primarily that cloning is possible.

Cloningthe creation of new accounts in the target domain that mirror accounts in the source domain but also maintain the source account primary security identifier (SID) in their sIDHistoryis only possible interforest. Cloning is nondestructive in that it leaves the source accounts intact; this is desirable in a number of cases:

  • Staged migrations. In this case you want to migrate some or all users and groups from the source domain to the target domain, but leave the accounts in a disabled state or merely not have the users log on to their new accounts until some later date, that is, until the new environment has been adequately tested, or until the users have been trained. The fact that cloning is nondestructive means that the users can continue logging on to their existing accounts until it is appropriate to switch over.

  • Parallel environments. This case is similar to the previous case, except that you want the migrated users to log on with both their new and old accounts. An example of this might be where users have to continue logging on with their old accounts to access an application that does not use sIDHistory and that does not allow access based on the new account. Again, the nondestructive nature of cloning means that the user's old account can continue to be used as long as required.

  • Fallback. The fact that the user's old account remains available, if desired, even after cloning means that as long as the old account remains in existence, it is always possible for users to use their old accounts in case of some disaster.

Another advantage of cloning, and therefore of interforest migration, is that apart from the requirements imposed by the configuration required to carry it out, it is a very straightforward, easy operation with few constraints.

Disadvantages of Interforest Migration

For some customers, certain factors might make interforest migration undesirable:

  • Resource access with sIDHistory. Even though the constraints on cloning require that SIDs must be unique within a forest, some customers prefer not to rely on sIDHistory in a cloning context. This is because until the source account is removed, it remains theoretically possible for a dishonest administrator to take advantage of the fact that sIDHistory in this context allows two accounts to gain access to resources using the same SID, that is, via the old account's primary, and the sIDHistory of the new account.

  • Change password. Microsoft-provided tools do not support copying passwords between forests, thus in all interforest scenarios the migration requires the user's password to be reset.

  • Globally unique identifier (GUID) not preserved. Objects in Microsoft Active Directory are identified by GUIDs, and cloning does not preserve GUIDs. Because this is a limitation only when dealing with Windows 2000 source domains, and the primary interforest scenario is migrating from Windows NT 4.0 to Windows 2000, this is unlikely to affect many customers.

Interforest Migration Tools

The following tools can be used to migrate users, groups, and computer accounts in interforest scenarios:

  • ADMT. Clones users and groups, migrates computer accounts and trusts.

  • ClonePrincipal. Clones users and groups.

  • Netdom. Migrates computer accounts and trusts.

Intraforest Migration

A migration can be described as being intraforest when it takes place between two domains in the same Windows 2000 forest. Because a Windows NT 4.0 domain cannot be part of a Windows 2000 forest, intraforest migration is not applicable when you are migrating from Windows NT 4.0 domains.

Advantages of Intraforest Migration

Intraforest migration as a migration scenario is primarily concerned with allowing customers to restructure domains after they have been upgraded into the target Windows 2000 forest. Intraforest migration, like interforest migration, makes use of sIDHistory to maintain resource access.

As mentioned earlier, cloning is only available in interforest scenarios. As a result, to make use of sIDHistory in intraforest migrations, the object must be moved from source domain to target, that is, the source object ceases to exist as a result of the migration.

Intraforest migration has a number of attractions:

  • Password preservation required. Windows 2000 can copy user passwords from domain to domain in the same forest as part of an object move operation. If password preservation is absolutely required, then intraforest migration may be desirable.

  • GUID preservation required. Windows 2000 preserves the object GUID in object moves intraforest. If a customer is using applications that establish user identity via GUIDs, then intraforest migration could be desirable.

  • General user management scenarios. These are separate from, but related to, migration scenarios. A common example would be a requirement to move a user from one domain in the forest representing a foreign subsidiary, to a different domain in the forest representing another country. Here it would be useful to be able to move the user while preserving his or her personal resource access, password, and GUID.

Disadvantages of Intraforest Migration

Some disadvantages to intraforest migration are:

  • Destructive operation. Because intraforest migration using sIDHistory requires the source object to be destroyed, it is not possible to implement the staged and parallel migrations as described in the same way.

  • Closed sets. The closed set requirement with respect to intraforest migration is discussed elsewhere, but the essence is that in order to maintain group membership rules, users and their global groups must be moved together. Because this is a destructive operation, this is often impossible without moving the entire domain.

Intraforest Migration Tools

The following tools can be used to migrate users, groups, and computer accounts in intraforest scenarios:

  • ADMT. Moves user, group, and computer accounts.

  • MoveTree. Moves user and group accounts and OUs.

  • Netdom. Migrates computer accounts.

Summary of Tool Functionality*

Feature

ADMT

ClonePrincipal

Netdom

MoveTree

Comments

Interforest

 

   

Intraforest

 

   

Enables sIDHistory

 

   

Graphical User Interface

   

   

Scriptable

 

   

Preserves passwords

  

ADMT, like MoveTree, preserves passwords in intraforest migrations.

Preserves GUIDs

  

ADMT, like MoveTree, preserves GUIDs in intraforest migrations.

Migrate users

 

   

Migrate groups

 

   

Migrate computers

  

   

Migrate trusts

  

   

Migrate OUs

   

   

Migrate user profiles

   

   

Migrate service accounts (update SCM)

   

   

Updates access control lists (ACLs) on resources

   

   

*A dot indicates that the feature is supported by the tool. A blank means the feature is either not supported or not relevant for that tool.

Description of Restructuring Tools

This section looks at each of the tools in some detail. The chapters in section 2 of this guide cover usage of the tools.

Active Directory Migration Tool

ADMT is designed to support Windows NT 4.0 or Windows 2000 to Windows 2000 domain migration scenarios, interforest and intraforest. It is implemented as an MMC snap-in, providing easy-to-use wizards to support the most-common migration tasks. Specifically, the tool supports tasks such as:

  • Mirroring trusts as needed.

  • Cloning local groups updating SIDHistory.

  • Cloning local groups maintaining memberships.

  • Cloning local groups in user-determined groupings.

  • Moving computers in user-determined groupings.

  • Translating SIDs on servers and workstations if appropriate, to remove/replace redundant SIDs.

  • Changing computer accounts to reflect the new domain/OU.

Requirements

If you are using ADMT to move machine accounts only, then no system modifications are required. However, if you need to clone users or groups, you need to set up the environment as described in the "Configuration Requirements" section of the description of ClonePrincipal.

ClonePrincipal

ClonePrincipal is a group of sample scripts for Microsoft Visual Basic illustrating the usage of a Component Object Model (COM) object that supports the cloning of users and groups. The ClonePrincipal files, located in the support tools directory on the Windows 2000 product CD, allow an administrator to clone users and groups between domains in different forests.

The COM object (implemented in clonepr.dll) clones a security principal from a Windows NT 4.0 or Windows 2000 source domain into a native mode Windows 2000 domain in a different forest.

A "clone" is an account in a native mode Windows 2000 domain for which Windows NT 4.0 account properties and group memberships have been copied from a source account. Although the clone necessarily has a different primary SID than the source account, the SID of the source account is copied into the clone's sIDHistory attribute. Populating the sIDHistory attribute with the SID of a source account allows the clone to access all network resources available to the source account, providing trusts exist from the resource domains to the clone's account domain.

Network access is preserved via sIDHistory because in a native mode Windows 2000 domain, user interactive logon creates an access token containing not only the user's primary SID and global group SIDs, but also the user's sIDHistory and the sIDHistory of these groups.

When to Use ClonePrincipal

ClonePrincipal is used to clone users and groups between Windows NT 4.0 and Windows 2000 source domains and native mode Windows 2000 domains in different forests. While ADMT supports the same functionality, ClonePrincipal consists of a set of sample Visual Basic scripts and so it can be customized to support nonstandard migration scenarios.

You should use ADMT if:

  • You want to use a graphical user interface to perform the migration, and want to be able to select the objects.

  • You want to use a single tool for all migration operations, no matter if you migrate users or computers, or if you migrate interforest or intraforest.

You should use ClonePrincipal if you want to customize specific migration steps, such as adding users automatically to a new group during the migration.

It is good practice not to mix the use of ADMT and ClonePrincipal for migration operations. ADMT and ClonePrincipal use different mechanisms to detect whether objects have been moved in the past, and mixing the tools might lead to undesired results.

Since ADMT is the most versatile and powerful tool, it most likely will be the tool of choice.

ClonePrincipal Files

The following files make up ClonePrincipal:

  • Clonepr.dll. A COM server implementing helper functions.

  • Sidhist.vbs. A script that copies the SID of a source principal to the sIDHistory of an existing target principal.

  • Clonepr.vbs. A script that copies the properties of a source object, and the source SID to the sIDHistory of a target object, creating the target object if necessary.

  • Clonegg.vbs. A script that clones all global groups in a domain, including well-known global groups such as Domain Administrators, Domain Users, and Domain Guests.

  • Cloneggu.vbs. A script that clones all global groups and users in a domain, including well-known global groups such as Domain Administrators, Domain Users, and Domain Guests.

  • Clonelg.vbs. A script that clones all local groups in a domain that are not well-known accounts.

  • Adssecurity.dll, Adserror.dll. Helper COM objects.

Requirements

In order for ClonePrincipal to work properly, the following conditions must be met:

  • The target domain must be running Windows 2000.

  • The target domain must be running in Windows 2000 native mode.

  • Source domain may be running:

  • Windows NT 4.0 (Service Pack 4 or later).

  • Windows 2000 mixed mode.

  • Windows 2000 native mode.

  • For Windows NT 4.0 source domains: The machine supplied to the scripts for the source domain must be the source domain primary domain controller (PDC).

  • The source domain must not be in the same forest as the destination domain (by definition a Windows NT 4.0 domain is not in the same forest).

  • The source object must be of one of the following types:

  • User.

  • Security enabled group, including:

  • Global group.

  • Local group.

  • Shared local groups (local groups created on the PDC and shared with the backup domain controllers (BDCs) in a Windows NT 4.0 domain.

  • Domain local group.

  • Universal group.

    The source object may not have a well-known SID (for example, Administrators, Users, and Power Users local groups). Well-known SIDs are identical in every domain; thus, adding them to sIDHistory would achieve very little.

  • The SID of the source object must not already exist in the target forest, either as a primary account SID or in the sIDHistory of an account.

  • For Windows NT 4.0 source domains: Modify the registry on the source PDC, adding the DWORD value TcpipClientSupport to HKLM\SYSTEM\CurrentControlSet\Control\LSA. This value must be set to 1 to enable the Security Accounts Manager (SAM) operations required for cloning to take place over remote procedure call (RPC).

  • A trust must be created from the source domain to the target domain.

  • The user carrying out the migrations must have membership of the Domain Admins group in the target domain to clone.

  • The user carrying out the migrations must also have administrator privileges in the source domain; this can be achieved by adding the Domain Admins group from the target domain to the Administrators group in the source domain.

  • A local group must be created in the source domain called srcDomainName$$$, where srcDomainName is the name of the source domain, that is, if the domain is called Redmond, the group would be called Redmond$$$.

  • Auditing of success and failure of account management operations must be enable in both the source and target domains.

ClonePrincipal Syntax

This section defines the command line usage of the sample scripts. These scripts must be run on the console of the target domain controller. They cannot be run from a remote workstation, except via a mechanism such as Terminal Server connected to the target domain controller.

cscript sidhist.vbs  
  /srcdc:SrcDC /srcdom:SrcDomain /srcsam:SrcSamName /dstdc:DstDC 
  /dstdom:DstDomain /dstSam:DstSamName 
cscript clonepr.vbs  
  /srcdc:SrcDC /srcdom:SrcDomain /srcsam:SrcSamName /dstdc:DstDC 
  /dstdom:DstDomain /dstSam:DstSamName /dstDN:DstDN 
cscript cloneggu.vbs 
  /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC /dstdom:DstDomain /dstOU:DstOU 
cscript clonelg.vbs 
  /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC /dstdom:DstDomain /dstOU:DstOU 
cscript clonegg.vbs 
  /srcdc:SrcDC /srcdom:SrcDomain /dstdc:DstDC /dstdom:DstDomain /dstOU:DstOU

For detailed instructions on installing and using ClonePrincipal, please refer to the ClonePrincipal User Guide (ClonePrincUserDoc.doc) that can be found with the program files on the Windows 2000 product CD.

Netdom

Netdom is a command line utility that allows administrators to move computers between domains and query and recreate domain trusts.

When to Use Netdom

Generally, Netdom is used in conjunction with ClonePrincipal in interforest domain migration scenarios to move computer accounts, because ClonePrincipal can only move user and group accounts. It also can be used without ClonePrincipal for other domain management tasks.

Requirements

Netdom has no specific configuration requirements.

Netdom Syntax

Netdom command [/d:domain] object [/options]

Command

You can think of supported commands as applying to one of two general categories:

  • Commands that apply to workstations and member servers.

    ADD

    For adding computer accounts to domains

    JOIN

    For joining a workstation or member server to a domain

    MOVE

    For moving a workstation or member server to a new domain

    REMOVE

    For removing a workstation or member server from a domain

    RENAME

    To assist in Windows NT 4.0 domain rename efforts, applies to Windows NT 4.0 backup domain controllers.

    RESET

    For resetting secure channel passwords upon which memberships are based.

    VERIFY

    For verifying the secure channel passwords between a member and its domain

  • Commands that apply to domains.

    QUERY

    For retrieving membership and trust information from a domain

    TIME

    For synchronizing time within a domain

    TRUST

    For establishing, verifying, or reestablishing a trust relationship

/d:domain

Regardless of the command, you must always provide a domain. The domain name can be specified as a Windows NT 4.0 NetBIOS name, or a Windows 2000 Domain Name System (DNS) name. If the option is not specified, then the domain to which the current computer belongs is assumed.

For workstation and member server commands, the /d:domain flag refers to the domain to which the workstation or member server currently belongs, or should belong, after the operation is completed.

For the TRUST command, /d:domain always refers to the trusted domain.

Object

An object is, or is the name of, one of the following:

  • Workstation

  • Server

  • Domain controller

  • Domain

[/options]

Options available for all commands:

/Ud:[DOMAIN\]USER

User account used to make the connection with the domain specified by the /d argument. If this option is not specified, the current user account is used.

/Pd:[password | *]

Password of the user account specified with /Ud. If *, then password is prompted for.

/Uo:[Domain\]User

User account used to make the connection with the object on which the action is to be performed. If this option is not specified, the current user account is used.

/Po:[password | *]

Password of the user account specified with /Uo. If *, then password is prompted for.

/S:server

Specifies a specific domain controller that an operation should be performed against. This option is useful for commands that otherwise may be performed using any domain controller in /d:domain.

/Verbose

By default, only the result of the operation is reported. If the verbose operation is specified, then the output lists the success or failure of each "atomic" transaction necessary to perform the operation.

/Help

Netdom /help should give brief help on all commands. Netdom command /help should give verbose help.

Options available for the ADD, JOIN, and MOVE commands:

/OU:ou path

Name of a destination OU in /d:domain. The OU path starts immediately below the root of the domain name context (that is, the domain node).

Options available for the JOIN and MOVE commands:

/Reboot[:Time in seconds]

Specifies that the computer being joined or moved should be shut down and automatically rebooted after the join or move has completed. The number of seconds before automatic shutdown can also be provided. Default is 20s.

When the time has expired, any open applications are automatically closed with no file-save dialog exposed.

Options available for the domain commands QUERY, TIME, and TRUST:

/Verify

When used in conjunction with the QUERY command, the /Verify option specifies that the secure channel secrets for all enumerated memberships or trusts should be verified in addition to being displayed. Unless the user is an enterprise admin, it may not be possible to verify all secure channel secrets.

When used in conjunction with the TIME command, the /Verify option displays the synchronization status of all domain controllers within the domain.

When used in conjunction with the TRUST command, the /Verify option checks the secure channel secrets upon which a specific trust is based.

/Reset

When used in conjunction with the QUERY command, the /Reset option specifies that the secure channel secrets for all enumerated memberships or trusts (which are currently broken) be resynchronized. The /Reset switch implies the /Verify switch. Unless the user is an enterprise admin, it may not be possible to reset all enumerated trusts or memberships.

When used in conjunction with the TIME command, the /Reset option synchronizes the clocks of those domain controllers that are not within the allowable skew range for the domain.

When used in conjunction with the TRUST command, the /Reset option verifies the secure channel secrets upon which the specific trust is based and resynchronizes them if necessary.

Options available for the QUERY command:

/Direct

Indicates that the query for trust relationships should only return direct trust relationships rather than direct and indirect relationships. Available only when DOMAIN is specified as the object in a QUERY command.

Options available for the TRUST command:

/Add

Specifies that a trust should be created.

/Remove

Specifies that a trust should be broken

/TwoWay

Specifies that a bidirectional trust relationship should be established rather than a one-way trust relationship.

/Kerberos

In conjunction with the /Verify option, /Kerberos specifies that the Kerberos protocol should be exercised between a workstation and a target domain.

/Flush

In conjunction with /Verify and /Kerberos, indicates that the workstation's ticket cache should be purged prior to verifying the functionality of the Kerberos protocol.

MoveTree

MoveTree is a resource kit utility available only for Windows 2000 that allows an administrator to move Active Directory objects from one Windows 2000 domain to another in the same forest. It works across child domains as well as two separate domain trees within a forest.

When to Use MoveTree

Use MoveTree when you want to move users, groups, and OUs between Windows 2000 domains in the same forest.

Requirements

The following conditions must be met:

  • The source domain can be either a mixed mode or native mode Windows 2000.

  • The target domain must always be a native mode Windows 2000 domain.

MoveTree Syntax

Movetree [/start | /continue] [/s SrcDSA] [/d DstDSA] [/sdn SrcDN] [/ddn DstDN]  
[/u Domain\Username] [/p Password] [/quiet]

/start

Start a MoveTree operation with /check option by default.

You could use /startnocheck to start a MoveTree operation without any check.

/continue

Continue a failed MoveTree operation.

/s <SrcDSA>

Source server's fully qualified primary DNS name.

/d <DstDSA>

Destination server's fully qualified primary DNS name.

/sdn <SrcDN>

Source subtree's root distinguished name.

/ddn <DstDN>

Destination subtree's root distinguished name. Relative distinguished name plus target parent distinguished name.

/u <Domain\UserName>

Domain name and user account name.

/p <Password>

Password.

/quiet

Quiet mode, run without any screen output.

Any error messages generated by MoveTree are automatically stored in the same directory as movetree.exe in a file called movetree.err.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft