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.