Windows 10: USMT 10 - issues with profile when migrating from Win7 to Win10

Hello,

Has anyone used USMT 10 to migrate from Win7 to Win10?


I have used USMT successfully in the past to move WinXP (32-bit) to Win7 Pro (64-bit). I downloaded the new ADK to get the v10 tools. I now have USMT 10 and was practicing the migration of Win7 Pro 64-bit users to Win10 Enterprise 64-bit. Just for completeness, I also tried Win7 Enterprise 64-bit -> USMT -> Win10 Enterprise 64-bit. The results were the same.

I have used the original MIG XML files previously and they did what I needed, so I intended to do the same here. My XML files are unmodified at this point, but I tried with a few modifications aimed at not bringing over Start Menu (shared & user specific) *.LNK files.I have had this failure with both the "no LNK files" and stock XML versions. I tested and the migration logs (scanstate and loadstate) both claim no error in the migration process. Reviewing the logs I see no critical errors or warnings.

The problem is that following the migration, the profiles that were migrated cannot use Start Menu, Cortana/Search, Notification Area (Action Center), or right click any icon pinned to the Taskbar. SearchUI.exe appears to not be running when I review Task Manager -> Details. Cortana is not listed under Processes.

A new user - someone who logs on without a migrated profile - is created properly and they work normally. Existing users - the tech profile that existed prior to the migration - work fine. It is only a failure within the migrated profiles. I have tried the suggested Start Menu repair actions (the Get-AppXPackage / AppXManifest.xml process) and multiple other suggestions. Nothing seems to repair this, and since I can create a new profile successfully or use a non-migrated existing profile, I have to believe it's a flaw in what I'm doing with USMT.


My scanstate script is: scanstate.exe \\system\migration_folder /i:migapp.xml /i:migdocs.xml /o /uel:90 /l:C:\scanstate.log /v:13

My loadstate script is: loadstate.exe \\system\migration_folder /i:migapp.xml /i:c:\intel\usmtfiles\miguser.xml /l:C:\loadstatelog /v:13

:)

 

USMT windows 10 Office 2016

Has anyone successfully managed to use USMT to migrate to Windows 10 (Office 2016) from previous OS and Office client and have the mail profile reattach?

I have tested on my lab and everything is migrating as expected from Win7 Office 2010 to Win10 Office 2016 but the mail profile is not present on the Win10 machine. Using the latest version of the advanced deployment toolkit.

 

USMT

Can USMT be used to migrate user profiles from windows 7 and up to a domain(server 2012 r2)?

 

It's out of the box I was thinking in.

 

I am having the same issue with Windows 7 to Windows 10 USMT. Have been cracking away at this for a couple days. Will let you know if I find anything.

 

Hey Mike,
I found that my problem was from using the CopyProfile function in sysprep. Without CopyProfile, USMT works just fine. Thanks Microsoft...

For the USMT functionality I would recommend adding a couple things.

1. Generate a Config File to customize the settings being moved:scanstate.exe /i:MigUser.xml /i:MigApp.xml /genconfig:Config.xml
- Edit the Config.xml to your liking. I would Exclude any Startmenu / Taskbar settings.

2. Add this line to your script right before the scanstate line. It will skip missing profiles which can save a lot of time.
SET MIG_IGNORE_PROFILE_MISSING=1

3. Add a second layer of logging so that you have a more granular output. Here is what I use:
scanstate.exe %USMTDEST% /localonly /i:Miguser.xml /i:MigApp.xml /config:config.xml /progress:scanstate_progress.log /l:scanstate.log /efs:copyraw /o /c /v:13 /UEL:30


4. Lastly for redundancy, I like to check the mig file to make sure it is not corrupt.
usmtutils.exe /verify:Summary "USMT.mig" /l:"Integrity_Check.log"

 

Hi Keyboard Jockey,
I think I reached the same conclusion when my coworkers and I started brainstorming about Sysprep as the issue not USMT. Unfortunately, you're confirming what I just saw in test earlier this morning.

I was thinking that in Win7 to Win10 moves, it would be best to start clean and I would have the user logon, let the profile build fresh, then copy data from Win7 (old machine) to Win10 (new machine). That would preserve the default profile settings we pre-supply as part of our imaging.

The other option was to drop the CopyProfile portion of the process like you did and then use USMT. Since you are doing that, I am curious how you handle customizations, especially Start Menu customizations.

We had a nice Start Menu config with our key applications pinned in logical groups. Losing that is not a deal breaker, but having the core applications pinned was well received by our test/pilot users. From a callback standpoint, I'd hate to lose the ability to customize our default profile.

I don't see how this got past MS quality assurance testing; enterprise customers shouldn't have to sacrifice using custom default profiles or the USMT tool.

Thanks,
Mike

 

Luckily Microsoft has given us Import / Export functionality for customizing the default profile post image. Here is what I am using:
Note that I just found the CopyProfile piece and have not completely tested. Will get back to you after final testing.

Export Start menu and Default App associations from a pre-configured computer:
Export-StartLayout -Path C:\tmp\start.xml

Dism /Online /Export-DefaultAppAssociations:%~dp0Defaultapps.xml

Then Import them back:
Import-StartLayout -LayoutPath C:\Temp\start.xml -MountPath $env:SystemDrive\
Dism.exe /online /Import-DefaultAppAssociations:%~dp0Defaultapps.xml

I bundle the import functions with the ManageTaskbar customizer:
TechNet Manage the taskbar / remove the Edge icon for new users

 

I figured it out finally!*Smile

You have to download and install the updates manually. I installed the updates from March 1st and 8th and now copyprofile does not break USMT.

Here is the link:

http://windows.microsoft.com/en-us/w...ory-windows-10

 

Thank you Keyboard Jockey. I see USMT in the list of fixes for the March 1st 10586.122 build. We are currently using build 10586.218 (April 12) so I was wondering if you had already injected the March 1st & March 8th updates into your master image before this test.