Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In this section you find technical references for command line setup, 2PXE Console Commands, as well as reference documentation of the 2PXE Config file
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
All communication is now HTTPS between the iPXE boot loader and the 2PXE server, regardless of HTTP state of the DP.
HTTPS DP’s and NTLM DP’s are now supported, no need for anonymous access configured on the DP.
Change from using DHCP option 252 to 175
Pure PowerShell setup got revamped to work again with HTTPS communication
iPXE -> 2PXE TFTP communication methods are no longer supported, use HTTPS instead
Change to work with subordinate CA servers in Configuration Manager integration
The use of Windows boot loaders is discontinued
Minor bug fixes
Improvement to performance
Filter abilities to Configuration Manager TS deployments
Updated boot screen
WIM File injection - No need to modify the boot image
TFTP Server
Supports option to bind to single IP for multi NIC machines
Allows to link to single port for TFTP transfers
Registry Detection – No need to restart service when Configuration Manager changes configuration
iPXE WinPE Client – Now included and shipped as part of 2PXE installer
Custom Variable injection – Task Sequence runs as part of variable creation
Improved Web Service integration
WimBoot WinPE loader:
Ability to inject files into RAM held WinPE image
Bug fixes
iPXE Network Boot Program Changes:
Included Syslog Client
TLS Updates to support IIS
Added Certificate commands for iPXE
Updated to latest build at time of compiling
Bug fixes for Realtek NIC’s
Added and updated logging options for troubleshooting.
Added infrastructure support for UEFI 2.5 and above based systems
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.
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.
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
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.
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" />
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).
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.
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
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).
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
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.
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.
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.
iPXE Anywhere can obtain the appropriate boot actions from other SMTs by:
Configuring 2PXE PowerShell scripts to interact with the other system.
Configuring the iPXE Anywhere Web Service to talk to the other system directly.
The iPXE Anywhere solution consist of four major components:
Figure 3 iPXE Anywhere Main Components where the Web Service and Database are optional components.
This sections gives a little more background on the several major components that make up iPXE Anywhere.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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)
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).
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.
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.
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.
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!
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.
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):
Vendor class for BIOS machines (x86 and x64)
Vendor class for x86 UEFI machines
Vendor class for x64 UEFI machines
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.
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:
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.
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:
Make sure you cover all the different “Types” of HW you want to boot.
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.
Any issues, give us a shout on the regular support channels.
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.
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.
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).
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.
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.
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 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!
For more information on this please contact
If you want to read more, have a look here:
If you need some basic understanding around how to set up and work with Microsoft DHCP Policies then please have a read of the following Microsoft article:
NOTE: If Option 60 does not appear in the list you can add it by following these instructions:
DHCP Name Field | Microsoft Name | Value | Example |
Next-Server (SIADDRR) | Option 66 | IP of the 2PXE server | 192.168.10.30 |
Filename | Option 67 | Boot file name | Unique per HW type BIOS both x64 and x86 Boot\x86\undionly.kpxe UEFI – x64 Boot\x64\snponly_x64.efi EUFI – x86 Boot\x86\snponly_x86.efi |
Option 175 | Option 175 | Url of 2PXE FQDN in lowercase and Port number | https:// pxe01.2pint.local :8050/ Note: This needs to be lowercase and must contain the port and end with a slash “/” |
Type | Architecture Name | 2PXE Boot File | Comment |
0 | Intel x86PC | boot\x86\undionly.kpxe | This is the typical BIOS machine. This machine is typically also capable of running x64 code.* |
1 | NEC/PC98 | Japanese 16-bit microcomputer manufactured by NEC. Old school! |
2 | EFI Itanium | What ever happened to Itanium? |
3 | DEC Alpha | Oooh, I remember the Alphas. *sigh* |
4 | Arc x86 | boot\x86\undionly.kpxe | Think Virtual Box sends this… unsure. |
5 | Intel Lean Client | Oh dear, remember this hype? Net-PC… |
6 | EFI IA32 | boot\x86\snponly_x86.efi | 32 bit EFI machines, typically tablets running x86 Windows on newer HW. |
7 | EFI BC | boot\x64\snponly_x64.efi | 64 bit EFI, majority of EFI machines fall under this category. |
8 | EFI Xscale | Not supported? | XScale is a microarchitecture for central processing units initially designed by Intel implementing the ARM architecture. |
9 | EFI x86-64 | This is for systems that are capable of running both x86 and x64 EFI. Systems of this sort are very rare as the developers have to write code to support both architectures. |
2PXE is the PXE server component, head over to the Quick Start guide on page 6 and get going installing.
It can be installed in three flavors:
Configuration Manager integrated – On a Configuration Manager Distribution Point
PowerShell Driven – Not requiring any infrastructure
Referral only – For System Integrators
The 2PXE server can be installed on its own without anything else.
iPXE Anywhere Web Service is a way to get even better PowerShell control, database logging and a lot of other nice things.
You can use 2Pint Software with or without BranchCache.
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"
Start the installation by executing the correct installer (x64 for x64 systems). Ensure you have the License.cab available for the installer to access. The following Welcome dialog will appear |
After you click the Next button the license agreement page appears, click to agree the terms and conditions after you read through and agree to all the statements. |
In this next dialog you have the several options:
|
The next dialog is the Licensing dialog. Here you have to select the license file for the installer to continue. Click on the “…” button to browse for the License.cab file. Browse and select a valid License.cab file and click ‘Open’. The path to the license file will now be updated. NOTE: If you select an old expired license file the installer will continue but the 2PXE service will stop soon after starting. |
Select whether to install together with the iPXE Anywhere Web Service or not. Note: This can easily be modified later. If you are integrating, the URL needs to be the one resolved by the iPXE binary, i.e. it cannot be a localhost address. |
Next, configure the account under which you the 2PXE service will run, either LocalSystem, or using a specific local or domain account. Please note that a Local or Domain User account must have the ‘Logon as a Service’ right |
Next, you can choose a port for the 2PXE HTTP service. The default is 8050 but you may enter your own custom port should you wish. Whichever you choose, you will need to click the ‘Test Port’ and then, assuming the Port is available, click Next. |
If you are using the Configuration Manager handler, enter the server name of the server that hosts the Configuration Manager Database. If you are running 2PXE on that server, you can select (local). Click next to continue. |
The installer should then connect to that server and fill out the Database name for you. Check this, and if it’s correct, click next to continue. Otherwise enter the correct name. |
In this screen you can configure account that will be used to connect to the Configuration Manager Database from the 2PXE service. We recommend that you use the same account that you specified for the 2PXE service. You can choose a separate account if you must but this may have unexpected results. You are required to test the connection to verify that it has the correct rights before you can continue. |
Tell the installer where you want to install the 2PXE service, and click next. |
Select if you want automatic firewall rule creation for Microsoft Firewall. If you are using third party firewall, check the Firewall documentation in this guide. |
If you are using HTTP, and the DP is not in anonymous mode, you need to define an iPXE Network Access Account. This can be left at default if you are using HTTPS. |
We are now ready to unleash 2PXE magic, so go ahead and click on Install, sit back and enjoy a cup of tea? |
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.
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.
The format of the string is a typical .Net connection string URI so port and other items can be specified. For more information please refer to: https://msdn.microsoft.com/en-us/library/vstudio/system.data.sqlclient.sqlconnection.connectionstring(v=vs.100).aspx
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
Specifies the command line to wimboot, possible parameters are: gui, pause, pause=quiet, rawbcd, index=x For details see: http://ipxe.org/appnote/wimboot_architecture
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.
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
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.
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?
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.
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.
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.
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:
Stop the 2PXE Service if it is started
Enable Configuration Manager Extension by setting EnableSCCMExtension to “1”
Disable the PowerShell Extension by setting EnablePowerShellExtension to “0”
Disable the referral only mode by setting iPXEWSOnly to “1"
Set EnableSCCMSQLConnection to “1”
Set ConfigMgrSQLConnectionString to the right one, basically you need the Server FQDN and the Configuration Manager DB name in there.
Enable iPXE Boot loaders by setting EnableiPXEBootLoaders to “1”.
Enable 2PXE HTTP server by setting RunHttpServer to “1”.
Optional: Enable Unknown Machines support by setting EnableSCCMUnknownMachinesSupport to “1”
Run the service in interactive mode as per below.
Stop the 2PXE Service if it is started
Enable the PowerShell Extension by setting EnablePowerShellExtension to “1”
Disable the Configuration Manager Extension by setting EnableSCCMExtension to “0”
Disable the referral only mode by setting iPXEWSOnly to “1"
Enable iPXE Boot loaders by setting EnableiPXEBootLoaders to “1”.
Disable the 2PXE HTTP server by setting RunHttpServer to “0”.
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.
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.
Edit the 2PXE PowerShell files and make sure it returns a proper URL to the files above.
Create a Windows Firewall rule to allow incoming TCP traffic to the 2PXE Web service on port 8050
Bounce the service and check for errors
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).
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.
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.
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.
If you have a SCCM PXE Service Point installed – remove it.
If Windows Deployment Services is installed, remove or at least stop/disable the service.
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
Install the MSI interactively
Make sure you select Configuration Manager integrated and Bind to a single IP. Leave all other values as default
If you are using HTTP, and the DP is not in anonymous mode, you need to define an iPXE Network Access Account.
Let the installer do it’s thing
Welcome to the future! PXE Boot a Machine.
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.
Install the MSI interactively
Select PowerShell integration on the mode screen and Bind to a single IP address:
Welcome to the future! PXE Boot a Machine.
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.
The client performs a network boot.
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.
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.
PXE Client downloads the configured boot loader using TFTP.
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.
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:
This page details how to use custom entries with WinPEShl.ini to run custom actions before or after the machine boots.
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.
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.
The corresponding for an x86 system:
There are a few tips here on the syntax:
Note that the x86 and x64 entries are just for matching the machines booting, NOT the server itself.
As this is XML, some characters might need to be encoded, using XML encoding syntax to allow proper handling of the .config file itself.
If you mess up the .config file, the service will fail to start and crash.
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.
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.
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:
For a typical EFI boot, without the optional boot fonts, a total of 314KB of data is transferred per booting device. A 99,9% reduction from the standard TFTP protocol. All data sizes in Kilobytes. Note that the file version sizes are averages as some builds might include debug information and/or troubleshooting tools like nslookup and ping etc.
The total transfer of data is then typically the iPXE boot loader, then wimboot (hashed or not) and the boot.bcd file + some iPXE scripts to hold it all together. Then we transfer the hash of the WinPE image which then does the TFTP download using TFTP.
The following speeds have been noted in our labs downloading over a poor link, with BranchCache support 5 clients serving the WinPE image and on Gigabit network without BranchCache. The test speeds are with EFI capable devices and for downloading a 300MB WinPE image only.
A typical boot process using iPXE as the boot loader looks like the following:
Client starts,
Initiate the on board PXE ROM
PXE ROM requests an DHCP with HW capabilities in DHCP request
Typically Option 60 and Option 97 are used for architecture management
DHCP Servers (Proxy DHCP or/and DHCP) responds with right filename depending on HW capabilities in the requesting DHCP package
PXE ROM merges DHCP with possible proxy DHCP response(s) according to the PXE standard, and developers interpretation of that standard.
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.
TFTP of the boot loader finish
PXE ROM loads iPXE
iPXE initializes and does a whole lot of magic before launching the embedded script.
Embedded script checks that all seems to be in order and then processes the logic.
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/
iPXE sends up heaps of info about the client to the 2PXE server over https
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.
An iPXE boot script is sent down to the client for execution
iPXE executes the script and transfers the corresponding files listed in the boot script, typically booting a WinPE image.
Client downloads required files using HTTP with BranchCache support from the source:
Certificates, in order for WinPE to trust the 2PXE server
iPXEWinPEClient.exe, which sets up the right certificates and environment
Wimboot as the kernel to load the WinPE image
Boot.sdi as the NTFS virtual drive is included in the boot.wim image
Optional boot fonts are used from the boot.wim image
bcd file is created dynamically by the 2PXE service
WinPE boot.wim file, typically from the Distribution Point
A new WinPEShl.ini which replaces the original one, executes the iPXEWinPEClient.exe as the first step
The WimBoot kernel boots the downloaded WinPE image using the bcd data
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.
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 or use our online forums.
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:
Name | Protocol | File | Port | InterfaceType |
2Pint Software 2PXE – TFTP | UDP | C:\Program Files\2Pint Software\2PXE\2Pint.2pxe.service.exe | 69 | ALL |
2Pint Software 2PXE – DHCP | UDP | C:\Program Files\2Pint Software\2PXE\2Pint.2pxe.service.exe | 67 | ALL |
2Pint Software 2PXE – PXE | UDP | C:\Program Files\2Pint Software\2PXE\2Pint.2pxe.service.exe | 4011 | ALL |
2Pint Software 2PXE – HTTP | TCP | Any | 8050 | ALL |
File Name | Size | Hash size | Purpose |
snponly.efi | 150 | N/A | EFI iPXE bootloader, using UNDI, can’t be use BranchCache as its the start of the process |
undionly.kpxe | 75 | N/A | BIOS iPXE bootloader, using UNDI, can’t be use BranchCache as its the start of the process |
WimBoot | 35KB | 1KB | WinPE boot loader |
Boot.bcd | 12KB | N/A | Typically about +8KB per added |
Boot Scripts | 1-2KB | N/A | Auto generated |
Variable.dat | 22KB | N/A | Transferred using TFTP from Configuration Manager binaries in WinPE |
Windows PE | 300-500MB | 150-300KB | Size depends on drivers, optional components etc. |
Transfer | Kilo Bytes | Comment |
Total BIOS WAN transfer with BranchCache | ~275KB |
Total EFI WAN transfer with BranchCache | ~350KB |
Reduction in percentage of WAN traffic | -99.9% | Yeah, it’s that awesome! |
Bandwidth Up/Down/%Packet Loss | Speed (mm:ss) | Reduction from TFTP |
56/33.6 Kb 2% (Modem) | 02:00 | Are you kidding me? |
128/512 Kb 2% (ISDN/DSL Type) | 00:30 | Keep dreamin baby! |
1.544Mb/s (Typical T1) | 00:10 | Still aint happening! |
10Mb/s 1% Loss | 00:07 | On a sunny day? Right! |
100Mb/s 0,5% Loss | 00:07 | About 10 mins |
1Gb/s 0% Loss with BranchCache | 00:06 | Down 1-5 mins |
1Gb/s 0% Loss without BranchCache | 00:02 | Down 1-5 mins |
This page covers scenarios where trunks and other multi NIC configurations are in place. There might be some extra configuration required to make everything work.
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).
iPXE includes an interactive command line that can be used for manual booting and for diagnosing problems. Commands can also be used as part of an iPXE script, or to build a custom menu.
The following commands are supported by iPXE.
The following commands are supported by iPXE.
autoboot - Boot system from network interface
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
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
sanhook - Attach SAN device sanboot - Boot from SAN device sanunhook - Detach SAN device fcstat - Display Fibre Channel ports fcels - Issue Fibre Channel ELS request
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 - Create menu item - Add menu item choose - Choose menu item
console - Configure console colour - Define colour cpair - Define colour pair Form - parameter commands params - Create form parameter list param - Add form parameter
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
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
What | UDP | TCP |
DHCP & TFTP |
2PXE HTTP Traffic | 8050* |
iPXE Anywhere | 8051* |
67*, 69, 4011*, Random
This page explains hot the CustomMenuItems item in the .config file works to allow custom actions in the 2PXE menu.
Note: Please use 2.9.18.0 or later with 2PXE when experimenting with this.
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.
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:
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!
After the snippet returns, it will run the "goto keypressed" label, which is an internal label to return to the menu. You can call this yourself in your custom script if you want to exit out early.
You can have multiple items in here, as long as you match the keys as per below:
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 && etc.
If you want a line break, you can do this two ways;
Create an actual line break in the .config file
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:
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:
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.
