Encontrei esse problema recentemente e, após vários dias de depuração, descobri o problema e corrigi-lo.
Drumroll por favor:
Após instalar o Hyper-V Server 2016, use uma ferramenta off-line (como, por exemplo, o Windows PE) para montar a seção SYSTEM da nova instalação e altere o DWORD ControlSet001 \ Control \ BootDriverFlags de 0x04 para 0x1c. (Você provavelmente deve alterar a versão do ControlSet002 também para uma boa medida, e você pode fazer as alterações em seu install.wim para evitar ter que fazer isso após cada instalação).
(Porque é claro leva uma semana e um depurador de kernel para descobrir que isso requer apenas uma mudança de dois bits em um campo de bits obscuro e completamente não documentado.)
Veja por que.
O carregador de inicialização do Windows usa rotinas UEFI internas para localizar a instalação do Windows e carrega o kernel e os drivers de inicialização na RAM antes de chamar o ExitBootServices. Depois de fazer isso e passar o controle para o kernel, o kernel não pode acessar o volume de inicialização a menos que os drivers apropriados já estejam presentes na RAM.
Aqui está o kicker, no entanto: o winload.efi não é complexo o suficiente para enumerar o hardware e determinar quais drivers são realmente necessários. Em versões mais antigas, carregaria apenas as coisas definidas para o Boot Start. No entanto, o carregamento de drivers estranhos incorre em uma penalidade de desempenho e, quando o Windows começou a oferecer suporte a mais classes de dispositivos de inicialização, foi necessário um sistema melhor.
Insira o valor BootFlags em drivers individuais e o valor BootDriverFlags do sistema. Se (BootFlags e BootDriverFlags)! = 0, o driver será carregado mesmo que não esteja configurado para Boot Start. Cada bit do valor deve corresponder a um tipo diferente de hardware, então o valor de BootDriverFlags define quais tipos de hardware podem ser inicializados.
Quando esse mecanismo foi introduzido, o Bit 3 foi designado para dispositivos de inicialização USB, mas a inicialização de dispositivos USB não era suportada no Windows padrão. A versão do Hyper-V Server 2008 R2 adicionou suporte específico para inicialização de USB definindo este valor para 0x04, e esse valor foi definido em todas as versões do Hyper-V Server lançadas desde então.
As melhorias gerais feitas desde então para oferecer suporte ao recurso Windows To Go significam que você não precisa usar o truque de inicialização para VHD recomendado para versões anteriores do Hyper-V Server instalado em dispositivos USB. No entanto, eles também alteram o significado do valor BootDriverFlags. Os dispositivos USB 3 receberam um bit separado e os cartões SD receberam especificamente outro bit.
Na versão de 2016, isso significa que um valor de 0x04 agora permite a inicialização apenas de discos USB2 que não sejam cartões SD. Todas as versões do Server 2016, exceto o Hyper-V Server, vêm com o valor padrão de 0x1c, que permite a inicialização de cartões USB2, USB3 e SD; no entanto, o valor de 0x04 ainda é definido no Hyper-V Server, porque foi adicionado como uma substituição no processo de criação de imagem para a versão 2008R2. Em vez de adicionar um recurso, no entanto, esse valor agora o remove.
Isso explica por que algumas soluções anteriores para esse problema recomendavam desativar o USB3 e inicializar a partir de um dispositivo USB em vez do cartão SD: isso forçaria a categoria do dispositivo de inicialização a ser algo ainda coberto pela definição agora mais limitada de o bit "USB" em BootDriverFlags.