USMT user file migration
Hi Niall (TGIF ;-) Thanks, I'll take a look into Peter's 'auto jump'. I hadn't seen that post. It definitely failed in the user state capture. What actually happened was that the migration failed later in the task sequence due to another problem, but I was able to rescue the UserState data to a USB disk and do a bare metal build on the machine. I then manually did a loadstate on the machine. I checked back on the USB disk and the files weren't there either. Thinking about it, I guess they could have been lost in the robocopy from the C:\UserState to the USB drive, but I think that's unlikely. Cheers Simon
October 14th, 2011 8:14am

Hi All We're using USMT 4 with hard linking to upgrade from XP to Windows 7 and this seems to be working well. I'm using MigApp.xml and MigUser.xml and I'm specifying to migrate only the currently logged on user. However, we've had one instance (that I know of so far) where not all of the users' data was migrated successfully. The user had a folder on the root of the c:\ which was only partially migrated and also some files within My Documents were also missed. Unfortunately, the scanstate logs were removed before I could get to them so I can't go digging there. I'm trying to ascertain under what circumstances files might not be copied, other than just by their file extension. I've looked over the "What does USMT migrate" article but there don't seem to be any clues there. I thought that by migrating only the logged on users' data, files created by another user might be missed, but that doesn't appear to be the case. I've also performed tests using hidden files, read only files etc. but they all seem to come across too. So really I'm just after some general ideas as to why files might fail in the hope that I can mitigate against this happening in the future. Cheers Simon
Free Windows Admin Tool Kit Click here and download it now
October 14th, 2011 2:02pm

hi Simon sometimes strange things happen, you can't prepare for every eventuality but you can prepare yourself for failure, ie: make sure that if there is a failure that you DO have a copy of the scanstate.log file so that you can examine it for the reasons why it failed, to do this make your task sequence 'auto jump' (by using the _SMSTSLastActionSucceeded equals FALSE variable) to a group which copies all pertinent logs to somewhere you can reach, something like the following method, that way if theres a failure, at least you've got logs to review. do you know if it was the Capture user state or Restore User state (in this case) where it failed ? My step by step SCCM Guides I'm on Twitter > ncbrady
October 14th, 2011 2:27pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics