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 (6)
  1. Anonymous says:

    UPDATE: a post regarding this topic originally went live on 5/29/2008.  This was written to clarify

  2. tdolan says:


    Thanks for your constructive feedback on this post.  Although this doesn’t resolve the need for a workaround, I have updated the blog post (see the link at the top) to more accurately describe the bug as well as the effort that must go into implementing a scalable work around.

    It’s great to hear that you wouldn’t dream of making all domain users and admin on a box, even temporarily.  I certainly wasn’t trying to suggest that (and I hope that my update to the post makes that clear).

  3. Anonymous says:

    That’s a terrible solution. We tried using a similar work around at our company. By the way, we wouldn’t dream of making all domain users admin on a box (even temporarily).

    One of the problems we had is that we have clients in 13 different languages. Vista internationalizes the names of the local groups.

    So on a non-English client, before you type in the "simple" solution in this article, you have to write more code to find out the actual name of the "administrators" group on the PC.

    I think a better solution would be for Microsoft to fix the bug.

  4. Anonymous says:

    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.

  5. Joe says:

    Is it possible to run USMT 3.01 under system context?

  6. Noam says:

    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?

Comments are closed.

Skip to main content