Understanding USMT 4.0 Behavior with UEL and UE

Artigo
11/30/2009

Ned here again, reporting live from the tree. Today I am going to explain an expected behavior with USMT 4.0 when using the /UEL and /UE switches. These have been causing some confusion as mass migrations to Windows 7 have commenced.

Background

The UEL option in USMT is used to exclude user profiles based on their last logon date. You can exclude by number of days, by a specific cutoff date, or just any currently logged on users. The UE option allows you to exclude user profiles from being migrated based on their name. It supports wildcards and domain versus local users. For example:

Exclude any users named “administrator”:

SCANSTATE.EXE /ue:*\administrator

Exclude any Contoso domain users named like “admin”:

SCANSTATE.EXE /ue:contoso\admin*

Exclude any profiles that haven’t been logged on in more than 60 days:

SCANSTATE.EXE /uel:60

Exclude any profiles that haven’t been logged on since July 1, 2009:

SCANSTATE.EXE /uel:2009/07/01

An administrator migrating XP and Vista computers to Windows 7 can use these options to make sure crusty old accounts and special users – such as the local administrator or a service account – are not migrated.

So far so good? Here comes the confusing bit.

Behavior

USMT has a ton of internal rules that control what it does when options are overlapped. UEL and UE both do similar things – they exclude user profiles. What you might expect is that if you specify both settings, any users specified by UE are excluded, and then any other profiles that are older than UEL are also ignored.

You’d be expecting incorrectly.

USMT precedence does not always merge settings – it overrides settings. In this case, using UEL and UE together results in UE being completely ignored. So if a user has logged on within the UEL timeframe - even if they are excluded by UE - they are considered part of the gathered migration units. This behavior is by design.

It certainly makes more sense to me that UE should take precedence. After all, as an Administrator, I know the users that I want to block from the migration. And, I also know that ancient accounts are not worth migrating; no one is using them. So I’d probably want my specific users excluded as well as any generic moldy oldies too.

Workarounds

All hope is not lost though. I have two workarounds for you, depending on the OS from which you are migrating.

First, use the DELPROF.EXE utility on Windows XP to purge old user profiles prior to running the USMT SCANSTATE. This is a free download that allows you to specify the number of days to consider a profile valid, and delete any older ones. Using DELPROF, in a batch script with SCANSTATE, gets you the needed functionality. For example, here I am going to quietly delete any profiles older than 30 days, then USMT will exclude any users named “administrator”:

DELPROF.EXE /q /i /d:30
SCANSTATE.EXE /ue:*\administrator <additional USMT command-line>

Vista or later

If you’re migrating from Windows Vista, there’s a group policy you can use to automatically delete old profiles. By enabling “Delete user profiles older than a specified number of days on system restart” you get the same effect as DELPROF on XP – any profiles older than your specified days are removed automagically during the computer startup. By putting this policy in place before you start migrating computers, you can run your SCANSTATE with just the UE option. Remember that the client computer must be restarted for this policy to run.

Important note: Make sure you have installed SP2 or hotfix KB945122 before deploying this group policy!

You can read more about this group policy here. For the folks that like pictures:

All Operating Systems

Use different settings in the Scanstate versus Loadstate phases. So if you used:

scanstate [options] /uel:14

and

loadstate [options] /ue:*\something
<or>
loadstate [options] /ue:something\*

Then you would get the desired result. The downside to this workaround is that you would be unncessarily gathering data and possibly making the scanstate run much longer/be much larger.

Wrap Up

Hopefully this helps clear things up for you on migrating with USMT. It’s interesting to note that this behavior exists with USMT 3.01 as well, but since Vista could be upgraded directly from XP, most folks never ran into the problem. Removing extraneous profiles prior to running a USMT migration is always a good idea – it makes the migration faster and less error prone. So using DELPROF or Group Policy can be considered a best practice.

For plenty more info on using USMT 4.0 to migrate computers, I recommend:

Ned “what are you waiting for, go deploy Win7” Pyle

Compartilhar via