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

  • Article

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.