Planning a Migration Project with Migration Manager

Overview

This Chapter covers what to consider when planning a migration project with Migration Manager and recommended steps to make migrations as efficient and painless as possible.

Project Considerations

Examining the basic conditions and available resources helps determine the best approach to a project. Aspects to consider include:

Types of Computers and User Profiles

Migration Manager can migrate user state from both regular Windows desktops and from servers used for Terminal Services/Remote Desktop Services. Migration Manager also supports roaming profiles, profiles using folder redirection, and saving user state from offline Windows. Different types of profiles have different requirements.

Number of Computers

Determining the number of computers to be migrated informs whether to automate extraction and injection processes. Migration Manager can handle manual or automated migration up to thousands of systems.

Anti-Ransomware/Anti-Malware

Some anti-ransomware and anti-malware applications create 'bait', 'trap', or 'canary' files which could be migrated by Migration Manager. Applications known to implement this method of preventing ransomware includes RansomeFree, and Palo Alto Traps. It is advised that these types of applications be disabled during the migration process. If these extra files are being migrated and the applications cannot be disabled due to company policies, then configure Migration Manager to not extract these files. This may involve selecting specific folders to migrate files from (instead of migrating file types from all fixed disks such as with 'Data Files' content selection such as Excel Data Files), or by identifying the offending file names and creating exclusion File Rules in Migration Manager to exclude their extraction.

Networked Environment

In a networked environment, a central server may be used to store user state data extracted during migration. Bandwidth limitations must also be taken into account. If no networked environment is available, external media storage will be required.

Operating System Deployment

Is the migration part of an overall OS deployment project in which deployment tools are used? Migration Manager can be integrated with common OS deployment solutions to automate user state extraction from the prior platform and injection (including any upgrade translation required) following OS and application installation by the deployment tool.

User State Data Storage

User state data can take up a considerable amount of space when user data files are included. Sufficient storage space must be provided. Storage space is particularly important if user data will be stored for some length of time (e.g. in gradual migration or user-state backup scenarios). For in-place OS refresh it is recommended to use hardlinks to reduce storage requirements and improve performance.

Migration Manager Process Overview

  1. Install Migration Manager in a central location (see Installing Migration Manager).
  2. Create one or more configuration files using the user interface (see Configuring Migration Manager).
  3. Run Migration Manager on each of the source systems where user state data should be extracted (read). See the “Migration Manager Automation Guide” for more information on how this can be automated.
  4. Run Migration Manager on each of the target systems where user state data should be injected (written) to. This can also be automated.

Installing Migration Manager

Migration Manager supports a single installation on a server from which Migration Manager is shared so it can be accessed and run from other systems. This is described in more detail in Installing Migration Manager.

Choosing a Data Store Location

Bandwidth, storage space, duration of migration and availability of a network connection are all critical considerations in choosing a data store location. The size of a typical user’s data files, multiplied by the number of users being extracted, is a reasonable estimate for how much space is needed (although since Migration Manager compresses data, the space required will typically be less).

As mentioned earlier, the overall migration process determines how much storage space is required. In a large, automated migration project, large volumes of user data may be extracted, requiring more storage space. Additionally, it may be necessary to incrementally extract data from the source systems over a period of time as there may be too many systems to be able to do it in one single operation due to network bandwidth considerations. In this case, dedicated storage space will be required until the data can be injected to the target systems.

Alternatively, less storage space is needed if systems are migrated in small batches. Dedicated storage space will be required only briefly since the data is injected soon after extraction.

For in-place OS refresh using hardlinks, the data store location must be the local NTFS drive.

Creating Configuration Files

The complexity of the migration project determines how many configuration files are required. For a smaller project a single configuration file may cover all migration parameters. For a larger, more complex, project multiple configuration files may be required depending on the variety of applications, different types of users and so on.

Configuration options are described in Configuring Migration Manager and the “Migration Manager Automation Guide” explains how to specify configuration files in automation scenarios.

Extracting User State Data

Extracting user state data is performed on the previous or “source” PC. While extraction can be performed manually using Migration Manager’s user interface, the rich command-line capabilities in Migration Manager make it easy to integrate into any desktop management suite.

Extract User State describes the extraction user interface and the “Migration Manager Automation Guide” provides a complete command-line reference.

Injecting User State Data

Injection is done after target systems have been prepared by installing the operating system and applications. Translations may also occur during the injection process in cases of OS and application upgrades.

Inject User State describes the injection user interface and the “Migration Manager Automation Guide” explains how to automate injections.

Migrating Computers in a Networked Environment

Overview

The most common scenario for using Migration Manager is an environment with one or more Windows domains in which users are migrated from their old systems to new systems. Usually migration occurs in conjunction with an operating system upgrade, application upgrade, and/or PC replacement project).

Source Systems

Migration Manager fully supports both systems primarily used by a single user and systems shared by several users. The “Migration Manager Automation Guide” describes how to include or exclude specific users or categories of users (e.g. local computer accounts).

Target Systems

The operating system and applications must be installed on target systems prior to user state injection. Injecting user state after installing applications is critical, as most installers wipe out settings found during installation and replace them with defaults.

Process

In order to make the migration process as efficient as possible, it’s possible to extract and inject multiple systems in parallel. Migration Manager is flexible enough to support either all extractions followed by all injections, or paired extraction and injection operations.

Migrating Users between Domains

Process

Migration between domains in a networked environment is typically done through command-line automation using the /DOMAIN or /INCLUDEUSER commands (described in the “Migration Manager Automation Guide”). This can also be done in the user interface as described in Inject User State.

Other than specifying the relevant /DOMAIN or /INCLUDEUSER domain, domain migration is no different from the general process for migrating users in a networked environment described above.

Note
Migration Manager does not create domain user accounts. If a user is being migrated from DomainA to DomainB (e.g. the user DomainA\hdowd is being migrated to DomainB\hdowd), the user’s account must already exist in the target domain or the injection will fail.

While the new account must exist, it is not necessary for the user to log on to DomainB prior to migration.

Migrating Stand-Alone Computers

Overview

To migrate individual computers in a stand-alone manner, install Migration Manager and store extracted data on removable storage (e.g. a USB flash drive, a USB hard drive, etc.).

If using a USB flash drive, the device must be large enough to hold extracted user state data. The size of the user’s data files is a reasonable estimate for how much space is needed (although since Migration Manager compresses data, the space required will typically be less).

Installation

The Migration Manager installation program does not display removable devices as possible destination devices. It is necessary to specify the drive letter of the removable device in the installation path.

Alternatively, if Migration Manager is installed on a computer, the installation directory (with all of the sub-directories) can be copied to the removable device.

Process

The following process applies when using a removable storage device:

  1. Add the removable storage device to the source system.
  2. Navigate to the directory where the Migration Manager files are located.
  3. Launch MigrationManager.EXE
  4. Select the users and applications that should be migrated (see Extract User State for more information).
  5. Run the extraction.
  6. Remove the device from the source system.
  7. Add the device to the target system.
  8. Navigate to the directory where the Migration Manager files are located.
  9. Launch MigrationManager.EXE
  10. Select the user state data that should be injected (see Inject User State for more information).
  11. Run the injection.

Of course it’s also possible to create scripts to do the extraction and injection automatically. See the “Migration Manager Automation Guide” for more information on using Migration Manager from the command-line.

Migrating Users with Roaming Profiles

Migration Manager supports migrating users configured to use Roaming Profiles. There are, however, some prerequisites for being able to migrate all user-related information. The best practices configuration steps provided by Microsoft for Roaming Profiles on Windows Server 2008 R2 are summarized below.

Note
The steps below grant System Administrators full access to all files stored on the Roaming Profiles share. This is necessary for Migration Manager to be able to extract files that belong to the users. If this doesn’t work for your environment you will not be able to use Migration Manager to migrate users configured with Roaming Profiles.

Profile Share Configuration

On the server that will be used to hold the Roaming Profiles:

  1. Create the directory where the profiles will be stored (e.g. C:\Users)
  2. Create a share for the directory and give it a name ending with a ‘$’ (e.g. Users$), this ensures that the share will be hidden from browsing.
  3. Grant “Full Control” permissions on the share to these groups:
    • test
    • SYSTEM
    • Roaming Profiles (domain group)
    • Domain Admins (domain group)
    • Administrators (domain group)
  4. Grant “Full Control” security permissions to the directory to these groups:
    • Domain Admins (domain group)
    • Administrators (domain group)
  5. The security group that contains all Roaming Profile domain accounts needs special security permissions to the directory (set to apply to the directory only):
    • List folder/read data (Allow)
    • Create folders/write data (Allow)
  6. Finally, the built-in security group “CREATOR OWNER” must be granted special security permissions to the directory (set to apply to subfolders and files only):
    • Full control (Allow)

Group Policy Configuration

In order for Migration Manager to work properly in a Roaming Profiles environment, the account running Migration Manager operations must have access to all profile resources. The best way to provide the access to Migration Manager in a Roaming Profiles environment is to have the Administrators security group have "Full Control" over Roaming Profiles. This means that the account that runs Migration Manager on target systems must be part of the built-in Administrators group on the system that stores the Roaming Profiles or is part of a domain security group that is part of the Administrators security group.

Note
The built-in Administrators security group must be used since Group Policy does not allow any other security group to be granted administrator access to Roaming Profiles.
  1. Open the Group Policy Management Editor (gpedit.msc) to edit the Default Domain Policy (it’s recommended to edit this policy to ensure that the policy is enforced on all computers in the domain)
  2. Navigate to Computer Configuration | Administrative Templates | System | User Profiles
  3. Enable the “Add the Administrators security group to roaming user profiles” policy
  4. Save and close the Group Policy Management Editor
Note
If you plan on using Migration Manager right away you will need to force a Group Policy on all computers in the domain.

Migrating Users with Folder Redirection Enabled

Migration Manager supports migrating users configured to use Folder Redirection. There are, however, some prerequisites for being able to migrate all user-related information. The best practices configuration steps provided by Microsoft for Folder Redirection on Windows Server 2008 R2 are summarized below.

Profile Share Configuration

On the server that will be used to hold the redirected folders:

  1. Create the directory where the users’ redirected folders will be stored (e.g. C:\Users)
  2. Create a share for the directory and give it a name ending with a ‘$’ (e.g. Users$), this ensures that the share will be hidden from browsing.
  3. Grant “Full Control” permissions on the share to these groups:
    • SYSTEM
    • The security group that contains all users configured to use Folder Redirection (e.g. Folder Redirection Users)
    • Domain Admins (domain group)
    • Administrators (domain group)
  4. Grant “Full Control” security permissions to the directory to these groups:
    • SYSTEM
    • Domain Admins (domain group)
    • Administrators (domain group)
  5. The security group that contains all Folder Redirection domain accounts needs special security permissions to the directory (set to apply to the directory only):
    • List folder/read data (Allow)
    • Create folders/write data (Allow)
  6. Finally, the built-in security group “CREATOR OWNER” must be granted special security permissions to the directory (set to apply to subfolders and files only):
    • Full control (Allow)
Note
The user used to run Migration Manager during extraction/injection of users configured for Folder Redirection must be a member of the Domain Admins security group.

Migrating Users in a Remote Desktop Services Environment

Migration Manager supports migrating users to/from Remote Desktop Services (RDS) and Terminal Services (TS) environments. This section describes recommended configuration settings for Migration Manager to work effectively.

General Setting Recommended Value
Delete temporary folders on exit Yes
Use temporary folders per session Yes
Restrict each user to a single session Yes
User logon mode Allow all connections

The licensing mode of the environment does not impact Migration Manager.

If a Connection Broker is configured for your environment, it’s important to ensure that all user profiles are synchronized among the fail over or farm servers; otherwise the extracted profile data may be incomplete or out of date.

Gateway Configuration

If a Gateway is configured for your environment, the Connection Authorization Policy must be configured to allow the administrator account used to run Migration Manager full access to the server.

The Resource Authorization Policy (RAP) must be configured to allow for the most permissive access to system resources for the administrative account used to run Migration Manager; preferably Migration Manager should be granted access to all resources. If this conflicts with your security policies it’s possible to configure a temporary RAP to allow for permissive access for Migration Manager operations and then revert back to more restrictive RAP when the operation is complete.

Migrating Users from an offline system

Overview

From Windows PE, Migration Manager can be launched from a network share. User states can be extracted from the offline Windows system. The boot drive and Windows PE system drive are automatically excluded. Currently, Migration Manager must be launched from Windows to inject user states.

Process

Install Migration Manager to a network share. Launching MigrationManager.cmd from Windows PE will ensure Migration Manager launches with the same architecture as the Windows PE OS (the offline Windows system can be the same or different architecture). Offline users can be extracted through the user interface or automated. The process can be automated using the same command lines used for migrating an online Windows system, by calling MigrationManager.cmd instead of MigrationManager.exe in the command line. To inject the user states, Migration Manager must be launched from the target Windows machine, and the source offline personality by default is stored under the Windows PE MAC address instead of by computer name.

Overview

During an in-place operating system refresh, Migration Manager can create hardlinks to data files locally on NTFS volumes. This provides a much faster and use very little storage space by not moving the files. By protecting the specified local folder that the hardlinks are stored in during the OS reimage (not handled by Migration Manager), the file data will remain in-place on the computer's drive(s). After the OS reimage, Migration Manager will restore the proper location of the files and the hardlink store can be deleted.

Note
The drive(s) must not be formatted during the the OS reimage, and the storage location of the hardlinks and other personality settings must be protected on each NTFS volume to prevent complete loss of data during this migration type.

Process

Migration Manager can be run from a network share, from an external USB drive, or sent as a package to the client using an ITSM platform (such as SCCM). There are two key configurations related to hardlinks:

  1. The datastore location must be set to a local drive location (such as C:\_Data). This can be done by either setting the Data Store location in the User Interface and saving the configuration, or by command-line (see the section Using Hardlinks in the Migration Manager Automation Guide for details).
  2. The data storage type must be set to use hardlinks. To save this setting in the configation file, select Store data locally with hardlinks (NTFS) within Preferences on the Extraction Policies tab. To do this using a command-line refer to /HARDLINKS in the Migration Manager Automation Guide.

After extracting hardlinks, the location in which settings and the file hardlinks is stored must be protected from being wiped during the OS reimage process. Migration Manager does not provide this, and failure to implement this protection will result in complete data loss. SCCM and MDT provide this functionality with the built in variable OSDStateStorePath.

Note
If using SCCM or MDT for this process, it is recommended the data store location be set using the Task Sequence Variable OSDStateStorePath and specified on the command line with /personalitypath %OSDStateStorePath%. Refer to the Migration Manager Automation Guide section Using Hardlinks for more information.


Note
File attributes read-only and File is ready for archiving do not persist during a hardlink migration due to NTFS limitations.