Planning your implementation
With or without the iPXE Anywhere Web-Service?
The 2PXE server can operate on its own without the need for the iPXE Anywhere Web Service (it will still use https) but must do all the heavy lifting on it’s own.
The iPXE Web Service offers a lot of extra functionality such as logging, reporting, integration with StifleR, custom scripting and a heap of other options limited only by the imagination!
Some ideas of what can be achieved:
Integration with an MDT database
Checking and upgrading the BIOS version on a machine before OS install
Presentation of a special ‘technician’ menu with diagnostic tools etc.
Because iPXE Anywhere Web Service is driven by a PowerShell scripting interface, the sky’s the limit.
The following high level schematic shows the different setup just using 2PXE compared to integration it with iPXE Anywhere Web Service.
StifleR Integration
The 2PXE service can be integrated with StifleR using the SysLog feature. This feature requires the iPXE Anywhere Web Service and StifleR: https://2pintsoftware.com/products/stifler
For information about this integration please review the iPXE Anywhere Web Service documentation.
DHCP scope options vs IPHelpers?
This is a big debate and the full story cannot be fit into this guide. The topic of DHCP configuration for PXE booting is so complex it requires its own document. So we wrote one – Using DCHP To Control PXE Booting for BIOS and EFI Clients
Reasons to use DHCP options to control network boot:
Smaller footprint to deploy
Maybe no need to talk to the network team
Reasons not to use DHCP options to control the network boot:
No ability to use DHCP to set the right boot loader
DHCP changes can be hard to tweak and test depending on vendor of DHCP
Difficult to directly control which machines receive PXE boot offers.
More administration needed to allow different boot options to different clients
No need to talk to the DHCP team.
When using DHCP options there is no way for the iPXE NBP to automatically detect the options values from the 2PXE server. Instead the URL for the client to contact is configured through DHCP option #175: https://<server.f.q.d.n>:<port>/ - covered later in this document.
NOTE: This URL must be in lower case and end with a trailing backslash.
Figure 4 shows how a Microsoft DHCP server giving out Option #66 and #67 can be used to boot a computer with iPXE.
2PXE can be booted using any kind of DHCP server, without using the built in proxyDHCP server, but this does not work well in all configurations. In order to manage this effectively, when having both BIOS and UEFI, machines we recommend using a smart DHCP server like ISC for Linux or Microsoft DHCP 2012 or later for Microsoft environments.
If your DHCP server is not smart enough to respond with the right info you can still use 2PXE, just use IP helpers to manage the boot requests instead.
Figure 5 depicts a PXE boot using the 2PXE DHCP Proxy
Which 2PXE Operational Mode?
2PXE can operate in three different modes:
Configuration Manager Integration – allows Microsoft Configuration Manager customers to use iPXE to use the boot media directly from the Distribution Point.
PowerShell Extension – allows non Configuration Manager customers to boot to WinPE files over HTTP or TFTP, to use iPXE for the HTTP downloads and also use TFTP with regular images. (Don’t confuse this with the PowerShell capability from iPXE Anywhere Web Service)
Referral, used by System Integrators to point to an already existing 2PXE infrastructure.
Each mode is handled by what’s called a “Request Handler”. In this next section we will explain each of the three options and where they should be installed.
Enabling the 2PXE Request Handlers
The 2PXE service operates two service request handlers. They can both run in parallel, although this is not recommended. The mode is set by the installer, so typically no further action is required after the install. If need you can change the mode of operation after installation you can do so by changing the configuration values in the .config file as follows:
For Configuration Manager Request Handler:
<add key="EnablePowerShellExtension" value="0" />
<add key="EnableSCCMExtension" value="1" />
<add key="iPXEWSOnly" value="0" />
For PowerShell Request Handler
<add key="EnablePowerShellExtension" value="1" />
<add key="EnableSCCMExtension" value="0" />
<add key="iPXEWSOnly" value="0" />
Note:(Don’t confuse this with iPXE Anywhere Web Service PowerShell)
For redirect to iPXE WS only:
<add key="EnablePowerShellExtension" value="0" />
<add key="EnableSCCMExtension" value="0" />
<add key="iPXEWSOnly" value="1" />
Microsoft Configuration Manager Request Handler (EnableSCCMExtension)
This request handler contacts the Configuration Manager Site server in order to determine the boot action. In order to enable the Configuration Manager integration, the 2PXE service must be installed on a Configuration Manager Distribution Point. It is recommended that you create a new Distribution Point and install 2PXE onto that dedicated system. Only one small VM Distribution Point is required with the WinPE boot images distributed to it to cover an entire Enterprise boot needs (assuming that you have the recommended setup of iPXE with http and BranchCache enabled.)
There are two modes of operation for the Configuration Manager Handler:
Using SQL to contact the Site Server
Using HTTP to contact the Site Server via the Configuration Manager Management Point (MP)
The HTTP/MP method has the upside of being HTTP traffic but the downside of only returning one boot action per client, just like the WDS PXE Service Point, so it’s not the preferred option.
The SQL method is faster (as the MP way is behind the scenes executing more or less the same SQL), and also works fairly well over slow connections as it’s very little data being pulled over the wire. The SQL method only works with the iPXE Boot loaders.
The SQL method also automatically deals with multiple computers sharing the same Ethernet USB dongle and multiple machines with the same UUID (SMBIOS_GUID).
PowerShell Request Handler (EnablePowerShellExtension)
The PowerShell extension allows you to control the boot order, i.e. querying or feeding other data sources with information.
The integration is managed by two PowerShell scripts that are located in the installation directory. The first script is PowerShellExtensionAllowBoot.ps1 This script is called to handle the initial request to determine if the machine should boot at all. This script is executed several times during the boot process, depending on the DHCP client of the PXE capable device. The other script PowerShellExtensionBootImages.ps1 takes over when the machine has booted to iPXE. This is typically executed once, but can be executed several times where iPXE loaders are not used.
Last updated
