共用方式為

USMT and U: Migrating only fresh domain profiles

  • 發行項

Hi folks, Ned here again. Frequently someone asks me how to make USMT 4.0 migrate only recently used domain user profiles. This might sound like a simple request for a USMT veteran, but there are some subtleties caused by processing rules and behaviors. Today I go through how this works, talk about pitfalls, and ultimately show how to solve the issue. Forearmed, you can solve quite a few more migration scenarios once you understand the rules and technique.

The goal and initial results

The plan here was to migrate only Cohowinery.com domain user profiles that had been accessed in the past three months, while skipping all local user profiles. This test computer had a variety of local and domain profiles, some of them very stale:

image

The USMT syntax used was similar to this:

Scanstate.exe c:\store /uel:90 /ui:cohowinery:\* /i:migdocs.xml /i:migapp.xml /c /o

So far so good. Then they restored the data:

Loadstate c:\store /uel:90 /ui:cohowinery:\* /i:migdocs.xml /i:migapp.xml /c

Which failed and returned to the console:

Starting the migration process

Processing the settings store

Selecting migration units

Failed.

Unable to create a local account because /lac was not specified

See the log file for more information.

LoadState return code: 14

Looking in the loadstate.log they saw:

The account 7-x64-rtm-01\admin is chosen for migration, but the target does not have account 7-X64-RTM-01\admin. See documentation on /lac, /lae, /ui, /ue and /uel options.

Unable to create a local account because /lac was not specified[gle=0x00000091]

What the? The "admin" user is a local account. Why was that migrated?

image

So they went back and examined the scanstate console and noticed something else:

image

Huh. All the domain users were migrating, even though the BShirley and SDavis had not logged on in more than two years. They could enable /LAC to stop the loadstate failure but that wouldn't accomplish the goals.

Understanding what happened

USMT has complex rules around profile precedence and the /UI, /UEL, and /UE command-line switches. Despite the best efforts of our talented TechNet writer Susan, the syntax is inherently nutty. Let's get the rules straight here first:

  • /UI (User Include) always migrates a profile, regardless of /UE or /UEL. This looks simple until you learn that unless you also specify /UE:* then /UI always migrates all profiles regardless of arguments supplied. You must always use /UE:* if using /UI.
  • /UE (User Exclude) blocks migrating profiles as expected, but it is always overridden by /UEL and /UE.
  • /UEL (User Exclude based on last Logon) migrates profiles based on "newer than" rules; either a date or a number of days. Meaning that if a user's NTUSER.DAT has been modified within the time or date, that profile will be included in migration. /UEL always supersedes /UE.
  • You don’t have to include /UI if you’re using /UEL or /UE. If you're blocking one thing - like if I only want to block local using /UE:%computername%\* - leaving the /UI off is sufficient and less confusing.
  • All users are implicitly migrated. So not providing any switches gets everyone.

Returning to the scenario above, we now know what happened:

  1. /UI was set for all domain users, meaning all domain users will migrate despite /UEL.
  2. /UEL would have blocked local users from migrating, but those accounts had logged on recently.
  3. Because the local users were included and (naturally) did not exist on the destination computer, loadstate required the /LAC switch to recreate them.

One more insidious point: by running a scanstate on a computer - even if you have various profile filters listed and even if you cancel the scanstate from completing the examination phase - all of the profiles are loaded and unloaded. Meaning that if you run scanstate even once, /UEL will no longer work because all of your NTUSER.DAT files are modified to "right now".

When testing UEL be sure to keep one of those handy "file date modification" utilities close. I use an internal one here called FILEDATE.EXE, but there are a zillion similar freebies on the internet (often with the same name). All you need to do is change the date on a given NTUSER.DAT to make it "stale" to USMT.

image

Making it work

You know how I like to ramble on about how things work and why they do what they do. Many readers just want the fix so they can get back to FaceBook YouTube work. No one says you have to use the same command-line on your scanstate and loadstate. In this case, that's the solution:

Step 1

Scanstate the source computer using only /UEL. This meets the need for only getting current profiles. This may catch some local user profiles but a local user is unlikely to have much data to migrate. It's also unlikely that a local user is in regular use in a domain environment, meaning /UEL probably catches it as well. For example:

Scanstate c:\store /uel:90 /i:migdocs.xml /i:migapp.xml

image

Even in my example where a local user was gathered above, it added only 25MB to each store when using a Windows 7 source computer (due to the default Windows Mail files created for all users). If I had used a hardlink migration, it wouldn't even have been that. In reality, my local profiles were quite stale as I had not used them since creating the computer - I had to log on to them to make them "fresh" for my example. J

Step 2

Loadstate the destination computer using /UI and /UE. This prevents the restore of any local profiles captured earlier. Since I only catch "fresh" profiles in the scanstate, there's no need to provide /UEL here. For example:

Loadstate c:\store /ue:* /ui:cohowinery\* /i:migdocs.xml /i:migapp.xml

image

With that I finally meet the goal of only migrating domain users that have logged on within the past 90 days.

Note: If the source and destination computer names are identical (perhaps a wipe and load scenario), you could alternatively use:

                Loadstate c:\store /ue:%computername%\* /i:migdocs.xml /i:migapp.xml

Musings

To wrap up the USMT rules: nothing means everything, something means everything except when it means nothing, and sometimes often means never. Simple!

Other notes:

  • More detail and examples on all of this here:

https://technet.microsoft.com/en-us/library/dd560781(v=WS.10).aspx https://technet.microsoft.com/en-us/library/dd560804(v=WS.10).aspx

  • I used /C a few times for ease of repro. Microsoft still recommends using a config.xml file with error handling rules rather than arbitrarily bypassing non-fatal errors with /c.
  • There is a paradox Easter egg in my examples. Whoever points it out in the Comments first gets the "AskDS Silverback Alpha Geek Crown", currently worn by Darkseid64.

Until next time.

Ned "U-Haul" Pyle

Comments

  • Anonymous
    May 08, 2011
    I  Think you easter egg is in following code Loadstate c:store /ue:* /ui:cohowinery* /i:migdocs.xml /i:migapp.xml Running loadstate with excluding all users

  • Anonymous
    May 09, 2011
    Gosh no - I'd never intentionally provide a bad example. :) That example is totally correct. It's something much more subtle. Think "time".

  • Anonymous
    May 09, 2011
    May this one be your easter egg? "wipe and load" means "formatted hard disk", so c:store is quite inconvenient for data storage...

  • Anonymous
    May 09, 2011
    Nope, although that's a great guess. Wipe and load in our USMT scenario means "delete everything except the hardlink store folder". That way you have all the benefits of a fresh, empty drive as well as a super fast restore of user data.  

  • Anonymous
    May 10, 2011
    I couldn't see 7-x64-rtm-01admin account in the list of collected with scanstate, but it seems that it should be...

  • Anonymous
    May 10, 2011
    I don't understand the question Artem.

  • Anonymous
    May 10, 2011
    There is no info about user 7-x64-rtm-01admin in the screenshot for output of command Scanstate c:store /uel:90 /i:migdocs.xml /i:migapp.xml (Step 1). But according to the first screenshot in this topic local admin has logged in several days ago and his profile should be collected with scanstate tool. Have you also reset date for admin profile as you've done for bshirley and sdavis?

  • Anonymous
    May 10, 2011
    (fixed typo) Yes, he is migrating due to being newer. The repro is not set all the way back to patient zero at that point, it's just supposed to show you how the techniques work. I'm suprised no one has caught the easter egg yet, it's about time someone did. :-D

  • Anonymous
    May 23, 2011
    No more guesses on the Easter Egg? I'll give you a hint - it has nothing to do with USMT at all, and everything to do with profile ages.

  • Anonymous
    May 24, 2011
    The comment has been removed

  • Anonymous
    May 24, 2011
    Yes - but why?! :)

  • Anonymous
    May 24, 2011
    The comment has been removed

  • Anonymous
    May 24, 2011
    I don't know what that means. :)

  • Anonymous
    May 25, 2011
    The comment has been removed

  • Anonymous
    May 25, 2011
    I'll end the suspense here: I have a Windows 7 profile last modified in January 2009. The OS didn't RTM for another 7 months. :)

  • Anonymous
    May 25, 2011
    Ahhhh, I was even looking at that angle as I was searching Bing (insert sound) for things that happened on that date. Nice one!