Can PXE boot of Hyper-V VMs be disabled?

Question

Hyper-V virtual machines have the ability to PXE boot. Obviously, PXE boot raises some security concerns. The problem is, unlike a typical physical machine's firmware, there isn't an obvious way to disable PXE boot altogether.

Hyper-V manager shows each of the VM's network adapters in Settings=>Firmware=>Boot Order:

You can move a network adapter to the bottom of the boot order, but you can't remove it altogether from that screen. So if, for some reason, Hyper-V can't boot from any of the other drives, the VM still tries to PXE boot and shows this screen:

I've scoured Settings=>Network Adapter for a way to disable PXE boot to no avail.

So my questions are:

1. How do you disable PXE boot in a Hyper-V VM?
2. If you can't disable PXE boot, is there a good reason why?

---

I'm using Windows Server 2012 R2

Answer 1

Use Powershell to Remove Network Boot Devices from the Boot Order

You can use PowerShell to strip the Network BootTypes from the VMs boot order.

Extract the Current Boot Order

Using Powershell you can use this command to extract the current boot order:

$old_boot_order = Get-VMFirmware -VMName testvm -ComputerName MyHyperVHost `
                  | Select-Object -ExpandProperty BootOrder

If you inspect $old_boot_order You should see the list of boot devices for testvm. Something like this:

Strip the Network Boot Devices

You can strip the boot devices from the boot list with the Network BootType using this command:

$new_boot_order = $old_boot_order | Where-Object { $_.BootType -ne "Network" }

Inspecting $new_boot_order should look something like this with no more Network boot devices:

Set the New Boot Order

To set the new boot order for the VM use this command:

Set-VMFirmware -VMName testvm -ComputerName MyHyperVHost -BootOrder $new_boot_order

Confirm the New Boot Order

To confirm what you did use that first Get-VMFirmware command again:

Get-VMFirmware -VMName testvm -ComputerName MyHyperVHost `
| Select-Object -ExpandProperty BootOrder

---

Beware: If you use both PowerShell and Hyper-V manager to make changes to the boot order, PowerShell may report erroneous (out-of-date) boot order. See also this technet thread.

Answer 2

In case someone lands here looking for Generation 1 VM solution, I ended up looking for it all around the place.

Found it was really simple, in MS official docs:

https://docs.microsoft.com/en-us/powershell/module/hyper-v/set-vmbios?view=win10-ps

Set-VMBios TestVM -StartupOrder @("Floppy", "LegacyNetworkAdapter", "CD", "IDE")

This example configures virtual machine TestVM to check for a boot device in the following order: floppy disk, network, CD drive, hard disk.

The Set-VMBios supports -VMName <name of VM> as well, I use that for readability, while MS docs obviously uses shorter form.

Answer 3

Those firmware entries you mention are of type Firmware Application (101fffff). They can be controlled from within the guest OS using bcdedit, the hypervisor will replicate changes:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749510(v=ws.10)

Host:

get-vmfirmware six

VMName SecureBoot SecureBootTemplate PreferredNetworkBootProtocol BootOrder
------ ---------- ------------------ ---------------------------- ---------
Six    Off        MicrosoftWindows   IPv4                         {File, Drive, Network}

Guest:

bcdedit /enum all /v

Firmwareanwendung (101fffff)
----------------------------
Bezeichner              {e56c0c0b-9e14-11eb-8bb5-00155d001627}
description             EFI Network

bcdedit /delete {e56c0c0b-9e14-11eb-8bb5-00155d001627}

The entry has been removed from the Hyper firmware page (if the settings are currently open, hit the refresh button on the firmware page)

get-vmfirmware six

VMName SecureBoot SecureBootTemplate PreferredNetworkBootProtocol BootOrder
------ ---------- ------------------ ---------------------------- ---------
Six    Off        MicrosoftWindows   IPv4                         {File, Drive} <<< no network

But what if we remove the harddisk?

Firmwareanwendung (101fffff)
----------------------------
Bezeichner              {e56c0c0c-9e14-11eb-8bb5-00155d001627}
description             EFI SCSI Device

bcdedit /delete {e56c0c0c-9e14-11eb-8bb5-00155d001627}

Congratulations, you just killed your machine. There's no option on the Hyper-v Gui page to fix this, nor will a guest reboot fix this, so thank you for providing a powershell command to fix this, I just tested, it's working. In the Hyper GUI, there's a stupid way to fix the firmware by opening the harddisk page, changing SCSI number, clicking "Apply", then changing it back, hitting "apply" again. There's MS for you.

What happens on a real computer when a firmware application is removed through bcdedit? Will the motherboard (or whereever that mysterious NVRAM resides) re-create the firmware entry after a reboot? Will it be then picked up by bcd store automatically?