Windows 8 : Upgrading or migrating from a previous version of Windows (part 4) - Migrating user data

Migrating user data

Consider an example in which you have a shared computer that the marketing department uses for interns who need to access the Internet. The computer is not connected to the domain, but it has a network connection. This summer, Bob, Mary, and John are the interns using the computer. Because of a policy to replace computers every three years, this computer is due for an upgrade to the new company standard computer. To migrate the user data between computers, the command looks like this:

ScanState c:\migstore /i:miguser.xml /r:5 /w:5

This ScanState command migrates all the user data for these users and the administrator to the local C:\migstore folder so all the users and their data are easily moved to the new system. If errors occur, five retries will be used, and the application will wait five seconds between attempts. After the information has been collected from the original computer, you can run Loadstate.exe to complete the migration process.

In many cases, a computer will have more than one user profile because several people have logged on to the system. In the previous example, ScanState found three user accounts; ScanState and the data for them was copied to the StorePath. The /i:miguser.xml option specifies that user data should be migrated, and by default, all the user profiles are included in this process.

The migration file can be stored on a network share as long as the user account running the User State Migration Tool has access to the share.

Note

A TIP FOR MIGRATION

You might want to place the migration file and USMT application files on a removable USB drive if you will be managing a few machines. Then, if you need to perform a one-off migration, you can use the USB disk to access the tools and store the files.

The process of bringing the migrated data to the new computer is as simple as changing from using the ScanState.exe command to using the LoadState.exe command. In many cases, the same options can also be used for the import. Both the ScanState.exe and LoadState.exe utilities contain an auto switch that uses predefined options to migrate data between computers.

Windows 8 uses a new tool for system deployment called the Assessment and Deployment Kit (ADK) for Windows 8, which contains the x86 and x64 versions of the User State Migration Toolkit. The Windows Assessment and Deployment Kit for Windows 8 can be used on previous versions of Windows, including Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2.

You will still use LoadState.exe to complete a USMT migration; the tool looks much like it did in Windows 7. When the latest version of the USMT is installed on Windows 8 and the .mig file from the previous portion of this lesson has become available, you can begin LoadState.exe.

AN EFFICIENT WAY TO MIGRATE FILES

When I have used LoadState to complete migrations to Windows 8, I have found that copying the migration file to the hard disk of the target computer was the best way to complete a migration. The tool can use network shares to store files, but given the size of some of these files, the local copy proved the most efficient.

To start LoadState.exe, open an administrative command prompt on the target computer and navigate to the folder on which the USMT is located. By default, this is C:\Program Files (x86)\Windows Kits\Assessment and Deployment Kit\User State Migration Tool.

Choose amd64 or x86, depending on the architecture used in the migration. Like in other scenarios, information from a 64-bit Windows-based source computer must be migrated to a 64-bit target computer. Attempting to mix architectures will result in errors, causing the migration to fail before it starts.

Using LoadState.exe is fairly straightforward; however, it is important to be aware of the following restrictions:

• If the user account is not created as part of the data migration, the data will be migrated and accessible to those users with permissions, but no user account will be tied to that data. When attempting to create user accounts to rectify the issue, Windows will point out that the user account already exists.

• Large user profiles will cause slower migrations, and not everything you might think is contained in a profile will be transferred. When performing user state migrations, files and folders can be contained within expected folders that are skipped during the process. For example, a Pics folder within My Photos might not be migrated, depending on the options used when performing the migration.

These aren’t reasons to avoid the tools, but they are items that you should think about before going through migrations of data. Nothing is worse than finding out after the fact that things are missing.

Data for five user accounts was migrated out of a Windows 7–based computer to be stored for later import into a Windows 8–based computer. The command for bringing this into Windows 8 by using LoadState looks like this:

Loadstate.exe c:\<storefolder>\ /i:miguser.xml /c /lac

This command creates the users found in the migration file as local users because of the /lac switch. In addition, /c allows LoadState to skip over non-fatal errors and continue without interruption.

Using /i:miguser.xml enables only the user data to be migrated into the Windows 8 environment. Because ScanState.exe and LoadState.exe have many of the same switches and options, keeping the options similar for each migration tends to make the process a bit smoother. Another thing to understand about LoadState is that the /lac switch allows the creation of user profiles, but it does not create actual user accounts for logon.

Lessons learned during a test migration

When creating a test user called Bob on a Windows 8–based client machine, who also happened to be a test user on the Windows 7–based machine used for migration, it was noticed that if Bob was around before pulling in the migrated data with LoadState, the user information appeared as expected on Bob’s desktop.

After the migration completed, adding a user with the same user name as one used in the migration did not work. Windows indicated that this user name was already used. Doing this makes sense in some cases. If you are moving one user to a new computer and need to ensure that his or her account and all its information arrive, creating the account ahead of time can be helpful, especially for local users.

For domain accounts, the migration behaves a bit differently. Because user account information is accessed during the logon process, the logon can be tied to an existing set of user information, allowing access to the account data. For example, Bob works for Contoso and has a user object in the Contoso domain. He is getting a new Windows 8–based computer, and the IT department migrated his information. When looking at the C:\Users folder on the new computer, Bob has a user profile folder. When Bob logs on as Contoso\Bob, the Active Directory domain logs him on and attaches to the profile folder on the computer, providing access to the documents, settings, files, and other folders Contoso\Bob maintained in his profile that was migrated from his Windows 7–based computer. If the profile for a user, like Bob, already exists, the user’s domain profile is stored using the <domain>.<user> nomenclature—in this case, contoso.bob, to ensure that it is separate from the bob local account folder.

Important

MIGRATING LOCAL ACCOUNT DATA

When migrating local account data from one computer to another, ensure that the user account exists on the Windows 8–based target machine prior to migrating the user account data into that system. Failure to do so will likely render logon impossible. Because Active Directory accounts do not authenticate locally but can store data in profile folders, no staging of these accounts is required.

Note that the User State Migration Tool requires a top-level directory for the StorePath, such as C:\Store. This path is needed because compressed and uncompressed files can be within the same store. Using this path simplifies the migration process by allowing the migration tools to use both compressed and uncompressed files.

When creating your store folder, remember the USMT folder that is created inside the path chosen during ScanState. Failure to include this folder when running LoadState, especially if you move the StorePath folder, will result in errors.

If you are logged on to the target computer as one of the user accounts being migrated from another computer, the settings might change for that account as they are imported. For example, if your user account is being migrated from another computer and you are logged on and performing the LoadState operation, you might notice that some settings, including desktop personalization items, change during the process.

In many cases, you are unlikely to work with local user accounts on the job because most organizations employ Active Directory domains to manage users and computers. Remember that when you are migrating user information, the user account must exist on the target computer for that data to be accessible. The easiest way to ensure that this happens is to log on to the target system as one of the users whom you are migrating while ScanState is running.

Remember that the User State Migration Tool exists to enable administrators or IT staff to ensure a smooth user experience during a computer change. When used carefully, the migration can be smooth for all parties involved.