Changes from 2.5.0.0 to 2.7.0.0

1. All communication is now HTTPS between the iPXE boot loader and the 2PXE server, regardless of HTTP state of the DP.

2. HTTPS DP’s and NTLM DP’s are now supported, no need for anonymous access configured on the DP.

3. Change from using DHCP option 252 to 175

4. Pure PowerShell setup got revamped to work again with HTTPS communication

5. iPXE -> 2PXE TFTP communication methods are no longer supported, use HTTPS instead

6. Change to work with subordinate CA servers in Configuration Manager integration

7. The use of Windows boot loaders is discontinued

8. Minor bug fixes

Changes from 2.2.0.0 to 2.5.0.0

1. Improvement to performance

2. Filter abilities to Configuration Manager TS deployments

3. Updated boot screen

4. WIM File injection - No need to modify the boot image

5. TFTP Server

   1. Supports option to bind to single IP for multi NIC machines

   2. Allows to link to single port for TFTP transfers

6. Registry Detection – No need to restart service when Configuration Manager changes configuration

7. iPXE WinPE Client – Now included and shipped as part of 2PXE installer

8. Custom Variable injection – Task Sequence runs as part of variable creation

9. Improved Web Service integration

10. WimBoot WinPE loader:

    1. Ability to inject files into RAM held WinPE image

    2. Bug fixes

11. iPXE Network Boot Program Changes:

    1. Included Syslog Client

    2. TLS Updates to support IIS

    3. Added Certificate commands for iPXE

    4. Updated to latest build at time of compiling

    5. Bug fixes for Realtek NIC’s

12. Added and updated logging options for troubleshooting.

13. Added infrastructure support for UEFI 2.5 and above based systems

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:

1. Smaller footprint to deploy

2. Maybe no need to talk to the network team

Reasons not to use DHCP options to control the network boot:

1. No ability to use DHCP to set the right boot loader

2. DHCP changes can be hard to tweak and test depending on vendor of DHCP

3. Difficult to directly control which machines receive PXE boot offers.

4. More administration needed to allow different boot options to different clients

5. 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:

1. Configuration Manager Integration – allows Microsoft Configuration Manager customers to use iPXE to use the boot media directly from the Distribution Point.

2. 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)

3. 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.

3.0.7.0 - 2022-10-06

1. Sort an issues where the license check fails if registered company name registry key is missing on Windows.

2. Remove invalid substring case check for old iPXE issue in URL case which caused server to not function in some scenarios.

3. Added support for CAS server, SQL connection can now be against a ConfMgr CAS DB.

4. Added warning for boot image not being on the DP, before the query did not return any deployments if the boot image was not on the server, now we generate an error event and removes any linked deployments.

5. Fixes and issue where the serial number being URL encoded which makes machines with space in serial number wrongly removed from the result set.

6. Improved logging and event generation when machines are removed from the result set of deployments for various reasons.

7. Increase max length of serial number to match ConfigMgr of 255 characters.

8. Improved BootGen.exe now as .Net Framework .exe.

9. BootGen.exe now allows for .ISO file creation

10. Allows order of task sequences with ConfigMgrOrderBy property.

3.0.6.0 - 2022-07-06

1. Support for USB dongles with our without MAC passthrough

2. Improved support for MAC passthrough on HP devices

3. Support for new NCM based (Android) phone tethering

4. Support for regular Android based tethering

5. Support for Apple based tethering (iPhone, iPad etc.)

6. Support static IP builds in

7. Fixes an issue where autoexec.ipxe cannot exit the boot process when making the execution optional.

8. Fixes and issues where autoexec.ipxe cannot be used unless full script is in the autoexec.ipxe.

9. Releases the improved USB media creator

10. Initial support for UTF-8 based text input/output

11. iPXE now allows to change keyboard locale

12. Fixes an issue where text based licensing does not work correctly

3.0.5.0 - 2022-04-25

1. Fixes a bug in 3.0.4 where a missing alternative host name fails the service in certain scenarios.

2. Added support for select root CA via thumbprint when having multiple CA's in ConfigMgr.

3. Support for alternative host name for only the boot.wim file from ConfigMgr servers.

4. Removes the need for security on fnConvertLocalToUTC function in ConfigMgr by removing call to function.

3.0.4.0 - 2022-03-16

1. Enabled a scenario for booting with no other infrastructure than 2PXE together with iPXE WS.

2. Enabled support for cloud native booting.

3. Updated iPXE network boot loaders with improved USB support.

3.0.3.0 - 2022-02-04

1. Add support for USB Dongle MAC bypass support for HW supporting this.

2. Fixes an issue where Hyper-V causes a BSOD in WinPE.

3. Support for native USB dongles via native iPXE driver.

4. Support for native EFI SNP driver booting via USB keys.

5. Support for autoexec.ipxe script logic.

6. Adds support for USB booting with or without PXE/DHCP servers.

3.0.0.0 - 2021-08-09

1. Fixes an issue with 2.9.20.0 where BIOS machines cannot be booted.

2. TFTP files are now being cached in RAM. Controlled via the CacheTFTPFilesInMemory configuration property.

3. The iPXE network boot program now uses native USB drivers for docks and USB dongles.

4. Two new boot files: snponly_usb_x64.efi and snponly_usb_x86.efi are available. If you want to use the new USB driver mode and using DHCP, please make sure the name is updated.

5. Performance fixes when booting via BranchCache.

6. Fixes an issue where the iPXE network boot loaders ran out of memory when having many BranchCache connections.

7. Fixes an issue where iPXE network boot loader fails when using an uppercase HTTP scheme.

8. Fixes an issue where the https cert used by iPXE is not in the correct case.

9. Fixes an issue with Cisco 9200 hardware when used with DHCP Option #82.

10. Fixes an issue where a malformed DHCP PXE request packet would cause server to become unresponsive if enough requests where pushed.

11. Updated logging to remove large amounts of log entries when 2PXE is used in environments where IP phones are being used.

2.9.20.0 - 2021-07-01

1. Fix when using https and no tools sections.

2. Fix for iPXE NBP program not parsing HTTP or HTTPS in upper case. Later resolved in: https://github.com/ipxe/ipxe/commit/2690f730961e335875cac5fd9cf870a94eaef11a

2.9.18.0 - 2021-06-04

1. Fixes an issue where the DHCP reply from the proxyDHCP component does not match the BOOTP flags of the requesting packet. This can create issues with some DHCP Relay servers who fails to forward the DHCP packets the right way.

2. Non issue, SNAME field in the DHCP packet is changed from the client requesting IP to the 2PXE server IP.

3. Fixes an issue where DHCP Option 82 packet data was copied from the outgoing packet and not the incoming packet.

4. Non issue, fixes an parsing mis config when a DHCP Relay server's outgoing packet sending IP is not matching the actual IP Relay interface IP. This makes network analysing and capturing confusing. Aligned the code to reply to the GIADDR field if present, ignoring the sending IP if there is a GIADDR field set.

5. Changes to the behaviour and samples of CustomBoot items: Booting custom entries in 2PXE menu

2.9.17.0 - 2021-05-28

1. Fixes an issue where a machine in ConfigMgr might fail to boot a second time if the installation fails half way through or has not initiated hardware inventory before the second rebuild attempt.

2. Fixes an issue where building machines only using GUID based entries fails.

2.9.16.0 - 2021-05-11

1. Fixes potential issue where Option 82 values are not set right for proxyDHCP packets.

2. Initial work for Active Directory integration as a separate PXE request provider.

2.9.15.0 - 2021-05-05

1. Fixes issues where Option 82 is not used which leads to no reply in some scenarios.

2. Fixes minor issues with error handling text in app.config.

2.9.14.0 - 2021-04-28

1. Fixes an issue with developers not understanding that a .13 version is an unlucky version.

2. Fixes issue an issue with installing the server at all due to configuration file issues.

2.9.13.0 - 2021-04-27

1. Fixes a bug where 2PXE fails to boot a client if any TS is deployed to the client without having the boot image distributed to the DP.

2. Fixes some logging cases to only be available for debug builds to improve performance.

3. Adds functionality to allow scenarios where DHCP Option 82 is required for added DHCP security.

4. Reworked the Fast network option to allow non BranchCache deployments for fast networks.

5. Updated the error handling screen.

2.9.9.0 - 2020-11-26

This is a release that covers several new features and some ground work for future builds.

1. Updated installer and new licensing engine.

2. Ability to modify default screens

3. Amazeballs handling for known/unknown devices with same MAC/GUID's

4. Ability to override (replay) deployed mandatory sequences.

1. 2PXE is the PXE server component, head over to the Quick Start guide on page 6 and get going installing.

   1. It can be installed in three flavors:

      1. Configuration Manager integrated – On a Configuration Manager Distribution Point

      2. PowerShell Driven – Not requiring any infrastructure

      3. Referral only – For System Integrators

   2. The 2PXE server can be installed on its own without anything else.

2. iPXE Anywhere Web Service is a way to get even better PowerShell control, database logging and a lot of other nice things.

3. You can use 2Pint Software with or without BranchCache.

Review Installation Files

The 2PXE service can be installed to any location, but we recommend it to be installed in the default directory. Once the service is installed, the following files should be present in the installation folder:

• Main Service Executable 2Pint.2Pxe.Service.exe

• Configuration File 2Pint.2Pxe.Service.exe.config

• Main DLL 2Pint.2Pxe.dll

• License file License.cab

• License file License.nfo extracted from License.cab

• Microsoft .net dependency dlls

• PowerShell scripts for managing the PowerShell Extension

• Readme.txt

• End User License Agreement file

• Boot folder with iPXE boot loader files & wimboot binary

Important: Ensure that the License.nfo file has been created and that the license information inside the file looks correct by opening it up in notepad.

Check the 2PXE service

The Windows Installer file will install a service called 2PXE which it will also start during the install. Typical failures to start can be that the license file is wrong, or that something is using the ports that 2PXE is trying to use.

NOTE: Don’t forget that F5 (refresh) button, the service might show as running but is it really?

Check the RemoteInstall Folder

The RemoteInstall directory is created within the 2Pint Software\2PXE \ProgramData folder as per below:

Note: These files are left behind after an msi uninstall of 2PXE, but will be removed if the PowerShell removal script is used.

Inside the RemoteInstall folder you have more folders with default and temporary files. These files are managed by the service and normally don’t require any further configuration.

Figure 8 shows the root of the RemoteInstall directory used for hosting the boot files used by the TFTP transfer. The only file that requires attention is the Sources, from where the WinPE boot images are accessed. Images needs to be copied to here to allow booting using PowerShell extensions.

If you are using the PowerShell extension with regular Windows Boot Loaders the Sources folder is where you place your boot images.

2PXE Windows Event log

At service start up 2PXE checks for and if not present will create a Windows Event log.

Note: The log is located under the Application and Services Logs in the Event Viewer. This log is not removed as a part of the uninstallation.

Adding Boot Images

The Configuration Manager integration handles its own Boot Image process and requires no configuration of Boot Images. If Boot Image retrieval and distribution was working before 2PXE was installed then it should work after.

For adding images when using PowerShell integration, please refer to the 2PXE PowerShell Mode Guide.

2PXE Service Settings List

All 2PXE Service configuration is done through the 2Pint.2PXE.Service.exe.config file which is located in the 2PXE installation folder. Changes are not reflected until the service is restarted so please remember to start and stop after changes are made.

Note: Copying from word can bring the wrong type of “” quote signs, so don’t copy the quote signs into the config file.

2Pint.2PXE.Service.exe.config

The 2Pint.2PXE.Service.exe.config file has the following for configuration options, not all settings work together, so some basic logic needs to be applied. See the table at the end of this section.

EnablePowerShellExtension

Enables the PowerShell Extension, allow control of the boot process via the PowerShell script specified in the PowerShellExtenstionScript below. This will move over the boot object to PowerShell which will return the correct actions for the machine booting via the PowerShell script.

Value: ”0” to disable and ”1” to enable.

EnableSCCMExtension

Enables the SCCM Extension, can be used in conjunction with the PowerShell Extension. This requires the service to be installed on a SCCM Distribution Point and that you have access to the Site Server via the correct group membership.

Value: ”0” to disable and ”1” to enable.

EnableSCCMSQLConnection

Specifies to use a SQL connection to the Configuration Manager Database and boots the boot.wim images directly from the DP. If you don’t use this option 2PXE will use HTTP to get the boot request just like the Configuration Manager PXE Service Point and can only return one boot image per client. So SQL connection is recommended for Configuration Manager integration. Then you get the full fancy menu

Value: ”0” to disable and ”1” to enable.

ConfigMgrSQLConnectionString

Connection string to the Configuration Manager database. This is used when the SQL Connection is used by setting the EnableSCCMSQLConnection value set to 1. To allow access to the DB, add the machine account of the 2PXE server to the local group ConfigMgr_DViewAccess on the site server. Or define a separate login if you want to.

Value: "Data Source=<ServerName>;database=<DatabaseName>;Integrated Security=True"

EnableSCCMUnknownMachinesSupport

Support unknown machine support in SCCM. On/Off. Simple as that. Imagine if all settings were this easy?

Value: ”0” to disable and ”1” to enable.

EnableSCCMMenuCountdown

Sets the countdown for when only non-mandatory (optional) task sequences are targeting the computer. After countdown the computer exits to next boot device on the computer. A value of ”0” (zero) disables this feature and the menu will prompt until a task sequence is selected. Value in milliseconds but keep the value above ”1000” otherwise it might fail.

Value: ”0” to disable and boot last deployed mandatory TS and above “1000” to enable and wait 1 second, “3000” waits for 30 seconds etc.

EnableSCCMMandatoryCountdown

Sets the countdown when one or multiple mandatory task sequence deployments are targeting the computer. A value of -1 (minus one) disables this feature and the menu will prompt until a task sequence is selected. A value of ”0” (zero) disables this feature and the computer will boot the mandatory task sequence targeted deployment with the highest deployment creation time, just like Configuration Manager does with the PXE Service Point. Value in milliseconds, zero or -1.

Value: “0” to disable and boot last deployed targeting mandatory TS and above 1000 to enable, set to -1 to disable completely and prompt the user for selection.

SCCMReportState

Instructs 2PXE to send state messages to Configuration Manager for mandatory deployments. 1 to send, 0 to not send. Set this to 0 when using a Rubicon step in the task sequence to set the PXE flag.

Value: ”0” to disable and ”1” to enable.

EnableiPXEBootLoaders

Specifies to use iPXE boot loaders instead of any Windows boot loader. When used iPXE boots the boot.wim images directly from the DP, when using SCCM and from HTTP server when using the PowerShell or default request handler. iPXE uses HTTP instead of TFTP from the RemoteInstall Directory.

Value: ”0” to disable and ”1” to enable.

iPXEF12PromptTimeout

How long is the timeout for the F12 notification for iPXE loaders for non-mandatory deployments in milliseconds. E.g. 10000 = 10 seconds

Value: ”nnnnnnn” milliseconds

UseEmbeddedBootSDI

Specifies to use an embedded boot.sdi image inside the boot.wim file under the \sms\boot\boot.sdi folder. This is always present in Configuration Manager images, so then 2PXE always uses embedded boot.sdi file regardless of this setting. For non-Configuration Manager installations, you may use a default WinPE image, and this file is not present unless added. If you cannot add this file to the boot.wim make sure this value is set to "0".

Value: ”0” to disable and ”1” to enable.

wimbootParams

Value: ”gui”

EnableiPXEAnywhereWebService

Specifies to use iPXE Anywhere Web Service.

Value: ”0” to disable and ”1” to enable.

iPXEAnywhereWebServiceURI

Specifies the address port to the iPXE Anywhere Web Service. Please see the iPXE Anywhere Web Service information on how to configure this.

Value: ”http:// ipxe.webservice.local:8051”

RemoteInstallPath

Specifies the path to the RemoteInstall folder that contains boot files and images. It will be created if it doesn't already exist. You should always enter a local path, and can use environment variables. Sub-directories Boot, Tmp and Sources must be present immediately below this folder or they will be created by the service, so ensure you specify a path to which the service account has access.

Value: “%PROGRAMDATA%\2Pint Software\2PXE\RemoteInstall”

PowerShellExtensionAllowBootScript

Specifies the path to the PowerShell script that manages reply to the client, if any. Note that this script does not return the boot image itself, and that this script can run multiple times per boot of each client. This will only return true or false and then the initial loader will contact the PXE server again with architecture info etc. It will not be created if it doesn't already exist. You should always enter a local path, or use environment variables for a local path.

Value: “%PROGRAMDATA%\2Pint Software\2PXE\PowerShellExtensionAllowBoot.ps1”

PowerShellExtensionBootImagesScript

Specifies the path to the PowerShell script that manages reply, boot files and images. It will not be created if it doesn't already exist. You should always enter a local path, or use environment variables.

Value: “%PROGRAMDATA%\2Pint Software\2PXE\PowerShellExtensionBootImages.ps1”

EnableDebugLog

Set EnableDebugLog to "1" to enable logging to the file specified in DebugLogPath.

Value: ”0” to disable and ”1” to enable.

DebugLogPath

This log will be fairly verbose, so remember to set it to "0" to switch it off afterwards. Errors and warnings will always be logged to the 2PXE event log. Ensure that the service account has access to the path if no log is appearing.

Value: "%PROGRAMDATA%\2Pint Software\2PXE\2PXE.log"

RunHttpServer

2PXE has a built-in Web Service for iPXE integration. You can switch it off by setting the value to "0" below, for instance if you have your own iPXE Anywhere Web Service server this is not needed. The HTTP WCF service only allow access to files under the RemoteInstall directory, and cannot transfer files outside this location.

Value: ”0” to disable and ”1” to enable.

RunOnHttpPort

Sets the port for the 2PXE http WCF service to a unique value.

Value: "8050" or any other value.

RunOnDhcpPort

By default, 2PXE answers on both the DHCP (67) port and PXE (4011) port. You can control this by setting the values to "0" for off or "1" for on below, for instance if this machine also acts as a DHCP server.

Value: ”0” to disable and ”1” to enable.

RunOnPxePort

By default, 2PXE answers on both the DHCP (67) port and PXE (4011) port. You can control this by setting the values to "0" for off or "1" for on below, for instance if this machine also acts as a DHCP server.

Value: ”0” to disable and ”1” to enable.

RunTftpServer

2PXE has a built-in TFTP server, written by Jean-Paul Mikkers. You can switch it off by setting the RunTftpServer value to "0" below, for instance if you have your own TFTP server.

Value: ”0” to disable and ”1” to enable.

TftpFilter

These are the folders beneath RemoteInstallPath that the TFTP server will serve files from. Specify one or more relative wildcard paths separated by semi-colon.

Value: "boot\*;\tmp\*;\boot\*;tmp\*;\Sources\*;Sources\*"

TftpBlockSize

Tweak the values below to decrease image download times. Note that PXE BIOS, routers and other network equipment may limit these settings further. Set TftpBlockSize to 512, 1024, 1456, 2048, 4096, 8192 or 16384. Default value is 1456.

Value: ”4096” to set the block size to 4096.

TftpWindowSize

Tweak the values below to decrease image download times. Note that PXE BIOS, routers and other network equipment may limit these settings further. Set TftpWindowSize to the number of packets to send without waiting for acknowledgement. Maximum is 32, default is 1.

Value: ”16” to set to the recommended value of 16 which works on most HW.

EnableiPXEAnywhereWebService

Specifies to use iPXE Anywhere Web Service.

Value: 0 to disable, 1 to use reporting functionality only, 2 to move the entire request over to the web service + reporting. 3 is 1+2 and the ability to execute cmdline from iPXE WS in WiNPE

BootRequest = 1,

Syslog = 2, <- Using the resolved IPv4 Addresss of the iPXE Anywhere Web Service unless overridden by adding the <add key="iPXEAnywhereWebServiceIP" value="192.168.xxx.yyy"/> setting in this config.

ReportBootConfiguration = 4,

ReportDLStart = 8,

ReportDLComplete = 16,

ReportDLBoot = 32,

RunCmdLineWinPE = 64

A value of 62 (2+4+8+16+32 = 62) Gives you all but BootRequest and RunCmdLineWinpE.

For iPXE and StifleR Integration requires a minimum of; 2+4+8+16+32 = 62

iPXEAnywhereWebServiceURI

Specifies the address and port to the iPXE Anywhere Web Service. Please see the iPXE Anywhere Web Service information on how to configure this.

Value: "http://"/

Username

Username and domain name to use to access content in form of DOMAIN\Username, password is stored in the Password.config file in the same folder as the config file.

Value: [%USERDOMAIN]\[%USERNAME]"

FWTFTP

Set to 1 to create the Port 69 UDP Firewall exception as service startup

Value: ”0” to disable and ”1” to enable.

FWDHCP

Create the Port 67 UDP Firewall exception as service startup

Value: ”0” to disable and ”1” to enable.

FWPROXYDHCP

Create the Port 4011 UDP Firewall exception as service startup

Value: ”0” to disable and ”1” to enable.

FWHTTP

Create the Port 8050 TCP Firewall exception as service startup

Value: ”0” to disable and ”1” to enable.

BindToIP

When using high performance option, the underlying class does not know the route of the UDP packet, hence it needs an address to send back data from. Specify an IP address local to the machine (NIC) to use to send UDP packets from.

Value: Set to the IP address as required

UseHighPerformanceRestartableThreads

Better thread management for large organizations that do a lot of PXE requests, this requires BindToIP setting to be set.

Value: ”0” to disable and ”1” to enable.

Valid Configuration Combinations

The following list can be used to find supported and unsupported configuration combinations in this release, green indicating the “really” supported scenarios that we would like people to test:

The preceding table shows the different valid options, if you are unsure of your scenario, please contact support@2pintsoftware.com.

x86WinPEShlConfiguration and x64WinPEShlConfiguration

The x86 and x64 WinPEShlConfiguration options can be used to launch additional commands after WinPE has been downloaded, but before we hand over control to the ConfigMgr OSD Client. This is commonly used to launch custom frontends etc. Below is an example on how to launch a command prompt.

Value: Text string, can be broken up in multiple lines for readability.

[LaunchApps] %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe %windir%\system32\wpeutil.exe,InitializeNetwork %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %windir%\system32\cmd.exe /c start Custom_Pause /wait cmd %SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

Installation and Configuration

Pre-Requisites

The following items must be installed and configured on the 2PXE Server regardless of which handler you will be using (Configuration Manager or PowerShell)

• The .NET Framework 4.6.2 or above must be installed.

• If you want to use Configuration Manager the 2PXE Software must be installed onto a CM Distribution Point.

Configuration Manager – Distribution Point

As stated previously, in an ideal setup, a dedicated Configuration Manager Distribution Point (DP) will be installed to handle all iPXE Anywhere PXE Booting.

Best practice:

• BranchCache has been configured in your environment

• DO NOT install WDS or a PXE Service Point on this system. The 2PXE server replaces that functionality and operate on the same ports (69 and 4011).

Configuration Manager – Security

Allowing Access to the Configuration Manager SQL Database

2PXE uses SQL as the fastest way to retrieve boot actions for a system. Add the service account (default the machine account of the Distribution Point) to the ConfigMgr_DViewAccess local group on the Configuration Manager Site Server. Members in this group have the required access for using distributed views against the Configuration Manager database. The account only requires read rights and can be further locked down if necessary.

Figure 6 shows the local group for accessing SQL, the SQL reporting group provides sufficient SQL rights.

Security without Configuration Manager

If you are not using Configuration Manager then the only security related issue is to ensure that the boot URL returned from the PowerShell command is accessible with anonymous security or by using an ACL and the iPXE Network Access Account.

2PXE Service Install

The installer is an MSI, which adds a Windows service for hosting the proxyDHCP and the TFTP service. There are two versions. One each for x86 and x64.

Installation requires administrative rights, as does running the service as it needs to create BCD files.

There is no way to avoid the requirement around full admin rights, so the recommended installation is always on a server system and not on desktop devices.

Licensing

Licensing for iPXE Anywhere is provided via a Licensing .cab file which will have been sent to you as part of the 2Pint registration and download process. The license file will contain your company information and is used to validate the installation.

Figure 7 shows the contents of a typical installation source folder. One x86 installer and one x64 installer plus a default license file.

The 2PXE Server and iPXE Anywhere is licensed per network bootable node. When using Configuration Manager this is verified shortly after service startup and at a timely interval. The following SQL query will be used to check the number of devices in the database:

select Count(*) As LiveSystems from v_R_System where ResourceType = 5 AND

AgentEdition0 = 0 OR /* Windows Desktop or laptop computer */

AgentEdition0 = 1 OR /* Windows ARM-based device (running Windows RT) */

AgentEdition0 = 5 OR /* Mac computer */

AgentEdition0 = 6 OR /* Windows CE */

AgentEdition0 = 7 OR /* Windows Embedded */

AgentEdition0 = 12 OR /* Intel System On a Chip */

AgentEdition0 = 13 /* Unix and Linux servers */

This means that you can still have a large number of users and other device types that are non PXE bootable like iOS devices & iPAD’s in your hierarchy.

NOTE: All the iPXE Anywhere installers can be run manually or automated (silent). See the appendices for further information on command line switches.

Once completed, hit the “Finish” button to exit the installer. You are now done!

Using IP Helpers

If you are using IP Helpers to direct your PXE traffic then your routing hardware should be configured to redirect DHCP Requests to both your DHCP server and to the 2PXE Server. The PXE Boot request will be picked up and processed directly by 2PXE Server. The request package contains all of the information required by 2PXE to ascertain the hardware type and machine identification in order to ensure that the correct boot information can then be sent to the requesting client.

If you are using IP Helpers then the rest of this DHCP Configuration section can be skipped as it only applies to environments that are using DHCP options to handle PXE boot requests.

Using DHCP Options

If you are not using IP helpers to control the PXE process, you need to do some changes to your DHCP infrastructure to allow PXE booting to work. The DHCP server must be configured to enable it to reply to a requesting client with enough information to allow the client to obtain a boot file. This includes the IP Address of the PXE Server, the appropriate boot file name (according to client hardware type) and the URL and Port number for the https session.

• You need to define the IP of the server to do the initial download from, using the next-server field (Which Microsoft sets by using Option 66, which allows a DNS name that is then resolved to an IP that as setting the next-server field.)

• You need to define the appropriate filename to boot. This is unique per hardware type and needs to be defined through a rule or other DHCP server logic. If you are using IP Helpers, this is handled directly by the 2PXE service, but when using the DHCP server, the DHCP server has to do this logic filtering instead. This is Option 67.

• We need to define the HTTPS url and Port for iPXE to use when communicating with the 2PXE Service. As we are using HTTPS this string needs to exactly match the host header of the machine, otherwise the TLS session will fail.

NOTE: To reiterate – “this needs to match the host header of the machine” this means it must be in lower case, must be spelt correctly and must contain a trailing slash:

https://<server.f.q.d.n>:<port>/

The following table shows what you need to set to make sure 2PXE works as it should and example values:

Configuring a Microsoft DHCP server for 2PXE server

This is an example setup where the 2PXE server IP is 192.168.10.30 and the FQDN host name is PXE01.2pint.local and the default port is 8050. This guide will help you to define DHCP options to boot of UEFI machines as well as BIOS computer from the same 2PXE server, using DHCP options and thus bypassing the need & requirement for IP Helpers on the routers.

What’s required?

This guides go through creating DHCP scopes to boot of a 2PXE server using a Microsoft DHCP server, it requires:

• Microsoft DHCP Server running on at least Server 2012 with some DHCP scopes set up

• A 2Pint Software 2PXE Server providing boot services

• At least one router in between clients PXE booting and the servers, blocking DHCP/Broadcast traffic

• A BIOS client computer (can be virtual, all Hyper-V Gen1 is BIOS)

• A x64 EFI client computer (can be virtual, Hyper-V Gen2 is EFI)

What’s the Outcome?

The outcome of the guide is that you will be able to boot computers using DHCP options, with the same process and outcome as using IP Helpers.

Client boots -> DHCP server replies -> Client contacts 2PXE server -> iPXE Network Loader talks to 2PXE over https to get correct boot action -> Boot WinPE (Typically).

First things first - The Basics!

PXE is a software standard, which makes room for developers to interpret things slightly differently which means that unexpected bugs and issues in the code are a way of life. If you have worked with PXE before you will know that things do not work flawlessly at all times.

1. If you are having issues, try to get the latest BIOS/Firmware for computer. For on board NIC’s (LOM is the term us PXE nerds use which means LAN-On-Motherboard) this is typically a BIOS update as the PXE ROM is located in the BIOS storage. For extra physical NIC’s the vendors have their own tools to burn new FW into the ROM.

2. Microsoft’s official view is that DHCP options are not supported to boot machines from WDS, but we think that that is probably because they have a bug in their software. Read about that here:

Using the workaround mentioned in this guide works, If it doesn’t then please report any abnormalities to us and we can help. The simple fact is, it does work to boot machines using DHCP options, as long as you follow this guide.

1. You say EFI, I say UEFI, same stuff different name. Typically you can just call it UEFI and not bother about the technicalities. UEFI & EFI FTW!

So why does it work with IP Helpers?

How does the server know which file to give the client? Magic? No, it’s actually fairly straightforward. As part of the DHCP request (In particular Options 60 and 93) the client sends the servers quite a bit of information about its hardware and other identifying information.

The Option 60 string sent as part of the clients request is in the following form:

PXEClient:Arch:<Type Flag>:UNDI:<Options>

The server picks up the Type Flag and can respond with the correct boot loader file. This is how EFI and BIOS booting can work from the same server when using IP Helpers but not with static DHCP options. With IP Helpers the PXE server directly receives a copy of the DHCP request which contains the Option 60 information. The PXE Server can then review this information and send back the appropriate boot file information (Also using DHCP Options). The PXE Client can then merge the DHCP and PXE server offers to form the necessary request. When using DHCP options the PXE server doesn’t get to talk to the client during this early exchange, so the processing must be moved to the DHCP server to mimic this functionality.

As of the writing of this document, the following pre-boot architecture types have been requested. The ones in thick borders are the 3 essential ones, the rest can fairly safely be ignored depending on the size of your organization.

*Type 0 machines can be both x86 and x64, the wdsnbp.com checks the CPU capabilities and sends that info back to the server, more on that below.

The Type is always preceded by four zeroes, so like 00007 and 00006 for x64 and x86 EFI types. A BIOS machine will then be 00000 as its 4 zeroes plus zero for the first Intel x86PC entry.

EFI BC is the x64 UEFI alright, but what does BC stand for? EFI BC = EFI Byte Code. EFI Byte Code is a processor agnostic language for device drivers, PXE, and other EFI extensions so that the code can be written once and run on any supporting platform.

NOTE: There was some confusion in the industry around this technology so some machines might report in as type 9 (EFI- x86-64). In this case try upgrading the firmware.

DHCP Policy Rules for controlling boot files

Most Non-Microsoft DHCP servers can review the info in the DHCP requests and respond with different options depending on what’s in the request. Microsoft was a bit late to the table however, and it wasn’t until Server 2012 that this feature was introduced and a lot of Administrators are not aware of this functionality.

In order to use these new policies, we need to set up a Vendor Class to capture the Option 60 information. Then we will use this option to capture requests from clients that match this Class.

In a typical environment you want to use 4 class definitions (although you could use less):

1. Vendor class for BIOS machines (x86 and x64)

2. Vendor class for x86 UEFI machines

3. Vendor class for x64 UEFI machines

4. Vendor class for x86 & x64 EFI capable HW

When it comes to BIOS machines, the support for x86 and x64 is detected by the boot loader itself. As all x64 machines can run x86 code, the x64 BIOS request is handled by the x86 file.

NOTE: DHCP Policy objects were introduced in Windows Server 2012, so if you are on 2008, you cannot do these cool things. Upgrade or go with a free Linux DHCP like ISC DHCP, your choice.

Creating Required Vendor Classes

Vendor classes are used to identify machines booting, it’s basically a way for the DHCP server to detect that one machines should fall under a specific category.

Right click the IPv4 object in the DHCP console and select “Define Vendor Classes…”

The DHCP Vendor Classes dialogue box will appear, hit the “Add…” button and the “New Class” dialogue box will appear. Give the first Class a proper name, so that people that read this after you have left the company, on the path to becoming a successful rock star, get it as well. In this example we have named it “PXEClient (UEFI x64)”. The display name has nothing to do with functionality, it’s just used for identification purposes. The description can contain anything as well, but hopefully something sensible.

Next, in the ID, Binary, ASCII window, under where it says “ASCII:” Click in that space and you will then be able to enter information into this field as follows:

PXEClient:Arch:00007

Please note that this is case sensitive so it must be entered exactly like the above, nothing more, nothing less. Once complete you should have:

Then we hit the OK button, and we get back to the “DHCP Vendor Classes” screen where you will see the new entry:

That’s it, we created our first Vendor Class and linked it to the data that a UEFI x64 client will send out in its DHCP request. Now, if you want you can create one more for x86 UEFI and also one for BIOS. The x86 UEFI one should appear as follows:

And for the BIOS entry like this:

When complete the three new vendor classes will appear as follows:

Creating new scope options

Once our PXE booted client needs to contact iPXE, it needs the FQDN URL of the 2PXE server. This is configured via DHCP option #175. This option does not appear by default, so it must be added.

Right click the IPv4 node in the console and select “Set Predefined Options...”

This will take you to the Predefined Options and Values screen, where you can add new settings. Click the “Add...” button.

This allows you to set up a template which will define how the option should behave and look when being set as a DHCP scope option. Enter details as follows:

Name: This can be anything describing the option

Data type: This should be set to String

Code: This should be set to 175

Description: This can be set to a little novel about life, or just describing the DHCP option and usage. Once entered you should have the following:

Once you click “OK” you can also fill in a default value that administrators will see when adding the DHCP option to their scope::

Click “OK” to close the Option dialog.

Creating new policy objects

Next we need to configure Policies. Right click on the Policies node and choose the “New Policy” menu option.

Please note that you can create Policies from the Scope Node as well, they don’t have to be Server wide. The DHCP server evaluates policies sequentially according to an assigned processing order. The DHCP administrator assigns the processing order to the policies. If policies exist at the server and scope levels, the server applies both sets of policies and evaluates the scope policies before the server policies. The processing order for a scope level policy defines the order of evaluation within the scope. If there are no policies defined at the scope level, the policies at the server level apply to the scope.

Type in some meaningful info, remember the rock start career is calling. Hit the Next button when you have typed in something creative. This takes you to the Condition page of the Wizard, here is where we match up the Policy with the Vendor Class that was created previously..

Keep in mind that there are x86 UEFI’s as well, and if these require support then you would define another Vendor Class with the value of PXEClient:Arch:00006. The 6 indicates x86 and 7 is x64, as per the table at the beginning of this article.

Click the “Next” button which allows you to set Conditions. Click the Add Button to add in a new Condition.

The AND/OR button doesn’t come in to play here as we will only have one rule. In the “Add/Edit Condition” page select “Vendor Class” from the “Criteria” drop down, and select the “Equals” Operator. Then select the PXEClient (UEFI x64) Vendor class from the list:

Ensure that the “Append Wildcard (*)” check box is selected as below. This makes sure that rest of the string is not used in the comparison. The smart people that clicked the RFC link and read a little will know that the entire Option 60 string looks something like PXEClient:Arch:00007:Undi:…. So it continues after 00007, hence the Append wildcard operator:

Click on the Add button.

The completed condition will appear as above. Next click the “Ok” button. This takes returns back to the Conditions page which now lists the newly added Condition. Make sure that the asterisk * is in the Rule Value to ensure that the wildcard is in play. If you forget to check this before you hit the “Add” button you will have to remove the Condition and add it in again.

Hit the “Next” button and move on.

Depending on where a Policy is created there is the ability to limit the policy to a certain IP Address range. Select “No” to this option and then click Next to move on.

Next to configure in the wizard are DHCP settings. This denotes what is sent to the client once it matches the Criteria rule created earlier. Options 60, 66 and 67 are all required.

Firstly Option 66 - Enter the IP Address (not the hostname) of the 2PXE server as the string value for this option.

Next Option 67:

The Option 67 string contains the iPXE file path details to snponly_x64.efi (the UEFI x64 file) The full path details are from the \ProgramData\2PintSoftware\2PXE\RemoteInstall directory.

Next set DHCP option 175 to configure the 2PXE server DNS name

Put in the correct value for the server as below, all lowercase, port number and ending “/” value. Note that this is https and accordingly must exactly match what is returned form the lookup. This is the reason for the lower case form and trailing slash.

Running DHCP server on the same server as 2PXE

NOTE: This part is only required when running 2PXE on the same server as the DHCP server – usually only in a Lab/POC environment.

Option 60 is added in the reply package as “PXEClient”. Don’t confuse this with the Request Option 60 which is like “PXEClient:Arch:000…” etc.

This setting forces the PXE client to use port 4011 when communicating to the PXE server service as the DHCP port will be in use by the DHCP server service.

The Summary Page

You can now complete the wizard. Hit the “Finish” button and make sure the Policy is in the “Enabled” state and listed as below:

The DHCP Scope Options should now appear as follows:

Configuration Options

At the moment our example set up is only for x64 UEFI machines, but what about those BIOS boxes? And x86 UEFI?

One “feature" is that DHCP Rules override default Scope options, so you can create default option 66 & 67 for BIOS machines and if you only have Type 0 (BIOS – remember?) and Type 7 (x64 UEFI machines) you would then be good to go. As there are not many x86 UEFI machines around anymore this may be enough.

If you do define default options 66 and 67 + 175 for the scope it looks like this (Yes, you can then remove DHCP option 175).

This is not the clearest solution, but having different rules for different hardware types does add overhead as more rules need to be processed.

Another option is to create 3 separate policies which allows the options to be set per policy. This is probably the most efficient way:

Then looking at the individual options, you will see the three Policy rules each giving out 66,67 and 175:

Things to watch out for:

1. Make sure you cover all the different “Types” of HW you want to boot.

2. A lot of people (especially Microsoft employees and MVP’s) will tell you that booting PXE from using DHCP options is not a good idea, they can safely be ignored.

3. Any issues, give us a shout on the regular support channels.

4. There is a Branchcache Bob video in the on the 2Pint web site that steps through a close approximation of the above as it applies to WDS.

Using DHCP Policies is a powerful way of controlling which boot file etc. a machine should have. You can also filter out MAC addresses etc. or you can control it on a per Hardware type regardless of capabilities.

iPXE Anywhere

The 2PXE and iPXE Anywhere web service both potentially requires changes to your firewall configuration. Generally changes these are not required if you are using the Microsoft Windows firewall.

2PXE uses the following protocols for booting WinPE images:

• Dynamic Host Configuration Protocol (DHCP)

• Pre-Boot Execution Environment (PXE)

• Trivial File Transfer Protocol (TFTP)

• Hyper Text Transfer Protocol (HTTP)

The following table outlines the User Data Protocol (UDP) and Transmission Control Protocol (TCP) network ports that are used during the process. You can modify the values that have an asterisk (*) by using the instructions in this manual.

Step by Step UDP and TCP ports used during image deployment:

1. The client performs a network boot.

2. 2PXE uses DHCP ports and TFTP to download the binary files. For TFTP and DHCP, you need to enable ports 67, 69, and 4011. The TFTP and multicast servers use ports in the range 64001 through 65000 by default.

3. In accordance with RFC 1783 (http://go.microsoft.com/fwlink/?LinkId=81027), the client chooses random UDP ports to establish the session with the server. If you are using a non-Microsoft firewall, you may need to use an application exception for TFTP on the 2PXE Server.

4. PXE Client downloads the configured boot loader using TFTP.

5. The client downloads Windows PE, typically over HTTP or HTTPS and boots to the Windows Deployment Services client. This download also uses the same TFTP ports as mentioned previously or using HTTP directly from the 2PXE server or from the Configuration Manager DP or any other configured HTTP server.

6. If reporting is enabled, the PXE client will try to communicate over to the iPXE Anywhere Web Service.

The following rules are automatically created when 2PXE starts:

Quick Install for Microsoft Configuration Manager

Best Practice recommendation is to build a new DP and install the 2PXE server onto that machine. If you must install it onto an existing DP that is running WDS and/or PXE servicing, then please ensure that you first disable these.

1. If you have a SCCM PXE Service Point installed – remove it.

2. If Windows Deployment Services is installed, remove or at least stop/disable the service.

3. Ensure access to the SQL DB:

• Add the service account (default is the machine account of the Distribution Point) to the ConfigMgr_DViewAccess local group on the Configuration Manager SQL Server

1. Install the MSI interactively

   1. Make sure you select Configuration Manager integrated and Bind to a single IP. Leave all other values as default

• 1. If you are using HTTP, and the DP is not in anonymous mode, you need to define an iPXE Network Access Account.

• 1. Let the installer do it’s thing

1. Welcome to the future! PXE Boot a Machine.

Quick Install Guide for PowerShell Request Handler

There is a separate iPXE Anywhere 2PXE Server PowerShell Mode Guide. Please refer to this for more on this solution.

The guide shows you how to setup iPXE Anywhere for use with the 2PXE PowerShell Request Handler using your existing WinPE Boot images. In order to witness the full majestic beauty of iPXE doing its thing, make sure that Branch Cache has been enabled in your environment, and that the WinPE Boot images have been cached into the BranchCache cache of one or more machines on the same subnet.

1. Install the MSI interactively

2. Select PowerShell integration on the mode screen and Bind to a single IP address:

1. Welcome to the future! PXE Boot a Machine.

The following commands are supported by iPXE.

Command reference

The following commands are supported by iPXE.

Boot commands

autoboot - Boot system from network interface

Network interface commands

ifstat - Display interfaces ifopen - Open interfaces ifclose - Close interfaces ifconf or dhcp - Automatically configure interfaces route - Display routing table nstat - Display neighbor table ipstat - Display IP statistics vcreate - Create VLAN vdestroy - Destroy VLAN

Image management commands

imgstat - Display images chain or imgexec or boot - Download and boot an executable image imgfetch or module or initrd - Download an image kernel or imgselect or imgload - Download and select an executable image imgfree - Discard images imgargs - Set image command-line arguments imgtrust - Set image trust requirement imgverify - Verify an image as trusted

SAN commands

sanhook - Attach SAN device sanboot - Boot from SAN device sanunhook - Detach SAN device fcstat - Display Fibre Channel ports fcels - Issue Fibre Channel ELS request

Configuration setting commands

config - Start interactive configuration tool show - Display configuration setting set - Set configuration setting clear - Delete configuration setting read - Prompt user to enter configuration setting inc - Increment numeric value of configuration setting login - Prompt user to enter user name and password Flow - control commands isset - Test for existence iseq - Test for equality goto - Jump to script label exit - Exit current shell or script

Menu commands

menu - Create menu item - Add menu item choose - Choose menu item

Console management commands

console - Configure console colour - Define colour cpair - Define colour pair Form - parameter commands params - Create form parameter list param - Add form parameter

Miscellaneous commands

echo - Print text to console prompt - Prompt user to press key shell - Start new interactive shell help - Display list of available commands sleep - Delay for fixed period of time reboot - Reboot system poweroff - Power off system cpuid - Check x86 CPU feature sync - Wait for background operations to complete nslookup - Resolve host name to network address ping - Check network connectivity pciscan - Scan for PCI devices

Misc commands

lotest - Perform loopback testing pxebs - Perform PXE boot server discovery time - Measure time taken to execute command gdbstub - Start remote debugging profstat - Display profiling statistics

NOTE: Because there are many options to configure via the command line install, we have created a PowerShell Script to use as a ‘wrapper’ for the MSI Install. You find the script at: https://github.com/2pintsoftware/iPXEAnywhere/tree/main/Install

The install can be configured through the following basic commands:

Installation on an X86 machine:

MSIEXEC /i "2Pint Software 2PXE Service (x86).msi" CABSOURCE=”C:\Temp\License.cab” INSTALLTYPE=”2” SERVICE_USERNAME=<domain>\<username> SERVICE_PASSWORD=<password> REMOTEINSTALL_PATH=C:\RemoteInstall /l* C:\Temp\2PXE.installation.log

Installation on an X64 machine:

MSIEXEC /i "2Pint Software 2PXE Service (x64).msi" CABSOURCE=”C:\Temp\License.cab” INSTALLTYPE=”2” SERVICE_USERNAME=<domain>\<username> SERVICE_PASSWORD=<password> REMOTEINSTALL_PATH=C:\RemoteInstall /l* C:\Temp\2PXE.installation.log

The above examples are ‘bare minimum’ examples. You may want to configure more properties during install, and we have included a reference of all the MSI properties below.

Mandatory MSI Properties

CABSOURCE=<Full path to License.cab> Full path to where you have your license.cab file

INSTALLTYPE="N” 1 is PowerShell integration, 2 is with MS Configuration Manager Integration

SERVICE_USERNAME=”LocalSystem” or "domain\username" if you want to use a domain account

SERVICE_PASSWORD=”xxxxxxxx“ Can be skipped if SERVICE_USERNAME is LocalSystem

Optional MSI Properties

CONFIGMGRSQL=”1” 1 to enable a SQL connection to the Configuration Manager DB, 0 to use HTTP via the Management Point (no menu)

If CONFIGMGRSQL is set to 1 the following parameters must be set

RUNTIME_DATABASE_LOGON_TYPE=WinAuthCurrentUser "SqlAuth" if using SQL Accounts. "WinAuthCurrentUser" uses Integrated Security.

ODBC_SERVER=”myserver.domain.local “ FQDN of the Configuration Manager Database Server

RUNTIME_DATABASE_NAME=CONFIGMGR_xxx Configuration Manager Database Name, typically CONFIGMGR_<SITECODE>

REMOTEINSTALL_PATH=”<path to remote install folder>” Media folder for the service where computers will boot from

DEBUGLOG_PATH="C:\MyLogfiles\2PXE.log" Path to the logfile

DEBUGLOG=”1“ 1 to enable and 0 to disable verbose logging

POWERSHELLSCRIPTALLOWBOOT_PATH Path to the PowerShell extension script for boot requests.

POWERSHELLSCRIPTIMAGES_PATH Path to the PowerShell extension for image selection.

RUN_ON_DHCP_PORT Specifies if the service should respond on DHCP port - 1 or 0

RUN_ON_PXE_PORT Specifies if the service should respond on PXE port - 1 or 0

RUN_TFTP_SERVER Specifies if the built-in TFTP Server should be started - 1 or 0

RUN_HTTP_SERVER Specifies if the built-in HTTP WCF Server should be started

EMBEDDEDSDI="1" Use an embedded boot.sdi image. See full documentation for more info

F12TIMEOUT=”10000" F12 prompt timout for iPXE loaders for non mandatory deployments in milliseconds.

IPXELOADERS=”1" # Use iPXE Boot Loaders 1 to enable and 0 to disable. If 0 2PXE will use Windows boot loaders

UNKNOWNSUPPORT=”1" 1 for enable (default) 0 to disable - enables Unknown Machine support in Configuration Manager

PORTNUMBER=”8050" 2PXE Http Service Port - 8050 by default

POWERSHELLSCRIPTALLOWBOOT_PATH=”c:\myscripts" Set only if using custom path location for .ps1 scripts

POWERSHELLSCRIPTIMAGES_PATH="c:\myscripts" Set only if using custom path location for .ps1 scripts

INSTALLFOLDER="C:\MyInstallPath" Default is C:\Program Files\2pint Software

ENABLESCCMMENUCOUNTDOWN="10000" Countdown for menu timeout if nothing is selcted (in Millisecs)

ENABLESCCMMANDATORYCOUNTDOWN="30000" Countdown for Mandatory deployments - the deployment will be executed after this expires (in Millisecs)

SCCMREPORTSTATE="1" Instructs 2PXE to send SCCM state messages for mandatory deployments. 1 to send, 0 to not send.

WIMBOOTPARAMS="gui" command line for wimboot. Possible parameters are: gui, pause, pause=quiet, rawbcd, index=x For details see: http://ipxe.org/appnote/wimboot_architecture

ENABLEIPXEANYWHEREWEBSERVICE="0” Specifies to use iPXE Anywhere Web Service. 0 to disable, 1 to use reporting functionality only, 2 to move the entire request over to the web service + reporting. 3 is 1+2 and the ability to execute cmdline from iPXE WS in WiNPE

BootRequest = 1,

Syslog = 2

Using the resolved IPv4 Addresss of the iPXE Anywhere Web Service unless overridden by adding the <add key="iPXEAnywhereWebServiceIP" value="192.168.xxx.yyy"/> setting in this config.

ReportBootConfiguration = 4,

ReportDLStart = 8,

ReportDLComplete = 16,

ReportDLBoot = 32,

RunCmdLineWinPE = 64

For example:

A value of 62 (2+4+8+16+32=62) gives you all but BootRequest and RunCmdLineWinPE. Therefore

for iPXE and StifleR Integration you would have to set it to a minimum of; 2+4+8+16+32 = 62

IPXEANYWHEREWEBSERVICEURI="http://url:Port" Specifies the address and Port for the iPXE Anywhere Web Service

NETWORKACCESS_USERNAME "[%USERDOMAIN]\[%USERNAME]"

NETWORKACCESS_PASSWORD “A123456!"

FWTFTP Set 1 to allow the installer to create the Port 69 UDP Firewall exception

FWDHCP Set 1 to allow the installer to create the Port 67 UDP Firewall exception

FWPROXYDHCP Set 1 to allow the installer to create the Port 4011 UDP Firewall exception

FWHTTP Set 1 to allow the installer to create the Port 8050 TCP Firewall exception

BINDTOIP Enter the server NIC IP address to which to bind the service

USEHYPERTHREAD" Value="1"

The default setup

2PXE writes a new WinPEShl.ini into the %programdata% directory each time it starts, one for x86 builds and one for x64 builds.

NOTE:

Please note that the WinPEShl.ini is ONLY transferred by default if the underlying configuration requires this. This is normally only the case for ConfigMgr related environments, and not other types of custom iPXE Anywhere Web Service scenarios. But the same file can be retrieved and injected if required.

The following text is written into the winpeshl.ini by default for an x64 boot image: (the x86 has other paths)

[LaunchApps] %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

The x86 part with it's default paths:

[LaunchApps] %SYSTEMDRIVE%\sms\bin\i386\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %SYSTEMDRIVE%\sms\bin\i386\TsBootShell.exe

The first line initialises the TSProgressUI.exe in WinPE to show ConfigMgr progress UI. This is done so that the second command, the iPXEWinPEClient.exe can show progress.

The second command, initialises the network drivers in a way that guarantees that the network is available at the time of the second command exits. It' seems as a trivial task, but is actually harder than what most people realise, as the WinPE environment linked with some extra interesting drivers for special hardware and it's a complicated mess to sort out.

The third command runs the iPXEWinPEClient.exe, but skips the network init, causing it to just contact the iPXE Anywhere infrastructure to report back/get any command line information required to run from the server side PowerShell script in the iPXE Anywhere Web Service.

The fourth command runs TSBootShell.exe that starts the whole OSD process. That's it.

Custom example to troubleshoot with cmd.exe as first step

If you want to modify the content of these WinPEShl.ini files, you can edit them directly in files under 2PXE's %ProgramData% directories, but the changes are only there until service restart. So if you want the change to be permanent, you need to change the .config file for 2PXE.

The following shows how to put an entry in the .config file for 2PXE, the key x64WinPEShlConfiguration and x86WinPEShlConfiguration. So the following adds a new step in there to launch a cmd.exe before it starts the TSBootShell.exe.

    <add key="x64WinPEShlConfiguration" value="[LaunchApps]
%SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe
%windir%\system32\wpeutil.exe,InitializeNetwork
%windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit
%windir%\system32\cmd.exe /c start &quot;Paused TS: Close this to continue&quot; /wait cmd
%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe"
/>

The corresponding for an x86 system:

    <add key="x86WinPEShlConfiguration" value="[LaunchApps]
%SYSTEMDRIVE%\\sms\\bin\\i386\\TsProgressUI.exe,/register:winpe
%windir%\\system32\\iPXEWinPEClient.exe,/NetworkInit
%windir%\\system32\\iPXEWinPEClient.exe,/SkipNetworkInit
%windir%\system32\cmd.exe /c start &quot;Paused TS: Close this to continue&quot; /wait cmd
%SYSTEMDRIVE%\\sms\\bin\\i386\\TsBootShell.exe"
/>

There are a few tips here on the syntax:

1. Note that the x86 and x64 entries are just for matching the machines booting, NOT the server itself.

2. As this is XML, some characters might need to be encoded, using XML encoding syntax to allow proper handling of the .config file itself.

3. If you mess up the .config file, the service will fail to start and crash.

4. Given point two above, make sure you check the xml integrity if you are uncertain using an XML parser that is better than notepad.exe.

5. If you don't have carriage return + newline by separating into the same line, you can do the same via \r\n in the line above.

Custom Example to use with TSBackground

When using OneVinn's/Johan Schreweliu's TSBackground app, the syntax needs to be updated a little to avoid having it crash. If you never heard of it, check out: https://onevinn.schrewelius.it/Apps01.html

So What needs to happen is the following line has to be added after iPXE Anywhere have done their bits, which is done by adding: %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/unregister

This then unloads the TSProgressUI in process COM server to allow TSBackground to override it, without it, it will look messy.

[LaunchApps] %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/unregister x:\sms\pkg\sms10000\TSBackground\TSBackground.exe

Given above, the following would be the .config entry:

    <add key="x64WinPEShlConfiguration" value="[LaunchApps]
%SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe
%windir%\system32\wpeutil.exe,InitializeNetwork
%windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit
%SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/unregister 
x:\sms\pkg\sms10000\TSBackground\TSBackground.exe"/>

The CustomMenuItems section provides the following capabilities;

• Provide a way to link custom iPXE scripting language with an entry in the menu provided by 2PXE.

• Using the custom script entry, a call to the iPXE Anywhere Web Service can be made to create custom scripting scenarios from the 2PXE boot menu.

How does it work?

Define one or many entries in the CustomMenuItems using the key/value format, where;

• The "key" value links to an entry under CustomItems which is just below in the same .config file.

• The "value" value is the display text shown in the menu itself on the machine you are booting.

The below scenario is linking a single entry as per below, in this case, we create a single entry with the "key" set to "myShell", and the display text will then be "iPXE Shell" in the menu:

  <CustomMenuItems>
    <add key="myShell" value="iPXE Shell"/>
  </CustomMenuItems>

So then we need a matching entry with iPXE code in the "CustomItems" sections. In this case, it's simple, create a key with "myShell" identifier, linking with above, then the iPXE code snippet to start a shell, is "shell". Simple!

  <CustomItems>
    <add key="myShell" value="shell"/>
  </CustomItems>

Multiple items

You can have multiple items in here, as long as you match the keys as per below:

  <CustomMenuItems>
    <add key="myShell" value="iPXE Shell"/>
    <add key="vaccine" value="Book Corona vaccination"/>
    <add key="bootToiPXWS" value="Reset device"/>
  </CustomMenuItems>

<CustomItems>
    <add key="myShell" value="shell"/>
    <add key="vaccine" value="echo Sorry not available here! &amp;&amp; prompt Press any key to return to menu"/>
    <add key="bootToiPXWS" value="chain https://server.fqnd...."/>
</CustomItems>

XML and advanced syntax

Keep in mind that the .config file is XML based, so using & and other XML syntax language, you need to escape them correctly so that the XML parsing is not broken. So an iPXE && would in the config file be &amp;&amp; etc.

If you want a line break, you can do this two ways;

1. Create an actual line break in the .config file

2. Don't use the \r\n line feed character inline. Its important that there is no \r\n characters in the script piece as the .Net parser will double escape this which break. Instead use the following syntax:

echo line 1
echo line2

Booting a custom WinPE image

Its certainly possible to boot against a custom boot image, you just have to issue the right commands, and make sure you have the right files available.

Please see the following link to the iPXE web site for some inspiration: https://ipxe.org/howto/winpe

The syntax would be something like this in the .config section:

Linking up against the iPXE Web Service

One great feature is to use the 2PXE menu items to integrate with the iPXE Anywhere Web Service. Please reach out to us if you have custom scripting scenarios you would like to discuss. You can use this issue to automate a "ticket" etc for machine refusing to boot, or reset PXE flags etc. There is really no end to the possibilities.

Normal 2PXE operation involves several binding to local interfaces, primarily for the DHCP and TFTP threads. The "BindTo" configuration value is used for the DHCP threads, as Windows handles multicast/broadcast responds in a very uncontrolled way, it needs to know from which adapter to send the broadcast reply, this is done by specifying the address for the DHCP threads to use when creating the sockets.

In some cases TFTP might fail to send the data from the correct interface and the servers UDP replies to the TFTP read requests ends up being sent from the wrong adapter/IP. In this case, create a new configuration entry in the .config file (next to the BindToIp) setting preferably, name it: "ListenToTftpIp" and set the value to the correct IP you want to use, such as "10.10.11.30" (in most scenarios this IP is the same as the BindToIp value).

Visit the 2Pint support Knowledge Base. There’s useful stuff in there – we promise.

If something is not right, ensure that the settings in 2PXE are set correctly. For each integration type the 2Pint.2PXE.Service.exe.config file values should be checked as follows

For Configuration Manager integration:

1. Stop the 2PXE Service if it is started

   1. Enable Configuration Manager Extension by setting EnableSCCMExtension to “1”

   2. Disable the PowerShell Extension by setting EnablePowerShellExtension to “0”

   3. Disable the referral only mode by setting iPXEWSOnly to “1"

   4. Set EnableSCCMSQLConnection to “1”

   5. Set ConfigMgrSQLConnectionString to the right one, basically you need the Server FQDN and the Configuration Manager DB name in there.

2. Enable iPXE Boot loaders by setting EnableiPXEBootLoaders to “1”.

3. Enable 2PXE HTTP server by setting RunHttpServer to “1”.

4. Optional: Enable Unknown Machines support by setting EnableSCCMUnknownMachinesSupport to “1”

5. Run the service in interactive mode as per below.

For PowerShell integration:

1. Stop the 2PXE Service if it is started

   1. Enable the PowerShell Extension by setting EnablePowerShellExtension to “1”

   2. Disable the Configuration Manager Extension by setting EnableSCCMExtension to “0”

   3. Disable the referral only mode by setting iPXEWSOnly to “1"

   4. Enable iPXE Boot loaders by setting EnableiPXEBootLoaders to “1”.

   5. Disable the 2PXE HTTP server by setting RunHttpServer to “0”.

   6. Check the UseEmbeddedBootSDI and set it to “0” if you don’t have the boot.sdi integrated in the image as described earlier in this document.

2. Ensure you have an IIS Virtual Directory for the wimboot.bin file, boot.sdi, and boot images (C:\ProgramData\2Pint Software\2PXE\RemoteInstall) and copy your boot images to the \Sources sub-folder. Also make sure that you have the correct MIME types setup. See the 2PXE Server PowerShell Mode Guide for these settings.

3. Edit the 2PXE PowerShell files and make sure it returns a proper URL to the files above.

4. Create a Windows Firewall rule to allow incoming TCP traffic to the 2PXE Web service on port 8050

5. Bounce the service and check for errors

Running the service interactively

Ensure that the service is stopped before doing this.

You can run the service directly from either a console or by double clicking the executable from within Windows Explorer. This starts the service in a command prompt window, allowing for simple troubleshooting as you can observe directly while the boot request rolls through the console window.

When running in interactive mode all debug logging will be pushed to the console window. This will greatly help when you run into issues or want to showcase the technology. Please note that the console runs under the user executing it and not the service account (SYSTEM by default) which can lead to access violations.

Note that boot speed can also be greatly reduced as the printing to console will take longer than the actual actions. We recommend that this mode is only used for testing or troubleshooting and is best utilized while booting only a single system.

As an example, the following screen shows the executable being run in interactive mode, failing to bind to HTTP.SYS as the port is being used by another process.

Figure 9 shows the 2PXE service running interactively, failing to bind to the HTTP port (due to the service already running).

Errors & Issues

There are many things that can go wrong in 2PXE. If the machine is not booting it’s likely that you have set a configuration that is invalid. Check the valid configuration options and if you can’t find the issue enable debug logging and send us the log after trying to boot an image. Please include any PowerShell scripts as well as the .config file in the email. Email the files to support@2pintsoftware.com or use our online forums.

Note: Don’t forget to add all the files to a .zip folder otherwise the email might get caught in a spam or antivirus filter.

Getting to an iPXE console session

When things fail early in the process you can get to a console and try to troubleshoot. Before the initial 2Pint Software splash screen appear you can press the ‘c’ key on your keyboard. You have only have a small window of time to press it so bang that thang until the console appears. You are to press the 'C' key when the following is visible or about to appear:

Once at the console type ’help’ to get a list of commands available for custom troubleshooting. Otherwise, the machine is now in debug mode and by typing 'exit' the regular process will continue, step by step, stopping at each command.

Support staff at 2Pint Software might instruct you to specific sequences of commands to run, otherwise, if you are just doing an initial test, type 'exit' and press enter as per below:

By continuing to type 'exit' and pressing enter you will move further and further in the process. Below shows what it looks after a few 'exit' has been typed in:

After a while, the screen turns to the custom boot images:

You can also review all available built in console variables by running help, or using the ’config’ command to get a graphical view of all values. The help output shows available commands:

You can then dig around, view variables and troubleshoot to your hearts content. Typically, you will have been directed here by 2Pint Software support staff.

iPXE Anywhere is a network booting solution which makes use of the open source iPXE network boot program. For details on this Open Source Project visit http://ipxe.org/

2Pint Software has funded the implementation of several components in iPXE and is a driving force behind iPXE development. One these add-ons is the inclusion of a Microsoft BranchCache client into the iPXE software. This is now part of the iPXE software available to everybody. We like to think of it as our sacrifice to the PXE gods for all to use and enjoy.

At 2Pint Software we add the “Anywhere” part which consists of the following two components:

• A Proxy DHCP/TFTP/HTTPS server called iPXE Anywhere 2PXE Server, the main PXE Server (this manual).

• An optional Web Service component called iPXE Anywhere Web Service which adds multiple extra functionality and controls over your build sequences.

These “Anywhere” components make the iPXE Network boot loader sing and dance by enabling communication, configuration and reporting between the iPXE clients and the backend Server infrastructure such as Configuration Manager..

Figure 1 shows a Configuration Manager integrated menu from 2PXE, with 2 Deployments to the same Task Sequence. One set to Available (A) and one Required (R).

How it Works – the simple version

A machine PXE boot request is picked up by the network boot server. The server parses the request and sends the corresponding boot file (BIOS or EFI) to the client. This file is very small and is well suited to low bandwidth situations.

Once the iPXE Network Boot Program (NBP) is downloaded it contacts the 2PXE Server (over HTTPS) which then checks for any configured actions for that client to execute (Lack of action will cause the NBP to exit out and continue the boot order.). If any configured actions are detected the server will send back a corresponding script to the client. The client will then execute this script which, typically, involves loading a high level OS over HTTP. Thanks to the inbuilt BranchCache functionality, when the system is instructed to load the Windows PE boot image this can be downloaded rapidly from local BranchCache peers rather than being transferred over the WAN from a remote server.

The diagram below shows a typical iPXE Anywhere, Microsoft Configuration Manager integrated environment. The 2PXE Server component replaces the Windows Deployment Server (WDS) and Configuration Manager Distribution Point PXE Service Point (PSP) components. It connects to the Configuration Manager database in order to retrieve the deployments available for a system, and dynamically builds a boot menu which is returned to the client system.

Figure 2 A typical iPXE Anywhere implementation

About iPXE Network Boot Program

iPXE is the leading open source network boot firmware. It provides a full PXE implementation enhanced with additional features such as:

• Boot from a web server via HTTP

• HTTP supports BranchCache V1 & V2

• Boot from an iSCSI SAN

• Boot from a Fiber Channel SAN via FCoE

• Boot from an AoE SAN

• Boot from a wireless network

• Boot from a wide-area network

• Boot from an Infiniband network

• control the boot process with a script

You can use iPXE to replace the existing PXE ROM on your network card, or you can chain load into iPXE to obtain the features of iPXE without the need to re-flash.

iPXE is free, open-source software licensed under the GNU GPL (with some portions under GPL-compatible licenses), and is included in products from several network card manufacturers and OEMs.

iPXE and BranchCache

If you are looking to use our PXE solution with BranchCache, but are not familiar with BranchCache, we recommend you read our BranchCache page before continuing with this document as it covers several key factors of BranchCache that might affect your design and setup.

http://2pintsoftware.com/microsoftbranchcache

2Pint Software OSD Toolkit

This nifty (free!) toolkit enables BranchCache in the Windows Pre-Installation Environment (WinPE) and also for non-BranchCache enabled systems like the Windows Professional family. This is only needed for integrating BranchCache and BITS into WinPE. It is not required to make iPXE Anywhere function. It is however highly recommended as, by enabling BranchCache in a resource intensive process like OSD, more systems on the network will share the load, ensuring a fast and effortless deployment without hogging bandwidth and system resources from other computers or the network.

If you are just looking to use HTTP boot without BranchCache you can skip this section. For more information on how to generate these WinPE images please refer to the 2Pint OSD Toolkit documentation. https://2pintsoftware.com/products/osd-toolkit/

You can also add BranchCache to WinPE at a later stage depending on your testing and requirements.

Other System Management Tools

iPXE Anywhere can obtain the appropriate boot actions from other SMTs by:

1. Configuring 2PXE PowerShell scripts to interact with the other system.

2. Configuring the iPXE Anywhere Web Service to talk to the other system directly.

For more information on this please contact support@2pintsoftware.com

Main iPXE Anywhere Components

The iPXE Anywhere solution consist of four major components:

Figure 3 iPXE Anywhere Main Components where the Web Service and Database are optional components.

Detailed iPXE Anywhere Component Information

This sections gives a little more background on the several major components that make up iPXE Anywhere.

iPXE Anywhere 2PXE Server

The 2PXE Service is a proxyDHCP server that responds to the initial PXE request. It has built in proxyDHCP, TFTP and HTTP services. Don’t confuse the 2PXE web service with the iPXE Anywhere Web Service, they are different animals. The iPXE Anywhere Web Service is the big brother of the 2PXE web service. The 2PXE Service is typically your entry point to the PXE booting method as this is the Service that parses requests and hands out the iPXE network boot loader.

iPXE Network Boot Program (NBP)

This is the core essence of iPXE Anywhere. A specially configured customized version of the open source iPXE solution tailored to work with the iPXE Anywhere server environment. Importantly, one of the components that is now enabled as a part of the default iPXE build is BranchCache. Having BranchCache enabled in an NBP enables you to load WinPE content from peer BranchCache systems that have that content in stored their local cache.

iPXE Anywhere Web Service (Optional)

This extends multiple functionality into the boot process. With the iPXE Anywhere Web Service in place the Network Boot Program can be configured to talk to this service directly. The Service talks HTTP with the client and SQL to the SQL DB (optional – see following). It is used for ‘extended functionality’ such as BIOS updating, interacting with Microsoft MDT, creating custom iPXE menus etc. Please refer to the separate documentation for that component.

iPXE Anywhere SQL Database(s) (Optional)

This is a part of the iPXE Anywhere Web Service. This database stores info about PXE booted computers and their capabilities. Traffic to this database is relatively small so this database may be hosted on SQL Express if required. Also connected to the iPXE Anywhere Web Service Database is a SQL Reporting Services Instance which is used to generate the Reports which are included as part of the installation.

Security

Unlike most network boot products, iPXE Anywhere uses a number of technologies which ensures that the boot process can be made 100% secure to protect any sensitive data.

Authentication

Before allowing the network boot, a user can be authenticated against a central repository such as on premise Active Directory or Azure.

Credentials can be either sent as clear text protected by SSL certificates or, for non SSL capable servers, by using NTLM or IIS Digest Authentication. iPXE Anywhere supports NTLM authentication against Windows Authentication for Configuration Manager distribution points.

Using SSL ensures that there is no way unauthenticated users can access media containing username or passwords. Unlike most network booting systems, the password can be provided at actual boot time, before loading any large image, which frees up time while increasing security.

Certificates

iPXE supports the HTTPS protocol, which allows you to encrypt all web server communication and to verify the server's identity. All HTTP traffic between iPXE boot loader and the 2PXE server is secured using SSL.

For maximum security there is the option to bind a public TSL certificate to iPXE.

Secure Boot

The iPXE Boot Loader now supports Secure Boot, which is a feature of UEFI that only allows certain Operating Systems to be loaded.

Note: Due to how Hyper-V uses boot verification, Secure Boot has must be disabled on VM’s when using iPXE to build clients.

Custom Certificates

iPXE supports the use of third party certificates (i.e. other than iPXE or 2Pint Software certificates) Contact us at support@2pintsoftware for further setup information.

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.

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.

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.