Wielding the power of USMT in SCCM 2007 R2 without Hardlinks!

By Chris Blackburn

I’m working with a client to fully automate their Windows XP to Windows 7 upgrades using SCCM, and while the OSD piece is in place and new install of Windows 7 from custom image is working, the next challenge is grabbing their user state via USMT.

We’re trying to avoid the whole “hardlinking” piece and take a KISS (keep it simple, stupid!) mentality. There are a lot of good resources online that would no doubt allow us to set this up but I’m always of the camp that Microsoft designed these features to work properly out of the box, so why make things more complicated!

So right out of the box we tried to take the “Capture all user profiles with standard options” setting, but if you do a little more digging behind USMT in general, this utilizes their default XML files: MIGUSER.XML, MIGAPP.XML. The problem with these is that they DO NOT grab anything within system or hidden folders. This is a problem when trying to grab things such as Local Settings/Application Data files, which a number of programs (even Microsoft Office!) utilize for storing settings. So how we do get around it? We need to create a custom.xml file that details what specifically we want to grab (and vice versa, what we want to exclude).

So let’s look at the default MIGUSER.XML and MIGAPP.XML files. The MIGAPP.XML gets pretty deep, as it goes as far as grabbing a lot of the individual application settings. In my client’s environment, they are rebuilding a box from scratch and do not care about any of their canned application settings, so then we really boil down to the MIGUSER.XML. In crafting our CUSTOM.XML file by reviewing some of the examples on Technet, we took a lot of pieces from the MIGUSER.XML, with the exception of purging out the “Shared” document spaces, My Pictures, and My Music. You should find this to be fairly typical however in a corporate environment. We also took it a step further and used some of the common folder (CSIDL) references on Technet to get even more granular on what we pulled from our hard drive.

So now that we’ve built our add the CUSTOM.XML, we’ll add into our USMT package, then, MOST IMPORTANTLY, update our package to the distribution point, and finally make an adjustment to our USMT task sequence, changing from “Capture all user profiles with standard options” to “Customize how user profiles are captured”. Now we’re ready to rerun our task sequence to capture the user state.

By looking at our scanstate.log file, we can see the entire command string that is issued. The only thing that sticks out is the missing “/all” switch, as well as our use of a “custom.xml” file when we change to customizing the process. If we look out at Technet on the scanstate.exe command reference we can see what the /all switch really does:

/all Migrates all of the users on the computer.

So does this mean without this switch we’re not backing up all of the profiles? No! By looking at our scanstate.log, as well as use a tool such as MigRecover to expand our USMT.MIG file, we’ll see the folder structure for all of the users on the box was pulled over. Awesome! This is exactly what we wanted to accomplish: grabbing all files in all specified folders.

The other thing I’d like to share about using MigRecover is by default it will show all expanded files as corrupt. This is because the file is encrypted with a key automatically by SCCM using these task sequences, and while expanding allows us to view the hierarchy of the file but not actually execute the files themselves. So where do we get the encryption key, since the scanstate.log only shows *** ? Easily enough, if we go under Computer Associates in SCCM and right-click on the target machine, by selecting View Recovery Information we get the key listed here. Now when we use MigRecover we simply add the password to the end of the file, and volia – we can fully access our archive.

Share your thoughts

css.php