Creating Administrative Procedures

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

You must define how the objects that you are migrating are to be administered during the interforest restructure process. Establishing administrative procedures for migration objects enables you to preserve the objects both in the source and the target domains, and therefore enables you to fall back to the premigration environment in the event that the restructure process is not successful.

Plan for the administration and management of the following types of account migration objects:

  • User accounts, including SIDs.

  • Global group membership.

  • User profiles.

Administering User Accounts

During the migration process, user accounts exist in both the source and the target domains. Administer changes to user accounts in the domain in which the user object is active. Continue to administer changes to group memberships in the source domain while the migration is taking place. Use the Replace conflicting accounts option in ADMT to remigrate user accounts as often as necessary during the migration process. This ensures that changes made to the account in the source domain are propagated to the account in the target domain. This operation merges the existing account and the new account so that administration of the object can continue in the source domain for the duration of the migration process.

The Replace conflicting accounts option applies the following guidelines when an account is migrated:

  • If you change an attribute in the target domain and it is not used in the source domain, then it is not overwritten with the NULL value from the source domain.

  • If you change an attribute in the target domain and it is used in the source domain, then it is overwritten with the value from the source domain.

  • If the user has group memberships, the memberships are merged together from the source memberships and the target memberships.

If this is not the desired behavior, you can configure ADMT to exclude attributes from being migrated so that attributes in the target domain are retained.

For example, if you migrate a user and after you complete the migration you set attributes on the new user object in the target domain, such as a telephone number or office number, and you remigrate the user by using the Replace conflicting accounts option in ADMT, the new information is retained in the target domain. If you changed the group memberships for the user in the source domain, the changes are propagated to the target domain when you perform the remigration.

Some attributes are excluded from the migration. These include:

  • Attributes that are always excluded by the system

  • Attributes that are in the system exclusion list

  • Attributes that are configured by the administrator to be excluded

Attributes that are always excluded by the system

Some attributes are always excluded from the migration by ADMT and cannot be configured to be migrated. This protects system-owned attributes. These attributes include:

  • Object globally unique identifier (GUID)

  • SIDs (although SIDs can be added to the SID history of the object in the target domain)

  • LegacyExchangeDN

System attribute exclusion list

The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications.

Attribute exclusion list

Administrators can define a list of attributes that are excluded from each migration. This is called an attribute exclusion list. By default, when using the ADMT console, state information for attributes that are configured to be excluded is stored in the UI and included in the exclusion list for the next migration. Scripting and command-line attributes do not have state information and therefore are not stored in the UI. These attributes must be added to the attribute exclusion list for each migration operation, either by means of the attribute name or by means of an option file.

Administering Global Groups

Continue to administer the groups in the source domain during the migration process. Remigrate groups as often as necessary by using the Replace conflicting accounts option in ADMT to ensure that changes made to group memberships in the source domain are propagated to the groups in the target domain.