Migration from hard drive about supergrate

[krisdb2009]

I understand your issue.
The sequence of events that would have worked is to have captured a user profile first on an external drive by copying SuperGrate.exe to an external drive and running a backup, then re-installing windows, then, once back in windows, running a restore.

There is offline capability in USMT (https://learn.microsoft.com/en-us/windows/deployment/usmt/offline-migration-reference) but SuperGrate pulls user info from WMI and there isn't a way to enumerate user info from an offline copy of windows. I suppose we could use a different method like mounting the offline registry and listing it that way for this specific scenario. Thoughts?

[Deng-Xian-Sheng]

For this offline scenario, we can disable the user selection function and only migrate all users. Most people have only one user on their computer (except for system users). ----- 原始邮件 ----- 发件人：Dylan Bickerstaff ***@***.***> 收件人：belowaverage-org/SuperGrate ***@***.***> 抄送人：靳灿奇 ***@***.***>, Author ***@***.***> 主题：Re: [belowaverage-org/SuperGrate] Migration from hard drive (Issue #109) 日期：2024年03月04日 10点48分 I understand your issue. The sequence of events that would have worked is to have captured a user profile first on an external drive but copying SuperGrate.exe to an external drive and running a backup, then re-installing windows, then, once back in windows, running a restore. There is offline capability in USMT (https://learn.microsoft.com/en-us/windows/deployment/usmt/offline-migration-reference) but SuperGrate pulls user info from WMI and there isn't a way to enumerate user info from an offline copy of windows. I suppose we could use a different method like mounting the offline registry and listing it that way for this specific scenario. Thoughts? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Deng-Xian-Sheng]

I spent about $35 to purchase a migration license for a commercial software called PCmover Professional, which is written in C # and has excellent functionality. I can't wait to reverse it and see how it works with USMT. Here is the download address for the installation package: https://dl.laplink.com/ml/pro ----- 原始邮件 ----- 发件人：Dylan Bickerstaff ***@***.***> 收件人：belowaverage-org/SuperGrate ***@***.***> 抄送人：靳灿奇 ***@***.***>, Author ***@***.***> 主题：Re: [belowaverage-org/SuperGrate] Migration from hard drive (Issue #109) 日期：2024年03月04日 10点48分 I understand your issue. The sequence of events that would have worked is to have captured a user profile first on an external drive but copying SuperGrate.exe to an external drive and running a backup, then re-installing windows, then, once back in windows, running a restore. There is offline capability in USMT (https://learn.microsoft.com/en-us/windows/deployment/usmt/offline-migration-reference) but SuperGrate pulls user info from WMI and there isn't a way to enumerate user info from an offline copy of windows. I suppose we could use a different method like mounting the offline registry and listing it that way for this specific scenario. Thoughts? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Deng-Xian-Sheng]

I am considering using Python to generate XML files for USMT.

I plan to implement the migration of applications.

Then, I created a repository, wrote some code, then deleted it, and then wrote a bit more.

I plan to scan the registry on the Windows system, application installation paths, and user data for applications, but I encountered a problem: applications don't have a unique and easily identifiable identifier that a program can recognize. I can't determine which registry item, application installation path, and user data belong to which application; they don't correspond, especially when they're mixed together.

I thought about using full-name matching, but that would still result in some unmatched entries. Those entries might be randomly picked from the stuff used by a hundred applications, possibly an abbreviation or alias of an application, leading to a mismatch.

Presenting such things to the user and asking them to decide whether to keep or discard them is too difficult.

So, I came up with a bold idea.

Actually, the initial idea was to scan all applications first and then scan the files or registry used by these applications until I realized that these two operations have a high degree of overlap. So, I changed it to scanning the registry and files used by applications first, and then distinguishing which application uses them.

Then I encountered the aforementioned problem: application names are not standardized.

So, the bold idea is to mix the registry and files together and let the user choose which ones to delete. The program will no longer categorize them.

The program will just read them out, and the order in which they are output will be the same as the scanning order. It will no longer classify by application, leaving it to the user to visually identify which ones are not needed and then delete them. Everything not deleted will be retained.

Just dump the registry and files onto the target computer.

The registry includes environment variables, the Start menu, etc., and the files include application installation paths, user data, etc.

Isn't this idea both interesting and absurd?

The Windows registry is really too messy. I don't know which keys the program should read.

Once successful, after generating the XML file, you only need to use USMT to migrate the contents of the Users folder, and then use the generated XML file to migrate the applications, and that's it.

I’m here mainly to see if there has been any progress on your project.

I reverse-engineered PCmover Professional and obtained its source code, but I couldn’t crack it. There’s just too much source code, and I couldn’t find anything useful. I’m not familiar with reverse engineering or C#; it’s written in C#.

After modifying its DLL and recompiling it, it seems the hash check failed. How unfortunate.

As for another software, izinstall, it’s probably entirely written in C++. There’s an annoying .dat file as large as 500MB that I can’t decrypt. I suspect there’s something good inside.

So I had to use Python to do something. I also checked out the USMT GUI editor, and it turns out it’s also paid!

In my opinion, USMT’s XML files cannot be used to migrate applications universally, because some applications generate different registry entries just based on the installation method. XML files can’t accommodate so many scenarios.

So, the solution is to dynamically generate XML files.

PCmover Professional’s codebase is really overloaded with stuff, and the interface is very outdated. For a supposed GUI program, it’s really old-fashioned.

The pricing model is also weird. Their official website is still written in PHP, an outdated technology.

Here’s its code: https://github.com/Deng-Xian-Sheng/PCmover

Here’s my Python code: https://github.com/Deng-Xian-Sheng/USMT-Helper

[krisdb2009]

Not sure if this info helps or not, but USMT is built into Windows for in-place upgrades. Next time you do a feature update or an in-place upgrade, open task manager and you will see USMT running.
My point is, if Microsoft can use USMT to do an in-place upgrade, surely it's pretty reliable for what it is and what it does. I wouldn't try to roll your own software migration tool.