次の方法で共有

Why you want (and need) to run USMT as a local administrator

  • [アーティクル]

UPDATE: an updated post is available here.  I'm leaving this post up to preserve the post history as well as comments.

Although there are a 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)

Have I convinced you yet that you always want to run USMT as an local administrator?

However, if you paid attention to the title of this post, you may be wondering how USMT treats domain administrators.  Unfortunately, a bug in USMT 3.0.1 prevents it from running properly when it is executed from a domain administrator account that isn't also a member of the machines local administrator account.

Thankfully, there is an easy work around for this.  However, before we get to the workaround lets discuss how this problem might occur.

Let's assume that your organization has an account "DomainAdmin" that is a domain administrator on your network.  Most likely this user won't be a member of any of the well known groups on all of your client machines.  However, due to the nature of the domain, this user will have administrator level access on any domain joined client machine.  As such, it probably makes a lot of sense to run USMT from this user account (whether manually or automatically).  However, this is exactly where this bug crops up.  Even though USMT should recognize a domain administrator as having administrator level access to any client machine it doesn't.  This will likely result in USMT failing.

As noted earlier, there is a workaround.  All that we need to do is get "DomainAdmin" added to each machines local administrator account, run USMT, and then remove "DomainAdmin" from the local administrator account (if desired, this removal could certainly be optional).  Thankfully, the net localgroup command can be used in scripts to accomplish just this.  For example, the following syntax adds a domain user to the administrators group:

net localgroup administrators %domain%\%user% /add

With a small variation we can remove this domain user from the administrators group:

net localgroup administrators %domain%\%user% /delete

By creating a script that calls these commands before and after Scanstate or Loadstate you can easily work around this bug.

Comments

  • Anonymous
    January 01, 2003
    UPDATE: a post regarding this topic originally went live on 5/29/2008.  This was written to clarify

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Making users a local admin for the sake of an application is always a terrible idea; especially for organizations that use enterprise management systems.  The purpose of removing admin rights from the user is to protect them from malware.  The only time someone should stay in the local admin group is if their job function requires it.  And USMT doesn't make that requirement. Is there any way to leverage SMS so that the user could compliment the migration process?  I'm thinking the user starts the migration and retrieves their own information and when necessary, use SMS to gather the system settings on the user's behalf.

  • Anonymous
    February 16, 2011
    Is it possible to run USMT 3.01 under system context?

  • Anonymous
    December 01, 2011
    I wonder if there is any workaround to run scanstate offline in windows XP SP0/SP1/SP2 (using USMT 3.0.1) using DART/WINPE?