Ned here again. To paraphrase Mark Twain, reports of XP’s life have been greatly exaggerated. Mainstream support ended in April 2009 and Service Pack 2 support ends on July 13, 2010 . With the release - and crazy popularity – of Windows 7, companies are exploring various options to move on from XP.
But there’s a catch: XP cannot be in-place upgraded to Windows 7. And even if you could upgrade it, most IT admins are wary of in-place upgrades, even if only by reputation. So what do you do? You use USMT 4.0’s new offline migration feature /OfflineWinOld .
1. Examine your current XP image(s) and inventory what applications are installed.
2. Make a decision on how you plan to deploy:
a. Use a Windows 7 DVD and install applications by hand (less than 100 computers – keep reading this post)
b. Create a new Windows 7 image that contains all your applications and is sysprepped (more than 100 computers – go read all about large deployments and maybe forget about this post ).
c. MDT 2010 or SCCM 2007 ( go read Mike and Dan’s blog and definitely forget about this post! )
3. Install WAIK somewhere and drop the USMT directory onto a network share or thumb drive.
4. Install Windows 7 on an XP computer using a “Custom (Advanced)” installation and not formatting the hard drive. Add the applications and join the computer back to the domain.
5. Run USMT scanstate with an offlinewinold hardlink migration.
6. Run USMT loadstate against that hard link store.
7. Repeat steps 4 to 6 until done.
8. Give self a raise - just like Congress.
Critical note: Everything I describe below is happening in your test environment first. Really .
Another critical note: There are certain OS customizations that may have made that cannot be migrated offline due to product limitations. Make sure that nothing on this list really bothers you before proceeding:
In addition, offline migrations can’t handle situations where someone has moved the Program Files or Documents and Settings folders to a different drive than the Windows folder. For businesses, many of these settings are unimportant (Media Center!) or are controlled through Group Policy anyways (Offline Files) so most customers don’t get in a twist over them. But if any of these are a show stopper for you, go with a normal online migration. It will be slower but ultimately more capable.
Good to go? On with the show.
1. Begin by inventorying your XP computers. You need to know what applications are installed on them so that they can be reinstalled. Check with your hardware vendors to make sure your computers don’t have any known issues with running Windows 7, or if they have updated firmware if they do. By now any credible vendor can at least tell you if an application is supported or not – even if the answer is “no”. If the vendor doesn’t know, it’s probably time to start looking at competitors – and I bet if you mention that, the vendor will suddenly know in a hurry! :-)
For more Windows 7 application compatibility info, go to our portal here .
2. Decide how to migrate and create your image. In this case, you decided to install Windows 7 by hand, add the applications (or create a simple Win7 image with the applications included), then use USMT to offline migrate.
3. Download the Windows Automated Installation Kit and burn the ISO to a DVD. Install on an administrator computer running Win 2003 SP2, Win Vista, Win 2008, Win 7, or Win 2008 R2 somewhere in the environment. You cannot install it on XP.Inside the (default) location for WAIK you will find the USMT data:
Copy those folders to a network share, to a USB thumb drive, etc. You will be using those files a lot for the next few days. If you only have plans to use x86 and not deploy 64-bit Windows 7 then don’t bother with the amd64 folder.
4. Note the name of your XP computer, and then install Windows 7 over the top of your existing Windows XP installation . In the example below you have booted from the DVD. Click “Install Now”.
You are prompted to choose “Upgrade” or “Custom (Advanced)”. If you choose upgrade, you get smacked down, so make sure you choose custom:
Windows servicing then notes that you already have Windows (XP) installed.
Here’s the critically important part: do NOT delete or format the disk. This sounds obvious, but I’ve already had several people format drives and then ask why USMT didn’t migrate any data. Guess what sort of backups they had taken…
Now, the setup runs and because it is not an upgrade it installs fast . My Windows 7 installations in a hyper-v guest usually take less than 20 minutes.
Log on and install any applications you need – at least the ones that were installed on XP for business use. Join the computer to the domain using the same name the XP computer used. This will keep the domain SID, group memberships, etc. that had belonged to this computer when it was XP.
At this point we have a nice pristine computer that has its old name, is joined to the domain, and has its old applications installed. We’re ready to migrate.
5. Start Windows Explorer and have a look around the drive. There is now a Windows.old folder. Expand that folder and you’ll find inside that all the user profile data exists – this includes files in My Documents , data on the Desktop, the user’s registry settings etc. The Windows.old folder also contains the system’s registry and file structure, under Windows and Program Files . Other folders that were not in the users’ profiles, Windows, and Program Files directories will still be on the drive in their original location. Everything has been preserved.
Open a CMD prompt as an Administrator.
Navigate to wherever you decided to store the USMT files. In the examples below they were copied from a network location to a local folder c:\usmt on the computer being migrated.
Run your scanstate operation. This will examine and gather up all the data that was preserved in the Windows.old folder. This scanstate should include the following commands at a minimum :
/offlinewinold: <path to your old XP Windows folder>
The store path will be used to store migration information about settings and what are called “hard links”. These are pointers to files that allow USMT to migrate those files without having to copy the files into the store or duplicate files that are identical. It saves a huge amount of time and space during the migration.
Note: If you have users that are specifically added to local groups on the XP source computer you will need to use a custom /config:config.xml file to specify that users should be added into specific groups. Usually this is for users that are members of the Administrators group in XP – something which you should not continue to do!
Here is a sample config.xml that makes all migrated users members of the Administrators group. Which again, you shouldn’t do! I cannot emphasize that enough, but I get asked about it frequently. Just remember that if you make your users administrators all the other security best practices in the world will not save them. This goes for every operating system ever made.
<changeGroup from="*" to="Administrators" appliesTo="MigratedUsers">
Genconfig has other good reasons to be run, make sure you look into it.
The scanstate runs, examining all the profiles and the computer configuration. All the data and settings are gathered up into migration units that are saved or hard-linked in the store.
Note: If you are interested in seeing what I mean about hard links, look at this sample output using FSUTIL.EXE . Here I dump out the hard link info from a file that actually exists in the backed up Windows.old folder. The hard link allows it to simultaneously “exist” in both spots at the same time.
Note: If you run the hard link scanstate successfully, you can get an error if you try to run it again:
scanstate.exe c:\store /o /hardlink /offlinewinold:c:\windows.old\windows /nocompress
Failed to delete 'c:\store\usmt'. Windows error 18.
An error occurred processing the command line.
Invalid store path; check the store parameter and/or file system permissions
Scanstate returned code: 27
This is expected. Use the usmtutils.exe tool included with USMT to delete the hard link store, then you can run the scan again. This in no way affects the real data living in windows.old ; it’s just deleting the hard links.
6. Now you run the loadstate operation against the same store you just created – there’s no need to reboot or so anything fancy. The loadstate should include the following commands at a minimum :
All the files, settings, profiles, application configurations, etc. are restored to their original spots on the hard drive. If any of the migrated users logon now they will find their files and settings haven’t changed – for the most part; it is a new operating system after all.
7. Repeat for all the other computers in your test environment . Then evaluate the results, have some users try things out, and consider going for it in production, repeating steps 4-6.
8. Chuckle at all the people that complained about the lack of an XP upgrade, secure in the knowledge that you now have a much more stable system with all the data and settings your users care about.
And yes, we do have this all publically documented in TechNet. But it’s buried pretty well in the appendix of this article and doesn’t have my pretty pictures. :-)
Until next time.
- Ned “no longer a DFSR SME” Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.