This may be a good place to announce that I’ve recently created a walkthrough video demonstration on using qvm-create-windows-qube to create a Windows 10 qube here: qvm-create-windows-qube 2.0: Windows 10 Demo (w/ Qubes Windows Tools) on Qubes OS - YouTube
Please feel free to refer to it should you require!
@jevank - I sent PRs to @elliotkillick for the rpc policy and msi issues. Also sent was one to more gracefully handle a missing qubes-windows-tools.iso file.
A Fix for fullscreen HVM issue under R4.1 is now available in current-testing repo.
Did anybody experience similar error
Booting from DVD/CD…
Boot failed: Could not read from CDROM (code 0004)
Booting from Hard Disk…
, when mounting the QWT image via loopback device
dom0: qvm-start [windows-qube-name] --cdrom [dispXXXX]:loop0
, as explained in GitHub - tabit-pro/qubes-windows-tools-cross: Qubes Windows Tools build with mingw, wine and qubes-builder ?
After second or third time try, same error appeared, but suddenly the drive also had been mounted successfully.
I can suggest to you: this solution.
Extract qubes-tools.msi flie from qwt iso, send it to usb drive and attach it via device manager in windows qube settings on the “Device” tab.
Tell me if it works for you pls. With last dom0 updates in qubes 4.1 PCI devices attaching was broken on my system. After starting HVM with usb controller attached, the host system freezes and reboot. I will install qubes 4.1rc2, on other SSD to fix it at this time.
Well, is there any qubes windows tools for R4.1rc4?
Yes, unofficial crossbuild project under tabit-pro · GitHub
They are working to push their updates into qubes repos but you can build it under fedora using their instructions.
B
@Yorz Thanks for your alternative solution.
In the meantime I repeated the install routine and image mounting did happen successfully at first try.
If you should experience same error, shutdown the windows VM properly and wait for Qubes domain to disappear, then restart. Repeat until CD-ROM available!
Might be worth to investigate some time to make install process more “stable”, but I agree, Windows is the toilet in the Qubes OS bathroom 
Looking back at the original suggestions at the start of this discussion, nearly all of them have been realized now, and Qubes R4.1 now provides Windows support which is better than that of R4.0 and earlier. Lots of thanks to all developers who made that possible with their good work! In most cases, installing Windows qubes and QWT can now be done reliably and without problems, and so we have an environment where many of the usual problems in Windows use are mitigated.
I sincerely hope that this will help to get many new users of Qubes OS! 
Thank you all for all the effort and hard work!
I am curious to know if anyone here experienced the following issue related to search index on window 10 (Windows Search not working in WIndowsVM based on Windows-10 template with moved user folder · Issue #7732 · QubesOS/qubes-issues · GitHub) and can confirm that the following commands do not break anything on a windows 10 AppVM:
DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
I remember reading on this forum that Qubes Windows Tools (QWT) doesn’t work on QubesOS 4.2, due to some vulnerability with the drivers that come from Xen (? I read that on QubesOS blog a while ago, and back then couldn’t understand the specifics of it, and now, I am failing to remember it properly).
What is the status of QWT going to be with QubesOS 4.2 when 4.2 gets a proper release (which should be soon). I remember @marmarek mentioning wanting/working for it to be back again available for 4.2 release. Is this still the case and on track?
I think you’re thinking of this QSB:
I think you’re thinking of this thread:
I’m not aware of any more recent news since then.
I just created a pull request qubes-doc #1391for the documentation on QWT installation to shed some light on this situation. Hope it helps a bit.
I would suggest the following command for installation instead:
sudo qubes-dom0-update qubes-windows-tools-4.1.69
No extra steps required.
I would really appreciate a “Community Guides” contribution about installing Windows 10/11 on Qubes OS 4.2.
Edit: I installed Windows 10 Pro successfully following the existing guide: http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/doc/templates/windows/windows-qubes-4-1/
Worked on QubesOS 4.2. I will try the Qubes Windows Tools, soon.
So, am I understanding this QSB right: This security concern ONLY affects the Windows qube that uses the Qubes Windows Tools (QWT) and the Xen windows PV drivers. This doesn’t cause a dom0 compromise, nor the vulnerability to spread to other non-Windows domU qubes. Am I understanding this right?
If so, I can consider using the existing QWT and the Xen Windows PV drivers, as I won’t be doing any InfoSec-sensitive computing in the Windows qube anyways (will be used mainly for interacting with computer-normies that insist on using zoom, etc.).
That’s how I understand the QSB. Here’s what the impact section says:
Impact
-------
If the Xen Project's Windows PV Drivers were compromised at build time,
all Windows qubes that have Qubes Windows Tools (QWT) installed may also
be compromised. If the drivers were not compromised at build time, then
there is no known vulnerability.
Dom0 is not affected, even though the `qubes-windows-tools` package is
installed in dom0, since neither the dom0 package build process nor dom0
itself interprets these driver files. Rather, the purpose of this
package is merely to make the driver files available to the Windows
qubes in which QWT are installed.
It doesn’t say anything about dom0 or other qubes (that don’t have QWT) being affected. (In fact, it explicitly says that dom0 is not affected.)
In Windows (just as in Linux) only 2 protection rings are used. IOW, instead of running the device drivers in their own ring (which the x86 hardware allows), both OS simply run them in kernel mode. Although para-virtualization, which Qubes OS generally uses for isolation, prevents direct access to hardware from inside the VM, and we have IOMMU (aka VT-d) too, I wonder what exactly a compromised driver means and what actual effects it may have. (especially, considering not every Qubes OS user has Intel ME disabled and FOSS BIOS)
Thanks for the hint! I’ve updated the text and added a warning about dom0 updates destroying the older version.