A couple of weeks ago I got my new Microsoft Surface Pro, I decided to go with the 1TB version to have enough space.
After the first minutes of setup I quickly wanted to run disk optimization, which for SSDs usually does quick trim operations. In my case this was running way longer then on my Surface Book, so I checked what was going on, and I realized that it was running Optimization on a Storage Spaces Virtual Disk, which is kind of strange.
I checked the disk configuration and really, my Surface Pro (2017) does have a Storage Spaces Virtual Disk which it boots from. The Storage Spaces Pool does include two physical 512GB NVMe drives with one Virtual Disk on top configured as simple (striped) volume. Right now I don’t know how they did it, but it seems now possible to boot Windows from a Storage Spaces Virtual Disk with the Windows 10 Creators Update or some Surface team magic. Then when Storage Spaces was introduced with Windows 8, boot from Storage Spaces was not possible.
Tags: Boot, Boot from, Hardware, Microsoft, PowerShell, Storage Spaces, Storage Spaces Virtual Disk, Surface, Surface Pro, Virtual Disk, Windows, Windows 10 Last modified: August 27, 2018
Hi Thomas,
I was interested in what you posted here. It makes sense to do this as 2 512 GB disks are likely cheaper than a single 1 TB drive. I have been able to manually use the storage PowerShell modules in the SCCM WinPE image to configure a storage pool and virtual disk. I then used diskpart to convert it to GPT, for EFI, then I was able to manually install Windows 10 1607 onto it. It would not be a far stretch to build this into the task sequence and deploy this where needed.
dean you are so full of it bro-lie much? also 2 drives always cost more than 1 drive
Hi Ken, in some cases this is true.
Hello,
I tried to replicate this on a personal workstation using two drives in Simple mode. I could install Windows on it, but UEFI could not find the EFI to boot. How did you get it to work?
Thanks,
Bryan
I’ve had a look at this myself, trying a few different attempts and recreating the disk structure above, on different systems.
I even looked in the Microsoft Surface tools to see how they did it, and tried their Powershell scripts on my other device.
However I do think there is some Surface “Special Sauce” going on, because as others have put, EFI just can’t see into the virtual disks to boot them. At this point, I’m thinking the UEFI loader on the Surface has some kind of Storage Spaces driver that makes it available at a lower level than is available at normal BCDBoot time.
So I think maybe we need to find this shim to make Storage Spaces earlier.
Hi Nick,
I arrived to the same conclusion, I feel it must be a UEFI driver. I found that I could create a Mirrored Tiered Storage Space that Windows 10 setup would recognize and install to. Even Windows 10 recovery would work, and the Start Up Diagnostics, notably, found no problems with the configuration. However, UEFI would not see it. I know there are other factors to if that was actually feasible, it was just an experiment.
In the end, I could install Windows 10 to even other more simple types of Storage Spaces volumes, but none of them would boot. I decided like you that the Surface Firmware must have a UEFI driver that allows the bootloader to see the SS volume.
Bryan
UEFI doesn’t need to see into storage spaces directly. It just needs to see the “EFI system” partition and start BOOTMGR – from there, Windows does the rest.
Nick, Bryan, the way to verify your theory (against B/S’s theory) is to put the two NVMe drives on a normal PC and see if it boots. If it boots then the UEFI partitions contains something magic and I wonder if Thomas can share the content of that partition with us?
Hello folks,
I’ve been looking at the same thing. I got my 1TB Surface Pro with the intention of dual booting it, but quickly found that Windows is not as flexible as Linux with striping solutions. In order to install Linux at all, I had to wipe out the existing partitioning. At this point, I can only get Windows reimaged (and bootable) to a single SSD.
From what I’ve read regarding UEFI, the vendor is able to implement any filesystem code they would like into their UEFI firmware. I’m guessing either Microsoft included basic Storage Spaces support in the Surface Pro firmware or the EFI partition is not within the Storage Spaces pool.
As I no longer have a striped Windows installation, can someone provide me with additional detail regarding the current partitioning? Specifically, the partitioning of the individual NVMe drives (probably need to use a non-Windows OS) and details about the volumes in the pool? I’d also appreciate it if someone could create a recovery drive from their striped Windows installation and provide the contents of any files under \sources\ that don’t end in .wim.
Thank you.
For those wondering, I can at least confirm for you that there is a custom driver loaded into UEFI for storage spaces, experimentally a year ago I tried to extract the driver (I don’t recall what tool but downloaded the latest firmware from Microsoft’s website and pulled it out of that, it’s very clearly labeled to do with storage spaces) and load it into a UEFI ROM that I was using with VM’s in the hopes I could leverage bootable storage spaces within a VM environment, unfortunately I was unsuccessful. However this could have been an error with my UEFI ROM and the way I injected the driver, less an issue with the driver itself. But loading into the EFI shell for said ROM did let me view and confirm said driver was listed as embedded, but it was throwing a few different pieces of information than I expected.
OK I made some considerable headway-there is a technician package to repair the broken RAID0-I located that suite of tools and original sourced firmware-basically a tool that wipes the hard drive for resale actually has a hidden automatic feature to build the array back up and get this that info isnt even in the guidebook for the tools-its mentioned briefly with a basic 3 line how to saying “put in disk and it auto fixes drive” no further mention of it-there is a uefi driver thats needed also and it hows the software “locks” onto both drives by their guid designation which see right thru stripe data=I imagine is like forming the raid in reverse-easy peasy for auto software-I have no time to test it as Im close to a solution for all puters-linux has been doing bootable software raid0 since wait for it-2014-there is a project that using several tools allows you to convert the windows file system to a more robust stable and fast file system that linux can share with win-there is a boot loader that drops win10 right onto a pre-configured bootable linux raid0 array-it can bypass linux altogether and combines with yet another project can tunnel into the linux for windows sub system feature which if my theory holds true is cable of playing windows pc steam games on a linux backbone free of pesky win updates and mid game crashes-Its what steam wanted all along: to break microsofts monopoly-I did find proof that bootable raid5 was available for win10 1703 version! why am I not suprised this should have been available all along but near doubling your speed would mean putting off buy a new puter and intel/microsoft cant have that-Oh and RTS used to have pcie lane bootable nvme but only with intel brand nvme ssd-the $1,000 ones of course
There indeed is an EFI driver called MsHyperSpaceDriver – description is “Storage Spaces EFI Driver”
Source (Peter Wishart): https://superuser.com/a/1402468/1115400
People however reported that attempts to inject such driver to virtual or physical UEFIs to use Storage Spaces as a boot device elsewhere failed.