Windows 10: Win10 Pro - Quest Migration and Intra-Forest Migration

I am currently supporting a Intra-Forest Migration (migration between domains of the same Forest) and experiencing a problem with Windows 10 Computers.

Scenario: Migrating shared computers from the source domain to the target domain prior to some of the functional users of that machine have had their source account migrated. All source accounts have a target account created, SIDHistory applied and security identifiers merged, and are mapped in the Quest Migration Manager database. Migrated machines are resource updated with the Quest RUM tool and no issues are identified.

Expected Behvaior: When a source user, who has used the machine in the past and has a local profile on the machine, logs into the workstation they get their previously established profile to load. When that user is migrated and begins to use target credentials, they continue to get their profile.

Results:
Windows 7 - Works perfectly
Windows 10 - Source user gets a new profile <username>.domainname. If we edit the registry to point the newly created profile to point to the profile directory of the correct profile, it works for 1 logon, after a logoff and a logon event the new, profile loads. If we log on with the Target credentials the correct profile to loads

Can anyone help me understand why the source and target credentials are not getting the same profile to load in this scenario?

:)

 

Migrating Win10 to NVMe SSD

I am going to migrate my Win10 to my NVMe SSD. Installation wise there should be no problem. However I cannot seem to be able to erase the old Windows 10 on the SATA SSD. If I boot from USB Win10 Installation media it only ask me whether I want to repair the SATA SSD Win10 or not. Any ideas on how to complete erase the SSD that currently have Win10 on it? I tried sanitize drive and PSID revert in Win10, neither would work. The SATA SSD is Crucial MX200.

 

Win10 migration to SSD

I am adding an SSD and want to migrate Win10 to it. My current HDD has too many files on it to migrate all, because the size of the SSD is smaller than the HDD. Where can I find out what files and folders are essential to operate Win10 and exclude all
other files so I can meet the size requirements of my SSD?

 

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