10

Been trying to test Hyper-v 2016 this afternooon but I am unable to get my R630 to boot from the USB I configured using the following instructions https://technet.microsoft.com/library/ee731893(ws.10).aspx

I used the exact same guide on Hyper-v 2012 R2 with no problems.

Anyone have any luck with this?

Daniel
  • 6,780
  • 5
  • 31
  • 60
Mr. Raspberry
  • 3,878
  • 12
  • 32
  • 1
    Windows Server 2016 is not Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2. What makes you think this should/would work? I can't find any MS documentation to suggest that it's possible. – joeqwerty Nov 23 '16 at 12:41
  • 3
    because of microsoft does have delays in updating documentation thinking about all issues with system itself it's hard to keep all online docs up to date it will be there just take time....... there's no reason why it wouldn't work like that...... – Michal Nov 23 '16 at 13:32

3 Answers3

8

I found the information about deploying Windows Server 2016 TP3 onto an SD card.

https://www.danielstechblog.info/how-to-deploy-windows-server-2016-tp3-onto-an-sd-card/

This topic describes deploying Windows Server on the SD card, but it was TP3. I guess you can perform the same actions with the release version.

Also, you can take into consideration SATA DOM.

https://www.supermicro.com/products/nfo/SATADOM.cfm

It is cheap and small size option for you. You can deploy any OS on it. So it is an option too.

Stuka
  • 5,181
  • 13
  • 11
4

I encountered this problem recently, and after several days of debugging, I've discovered the issue and fixed it.

Drumroll please:

After installing Hyper-V Server 2016, use an offline tool (like, say, Windows PE) to mount the SYSTEM hive of the new installation, and change the DWORD ControlSet001\Control\BootDriverFlags from 0x04 to 0x1c. (You should probably change the ControlSet002 version as well for good measure, and you can bake the changes into your install.wim to avoid having to do this after each install.)

(Because of course it takes a week and a kernel debugger to figure out that it just requires a two-bit change in an obscure and thoroughly undocumented bitfield.)

Here's why.

The Windows boot loader uses built-in UEFI routines to find the Windows install, and loads the kernel and boot drivers into RAM prior to calling ExitBootServices. Once it has done that and passed control to the kernel, the kernel cannot access the boot volume unless the appropriate drivers are already present in RAM.

Here's the kicker, though: winload.efi is not complex enough to enumerate the hardware and determine what drivers are actually required. In older versions it would load only things set to Boot Start. However, loading extraneous drivers incurs a performance penalty, and as Windows started supporting more classes of boot devices, a better system was needed.

Enter the BootFlags value on individual drivers and the system wide BootDriverFlags value. If (BootFlags & BootDriverFlags) != 0, the driver will get loaded even if it isn't set to Boot Start. Each bit in the value is supposed to correspond to a different type of hardware, so the BootDriverFlags value sets which types of hardware can be booted from.

When this mechanism was introduced, Bit 3 was designated for USB boot devices, but booting from USB devices was unsupported in standard Windows. The Hyper-V Server 2008 R2 version added specific support for booting from USB by setting this value to 0x04, and this value has been set in every version of Hyper-V Server released since.

The general improvements made since then to support the Windows To Go feature mean that you don't have to use the boot-to-VHD trick recommended for previous versions of Hyper-V Server installed on USB devices. However, they also change the meaning of the BootDriverFlags value. USB 3 devices have been given a separate bit, and SD cards specifically have been given yet another bit.

In the 2016 version, this means that a value of 0x04 now enables booting only from USB2 disks that are not SD cards. All versions of Server 2016 except Hyper-V Server ship with the default value of 0x1c, which enables USB2, USB3, and SD card boot; however, the value of 0x04 is still set in Hyper-V Server, because it was added as an override in the image build process for the 2008R2 version. Instead of adding a feature, though, this value now removes it.

This explains why some previous solutions to this problem recommended disabling USB3 and booting from a USB stick instead of the SD card: this would force the category of the boot device to be something still covered by the now-more-limited definition of the "USB" bit in BootDriverFlags.

Reid Rankin
  • 323
  • 1
  • 2
  • 7
  • The list of flag values and their meanings can be found here: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order#using-bootflags-to-promote-a-drivers-starttype-at-boot-depending-on-boot-scenario – RJ Cuthbertson Feb 26 '18 at 08:35
  • @RJCuthbertson Very nice! – Reid Rankin Feb 26 '18 at 11:11
1

I followed the directions to the letter (with the only exception being the drive letters) for Hyper-V Server 2016 and it worked perfectly for an old Dell PowerEdge T710 Server. It is running on the internal USB port now. However the Dell unit can tell the system that the internal USB should appear as a hard disk. That may have been the difference. But I can say yes you can extrapolate the instructions for 2008 R2 and apply it to the 2016 HyperV Server just fine.

DOS_Vader
  • 11
  • 1