Hasleo WintoUSB one snag

Hi folks

the Hasleo WintoUSB (paid version) is brilliant for converting current installs to WintoGo versions without needing clean re-installs (although this can be done manually via std windows commands) but if you have these on vhdx files and you want to revert back to "internal hdd /ssd" versions you are out of luck as Hasleo only looks for the "physical disk".

It's still do-able but but more long winded as you have to image your vhdx windows installation via macrium etc and restore to a non vhdx disk (probably again needing dism to re-install the bootloader).

Then you can do the conversion as ususal. That works -- so update your system and then use Hasleo to convert back to a WintoGo system. (or again you can do that part manually via dism and the bootloader).

It's a pity the developer hasn't allowed for the case of where vhdx files are used for the windows installations. He's got 50% of the process correct though.

I can't actually see any standard windows commands for determining whether an install is on a removable device or not. Typical registry hacks just don't work so this guy has got something right -- I just wish he could "finish it".

I use a load of WintoGo things -- different languages, different user privileges, different apps etc. The main problem still is with Ms as you even NOW can't update to a new build via WU from a windows install (vhdx or standard) that's on a "WintoGO" device.

Cheers
jimbo

Been using this for testing purposes on several occasions. It's great

WAI said:

Been using this for testing purposes on several occasions. It's great

Click to expand...

I agree -- but I've mentioned the snag -- get roundable though -- might not be so problematical for many people as they might not be running a load of Windows installs vfrom VHDX files !!!

I have the vhdx files stored on a NAS Linux server as vhdx files WITHIN VM's so users can install on their local laptops as WintoGo systems. . globally updating these is a bit of a manual exercise currently. I'm all for A.I and automation if it relieves people of essentially boring repeatable tasks !!!.

Cheers
jimbo

Yeah... I'm more of the Legacy type

When you create a wintogo device from wintousb, you can create the OS in a vhdx file on the external drive with an efi on root of usb drive.

You should be able to create a boot entry of the vhdx file on a Windows host OS.

cereberus said:

When you create a wintogo device from wintousb, you can create the OS in a vhdx file on the external drive with an efi on root of usb drive.

You should be able to create a boot entry of the vhdx file on a Windows host OS.

Click to expand...

Hi there

the problem is converting FROM a wintogo drive where the windows is on the USB in vhdx file(s) back TO an internal drive. The wintousb sees the whole drive so it can't find the windows system on the vhdx file (usually the "C" drive) on the external system. It's OK if the standard Windows install is on the external device is not in vhdx files.

If you can make it work -- love to know what you did.

My ext drive has 4 windows systems on it as single vhdx files. I just basically want to copy ONE to an internal SSD on a laptop. Usual methods like macrium still leave the INTERNAL file after being imaged and restored as a Wintogo system which isn't what I want.

My solution was a bit long winded but I cloned one of the vhdx systems to another external device - but not as a vhdx file --imaged and restored with macrium, fixed the bootloader, booted that up and was then able to use wintousb to convert that to an internal (std system).

cheers
jimbo

jimbo45 said:

Hi there

the problem is converting FROM a wintogo drive where the windows is on the USB in vhdx file(s) back TO an internal drive. The wintousb sees the whole drive so it can't find the windows system on the vhdx file (usually the "C" drive) on the external system. It's OK if the standard Windows install is on the external device is not in vhdx files.

If you can make it work -- love to know what you did.

cheers
jimbo

Click to expand...

You copy vhdx file to internal drive, mount the vhdx file as a drive, and create a boot entry

bcdboot #:\windows

where # is the drive of the mounted vhdx file.

cereberus said:

You copy vhdx file to internal drive, mount the vhdx file as a drive, and create a boot entry

bcdboot #:\windows

where # is the drive of the mounted vhdx file.

Click to expand...

That way as I explained - at least on my machine still then thinks it's a USB extenal system -- as it gives message on boot "Keep USB plugged in -- and won't update to new build via WU -- "W11 can't install on external USB drive". I tried that first of all before using the wintousb program. I even messed around with trying it on a VM - same problem.

I'm trying to update Canary build to latest build.

Cheers
jimbo

Hi there

@cereberus

This is what I get after trying your method ---




Even though the system is now on an Internal drive.

It will work though using the convoluted other procedure of hasleo wintousb converting to another USB disk as an internal disk and then cloning that disk back to the internal one via Macrium.

People have reported in the past also just cloning a wintogo disk to an internal disk also just leaves windows recognising the internal HDD as "An external drive".


Notice also one other thing -- when Hasleo converts back to standard disk from WintoGO partition it creates a separate UEFI partition with a separate fixed letter as C with windows on D - this hoses up the update process as windows reports can't update - missing files standard "repairs" don't work.

To fix that simply boot into command mode from windows install media, delete the HASLEO labelled wintogoeusb partiion - via delete volume in diskpart change the letter of the D vol (Windows to C via disk part) , create a new 100 MB EFI fat32 partition and re-install the bootloader.

Then it's fine and will update properly on internal drive. It's very rare these days that I want to do a CLEAN install -- that's often too much work these days.

Just tested this on update keeping apps etc with a VM :



all working nicely.

Finally !!!



Once this is done then you can create vhdx stuff etc for copying back to your Wintostogo systems -- all nicely updated. Keep the working (updated) windows install as a "reference" system -- update and then copy back to wintogo systems.

cheers
jimbo

Late to the party I know, but just wanted to ask something regarding WinToUSB as this thread seems more technical than anything I found so far. So, I cloned my W11 to an external NVMe using W2G, and almost everything runs pretty good. One thing is my Windows Updates fail, while on the original disk everything's fine. .NET updates and Defender updates install fine, but Cumulative Updates always fail after they reach 99% install. Those are not major updates like from 23H1 to 23H2 (I'm on 23H2 btw), they are just those monthy ones. I googled all the error codes I was given (all pointing to "the system cannot find the file specified"), but I have a hunch it's something to do with how WinToUSB works.

Another issue is that Windows Sandbox fails to start, as it complains about "media is write-protected" - whatever that means. Again, on the original disk it works prefectly fine. While googling around I think it's something about the Bitlocker thing, but I don't even use it, and none of my drives are encrypted. I disconnected all drives and storage media except the system drive, and something is still "write-protected". Event Viewer don't show anything, and there's no .log files written anywhere so I could decypher what's going on.

Apart from all that, I'm happy with how it all works (and that it works at all), it's just these two issues for which I'm hoping someone has the knowlegde to figure out what's going on, or at least could point me in the right direction. Thanks!