Comment on page
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.
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.
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.
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.