Share via

Managing Users, Groups, and User Profiles

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

You must define how the objects that you are migrating are to be administered during the interforest restructure process. By establishing administrative procedures for migration objects, you can preserve the objects both in the source domain and the target domain. Consequently, you can fall back to the premigration environment if the restructure process is not successful.

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

  • User accounts, including security identifiers (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 Migrate and merge conflicting objects option in the Active Directory Migration Tool (ADMT) to remigrate user accounts as often as necessary during the migration process. This ensures that changes that are 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 Migrate and merge conflicting objects 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, 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, it is overwritten with the value from the source domain.

  • If the user has group memberships, the memberships are merged 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, suppose that after migrating a user, you set attributes on the new user object in the target domain, such as a telephone number or office number. You remigrate the user by using the Migrate and merge conflicting objects option in ADMT, and 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 attributes include the following:

  • Attributes that are always excluded by the system

  • Attributes that are in the system attribute 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 the following:

  • Object globally unique identifier (GUID)

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

  • LegacyExchangeDN

  • objectSid

  • sAMAccountName

  • Rid

  • pwdLastSet

  • userPassword

  • member

  • userPrincipalName

  • manager

  • managedBy

  • isCriticalSystemObject

  • legacyExchangeDN

  • lastLogonTimestamp

  • dNSHostName

  • msDS-AuthenticatedAtDC

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 Microsoft 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. For more information about creating a script to exclude system attributes, see article 937537 (https://go.microsoft.com/fwlink/?LinkId=207024) in the Microsoft Knowledge Base.

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 user interface (UI) and included in the exclusion list for the next migration. Scripting and command-line attributes do not have state information. Therefore, they 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 Migrate and merge conflicting objects option in ADMT. This ensures that changes made to group memberships in the source domain are propagated to the groups in the target domain.

Planning for a user profile migration

User profiles store user data and information about the desktop settings of the user. User profiles can either be roaming or local. The migration process is different for local and for roaming profiles.

Profile translation is one type of security translation, and profiles are translated during the migration process. If you perform security translation in add mode, the SIDs in the target and the source domains both have access to the profile. Therefore, if you have to roll back to the source environment, the SID in the source domain can use the profile. If you perform security translation in replace mode, you must retranslate the profile by using a SID mapping file (undoing the security translation) to roll back to the source environment.

Important

If you have to roll back to your original configuration, notify users that profile changes made in the target domain are not reflected in the source domain.

Some organizations might choose not to migrate user profiles. Other organizations might choose to replace users’ workstations during the user account migration process, and use a tool such as the User State Migration Tool (USMT) to migrate user data and settings to the users' new computers. The following table summarizes the migration requirements for user profiles.

Type Description Migration Requirements

Roaming profiles

User profiles are stored centrally on servers. Profiles are available to the user, regardless of the workstation in use.

If you are migrating roaming profiles that are used on Windows Vista or later, prepare the roaming profiles for migration. For more information, see Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows.

During user account migration, select Translate roaming profiles on the User Options page in the User Account Migration Wizard. Then, translate local user profiles for a batch of users immediately after you migrate those users.

Local profiles

User profiles are stored locally on the workstation. When a user logs on to another workstation, a unique local user profile is created.

Translate local profiles as a separate step from the user account migration process. Select User profiles option on the Translate Objects page of the Security Translation Wizard. Translate local user profiles for a batch of users immediately after migrating those users.

Profiles not managed

Same as local profiles.

Users lose their existing profiles when their user accounts are migrated.

Hardware refresh

User state information is stored locally on the workstation.

Migrate as a separate step from the user account migration. Migrate the profiles to the user’s new computer by means of a tool such as USMT.

Preparing for migration of roaming profiles with computers that run Windows Vista and later versions of Windows

A roaming profile location is configured for a domain user account, and specified in the following way:

\\host.name.fqdn\ProfileShare\<profilename>

Typically <profilename> is replaced with %username%. Thus the actual location of a roaming profile for user RoamUserX is:

\\host.name.fqdn\ProfileShare\RoamUserX

The roaming profile folder (in this example, RoamUserX) is created at the time of first logon for RoamUserX, and the actual profile data is stored within that folder.

Beginning with Windows Vista, a change was made to profiles that made them incompatible with previous versions of Windows. To differentiate the new profiles, a .V2 extension was added to all roaming profiles for users on computers running Windows Vista and later.

The location of a roaming profile for the same user RoamUserX for a computer that runs Windows Vista or later is:

\\host.name.fqdn\ProfileShare\RoamUserX.V2

This version can co-exist with a roaming profile for an earlier version of Windows.

ADMT distinguishes the two different profile folder names.

In order to migrate a roaming profile folder using ADMT, the default access control list of the folder needs to be modified. By default, when a user logs on and the roaming profile folder and contents are created, the <profilename> or <profilename>.V2 folders are given the following ACLs:

  • SYSTEM – Full Control

  • user_name - Full Control

  • Owner = user_name

Therefore, only the owner of the profile, and the local system on which the share resides, are able to access the <profilename> or <profilename>.V2 folder. When the folder is assigned those default permissions, ADMT cannot access the folder for security translation.

To configure the folder permissions in order to allow ADMT to migrate the roaming profile, you can enable a Group Policy setting for the domain:

Computer Configuration\Policies\Administrative Templates\System\User Profiles\Add the Administrators security group to the roaming user profiles

If this setting enabled and propagated before the first logon of the user (before the roaming profile is created), then the roaming profile directory will have an added permission that grants Full Control to members of the Administrators group of the share host (host.name.fqdn in this example).

After this setting is enabled, migrations can be performed as long as the user who runs ADMT is included in the Administrators group of the share.

The user who runs ADMT user needs Full Control access on the roaming profile folders. To achieve that, you can try one of the following options:

    1. As a user with administrative access on the share computer (host.name.fqdn in this example), take ownership of the profile directories. This will give the ability to adjust ACLs as necessary.

    2. Add the user who runs ADMT to the ACL with Full Control and have the permission inherited to all subfolders and files.

    3. Perform the migrations.

    4. After the migration, restore the migrated as the owner of their own profile directory.

  2. Create a script (for example, using Windows PowerShell) that performs that following:

    1. Executes as SYSTEM on the share computer (host.name.fqdn in the example)

    2. Adds the Administrators security group to the ACL set of the profile folders – propagating to all subfolders and files

    3. Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files.

  3. Create a script (for example, using Windows PowerShell) that performs that following:

    1. Runs in the context of each roaming user (for example, as a logon task).

    2. Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files.