Udostępnij za pośrednictwem

Why you want (and need) to run USMT from an account directly associated with the local administrators group

  • Artykuł

UPDATE: a post regarding this topic originally went live on 5/29/2008. This was written to clarify some questions that come up in comments I received both online and offline.

Although there are a very limited number of scenarios in which USMT can be run without local administrator privileges, doing so ends up not being the most ideal situation.  There are a couple of reasons why:

  • USMT needs local administrator privileges to migrate many (if not all) operating system settings
  • Without local administrator privileges USMT can only migrate the currently logged in user
  • A bug in Vista SP1 prevents USMT from ever running as a local user on a Vista SP1 machine (KB article here)
  • The LoadState and ScansState documentation recommend that both tools be run from an account with local administrator privileges

Due to all the reasons above, as the product team, we strongly recommend that USMT only be executed from a user account that has local administrator privileges (and, if necessary, from an elevated command prompt).

However, there is an additional complication that must be considered in some cases.  A bug in USMT 3.x prevents it from recognizing users who have indirectly inherited administrator privileges as actually being an administrator.  Although the rest of the system will consider these users to be an administrator, USMT will not.  This will result in USMT either failing or completing the migration without gathering all the users, files, and settings as it was told to.

How can you tell if you will encounter this problem?  Is there a work around?

You can tell if you will encounter this problem by checking the computer management counsel to verify that the user account you will be running USMT from is a direct member of the local administrators group:

  • Windows Key + R
  • Type compmgmt.msc and press enter
  • Double click on "Local Users and Groups"
  • Click on "Groups"
  • Double click on "Administrators"
  • Check to see if the user that will be executing USMT appears in the "Administrator" membership list

If the user account you plan on running USMT from is directly on this list you should be good to go.  However, if it is not, you will likely encounter this bug.  As noted earlier, this bug occurs whenever the user is indirectly a member of the administrators group.  Once of the scenarios in which this is the case in when the user executing USMT is a member of a group that is listed as a member of the administrators group.  In this case, the membership tree might be something like so:

  • Administrators
    • User1
    • User2
    • GroupA
      • User3

Although users 1-3 are all administrators, user 3 won't be recognized as such by USMT due to this bug.

One work around is to temporary make the user executing USMT directly a member of the administrators group (add them to the group before executing Scanstate or Loadstate and remove them immediately afterwards).  This can be accomplished with a script in numerous ways.  For example, there are many cases where two net localgroup commands should do the trick. However, there are many other valid solutions.

If you are working with localized machines and choose to develop a script, keep in mind that the well known groups such as Users and Administrators will appear in the associated language (rendering workarounds that depend directly on the group name to fail). 

Although we don't like it when a work around is necessary to complete a migration, there are times when it is necessary that they be utilized.  Unfortunately, this is one of those times.

Comments

  • Anonymous
    January 14, 2012
    If this is the problem I am running into, I am going to tattoo this entire blog post to my forehead so no other person will become a victim of the USMT 3.x bug again!  Will test tomorrow....