Actually I prefer to create 'WTG + VHD' combination by using WinNTSetup.
OK. Then to cut a long story short, I don't think I will provide this in Rufus, because this is too targeted at power users/sys admins, and Rufus is primarily aimed at the general public. In most cases, Rufus tries to follow the standard implementation, so that users of the feature can feel right at home, and the standard implementation of Windows To Go (AFAIK) is not to use a VHD.
So I think I'll leave the realm of VHD Windows To Go support to WinNTSetup and other tools, which, if they're not doing a good enough job already, will probably be able to do so in the future. Specialized installs are better left to specialized tools.
I also have no plans for Rufus to help with multipartition setups. There again, this is power user/sysadmin stuff, so I reckon that people who want such a setup should either be knowledgeable enough to be able to create this by themselves, or just stick with regular setups if they think they need an automated tool to do that for them. And I do understand that a lot of people, especially on a forum like reboot.pro, may disagree with this stance, but I have to state that, in my experience, advanced features such as this one are (most of the time) troublesome to implement because:
- The people who want them are never quite satisfied with what the automation does (there's always one more tweak to add to satisfy person X, which will be different from another tweak that person Y want to help with their slightly different process).
- It quickly becomes super time consuming to ensure that all these special paths in the code work... and keep working!
- It also is super time consuming to try to educate people, who think they may have some use for the advanced features, but don't know enough about it to understand its use and therefore ask the develop of the app about it (and it doesn't matter how many hours you try to sink in documenting the feature, it's never clear enough).
So, as far as I'm concerned, Multi-Partition based WTG by adding 'WinNTSetup' and 'BOOTICE', with not make things better. It will add complexity, multiply points of failure, and be used by too few people to make it worthwhile.
I think that, if you want a custom setup such as what you describe above, you shouldn't ask for an automated tool to do that for you, as this will require a lot of involvement for a developer, and developers always have to cut features due to lack of time, even more so if they provide an application entirely for free.
Please also add x86_32 (ntfs_x32.efi driver) and even ARM along with x86_64 in Rufus ESP Partition.
I'll probably add x86_32 support in due time, but this will increase the size of Rufus (which I try to avoid), and I also need to investigate a few things with x86_32 drivers first. For instance, right now, all the efifs drivers seem to work for x86_32, except exFAT (whereas it works fine for x86_64), and I'd like to understand if maybe there isn't something to fix, that may also have an impact on NTFS x86_32. Again, my development time is fairly limited, so I can't add things as fast as everyone would like...
Will It also boot 'WTG' in Pure Secure UEFI mode similar to your Rufus method?
If you select GPT for UEFI in the Rufus options, you can boot in Restricted Boot (a.k.a. Secure Boot), as Rufus will not install its custom bootloader then, but create a Windows To Go drive in the exact fashion Microsoft recommends (with 100MB MSR, ESP and all). But then you lose the dual BIOS/UEFI ability. But then again, if you are that concerned about Restricted Boot, you want to use it in an environment where BIOS boot is not available (else you completely compromised your "security").
I have been considering getting the Rufus custom bootloader (UEFI:TOGO) signed by Microsoft, but this is tricky because:
- It's expensive and there are requirements, such as keeping your signing key on a certified secure machine, that are difficult to match for independent Open Source developers.
- Microsoft's Restricted Boot terms and conditions explicitly prohibit the signing of components that contain GPLv3 code, and the NTFS driver is GPLv3 (now I guess you're starting to understand why I am using Restricted Boot...). So I'd first have to rewrite the part that accesses the NTFS data not to use the NTFS driver...
Is it necessary to keep ESP Partition at the very end of USB Drive ?
If you want any hope of dual booting a removable W2G and access its content from Windows, it is.
But if you create a drive manually, you can put it anywhere (which is pretty much what the UEFI specs say). Rufus just puts it at the very end because it suits multiple purposes there.
Suppose I have a Fixed USB Drive and then I will create three partition as follows (...)
As far as I could see from the UEFI specs, a compliant UEFI system will look for the ESP anywhere, and boot from it, wherever it resides. Since the ESP has a specific ID (MBR)/GUID (GPT), whatever FAT partition you have, that doesn't have the specific ID should be ignored by compliant systems if an ESP is found. My understanding is that, it's only if an ESP is not found that an UEFI system can try to take a look at FAT partitions, in the order they exist on the disk, to see if they contain a bootable EFI file, and enable booting from them. But the ESP is meant to always have precedence.
Now, UEFI:TOGO is designed specifically for the partitioning scheme created by Rufus, so it is tied to look for an NTFS partition as the first partition (and will fail if it doesn't find one there). There again, I wish I had all the time in the world to add additional features, such as looking for the NTFS partition wherever, but, believe it or not, I have to keep a regular (non Open Source related) 9 to 5 job, so that I can keep providing all these apps and drivers for free, which in turn means that the amount of time I can spend on adding non essential features is severely restricted.
Then again, it's Open Source, so if anyone wants to send improvements for UEFI:TOGO, I'll happily apply them... 
I have used 'Windows10_TechnicalPreview_x32_EN-US_9926'
So far, I have NOT been able to create a working Windows To Go drive using any of the Windows 10 preview images, regardless of the standard method used (including the Windows To Go creation utility from the latest Win10 Enterprise Preview).
That's actually something I wanted to post about on this forum: Has anyone ever managed to get a working regular Windows 10 To Go drive using the MS Preview ISOs?
Right now, until Windows 10 is officially released, and I get some info on how the heck one is supposed to create a standard (i.e. non VHD) working Windows 10 To Go drive, Windows 10 To Go is UNSUPPORTED in Rufus.
This being said, I only have one physical UEFI system I can test with, and it's x86_64, so I haven't tried x86_32. I'll see if I can take a look to figure out that error, as it doesn't happen for x86_64.
Your Rufus also does not show 'Windows to GO' option if ISO Image contains 'install.esd'.
Do official Microsoft ISOs contain 'install.esd'?
If not, I'll probably have to push that request at the bottom of the "nonstandard stuff, that power users/sysadmins requested" list of things I'm not planning to implement in Rufus, unless I magically get a lot of time on my hands...
Still, if you can point me to an official Windows image that contains an .esd, I'm definitely interested...
Suppose if install.wim/install.esd contains multiple Windows Installation Indexes then which Index Rufus will use for creating WTG ?
I've never seen any official Microsoft Windows ISO (or Windows To Go creation guide) use anything but index 1 for the install.wim, so that's what Rufus is hardcoded to use.
As usual, the day someone points me to an image that doesn't match this expectation, I'll look into modifying the code. I should point out that I am not planning to go out of my way to support AOI as these are custom non official images, and I expect people who create those to have the sysadmin skills and tools required to use them as they see fit.
Win8.1 will not MBR-boot from an NTFS Removable drive (unless it is in a VHD file) - you just get an everlasting spinning circle of dots!
Yup, that's my frustrating experience... 
Since this is a forum dedicated to figuring out this kind of things, wouldn't it be nice if someone could take a look at the Windows boot process and try to come up with a patch to make 8.1 W2G also boot on removable?...
Win7 and Win8 will boot from a Removable drive however.
I didn't know that. Thanks for the info!
I mostly focussed on 8.1, and expected 8.0 and 7 to be equally restricted, so I only tested those with a fixed drive.
Even more reason for someone to try to figure out how to patch that 8.1 restriction, that didn't exist for earlier versions (and yeah, I know it would break Restricted Boot, but I think there are a lot of people out there who'd like Windows 8.1 To Go to work from removable).
.
, BUT you managed *somehow* to grub4dosize 
the GRUB2, which is an exceptionally good piece of news 
that while possibly - due to size constraints - somehow limits it capabilities, allows for a much "cleaner" minimal install.
