Migration from hard drive
Closed this issue · 5 comments
Is your feature request related to a problem? Please describe.
At present, I can only migrate through the network, but I did not purchase a new computer. Instead, I reinstalled the Windows system and the previous C drive is still there. I want to migrate the previous application to the current system.
Describe the solution you'd like
There is a button or option to select the path to the source system root directory, such as D:\
Describe alternatives you've considered
I will use the tool export to USMT command, and I will modify and execute it myself
It seems unlikely, but if you don't modify the application and still want to use it to help, this is the only way
The main issue is that USMT is not easy to get started with and learning is difficult.
If the hard drive cannot be used as the source, then those people can only bear the learning cost of USMT.
Additional context
no
other
What help can I provide? I am a programmer!
I feel that USMT is not easy to get started with, especially those XML files. I don't know what tools can generate them.
If manual editing is necessary, it can be troublesome, and Microsoft documentation does not provide tutorials similar to "Quick Start"
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?
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
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.