I believe you're missing an important statement from your link (emphasis mine): "No longer being actively developed" does not equate "no longer supported" (in a "ceased working" kind of sense) or "has been removed". As I mentioned, I tested Windows To Go with the preview 19H1 ISOs and now with the release, and found no issue whatsoever. So Windows To Go is still Go with 19H1 and it does looks to me like rumours of Windows To Go's death are being greatly exaggerated...
I personally doubt they will effectively remove Windows To Go support any time soon, and especially as soon as 20H1. The way I take it is that Microsoft realized that they were still carrying the old "Create a Windows To Go drive" feature that exists in the Control Panel of some versions of Windows (mostly Enterprise) and that dates back to Windows 8. That tool was pretty much already obsolete the day Windows 10 was released, precisely for the reasons listed by Microsoft (it was tailored for an exceedingly limited set of flash drives, because, at the time Windows 8 was released, very few flash drives could sustain the speed required to run Windows in To Go mode). So, since it makes no sense trying to maintain that tool any longer, they are laying the ground to have that tool removed. However, I doubt Microsoft are going to forcefully remove the core Windows To Go functionality (i.e. the one that is independent of the facility that was used to create the Windows To Go drive, which pretty much equates the ability to apply and run a WIM/ESD image on a removable drive), especially as we have explicitly have seen them fix a major bug there, which, if they probably could have ignored, and my understanding is that Microsoft must maintain some of the "boot & run from removable media functionality" for ARM64 devices anyway... So, while I wish I could state that I have more than enough spare time to try to take pre-emptive action for the many ways in which Microsoft (and others) may increase the usual level of entropy a developer has to deal, the truth is I really don't. So you won't see me take any action about Windows To Go until such time as Microsoft has veritably broken the core functionality, and in a manner that can't be worked around, which again, as long as all we get to see are some statements that probably have more to do with the re-assigning of internal Microsoft developer teams than anything else, I don't believe is going to happen any time soon.
Sir, One of my friends is trying to make a ''Portable WIN 10 1803 OS / Windows To Go''. He is getting the error : NTLDR missing. (a) Is Win 10 1803 is supported by Rufus for Windows To Go ? (b) Any probable reason why he is getting that error ? (c) Which Win 10 latest version is supported for Windows To Go ( rufus ) ? Thanks & Regards. ...
Yes, that's most likely your issue. The NTLDR message indicates that he is booting in BIOS/CSM mode and you asked him to create his drive in UEFI (non CSM) mode. Either he needs to disable CSM in his firmware (if he is really using UEFI), or he needs to recreate the drive for BIOS/CSM boot.
Sir, Greets, He is saying that he is not getting the 'Windows To Go' option while he is trying to make it from within Win 7 OS. A Senior also confirms that the Windows To Go option goes silent when he does it from Win 7. Please have a look here : https://forums.mydigitallife.net/th...ryzen-threadripper.76335/page-30#post-1540954 ( Arctucas & senior Enthousiast )
Because these files change all the time, and some ISOs do require a custom version. Also, and this is the most important part, the day someone tells me that, say, the latest Ubuntu needs to use a custom version of ldlinux.sys or GRUB because the vanilla 6.04 or 2.04 version won't work, I can just upload that version to the server, and everybody, including people who use an old version of Rufus, can create working bootable media for that version, without having to do anything. With the "just embed all the file in a big archive that's provided with Rufus", then I suddenly need to produce a new release every time a distro needs a custom bootloader, or a new version of GRUB or Syslinux is released, which is A LOT more problematic than people realize (because you also want to have somewhat stable code when you do release). And that's not even talking about the confusion this will add for users ("Ah, but you've been trying to create a bootable drive of distro X version y.z using 'Rufus offline' version a.b archive? That's not gonna work unless you download 'Rufus offline' version c.d or later!", with the ironical end result that people will have to download stuff anyway, and what's more, 99% of it will be files they have no need for). It is much better not to force people to download tons of files they don't need, through an archive that's going to become obsolete the minute GRUB/Grub4Dos/Syslinux release a new version, or some distro applies a custom patch that doesn't work with the vanilla version, and instead use an online mechanism that only downloads the files needed and that gets transparently updated behind the scenes so that it's always up to date, regardless of he version of Rufus you use. And that is why I am not planning to ever bother with what you suggest because it won't be as helpful for users as you believe it is.
I'd been thinking, about the Alt-E option to enable or disable dual BIOS+UEFI mode. why not make this option a "per session" or temporary option for Rufus, Akeo? in current non-beta versions of the Rufus tool that I was using, pressing Alt-E to enable dual BIOS+UEFI mode, then closing Rufus made the change permanent (saved the change to the rufus.ini file as EnableWindowsDualUefiBiosMode = 1); I had to edit the ini file and change that value back to 0 to disable dual bios-uefi mode so that when I run the Rufus tool again, I won't be needing to create future usb install media w/out the dual mode option.