iPXE Anywhere 2PXE Server Manual 2.7 · 4. Pure PowerShell setup got revamped to work again with HTTPS communication 5. iPXE -> 2PXE TFTP communication methods are no longer supported,

iPXE Anywhere 2PXE Server Manual 2.7.4

2Pint Software 8/17/17

1

IPXE ANYWHERE 2PXE SERVER MANUAL 2.7.4 2PINT SOFTWARE

2PintS o f t w a r e

Contents TL;DR version ................................................................................................................................................. 4

Change Log .................................................................................................................................................... 5

Changes from 2.5.0.0 to 2.7.0.0 ............................................................................................................... 5

Changes from 2.2.0.0 to 2.5.0.0 ............................................................................................................... 5

Quick Install Guides ....................................................................................................................................... 6

Quick Install for Microsoft Configuration Manager ................................................................................ 6

Quick Install for the PowerShell Request Handler .................................................................................. 6

iPXE Anywhere introduction ......................................................................................................................... 8

How it Works –Simple Sample ................................................................................................................. 9

About iPXE Network Boot Program........................................................................................................ 10

Want to use BranchCache? It’s optional for iPXE Anywhere! .............................................................. 10

2Pint Software OSD Toolkit ................................................................................................................ 10

Other System Management Tools ......................................................................................................... 10

Main iPXE Anywhere Components ......................................................................................................... 11

Detailed iPXE Anywhere Component Info ............................................................................................. 12

iPXE Anywhere 2PXE Server– The main PXE Server........................................................................ 12

iPXE Network Boot Program (NBP).................................................................................................... 12

iPXE Anywhere Web-Service (Optional) ............................................................................................. 12

Security..................................................................................................................................................... 13

Authentication ..................................................................................................................................... 13

Certificates ........................................................................................................................................... 13

Secure Boot .......................................................................................................................................... 13

Custom Certificates............................................................................................................................. 13

Planning – The boring part ......................................................................................................................... 14

With or without the iPXE Anywhere Web-Service? ................................................................................ 14

StifleR Integration ............................................................................................................................... 14

DHCP scope options vs IPHelpers? ....................................................................................................... 15

2PXE Operational Mode – PowerShell, ConfigMgr or what? ............................................................... 17

Enabling the 2PXE Request Handlers .................................................................................................... 17

Microsoft Configuration Manager Request Handler (EnableSCCMExtension) .............................. 17

PowerShell Request Handler (EnablePowerShellExtension) ........................................................... 18

Installation and Configuration .................................................................................................................... 19

Pre-Requisites .......................................................................................................................................... 19

ConfigMgr – Distribution Point .......................................................................................................... 19

2



ConfigMgr – Security .......................................................................................................................... 19

Allowing Access to the ConfigMgr SQL Database ............................................................................ 19

2PXE Service Install ................................................................................................................................ 20

Licensing .............................................................................................................................................. 20

2PXE Post Installation Configuration ........................................................................................................ 26

Review Installation Files ......................................................................................................................... 26

The 2PXE service – ensure its started ................................................................................................... 26

The RemoteInstall Folder ........................................................................................................................ 26

2PXE Windows Event log ........................................................................................................................ 27

Adding Boot Images ................................................................................................................................ 27

DHCP Configuration..................................................................................................................................... 28

Configuring a Microsoft DHCP server for 2PXE server ......................................................................... 28

What’s required? .................................................................................................................................. 29

What’s the Outcome ............................................................................................................................ 29

First things first - The Basics!............................................................................................................. 30

So why does it work with IP Helpers? ................................................................................................ 30

DHCP Policy Rules for controlling boot files ..................................................................................... 31

Creating Required Vendor Classes .................................................................................................... 32

Creating new scope options ............................................................................................................... 34

Creating new policy objects ............................................................................................................... 36

Firewall Considerations ............................................................................................................................... 47

The following steps explain the UDP and TCP ports that are used during image deployment: ... 47

Appendix A: Troubleshooting...................................................................................................................... 49

Running the service interactively ........................................................................................................... 50

Errors & Issues ......................................................................................................................................... 50

Getting to an iPXE console session ....................................................................................................... 51

Invalid Configuration File ........................................................................................................................ 52

Failing with an invalid boot.bcd file ................................................................................................... 53

Failing to find the boot.sdi file ............................................................................................................ 53

Connection Reset 0f0a6095 ............................................................................................................... 53

Not enough RAM in target computer ................................................................................................. 54

Slow first boot with PowerShell ......................................................................................................... 54

To aggressive filtering......................................................................................................................... 55

Appendix B: Further Reading ...................................................................................................................... 56

Typical Network Transfer and Transfer Speed ..................................................................................... 56

Typical Boot Process .............................................................................................................................. 57

3



Appendix C: 2PXE Service Settings List .................................................................................................... 58

2Pint.2PXE.Service.exe.config ........................................................................................................... 58

Valid Configuration Combinations ..................................................................................................... 62

Appendix D: Command Line Install ............................................................................................................ 63

Installation on an X86 machine: ......................................................................................................... 63

Installation on an X64 machine: ......................................................................................................... 63

Mandatory MSI Properties ...................................................................................................................... 63

Optional MSI Properties .......................................................................................................................... 63

4



TL;DR version 1. 2PXE is the PXE server component, head over to the Quick Start guide on page 6 and get

going installing.

a. It can be installed in three flavours:

i. ConfigMgr integrated – On a ConfigMgr Distribution Point

ii. PowerShell Driven – Not requiring any infrastructure

iii. Referral only – For System Integrators

b. 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 and database logging and

a lot of other nice things.

3. You can use our stuff with our without BranchCache.

5



Change Log 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 ConfigMgr 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 ConfigMgr TS deployments

3. Updated boot screen

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

5. TFTP Server

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

b. Allows to link to single port for TFTP transfers

6. Registry Detection – No need to restart service when ConfigMgr 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:

a. Ability to inject files into RAM held WinPE image

b. Bug fixes

11. iPXE Network Boot Program Changes:

a. Included Syslog Client

b. TLS Updates to support IIS

c. Added Certificate commands for iPXE

d. Updated to latest build at time of compiling

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

6



Quick Install Guides Quick Install for Microsoft Configuration Manager Best scenario for this is to build a new DP and put 2PXE on there. If you insist on putting it onto an existing DP that has WDS/PXE on it, then just make sure that you disable that stuff first

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

Services are installed, remove the service or at least stop/disable it.

2. Ensure access to the SQL DB are right.

Add the service account (default is the machine account of the Distribution Point) to

the ConfigMgr_DViewAccess local group on the ConfigMgr SQL Server

3. Install the MSI interactively

a. Make sure you select ConfigMgr integrated, leave all values default

b. Let the installer do it’s thing

c. If you are using HTTP, and the DP is not in anonymous mode, you need to define an

iPXE Network Access Account.

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

Quick Install for the PowerShell Request Handler In this quickstart we will setup iPXE Anywhere for use with our PowerShell Request Handler, using your own WinPE Boot images. Also, to witness the majestic beauty of iPXE doing its thing, make sure

7



that you are BranchCaching, and that you have your WinPE Boot images in 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:

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

8



iPXE Anywhere introduction iPXE Anywhere is a network booting solution using the open source iPXE network boot program, which is an Open Source Project. http://ipxe.org/

2Pint Software adds the “Anywhere” part which consists of a the following two components:

• A proxyDHCP/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 extra

functionality.

These server components make the iPXE Network boot loader sing and dance by communicating with, and reporting on the iPXE client software. It does things like saving information to a database and communicating with ConfigMgr etc.

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

2Pint Software has also funded the implementation of several components in iPXE and is a driving factor behind iPXE development. One these addons is a Microsoft BranchCache client into the iPXE software itself, and that is still part of the open source iPXE which is available to everybody. See it like our sacrifice to the PXE gods.

http://ipxe.org/

9



How it Works –Simple Sample A machine requesting PXE boot will be picked up by the network boot server. The server will parse the request and send the corresponding boot file (BIOS or EFI) to the client. This file is very small and the handles low bandwidth situations really well.

Once the iPXE NBP is downloaded it will contact the 2PXE server over https to get the right action to execute (Lack of action will cause the NBP to exit out and continue the boot order.). Once an action is detected the server will send back the corresponding boot script to the client. The client will then execute this script, which typically involves loading a high level OS over HTTP. When the system needs to load the Windows PE boot image, it can transfer the content from local BranchCache peers instead of copying it from the server.

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

Undionly.kpxeSnponly.efi

Wimboot.binBoot.bcdBoot.wim

Variables.dat

HTTP BC file Download

DHCP Offer

TFTP of iPXE (undionly/snponly)

DHCP Request

Boot Info

BITS/HTTP With BranchCache

Install.wim

Powershell

ConfigMgr

iPXE Anywhere DBPower BI & PowerMap

Power BI & PowerMap

iPXE Anywhere Web Service

2PXE Server

Powershell

Bare

Met

al

iPX

E En

viro

nmen

t

Win

PE

Envi

ronm

ent

Dep

loye

d O

pera

ting

Syst

em

Figure 2 A typical iPXE Anywhere implementation

10



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 Fibre 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 hassle of re-flashing.

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.

Want to use BranchCache? It’s optional for iPXE Anywhere! If you are looking to use our PXE solution with BranchCache, but are not familiar with BranchCache, we recommend you to 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 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 work. 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 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 OSD documentation. This is available here: https://2pintsoftware.com/products/osd-toolkit/

You can also add BranchCache to WinPE at a later stage if it should be required.

Other System Management Tools iPXE Anywhere can get the right boot actions from other systems by a few different ways:

1. Configure the 2PXE PowerShell scripts to talk to the other system.

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

For more information on this please contact [email protected]

http://2pintsoftware.com/microsoftbranchcache

mailto:[email protected]

11



Main iPXE Anywhere Components The iPXE Anywhere solution consist of four major components:

iPXE Anywhere DatabaseThis is a database used for reporting and storing boot data. It can provide real time boot data, boot statistics as well as historic data analysis. Runs on any MS SQL including SQL Express Editions.

#!iPXEiPXE Network Boot ProgramThe open source iPXE boot loader is used to boot over HTTP and to take the appropriate actions from a low level boot. It can show menus, boot to iSCSI and includes a Microsoft BranchCache client. This is custom version tailored for iPXE Anywhere. For a full list of übercool iPXE capabilities please visit: http://ipxe.org

2PXE Server: proxyDHCP & TFTPThis is your replacement for WDS that runs on any system that has the .Net Framework and offers a full proxyDHCP and TFTP server. Detects what to boot, like WDS with PXE Service Point. Used to load iPXE or standard Windows Boot Loaders. This is what responds to the PXE boot.

iPXE Anywhere Web ServiceThis is the Web Service that the iPXE Network Boot Program communicates with in order to display menus, boot to WinPE, boot to iSCSI etc. The service is hosted as a traditional win32 service and doesn t require IIS. The web service connects to the iPXE Anywhere Database if available.

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

12



Detailed iPXE Anywhere Component Info This sections gives a little more background on the iPXE Anywhere components. The solution called iPXE Anywhere has a few major components.

PXE booting client

Web ServiceScript Handling

2PXE ServerDHCP Proxy & TFTP

DHCP Server(All mordern types supported)

Web Service DB (SQL)History and Reporting

SQL Reporting Services

WAN as low as 28kb/s 5% packet loss

BranchCache Client BranchCache Client

3. iPXE Requests configurationTCP/IP HTTP(S): 8050*

Web Server holding soureHTTP or HTTPS

Optional: iPXE connects to WS (if configured)TCP/IP HTTP(S) via 8051*

Optional: iPXE sends statusTCP/IP HTTP(S) via 8051*

3. iPXE requests payloadTypically TCP/IP HTTP(S) 80*,443*

4. Payload comes from Microsofot BranchCache clients

LocallyTCP/IP HTTP 80* (encrypted)

WSD UDP 3702

1. If using ProxyDHCP, UDP Port 40112. Client gets iPXE binary using TFTP

UDP Port: 69

* Indicates configurable port

1. DHCP RequestUDP Port: 67,68

iPXE

iPXE Anywhere 2PXE Server– The main PXE Server The 2PXE Service is a proxyDHCP server that responds to the initial PXE request. It has a proxyDHCP, TFTP and HTTP service built in to it. 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 would parse your request and hands out the iPXE network boot loader.

iPXE Network Boot Program (NBP) This is 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. Things that are enabled as a part of the default iPXE build are BranchCache etc. Having BranchCache enabled in a NBP enables you to load WinPE from peer BranchCache systems that have WinPE in their local cache.

iPXE Anywhere Web-Service (Optional) This is an optional Web Service that the iPXE Network Boot Program talks to, if configured by 2PXE. This server talks HTTP with the client and SQL to the SQL DB (optional). 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.

13



iPXE Anywhere SQL Database(s) (Optional) Part of the iPXE Anywhere Web Service, this database stores info about PXE booted computers and their capabilities. This database can be hosted on SQL Express if necessary as traffic to this database is very small. Connected to the iPXE Anywhere Web Service Database is a SQL Reporting Services Instance used for pulling reports.

Security Unlike most network booting products, iPXE Anywhere can be made 100% secure and protect any sensible data by using a mixture of technologies.

Authentication Before allowing the network boot, a user can be authenticated against a central repository like Active Directory on premises or Azure.

The credentials can be either sent as clear text protected by SSL certificates or using NTLM or IIS Digest Authentication for non SSL capable servers. iPXE Anywhere supports authentication of NTLM against Windows Authentication for ConfigMgr distribution points.

Using SSL ensures that there is no way unauthenticated users can access any media containing username or passwords. Unlike most network booting systems, the password can be provided at boot time, before loading any large image, freeing up boot time and making the system even more secure.

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

For maximum security, you should bind a public TSL certificate to iPXE that can be verified and is valid.

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 to be disabled on VM’s when using iPXE to build clients.

Custom Certificates We can support the use of third party certificates (Not iPXE nor 2Pint Software) certificates. Contact us at support@2pintsoftware if you require this.

14



Planning – The boring part 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, still using https. It will then do all the heavy lifting itself. There is of course extra functionality that you get from the iPXE Anywhere Web Service like; logging, reporting, integrating with StifleR, custom scripting and a heap of other options – limited only by the imagination!

Some examples of things that you ‘could’ do are ; integrating with the MDT database, checking and upgrading the BIOS version before OS install, presenting a special ‘technician’ menu with tons of diagnostic tools etc – the list goes on. 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 by just using 2PXE compared to integration it with iPXE Anywhere Web Service.

PXE Client PXE Client

iPXE Anywhere Database2PXE (proxyDHCP/TFTP/HTTP Server) 2PXE (proxyDHCP/.. Server)

TFTP

TFTPHTTP

HTTP

iPXE Anywhere Web Service

HTTPDHCP

DHCP

StifleR Integration From version 1.5 the 2PXE service can be integrated with StifleR using the SysLog feature. This feature requires the iPXE Anywhere Web Service as well as StifleR: https://2pintsoftware.com/products/stifler

For information about integration with StifleR, please review the iPXE Anywhere Web Service documentation.

https://2pintsoftware.com/products/stifler

15



DHCP scope options vs IPHelpers? Oh, this is a big debate. There can be several reasons of why to use the different options. Reasons to use DHCP options to control network boot could be:

1. Smaller footprint to deploy

2. Maybe no need to talk to the network team if you control DHCP?

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

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

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

2. Ability to control which machine to send PXE offers to

3. Easily allow different boot options to different clients

4. 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. The URL to contact is transferred in DHCP option #175 as a URL based of: https://<server.f.q.d.n>:<port>/. This is covered later in this document.

NOTE: The URL has to end with a trailing backslash.

Note: 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

Figure 4 shows how a Microsoft DHCP server giving out Option #66 and #67 can be used to boot a computer with iPXE.

PXE Client

DHCP ClientOption # 67 = Filename

Option 66 = ServerNameOption #66 is translated to SIADDR field in the DHCP packet by

Microsoft DHCP. Option #66 is not really used.

http://2pintsoftware.com/download/using-dhcp-to-control-wds-pxe-boots-for-bios-efi-clients/

16



2PXE can be booted using any kind of DHCP server, without using the built in proxyDHCP server, but that might 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

PXE Client

DHCP Server

DHCP Client

Proxy DHCP Server (2PXE)

17



2PXE Operational Mode – PowerShell, ConfigMgr or what? 2PXE can operate in three different modes:

1. Configuration Manager Integration – allows Microsoft ConfigMgr customers to use iPXE to

boot the boot media directly from the Distribution Point itself.

2. PowerShell Extension – allow non ConfigMgr 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 you shouldn’t typically have to set anything of this after the install. You can change the mode of operation after installation by changing the configuration values in the .config file.

For ConfigMgr Request Handler:

<add key="EnablePowerShellExtension" value="0" />

<add key="EnableSCCMExtension" value="1" />

<add key="iPXEWSOnly" value="0" />

For PowerShell Request Handler




Note:(Don’t confuse this with iPXE Anywhere Web Service PowerShell)

For redirect to iPXE WS only:




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 ConfigMgr integration, the 2PXE service must be installed on a ConfigMgr Distribution Point. You can create a new Distribution Point if you do not want to install it on your main distribution points. This is the recommended approach. You only need one small VM Distribution Point with the WinPE boot images distributed to it to cover the entire enterprise boot needs (when using iPXE with http and BranchCache.)

18



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 ConfigMgr 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 a bit crap, really..

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

Has to beon same

server

Has to beon same

server



PXE booting client

Web ServiceScript Handling

Web Service DB (SQL)History and Reporting

SQL Reporting Services

BranchCache Client BranchCache Client

3. iPXE Requests configurationTCP/IP HTTP(S): 8050*

Distribution Point

4: Optional: iPXE connects to WS (if configured)TCP/IP HTTP(S) via 8051*

4: Optional: iPXE sends statusTCP/IP HTTP(S) via 8051*

3. iPXE requests payloadTypically TCP/IP HTTP(S) 80*,443*

5. Payload comes from Microsoft BranchCache clients

LocallyTCP/IP HTTP 80* (encrypted)

WSD UDP 3702

1. If using ProxyDHCP, UDP Port 40112. Client gets iPXE binary using TFTP

UDP Port: 69

iPXE

Site Server

Management Point

Database

5: State Message (PXE Advert Flags)

3: Deployment Information (Full)SQL Read from ConfigMgr database

3: Deployment Info (Limited)

2PXE Installed on a single/mutiple DP s per requirements

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 in the installation directory. One script is for dealing with the initial request, determining if the machine should boot at all. This will be executed several times during the boot process, depending on the DHCP client of the PXE capable device. This script is called PowerShellExtensionAllowBoot.ps1. 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 if iPXE loaders are not used.

19



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 (ConfigMgr 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 on a

Distribution Point.

ConfigMgr – Distribution Point The ConfigMgr Distribution Point (DP) should ideally be dedicated to iPXE Anywhere PXE Booting. A small VM will suffice. If this is possible, also ensure that:

• BranchCache is configured as described above if using it.

• DO NOT install WDS or a PXE Service Point on this system, as it is not required. The 2PXE

server replaces that functionality and operate on the same ports (69 and 4011).

ConfigMgr – Security There are three settings required for working with ConfigMgr.

Enabling SQL login for the Service account as covered later in this section

If you are not using ConfigMgr 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 then using the iPXE Network Access Account.

Allowing Access to the ConfigMgr 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 ConfigMgr Site Server. Members in this group have the required access for using distributed views against the ConfigMgr 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.

20



2PXE Service Install The installer is an MSI, which adds a Windows service for hosting the proxyDHCP and the TFTP service. There is one installer for x86 and one for x64. Only pre-requisite is .Net 4.62.

Installation requires administrative rights, as does running the service as it creates BCD files which requires administrative rights.

There is now way around 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 be supplied to you. The license file will contain your company information and is used to validate the installation.

Figure 7 shows a dumb picture showing the content of the typical installation download. 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 ConfigMgr 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 Anyhere installers can be run by both manual and automated (silent) if required, please review the appendixes.

21



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: Select to use either the PowerShell, ConfigMgr or Refferal Handler Select the method for connection to ConfigMgr (SQL or via MP) Unknown machine support Use the embedded boot.sdi in WinPE Use the iPXE Loaders Use HTTP for iPXE to 2PXE comms (Recommended) The IP to bind to

22



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 wold like the 2PXE service to run, either LocalSystem, or using a specific domain account. Note that this account must have the ‘Logon as a Service’ right if it’s a domain (or local user) account.

23



Next, you can choose a port for the 2PXE HTTP service. The default is 8050 but you can change that here. Click the ‘Test Port’ button to test, and then click Next.

If you are using the ConfigMgr handler, enter the server name of the server that hosts the ConfigMgr 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.

24



In this screen you can configure account that will be used to connect to the ConfigMgr Database from the 2PXE service. We recommend that you use the same account that you specified for the 2PXE service, but you can choose a separate account if you wish. Don’t say we didn’t warn you.. 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.

25



We’re now ready to unleash 2PXE magic, so go ahead and click on Install, sit back and enjoy a cup of tea?

The installer will go about its business, “doing its thang as the kids would say”. If you asked what it was doing it would say, “Installing…” got it?

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

26



2PXE Post Installation Configuration 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 dll’s

• 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 2PXE service – ensure its started 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: Dont forget that F5 (refresh) button, the service might show as running but is really stopped?

The RemoteInstall Folder The RemoteInstall directory is created in the ProgramData folder. Under the 2Pint Software\2PXE folder as per below:

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

27



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 fiddling with.

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, where the WinPE boot images are accessed from. Images needs to be copied there to allow booting.

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 2BPXE creates a Windows Event log at startup of the service, unless it already exists. Note: This log is not removed as a part of the uninstallation. The log is located under the Application and Services Logs in the Event Viewer.

Adding Boot Images Important:The ConfigMgr integration handles its own Boot Image process and requires no configuration of boot images. If you installed the 2PXE server with ConfigMgr integration you can skip this section.

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

28



DHCP Configuration 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.

NOTE: If you are using IP helpers, this entire section can be ignored.

• You need to define the IP of the server to do the inital download from, using filename (Which

Microsoft sets as Option 66)

• You need to define the right filename to boot to, this is unique per hardware type and needs

to be defined used a rule or other DHCP server logic to server the right name. If you are using

IP Helpers, this is handled by the 2PXE service, but as we are now using DHCP server, the

DHCP server has to do this logic filtering for us.

• We need to define the HTTP (HTTPS by default) url to use for talking back to the 2PXE server

from iPXE. As we are using HTTPS, this needs to match the host header of the machine,

otherwise the TLS session will fail.

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

DHCP Name Field Microsoft Name Value Example Next-Server (SIADDRR)

Option 66 IP of the 2PXE server 192.168.10.30

Filename (Option 67) 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 2PXE FQDN URL https://server.fqdn:8050/ Note: This needs to be lowercase and also containing the port as well as ending with a slash “/”

Note: 2PXE version 2.6 and some early 2.7 builds used option #252 ton control the DNS name of the server, this has been changed to #175 to better work with some DHCP servers.

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 RIG10C20.2PSTEST1.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. Bypassing the need & requirement for IP Helpers on the routers.

https://server.fqdn:8050/

29



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 to boot from

• 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 right boot action -> Boot WinPE (Typically).

30



First things first - The Basics! PXE is a software standard, which makes room for developers to interpret things slightly different. There are also rooms for bugs and issues in the code that follows the standard, so don’t expect things to always 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, probably because they have a bug in their software. Read about that here:

a. Using the workaround mentioned in this guide seems to work fine though, please report any abnormalities.

b. The truth is, it works to boot machines using DHCP options, as long as you follow this guide.

3. PXE Option 60 is used when the client requests a PXE server, and also when the Server replies. They of course have different values depending where it’s being used.

4. We have tested this on a number of physical as well as virtual environments, so it seems to work fine, but don’t get upset if it doesn’t work for you.

5. 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? Is it magic? No, it’s not magic. It’s fairly straightforward, the client tells the server in the DHCP request which HW capabilities it has. It does this in the Option 60 that the request has in it, also in Option 93.

A sample string that is sent in the clients request looks like the following:

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

The server then picks up the Type Flag and responds back with the right boot loader file. This is why EFI and BIOS booting works from the same server when using IP Helpers and not with static DHCP options. The PXE server gets a copy of the DHCP request with the Option 60 set, reviews it, send back the right file (Also using DHCP Options) and the PXE Client then merges the DHCP offer and the offer from the PXE server. Hallelujah. When using DHCP options the PXE server never gets a say, so you have to move the smartness to the PXE server and 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 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.*

31



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.

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

If you want to read more, have a look here: https://www.rfc-editor.org/rfc/rfc4578.txt

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

So 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 were some confusion in the industry so some machines might report in as type 9 (EFI- x86-64) type, try upgrading the firmware on those.

DHCP Policy Rules for controlling boot files So, 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 most people don’t know about it.

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):

https://www.rfc-editor.org/rfc/rfc4578.txt

32



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

DHCP Policy Rules is available in Windows Server 2012 or above DHCP Policy objects were introduced in Windows Server 2012, so if you are on 2008, you cannot do these coolio thingies. Upgrade or go with a free Linux DHCP like ISC DHCP, your choice.

A dummy guide to how to set up and work with Microsoft DHCP Policies can be found here: https://technet.microsoft.com/en-us/library/hh831538.aspx

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. Not that hard to grasp, really.

Ok, let’s do it! Right click the IPv4 object in the DHCP console and select “Define Vendor Classes…” The following pic will give a hint of where it’s at:

The DHCP Vendor Classes pop shows up, hit the “Add…” button and the following little nice screen “New Class” is staring at us. Give the first Class a proper name, so that people that read this after you have left the company in the path of becoming a successful rock star get it as well. I Named mine “PXEClient (UEFI x64)”, the display name has nothing to do with anything, it’s just a name, like “Bob”. The description can contain anything as well, typically something sensible. That was the easy part, now it gets a wee bit tricky, but I will hold your hand.

https://technet.microsoft.com/en-us/library/hh831538.aspx

33



Ok, just under where it says “ASCII:” we can actually set the mouse pointer there and type stuff in. This is where it a bit tricky; things are case sensitive so it needs to look exactly like this:

PXEClient:Arch:00007

Exactly like that, nothing more, nothing less, like below:

Then we hit the OK button, and we get back to the “DHCP Vendor Classes” screen and we see our little entry added:

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 look as follows:

34



For the BIOS, it looks like this:

We should now have 3 new vendors classes to play with:

Creating new scope options Once our PXE booted client will reach iPXE, it needs a way to contact the 2PXE server using a FQDN URL. This is done via DHCP option #175. This option is not there by default, so we need to add it. Right click the IPv4 node in the console and select “Set Predefined Options...”

35



This will take you to the following screen, where you can select to add new settings, click the “Add...” button.

This then allows you to provided the following data, which is template data, and will define how the option should behave and look when being set as a DHCP scope option.

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 what it is used for.

36



Once you click “OK” you can fill in a default value, this is the value that administrators will see when trying to add the DHCP option to their scope, so it’s good to have a template string as below:

Click “OK” to close the Option dialog.

Creating new policy objects Now hurry over to the next node, the Policies node. Here we right click and get the “New Policy” option as the first one, select it.

37



Also, please note that you can create Policies from the Scope Node as well, they don’t have to be Server wide. It’s up to you. Server Policies are for all Scopes, makes sense. If server Policies win over Scope Policies, I would assume so but don’t really know. The DHCP Policy wizard appears, amazing, time to go crazy on the keyboard, Policy Name and Description:

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 we just created.

38



Keep in mind that there are x86 UEFI’s as well, so if you want to support them as well you need to define another Vendor Class with the value of PXEClient:Arch:00006. The 6 indicates x86 and 7 is x64, remember the table in the beginning of this article? Good.

Adding Conditions Click the “Next” button to take us to the Conditions, then hit the Add Button to add in a new Condition.

39



The AND/OR button doesn’t come in to play here as we will only have one rule. In the “Add/Edit Condition” page we select “Vendor Class” from the “Criteria” drop down, and select the “Equals” Operator. Then we select our PXEClient (UEFI x64) Vendor class that we just selected. Select it. The screen below shows how it’s supposed to be looking:

Ensure that the “Append Wildcard (*)” check box is selected. 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:

40



Moving on. Hit the Add button, again, yes I know it’s tiresome…. Puh!

Now the page should look like the one above, we have added a Value and we can press the “Ok” button. This takes us back to the Conditions page, listing our newly added Condition. Make sure that the little * is available after the Rule, this means the wildcard is in play. If you forget to click this before you hit the “Add” button you have to remove the Condition and then add it in again.

41



Hit the “Next” button and move on.

Depending on where you created the Policy there might be a question whether to limit the policy to a certain range, select No on that and move on by clicking Next after selecting No.

42



Defining Settings For The Rule This takes us to the DHCP settings, basically what to respond to the client if a machine matches the Criteria rule we created earlier. Scroll down to the Option 60, 66 and 67 entries.

Then we got the IP added, let’s move on to option 67.

43



Here we add the iPXE file of snponly_x64.efi, with the full path to it, releative from the ReomoteInstall directory. Ok, nearly there, hit the Next button and we can then see the summary. We are on the home stretch now…

Set DHCP option 175 to configure 2PXE DNS name Scroll down to find option 175, check the checkbox to enable the value to be set.

Put in the right value for the server as below, not the lowercase, port and ending “/” value.

44



Click OK to close the

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.

So the option 60 is added in the reply package, defined above as “PXEClient”, don’t confuse this with the Request Option 60 which we know is like “PXEClient:Arch:000…” etc. Now if you don’t have Option 60 to choose in the list you can go and add it following these instructions: https://msdn.microsoft.com/en-us/library/dd128762(v=winembedded.51).aspx

This setting forces the PXE client to use port 4011 when communicating to the PXE server, as the DHCP port is in use by the DHCP server.

The Summary Page You can now complete the wizard. Hit the “Finish” button and take a well-deserved break. After that, make sure the Policy is in the “Enabled” state and listed like below:

https://msdn.microsoft.com/en-us/library/dd128762(v=winembedded.51).aspx

45



If you are really keen, then add in another option for x86 and x86x64 EFI as well as BIOS machines.

Use the table in the beginning of this article as the base for the values, if you can’t figure it out, then maybe it’s time for that rock star career sooner rather than later? Or ping us an email and we will come and help you.

So what we have now looks like this:

This of course means that no other machines than 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 are good to go. There are not many x86 UEFI machines around anymore, so you might get away with not setting that up.

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

Maybe not the clearest, so having different rules for different HW types could be a cleaner solution, but adds overhead as more rules needs to be processed.

46



If you want you can also create 3 Policies and then let the policies decide which options that are set, this might be the most efficient way. Like the pic below:

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

Believe it or not, you are now done, go ahead and try it out, if it’s not working we have some videos on or site on how to set it up that you can follow!

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.

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. if you want, controlling it on a per HW type, regardless of capabilities. Let us know if that is interesting and we will write about that as well.

47



Firewall Considerations The 2PXE and iPXE Anywhere web service both potentially requires changes to the firewall configurations unless 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.

What UDP TCP DHCP & TFTP 67*, 691, 4011*, Random2 2PXE HTTP Traffic 8050* iPXE Anywhere 8051*

The following steps explain the UDP and TCP ports that are 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 ConfigMgr 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.

1 The TFTP port can be locked to only use port 69 as the sending port. Note: This can degrade performance. 2 Random ports from 64001 through 65000*, to establish a session with the server for TFTP

48



The following rules are automatically created when 2PXE starts:

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


67 ALL

2Pint Software 2PXE – PXE


4011 ALL

2Pint Software 2PXE – HTTP

TCP Any 8050 ALL

49



Appendix A: Troubleshooting If something is not right, ensure that the settings in 2PXE is set correctly. Edit the 2Pint.2PXE.Service.exe.config file as follows

For ConfigMgr integration:

1. Stop the 2PXE Service if it is started

Enable ConfigMgr Extension by setting EnableSCCMExtension to “1”

Disable the PowerShell Extension by setting EnablePowerShellExtension to “0”

Disable the referral only mode by setting the bla to bla

Set EnableSCCMSQLConnection to “1”

Set ConfigMgrSQLConnectionString to the right one, basically you need the Server

FQDN and the ConfigMgr DB name in there.

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

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

7. Optional: Enable Unknown Machines support by setting

EnableSCCMUnknownMachinesSupport to “1”

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

For PowerShell integrated scenarios:

1. Stop the 2PXE Service if it is started

Enable the PowerShell Extension by setting EnablePowerShellExtension to “1” Disable the ConfigMgr Extension by setting Set EnableSCCMExtension to “0” Disable the referral mode Enable iPXE Boot loaders by setting EnableiPXEBootLoaders to “1”. a. Disable the 2PXE HTTP server by setting RunHttpServer to “0”. b. 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 got 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 got the right MIME types setup. Use the PowerShell below or the good old GUI – whatever suits!

3. Edit the 2PXE PowerShell files and make sure you return 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

50



Running the service interactively You can run the service directly from either a console or starting it by executing the executable from Windows Explorer. Ensure that the service is stopped before doing this. This starts the service in a command prompt window, allowing for simple troubleshooting as you can see the boot request roll through the 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 will run under the user executing it and not the service account (SYSTEM by default) which could 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 a single sysem.

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 [email protected] 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.

mailto:[email protected]

51



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 blue initial splash screen appear you can press the ‘c’ key on your keyboard. You have only on second to press it so might be a good thing to try the ‘c’ key until the console appears.

Once at the console you can then type commands like ’help’ etc to get a list of commands available.

You can can also review all available built in console variables by running ’config’.

52



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

Invalid Configuration File An invalid configuration file will cause the service to fail to start. Running this in user interactive mode will display which parameters that is not valid.

The picture above shows an invalid section for the iPXEAnywhereWebServiceIP setting, it does not contain the closing /> sections and does not close the XML parameter correctly.

As noted above, the service will refuse to start with a pretty useless error message. This happens

before any logging is available so it’s hard to troubleshoot.

Running the service in interactive mode (by just launching the 2Pint.2PXE.Service.exe as Administrator !UAC) you get a pretty clear view of the issue.

53



Failing with an invalid boot.bcd file When bootmgr.exe cannot find or read the BCD file:

File: \Boot\BCD

Status: 0xc000000f

Info: An error occurred while attempting to read the boot configuration data.

Likely casued by: The

Failing to find the boot.sdi file Status: 0xc000000f

Info: The boot selection failed because a required device is inaccessible.

Likely caused by:

1. Not finding the boot.sdi file as it’s not included in the image while the UseEmbeddedBootSDI

setting is set to “1”.

Figure 10 shows the 0xc000000f error caused by a missing boot.sdi file.

Connection Reset 0f0a6095 When the connection port is not answering:

Likely cause, you have enabled ConfigMgrSQL integration but not enabled the HTTP server. This is not a supported scenario at the moment. Enable the 2PXE HTTP server by setting the RunHttpServer config value to “1”.

54



Not enough RAM in target computer The following can occur if the target machine does not have enough RAM. Make sure that machines booted with 2PXE has at least 1024 MB of RAM. (More can be needed if the image contains x64 WinPE with .Net framework and a large number of drivers.)

Slow first boot with PowerShell Since the PowerShell script generates the BCD files on the fly, unless already created the first initial boot can timeout and go into retry mode as the creation of the BCD file takes too long. This is typically the case when not using the HTTP server and having the iPXE Boot Loaders enabled.

55



Depending on how many image BCD files are being returned it can take a retry or two before the machine is prompted with a menu or booting to an image. The second attempt will not go into retry as the BCD files will be reused. Since starting and stopping the service causes the temporary files to be cleaned out this is likely to happened in labs where starts and stops of the service is common.

To avoid this, enable the HTTP service in the configuration file.

To aggressive filtering If you filter to heavily with the optional filterings like

<add key="SCCMHideHiddenPXEDeployments" value="1"/>

<add key="SCCMOnlyShowCategories" value="OS Deployment, Windows 10 Deployment, Some Other Category"/>

<add key="SCCMStripCategories" value="Skip Me, Skip me as well"/>

You can get to the point that even if the machine was booted to iPXE that no valid TS applies. The following screen will then be visible:

56



Appendix B: Further Reading Typical Network Transfer and Transfer Speed For a typical EFI boot, without the optional boot fonts, a total of 314KB of data is transferred per booting device. A 99,9% reduction from the standard TFTP protocol. All data sizes in Kilobytes. Note that the file version sizes are averages as some builds might include debug information and/or troubleshooting tools like nslookup and ping etc.

File Name Size Hash size Purpose snponly.efi 150 N/A EFI iPXE bootloader, using UNDI, can’t be use

BranchCache as its the start of the process undionly.kpxe 75 N/A BIOS iPXE bootloader, using UNDI, can’t be use

BranchCache as its the start of the process WimBoot 35KB 1KB WinPE boot loader Boot.bcd 12KB N/A Typically about +8KB per added Boot Scripts 1-2KB N/A Auto generated Variable.dat 22KB N/A Transferred using TFTP from ConfigMgr binaries in

WinPE Windows PE 300-500MB 150-300KB Size depends on drivers, optional components etc.

The total transfer of data is then typically the iPXE boot loader, then wimboot (hashed or not) and the boot.bcd file + some iPXE scripts to hold it all together. Then we transfer the hash of the WinPE image which then does the TFTP download using TFTP.

Transfer Kilo Bytes Comment Total BIOS WAN transfer with BranchCache ~275KB

Total EFI WAN transfer with BranchCache ~350KB

Reduction in percentage of WAN traffic -99.9% Yeah, it’s that awesome!

The following speeds have been noted in our labs downloading over a poor link, with BranchCache support 5 clients serving the WinPE image and on GigaBit network without BranchCache. The test speeds are with EFI capable devices and for downloading a 300MB WinPE image only.

Bandwidth Up/Down/%Packet Loss Speed (mm:ss) Reduction from TFTP 56/33.6 Kb 2% (Modem) 02:00 Are you kidding me? 128/512 Kb 2% (ISDN/DSL Type) 00:30 Keep dreamin baby! 1.544Mb/s (Typical T1) 00:10 Still aint happening! 10Mb/s 1% Loss 00:07 On a sunny day? Right! 100Mb/s 0,5% Loss 00:07 About 10 mins 1Gb/s 0% Loss with BranchCache 00:06 Down 1-5 mins 1Gb/s 0% Loss without BranchCache 00:02 Down 1-5 mins

57



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

a. Typically Option 60 and Option 97 is 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 transfer of boot file using TFTP of file specified in merged DHCP offer

(iPXE) a. 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 into 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.

7. TFTP of the boot loader finish 8. PXE ROM loads iPXE 9. iPXE initializes and does a whole lot of magic before launching the embedded script. 10. Embedded script checks that all seems to be in order and then process the logic.

a. iPXE contacts the 2PXE server, this is done by using DHCP option 175 #for the 2PXE server which is the full URL to the 2pxe server like: https://rig10c20.2pstest1.local:8050/

11. iPXE sends up heaps of info about the client to the 2PXE server over https 12. 2PXE process the data and depending on the configuration settings it executes a

PowerShell script or talks to the ConfigMgr Database for boot actions. 13. An iPXE boot script is sent down to the client which executes it 14. iPXE executes the script and loads transfers the corresponding files listed in the boot

script, typically booting a WinPE image. 15. Client downloads required files using HTTP with BranchCache support from the source

a. Certificates, so that we can trust the 2PXE server from WinPE b. iPXEWinPEClient.exe, which sets up the right certificates and environment c. Wimboot as the kernel to load the WinPE image

i. Boot.sdi as the NTFS virtual drive is included in the boot.wim image ii. Optional boot fonts are used from the boot.wim image

d. Bcd file is created dynamically by the 2PXE service e. WinPE boot.wim file, typicall from the Distribution Point f. A new WinPEShl.ini which replaces the original one, executes the

iPXEWinPEClient.exe as the first step 16. The WimBoot kernel boots the downloaded WinPE image using the bcd data 17. WinPE Client boots WinPE and executes the iPXEWinPEClient.exe who starts the

networking, talk to iPXE Anywhere Web Service to report status, and then hand back which starts the custom process or the ConfigMgr task sequence engine.

58



Appendix C: 2PXE Service Settings List All 2PXE Service configuration is done through the application.config file (2Pint.2PXE.Service.exe.config) 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.


EnableSCCMSQLConnection Specifies to use a SQL connection to the ConfigMgr 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 ConfigMgr PXE Service Point and can only return one boot image per client. So SQL connection is recommended for ConfigMgr integration. Then you get the full fancy menu ☺


ConfigMgrSQLConnectionString Connection string to the ConfigMgr 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?


https://msdn.microsoft.com/en-us/library/vstudio/system.data.sqlclient.sqlconnection.connectionstring(v=vs.100).aspx

https://msdn.microsoft.com/en-us/library/vstudio/system.data.sqlclient.sqlconnection.connectionstring(v=vs.100).aspx

59



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


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.


iPXEF12PromptTimeout How long is the timout 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 ConfigMgr images, so then 2PXE always uses embedded boot.sdi file regardless of this setting. For non-ConfigMgr 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".


wimbootParams Specifies the command line to wimboot, possible paramteres are: gui, pause, pause=quiet, rawbcd, index=x For details see: http://ipxe.org/appnote/wimboot_architecture

Value: ”gui”

http://ipxe.org/appnote/wimboot_architecture

60



EnableiPXEAnywhereWebService Specifies to use iPXE Anywhere Web Service.


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.


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.


61



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.


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.


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.


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.

62



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:

Enable PowerShell Extension

Enable SCCM Extension

Enable SCCMSQL Connection

Enable iPXE BootLoaders

Run http Server

Valid Configuration

✓ ✓ ✓ Yes ✓ ✓ Yes ✓ Yes ✓ ✓ Yes, but http is not used

✓ ✓ ✓ ✓ Yes ✓ ✓ ✓ No ✓ ✓ ✓ Yes ✓ ✓ No ✓ ✓ Yes, but http not used ✓ ✓ ✓ Yes

Table 1 shows the different valid options, if you are unsure of your scenario, pleae contact [email protected].

63



Appendix D: Command Line Install NOTE: Because there are many options to configure via the command line install, we have created a PowersShell Script to use as a ‘wrapper’ for the MSI Install. Instructions for use are found in the PowerShell Files included in this release.

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 ConfigMgr 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 ConfigMgr 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 ConfigMgr Database Server

RUNTIME_DATABASE_NAME=CONFIGMGR_xxx ConfigMgr 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.

64



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 ConfigMgr

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” NOT ENABLED IN THIS RELEASE

IPXEANYWHEREWEBSERVICEURI="<url>" NOT ENABLED IN THIS RELEASE

65



Documents

iPXE Anywhere 2PXE Server Manual 2.7 · 4. Pure PowerShell setup got revamped to work again with HTTPS communication 5. iPXE -> 2PXE TFTP communication methods are no longer supported,