Further Reading

Typical Network Transfer and Transfer Speed

For a typical EFI boot, without the optional boot fonts, a total of 314KB of data is transferred per booting device. A 99,9% reduction from the standard TFTP protocol. All data sizes in Kilobytes. Note that the file version sizes are averages as some builds might include debug information and/or troubleshooting tools like nslookup and ping etc.

File Name

Size

Hash size

Purpose

snponly.efi

150

N/A

EFI iPXE bootloader, using UNDI, can’t be use BranchCache as its the start of the process

undionly.kpxe

75

N/A

BIOS iPXE bootloader, using UNDI, can’t be use BranchCache as its the start of the process

WimBoot

35KB

1KB

WinPE boot loader

Boot.bcd

12KB

N/A

Typically about +8KB per added

Boot Scripts

1-2KB

N/A

Auto generated

Variable.dat

22KB

N/A

Transferred using TFTP from Configuration Manager binaries in WinPE

Windows PE

300-500MB

150-300KB

Size depends on drivers, optional components etc.

The total transfer of data is then typically the iPXE boot loader, then wimboot (hashed or not) and the boot.bcd file + some iPXE scripts to hold it all together. Then we transfer the hash of the WinPE image which then does the TFTP download using TFTP.

Transfer

Kilo Bytes

Comment

Total BIOS WAN transfer with BranchCache

~275KB

Total EFI WAN transfer with BranchCache

~350KB

Reduction in percentage of WAN traffic

-99.9%

Yeah, it’s that awesome!

The following speeds have been noted in our labs downloading over a poor link, with BranchCache support 5 clients serving the WinPE image and on Gigabit network without BranchCache. The test speeds are with EFI capable devices and for downloading a 300MB WinPE image only.

Bandwidth Up/Down/%Packet Loss

Speed (mm:ss)

Reduction from TFTP

56/33.6 Kb 2% (Modem)

02:00

Are you kidding me?

128/512 Kb 2% (ISDN/DSL Type)

00:30

Keep dreamin baby!

1.544Mb/s (Typical T1)

00:10

Still aint happening!

10Mb/s 1% Loss

00:07

On a sunny day? Right!

100Mb/s 0,5% Loss

00:07

About 10 mins

1Gb/s 0% Loss with BranchCache

00:06

Down 1-5 mins

1Gb/s 0% Loss without BranchCache

00:02

Down 1-5 mins

Typical Boot Process

A typical boot process using iPXE as the boot loader looks like the following:

  1. Client starts,

  2. Initiate the on board PXE ROM

  3. PXE ROM requests an DHCP with HW capabilities in DHCP request

    1. Typically Option 60 and Option 97 are used for architecture management

  4. DHCP Servers (Proxy DHCP or/and DHCP) responds with right filename depending on HW capabilities in the requesting DHCP package

  5. PXE ROM merges DHCP with possible proxy DHCP response(s) according to the PXE standard, and developers interpretation of that standard.

  6. PXE ROM initiates the TFTP transfer of the boot file specified in merged DHCP offer (iPXE)

Note: DHCP is not actually booting from DHCP Option #66 in DHCP, in the case of a Microsoft DHCP server it translates the IP address in DHCP Option #66 to an IP address in the SIADDR field of DHCP. If you are using a non-Microsoft DHCP server you need to ensure it sends the SIADDR field of the 2PXE server.

  1. TFTP of the boot loader finish

  2. PXE ROM loads iPXE

  3. iPXE initializes and does a whole lot of magic before launching the embedded script.

  4. Embedded script checks that all seems to be in order and then processes the logic.

    1. iPXE contacts the 2PXE server, this is done by using DHCP option #175 which is the full URL to the 2pxe server like: https://rig10c20.2pstest1.local:8050/

  5. iPXE sends up heaps of info about the client to the 2PXE server over https

  6. 2PXE process the data and depending on the configuration settings it executes a PowerShell script or talks to the Configuration Manager Database for boot actions.

  7. An iPXE boot script is sent down to the client for execution

  8. iPXE executes the script and transfers the corresponding files listed in the boot script, typically booting a WinPE image.

  9. Client downloads required files using HTTP with BranchCache support from the source:

    1. Certificates, in order for WinPE to trust the 2PXE server

    2. iPXEWinPEClient.exe, which sets up the right certificates and environment

    3. Wimboot as the kernel to load the WinPE image

      1. Boot.sdi as the NTFS virtual drive is included in the boot.wim image

      2. Optional boot fonts are used from the boot.wim image

    4. bcd file is created dynamically by the 2PXE service

    5. WinPE boot.wim file, typically from the Distribution Point

    6. A new WinPEShl.ini which replaces the original one, executes the iPXEWinPEClient.exe as the first step

  10. The WimBoot kernel boots the downloaded WinPE image using the bcd data

  11. WinPE Client boots WinPE and executes the iPXEWinPEClient.exe which starts networking and talks to the iPXE Anywhere Web Service to report status, and then hand back to start any custom process or the Configuration Manager task sequence engine.