Windows – Troubleshooting tips for USMT

migrationtroubleshootinguser-managementwindows

We have a large Vista migration underway and are using USMT (User State Migration Tool) to grab profiles in preparation for the push, which has resulted in some problems.
The majority of the captures proceed smoothly however a significant minority fail with some quixotic errors, this is typical:

Info                  [0x080000] CopyStream: Can't copy streams from {"C:\Documents and Settings\All Users\Documents\My Pictures\060812-F-3108S-103.jpg"} to {"45"} object. Error 112. Exception class UnBCL::IOException: unable to write to FileStream.
enum Mig::SendObjectResult __thiscall Mig::CMediaManager::SendObjectInternal(class UnBCL::Stream *,const unsigned short *,const unsigned short *,int)
void __thiscall UnBCL::FileStream::Write(const unsigned char *,int,int)

Info                  [0x000000] Report problem is called
Info                  [0x000000] Unable to process object C:\Documents and Settings\All Users\Documents\My Pictures\060812-F-3108S-103.jpg -> 45, retries left = 3
Info                  [0x0802e6] Notification result: Retry.

….a bit later that becomes:

Error                 [0x0802e9] CopyStream: Can't copy streams from {"C:\Documents and Settings\All Users\Documents\My Pictures\060812-F-3108S-103.jpg"} to {"45"} object. 
Error 112. Exception class UnBCL::IOException: unable to write to FileStream.
enum Mig::SendObjectResult __thiscall Mig::CMediaManager::SendObjectInternal(class UnBCL::Stream *,const unsigned short *,const unsigned short *,int)
void __thiscall UnBCL::FileStream::Write(const unsigned char *,int,int)

Error                 [0x0802f1] Failed to store object "C:\Documents and Settings\All Users\Documents\My Pictures\060812-F-3108S-103.jpg", stream = "default". User aborted operation.
Error                 [0x08030a] MigDoMigration caught exception: class Mig::CAbortException: User aborted Send operation..
void __thiscall Mig::CMediaManager::SendCatalogEntry(class Mig::CCatalogEntry *)

…finally culminating in:

Info                  [0x000000] USMT error Code (status) = 11

Error code 11 corresponds to

USMT_UNABLE_DOMIGRATION  (A file is in use)

which does not seem to track with any activity occuring on the machine.

I've found the Microsoft documentation extremely unhelpful on diagnosing problems such as this and was wondering what tips other admins might have on troubleshooting USMT issues.

Best Answer

Check out this post from the USMT Tean Blog How to debug a USMT log like a Pro. They walk you through how to debug a log and cover off a very similar problem. The error they work on is the Error 112 which maps to "There is not enough space on the disk." which is what you are also getting.

In that particular case it turned out to be not running out of space, as alfred mentioned, but that the USB drive was formatted as FAT32 and not NTFS and couldn't handle single files larger than 4GB.

From USMT 4.0 Return Codes you can up the USMT logging as well:

As a best practice, we recommend that you set the highest verbosity level, /v:13, on the ScanState and LoadState command lines, so that the most detailed reporting is available in the ScanState and LoadState logs.

Not that I want to send you away from SeverFault but you might also want to check out myITforum.com as they have some really good coverage on USMT, SCCM, SMS, SCOM, MDT etc.

Related Solutions

Etiquette of Troubleshooting Problems In The Workspaces Of Others

There are three concerns as I see them: Changes to the physical workspace, changes to computer-specific properties, and changes to user-specific properties.

I would tend to err on the side of treading lightly re: changes to the workspace. Common sense says that making any changes to the physical workspace is a bad idea, IMO. That would include changing chair settings, moving items not directly related to the work being performed, rifling through papers on the desk, etc. That strikes me as rude.

Altering ergonomic settings for a short visit is probably a bad idea, too. Changing monitor brightness / contrast settings, for example, would be ill advised (unless the settings are so far off that you can't see to work).

Religious dogma aside, the axiom "Do unto others..." rings true here for me. I wouldn't do anything to someone else's workspace that I wouldn't want them to do to mine.

A robust remote control solution would take care of a lot of this. Sometimes you have to go out and lay hands on a computer. A user should be prepared to have the computer they use pulled out of their workspace, if necessary. It's not their computer-- it's the company's computer. It's not their workspace-- it's the company's workspace. Your example didn't have such a scenario in it, but users should be expected to understand that some failures could result in the computer in their workspace being removed and replaced and they should deal with that.

If I did have to pull a computer from a workspace I'd try very hard to inform the user before I did it. If I couldn't, I'd leave a large note w/ contact information and details on what work was done.

I'm less likely to tread lightly re: changes to computer-speciifc properties. It might disorient somebody to have their monitor turned off, but I think assuming basic computer familiarity re: turning on a monitor is well within the expectations of a computer user. Likewise, the last logon name (a personal peeve of mine, and one of the reasons why I have the "Don't show last logged-on user name" group policy setting deployed at all of my Customer sites) isn't a showstopper that a computer literate person should be unable to handle. The guiding principle re: computer-specific properties should be something like "Can a computer-literate person be expected to deal with this change w/o asking for help?"

Making changes to a user-specific properties is like making changes to their physical workspace, to me. You should tread as lightly as possible here, too. Think about what changes you'd want someone else making to your user-specific settings w/o your knowledge, and apply that judgement.

PostgreSQL – Default Superuser Username/Password After New Install

CAUTION The answer about changing the UNIX password for "postgres" through "$ sudo passwd postgres" is not preferred, and can even be DANGEROUS!

This is why: By default, the UNIX account "postgres" is locked, which means it cannot be logged in using a password. If you use "sudo passwd postgres", the account is immediately unlocked. Worse, if you set the password to something weak, like "postgres", then you are exposed to a great security danger. For example, there are a number of bots out there trying the username/password combo "postgres/postgres" to log into your UNIX system.

What you should do is follow Chris James's answer:

sudo -u postgres psql postgres

# \password postgres

Enter new password:

To explain it a little bit. There are usually two default ways to login to PostgreSQL server:

By running the "psql" command as a UNIX user (so-called IDENT/PEER authentication), e.g.: sudo -u postgres psql. Note that sudo -u does NOT unlock the UNIX user.
by TCP/IP connection using PostgreSQL's own managed username/password (so-called TCP authentication) (i.e., NOT the UNIX password).

So you never want to set the password for UNIX account "postgres". Leave it locked as it is by default.

Of course things can change if you configure it differently from the default setting. For example, one could sync the PostgreSQL password with UNIX password and only allow local logins. That would be beyond the scope of this question.

Best Answer

Related Solutions

Etiquette of Troubleshooting Problems In The Workspaces Of Others

PostgreSQL – Default Superuser Username/Password After New Install

Related Topic