Reference Materials for Migration 8.15 - Tips and Tricks

Active Directory Migration

The Active Directory migration scenario assumes you need to migrate only user accounts and resources (such as end-user workstations, file and print servers, and BackOffice servers) to another domain in the same or a different Active Directory forest. Either Exchange Server is not installed in the source forest or for some reason you do not want to migrate Exchange data to the target.

The Active Directory Migration scenario is illustrated in the figure below:

Figure 1: Overview of Active Directory migration process.

To migrate Active Directory, complete the following steps.

1. Establish directory synchronization between the source and target domains (optional). Configure the Directory Synchronization Agent to synchronize only object properties (including passwords and group membership) for all accounts within the specified synchronization scope. This ensures that all properties of source and target users are kept in sync during the co-existence period. If the coexistence period is short, you can skip this step.

2. Migrate the directory. Migrate accounts from the source to the target domain in migration sessions. You can delegate rights to perform the account migration to the other administrators in your environment.

3. Process distributed resources. Update distributed resources, such as end-user workstations, file and print servers, and application servers using Resource Updating Manager, adding permissions to the resources for the target users. When user workstations are updated, user profiles should also be updated, so the migrated users will get the same profile as the corresponding source users when they log on to the target domain for the first time. You can delegate rights to perform resource update to other administrators.

4. Move end-user workstations and servers to the target domain. This step is actually the user switch, because when you move a workstation to a target domain using Resource Updating Manager, the last logged-in domain on users’ workstations is changed from the source to the target domain and thus users start to log in to the target domain. Move file and print servers and other application servers that have been processed by Resource Updating Manager to the target domain.

5. Process BackOffice servers. Update Microsoft BackOffice servers, such as Exchange, SQL, and SMS Server, using the corresponding processing wizards. You can delegate rights to perform BackOffice server update to other administrators.
6. Move BackOffice servers to the target domain.
7. Stop directory synchronization (optional). If you established directory synchronization between the source and the target domains in step 1, stop and uninstall the Directory Synchronization Agents.
8. Disable the source accounts. We recommend that you wait some time after disabling the source accounts to make sure that all users are using their target accounts before you proceed to step 9.
9. Enable SID filtering. After you enable SID filtering, wait some time to ensure that all target users can access the resources they used before the migration.
10. Clean up SIDHistory from the target accounts. Once all users are fine and have access to resources they had before, proceed to clean up SIDHistory.
11. Clean up legacy account permissions from resources. Note that cleanup is hard to undo. It is recommended that you clean up permissions only when you are sure that all users are using their target accounts for all applications and have no problems accessing resources.
12. Clean up service attributes used for migration.
13. Decommission the migrated environments.

Step 1. Establish Directory Synchronization (Optional)

The following are the important issues to consider when synchronizing directories:

• Whether you need to establish directory synchronization
• Whether you need one-way or two-way directory synchronization
• Whether you should allow the Directory Synchronization Agent to create the objects

Do You Need to Synchronize the Directories?

Depending on your project requirements, you may or may not use the ongoing directory synchronization capabilities. You can skip this step if you are going to migrate a small number of objects from one Active Directory forest to another and the coexistence period (when there are active user accounts in both the source and target environments) is expected to be short (for example, a weekend).

However, directory synchronization is required if any of the following applies:

• You need to migrate a large number of objects from one Active Directory forest to another.
• The objects and resources are migrated in groups (for example, by departments).
• The source and target environments must coexist during a period of time (that is when administration happens in both environments).
• You need to migrate user mailboxes from one Exchange organization to another. Refer to the Exchange Migration and Active Directory and Exchange Migration scenarios for more details on directory synchronization requirements when Exchange migration is involved.

We recommend that you establish directory synchronization between source and target domains to ensure that objects’ properties are kept in sync and changes made to the objects in one directory are replicated to another directory.

Should You Choose One-Way vs. Two-Way Directory Synchronization?

In most cases, you only need one-way directory synchronization to be established between the source and the target domain and directed from source to target. This is the case when you migrate objects in groups to the target domain while continuing administration only on the source (make changes only to source objects) during the whole coexistence period. One-way directory synchronization ensures that all changes made to the source objects (such as passwords and group membership) that have been migrated to the target are replicated to the target directory.

However, sometimes two-way directory synchronization is needed. This is the case when two production directories are merged (for example, when two different companies merge), administration is performed on both sides simultaneously, and you want changes made to the objects on either side to be replicated to the other side.

Should You Have the Directory Synchronization Agent Create the Objects?

The Directory Synchronization Agent matches source and target objects by the criteria you specify. However, if the agent cannot find a matching object in the directory (no matching criterion is met), it can create one and then synchronize object properties.

The best practice for the Active Directory Migration scenario is to establish ongoing directory synchronization between the domains without object creation capability and to migrate the objects from the source to the target domain using migration sessions.

The other benefits of creating objects in the target domain by migrating them in migration sessions are:

• You can migrate the OU hierarchy in the migration session.
• You can specify the target OU in which the accounts will be created.
• You will be able to undo the migration session, if needed, by rolling back all changes made to the target directory.
• You can use import lists to rename and merge accounts on the fly.
• You can modify the accounts’ attribute values to be applied in the target domain.
• You can test your migration session using test mode and then use this session as a template for the live migration sessions.
• You can granularly select objects by their group membership.

The properties of the migrated objects will then be kept in sync by the Directory Synchronization Agent.

Keep in mind that if you establish directory synchronization and do not allow the Directory Synchronization Agent to create objects in the target directory, this does not prevent the Directory Synchronization Agent from searching for target objects that match the source objects by the matching criteria specified. If the agent finds a matching object for the source object in the target domain, it will merge and synchronize these objects regardless of whether the object was migrated in a migration session.

However, if you are going to implement the Exchange migration scenario, you may want to allow the Directory Synchronization Agent to create the disabled mailbox-enabled objects in the target domain. For more information about the Exchange migration scenario, refer to the Exchange Migration topic.

Step 2. Migrate the Directory

Using Migration Sessions

Migrate the accounts from one source domain to another using migration sessions.

Depending on your project requirements, you can migrate accounts in one or more migration sessions. You can also delegate account migration to other administrators by creating and pre-configuring the delegated migration sessions. For more information about delegated migration, refer to the Delegating Migration Activities topic earlier in this document.

We recommend migrating user accounts and groups together in one session in order to transfer group membership to the target accounts during a session. However, if you plan to migrate user accounts and groups in portions using multiple sessions, we recommend you use the following order to successfully transfer group membership information:

1. Migrate user accounts in multiple sessions.
2. Migrate universal, local and global groups.

If you migrate groups before users, group membership may not be resolved if a user account that is a member of the source group is not yet migrated to the target domain. Additional steps will be required to update group membership on the target after the user account is migrated, such as re-migrating and merging groups or running full directory resynchronization (if directory synchronization is established for that pair of domains).

Adding SIDHistory

We also recommend that you always add the SIDHistory attribute to the target accounts. This greatly helps to ensure that there is no impact to end users during the co-existence period of two environments, making your migration smoother.

Migrating Other Active Directory Objects and Preserving OU Hierarchy

Migration Manager allows you to migrate not only user and group accounts, but also other Active Directory objects, including organizational units (OUs), contacts, print queues, shares, and computers. If you want to preserve the existing OU hierarchy, select the OUs that you want to create in the target domain as well as objects to be migrated within these OUs.

Migrating Computer Accounts

We also recommend you select and migrate computer accounts in migration sessions. This allows you to specify the target OU where computer accounts will reside. When you later move computers from the source to the target domain, the existing (migrated) computer accounts will be used and no new computer accounts will be created in the default Computers OU in the target domain. You can also use these migration sessions to populate the computer list in Resource Updating Manager later with the computers to be processed. This eliminates the need to select individual computers that must be updated from all computers in the source domain.

Step 3. Process Distributed Resources

Distributed resources are end-user workstations, file and print servers, servers running IIS, scheduled tasks, and other services and applications. To ensure that resources will still be available to users when they start using their target accounts and when you have cleaned up SIDHistory, permissions granted to source accounts to access the resources must be re-assigned to the target accounts.

Service accounts and accounts used to run scheduled tasks must also be changed to the corresponding target ones to ensure that services and scheduled tasks will run correctly after the source accounts are disabled.

Update Methods

In order to re-assign user rights and permissions set to the objects, update local group membership, and change service and scheduled tasks’ accounts, distributed resources must be updated. You can do this in any of the following ways:

• Interactively, by using Resource Updating Manager (recommended). In this case the updating agent is installed on each computer selected for processing and controlled from Resource Updating Manager remotely. This also allows you track processing status and results.
• Locally, by using the command-line updating tool Vmover.exe and INI files. You can run the update on a computer either directly, from a command line, or via a user logon script.

Items that Can be Updated

The following items can be updated:

• Local group membership
• User rights
• Services
• Scheduled tasks
• Registry
• Local profiles
• Roaming profiles
• Shares
• Printers
• File system
• IIS
• DCOM
• COM+

"Leave Source Accounts' Permissions" Option

We strongly recommend selecting the Leave source accounts’ permissions option when updating the resources. This ensures that source users will still be able to access the resources after they have been processed. Then if you need to roll back and use your source accounts again, rollback will be immediate and therefore have no impact on source users. The permissions for these legacy accounts can be cleaned up after the migration is over (see step 10 below).

Factors to Consider

Here are the factors to keep in mind when doing the resource updating:

• The more objects the computer has (in most cases, this means the more files and folders), the longer it will take to process. Thus, processing a file server takes much longer than processing a workstation.
• Updating file system permissions requires a lot of disk access (I/O) operations and may slow the server for a period of time.
• Each computer in a set is processed by its own agent. Thus, all the computers are processed in parallel and it takes approximately the same time to process a dozen of workstations as a thousand.
• Expect about 10% of your workstations to require troubleshooting because they are offline, the Server service is not running, the domain administrators were removed from the local Administrators group, etc.

Accordingly, it is recommended that you create separate groups for end-user workstations and servers and that you process workstations first and then servers. See the Resource Updating Manager online help for details.

You may also want to perform server processing during non-business hours to ensure that no users are affected by a possible server slowdown.

Creating a Computer List

In Resource Updating Manager you can create the computer list in either of the following ways:

• Using information of the Computer Browser service (running on the console where Resource Updating Manager is started).
• Using the domain controller information. This allows for creating the list of computers from the domain controller, and therefore it will not be affected if there are problems with the Computer Browser service or WINS.

Administrative Rights

Administrative rights over the resources are required for successful resource updating (see the Quest Migration Manager - System Requirements and Access Rights document). To obtain administrative rights you can do any of the following:

• Add the account you are currently logged on to the console with to the local Administrators group on each computer to be updated.

• Use another account that is a member of a computer’s local Administrators group to connect to the computer. In Resource Updating Manager you can specify the credentials for each domain.

Server Service

Server service is automatically installed when you install the File and Printer Sharing service on the computer.

Server service must be running on a computer in order for it to be updated from either Resource Updating Manager or the command-line updating tool VMover.exe.

If for some reason (for example, due to your corporate policy) Server service is not allowed to run on the computers, you need to install or enable Server service temporarily, update the computers, and then disable or uninstall the service.

Client-side Firewalls

In Windows XP Service Pack 2, Microsoft introduced the Security Center, which includes a client-side firewall application. The firewall is turned on by default and configured to filter the packets sent to ports 137–139 and 445. These ports are used by the File and Printer Sharing service that must be installed and running on the computer to be updated.

In order to successfully update Windows XP Service Pack 2 computers from Resource Updating Manager, the File and Printer Sharing service must be added to the firewall Exceptions list and ports 137–139 and 445 must be unblocked.

If the File and Printer Sharing service was installed and running on a computer and a shared folder or printer were then created on that computer, these ports will remain open after you apply Service Pack 2 on Windows XP computer. However, if there were no shared folders or printers created prior to Service Pack 2 installation, these ports will be blocked. You need to make sure that ports 137–139 and 445 are not blocked by the firewall.

To install the File and Printer Sharing service:

1. Open the Local Area Connection settings as follows: right-click My Network Places icon on the desktop and select Properties. In the dialog that appears, right-click the Local Area Connection and select Properties.
2. In the Local Area Connection Properties dialog, click Install.
3. In the Select Network Connection Type dialog, select Service and click Add.
4. Select the File and Printer Sharing for Microsoft Networks in the Select Network Service dialog and click OK.

To unblock the ports used by the File and Printer Sharing service:

1. Start the Windows Firewall snap-in from Control Panel.
2. Check File and Printer Sharing in the Exceptions tab and click OK.

Command-line Updating

If for some reason you cannot use the agents to update computers from Resource Updating Manager, you can update the computers locally, using the command-line updating tool VMover.exe.

VMover.exe is located in the Aelita Shared\Migration Tools\Resource Updating\Agent subfolder of the Migration Manager installation folder (64-bit VMover.exe is located in the x64 subfolder). The update can be performed either directly from the command line or via a logon script.

To perform the updates, VMover retrieves the source-target account pairs from the INI file. This file can be created in Resource Updating Manager.

When using the INI file, VMover will perform the updates for all accounts migrated by that time the INI file was created.

Refer to the Quest Migration Manager for Active Directory Resource Processing Guide for more details.

Centralized Resource Update

Use Resource Updating Manager for centralized resource update. Determine the processing scope, i.e. select the computers on which you want to update resources. For that, you should create collections and include computers you want to process (for example, all workstations or all servers). Each collection will contain the computers to be processed, and the set of processing settings. You can create as many collections as needed. Remember to obtain administrative rights over the resources. For details, refer to Resource Updating Manager help.

Delegated Resource Update

We recommend you use delegated resource updating in sites or resource domains where you cannot get administrative access to computers.

Delegated and decentralized resource updating is useful if computers to be updated are located across a slow WAN connection and therefore sending multiple agents, no matter how small, would consume too much of the available bandwidth.

You can delegate the resource updating tasks to the remote site or to other domain administrators who have the required level of access and are located within an area of good connectivity to the computers to be updated.

Resource updating can be delegated by exporting the INI file and performing resource updating using this file by running the updating tools in stand-alone mode or running resource updating from the command line

Delegating Resource Processing Tasks

To delegate a task to other administrators

1. In Migration Manager, right-click Tasks under the Resource Processing node, select New Task, and select the task type.

2. Depending on the task you selected, the appropriate task configuration wizard will start. Select the Delegate the resource processing task option in the Configuration Mode step.
3. Specify the desired re-permissioning options for the task in the Re-Permissioning Options step.
4. In the Delegate Task step, select the accounts to whom you want to delegate the task and specify the Resource Admin role for these accounts.
5. Save the task configuration. The task will then appear in the Tasks container.

After the task is delegated, the delegated administrator can start Migration Manager from his or her location, connect to the migration project, select the task in the tree he or she was delegated rights to, configure the task (for example, specify the resources to be processed by the task), and run the task.

Creating Task Setup Packages

The setup package is a standard MSI installation file. There are two types of the setup packages:

• Packages containing the task configuration only, which are for administrators with Migration Manager installed on their workstations
• Packages containing the task configuration and executables needed to run this task, which are for administrators without Migration Manager installed

To create an MSI installation file for the task

1. In Migration Manager, select the task under the Resource Processing | Tasks node and right-click the task.
2. Click Create Setup on the shortcut menu.
3. Specify the output folder for the package.
4. Select the type of the MSI installation package.
5. Click Start.

Delegating Resource Update Using INI Files

Delegated resource updating can be performed by delegated administrators using the INI files received from the migration administrator.

Updating User Profiles

A user profile consists of two parts: the key in the system registry and the folder on a hard disk that contains user-specific data, desktop settings, and a registry hive stored in NTUSER.DAT file. Depending on where user data is stored (on a local hard disk or server), user profiles can either be local or roaming.

When a user configured with a roaming profile logs on to a workstation for the first time, a local copy of the roaming profile is created on the workstation. NTUSER.DAT is copied from the roaming profile folder to the corresponding local one as well.

User profiles (profile folders and registry keys for both local and roaming profiles) get updated when you run distributed resource updating from Resource Manager and select both the Local profiles and Roaming Profiles options.

After processing, the profiles are shared between the source and target user accounts. As a result, target users will use the same profiles as the corresponding source users do.

Enabling the “Cross-Forest User Policy and Roaming User Profiles” Policy

If the end-user workstations are running Windows 2000 SP4 or higher, you should enable the Allow Cross-Forest User Policy and Roaming User Profiles policy before you move the workstations to the target domain. This is to allow users to use roaming profiles stored on a server that is still a member of the source domain.

You can configure this policy either locally on the client workstation or by using a domain or organizational unit-based Group Policy object (GPO). To do this locally on a workstation, complete the following steps:

1. Log on to the computer as a user with administrator rights.
2. Click Start, click Run, type gpedit.msc, and then click OK.
3. Double-click Computer Configuration, double-click Administrative Templates, double-click System, and then click Group Policy.
4. In the right pane, double-click Allow Cross-Forest User Policy and Roaming User Profiles.
5. Click Enabled, click Apply, and then click OK.
6. Quit the Group Policy tool.
7. Allow sufficient time for the computer policy to be automatically updated, or update it yourself in Windows 2000 by running the following command in the command line:
   1. secedit /refreshpolicy machine_policy
   2. In Windows 2003 and Windows XP, use the gpupdate command.

For more details on user policies, refer to Microsoft Knowledge Base article 823862 at http://support.microsoft.com/default.aspx?scid=kb;en-us;823862.

Troubleshooting User Profile Update

Many system and service processes work on the workstation on behalf of users (for example, printer drivers and virus scanner services). If such a process does not properly close handles to the user profile hive it used, then the profile cannot be correctly unloaded when the user logs off. In addition, failure to close handles causes a problem with updating of the user profile: if the profile is locked by any service during processing, then the user may get a brand new profile when he or she logs on to the system with the target account for the first time after the workstation has been processed.

The User Profile Hive Cleanup Service (UPHClean) by Microsoft is intended to help troubleshoot such issues. For more information about UPHClean, refer to the following documents:

• Microsoft Knowledge Base article 837115, “Troubleshooting profile unload issues,” at http://support.microsoft.com/default.aspx?scid=kb;en-us;837115
• The UPHClean readme file, available at http://download.microsoft.com/download/a/8/7/a87b3d05-cd04-4743-a23b-b16645e075ac/readme.txt

To download UPHClean, use the following link:

http://www.microsoft.com/downloads/details.aspx?FamilyId=1B286E6D-8912-4E18-B570-42470E2F3582

Update Cluster Servers

Migration Manager is capable of re-permissioning a Microsoft cluster. However, it requires a more involved procedure than what is required by non-clustered servers. Refer to the Cluster Server Migration section of the Quest Migration Manager for Active Directory—Resource Processing Guide for a detailed procedure on how to migrate Microsoft cluster servers with Migration Manager.

Resource Updating Troubleshooting

Workstations

After you run the updating session, some computers you specified may not be successfully updated. The computer may be turned off or inaccessible by the network from your location (network connectivity problems), or you may not have enough rights to connect to it, and so on. Resource Updating Manager allows you to sort computer objects by last error status. If a computer was processed successfully, the last error field is empty and the computer can be removed from the list. Otherwise, you will see error descriptions. The typical errors are:

• Access is denied—You get this error when you do not have administrative rights over the server or workstation. Refer to the Administrative Rights section in theStep 3. Process Distributed Resources topic.
• The network path was not found—The cause is probably one of the following:
  • The computer is turned off.
  • It cannot be accessed by the network from your location due to network connectivity problems.
  • It cannot be found by name (the NetBIOS computer name cannot be resolved into the address due to DNS/WINS issues).
  • No computer with that name exists.
  • Firewall software is installed and enabled on a computer (such as Windows Firewall in Windows XP Service Pack 2) that prevents connecting to the computer.
  • It is a laptop computer whose owner is currently out of the office.

You need to diagnose each situation separately. Use the ping <ComputerName>, ping <Computer_IP_Address> and nslookup commands to determine whether you have a name-resolution problem or whether the computer is turned off or cannot be accessed by the network from your location.

• The Server service is not started – Start the Server service and try to process the computer again or follow the command-line updating procedure to update the computer locally.

Servers

We recommend you update servers during non-business hours to ensure that end users will not be affected by a possible decrease in server performance.

After adding servers to the Resource Updating Manager and starting the updating, wait for all computers to finish even if some have errors. Once the processing is finished, use the sort feature on the column headings to sort computers by problem, fix the problems, and start the updating again for only those computers.