> For the complete documentation index, see [llms.txt](https://documentation.2pintsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.2pintsoftware.com/2pxe-server/4.0/planning/planning-your-implementation.md). # Planning Your Implementation ## With or without the iPXE Anywhere Web Service? The 2PXE server can operate on its own, without the iPXE Anywhere Web Service (it still uses HTTPS), but then it must do all the heavy lifting itself. The iPXE Anywhere Web Service offers a lot of extra functionality, such as logging, reporting, integration with StifleR, custom scripting, and many 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 the OS is installed * Presenting a special "technician" menu with diagnostic tools Because the iPXE Anywhere Web Service is driven by a PowerShell scripting interface, the possibilities are nearly unlimited. The following high-level schematic shows the setup when using only 2PXE, compared to integrating it with the iPXE Anywhere Web Service. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/ITTyxxFuffB4kCqj780O/schematic.png) ## StifleR Integration The 2PXE service can be integrated with StifleR using the SysLog feature. This feature requires the iPXE Anywhere Web Service and StifleR: For information about this integration, see the iPXE Anywhere Web Service documentation. ## DHCP Scope Options vs IP Helpers Reasons to use DHCP scope options to control network boot: 1. Smaller footprint to deploy. 2. Maybe no need to talk to the network team. Reasons not to use DHCP scope options to control network boot: 1. No ability to use DHCP to set the right boot loader. 2. DHCP changes can be hard to tweak and test, depending on the DHCP vendor. 3. Difficult to directly control which machines receive PXE boot offers. 4. More administration needed to allow different boot options for different clients. 5. No need to talk to the DHCP team. When using DHCP options, there is no way for the iPXE NBP to automatically detect the option values from the 2PXE server. Instead, the URL for the client to contact is configured through DHCP option 175. {% hint style="info" %} **NOTE:** DHCP Scope Option 175 contains the 2PXE URL, which must be in lowercase and end with a trailing slash: `https://:/` {% endhint %} The following diagram shows how a Microsoft DHCP server that gives out options 66 and 67 can be used to boot a computer with iPXE. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/AVvUGwVncJqlOLvj6MpS/dhcp_vs_iphelper.png) 2PXE can be booted using any kind of DHCP server, without using the built-in proxy DHCP server, but this does not work well in all configurations. To manage this effectively when you have both BIOS and UEFI machines, a smart DHCP server is recommended, such as ISC DHCP on Linux, or the DHCP server in Windows Server 2019 or later in Microsoft environments. If your DHCP server is not smart enough to respond with the right information, you can still use 2PXE by using IP helpers to manage the boot requests instead. The image below depicts a PXE boot using the 2PXE proxy DHCP service. ![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/rhzbXOSw8U7ddZWsHtx5/2PXE-PXEDHCPDiagram.jpg) For general DHCP design guidance and detailed configuration instructions, see [DHCP Configuration](/2pxe-server/4.0/configuration/dhcp-configuration.md). The detailed guides are available under [Using DHCP Scope Options](/2pxe-server/4.0/configuration/dhcp-configuration/using-dhcp-scope-options.md), including [Creating DHCP Scope Options](/2pxe-server/4.0/configuration/dhcp-configuration/configuring-dhcp-scope-options.md) and [Manually Creating DHCP Scope Options](broken://pages/wmYiQV5yJt6S59xtf7AC). ## Which 2PXE Operational Mode? {% hint style="danger" %} **Configuration Manager compatibility** The Configuration Manager integration mode described below is not currently supported by 2PXE Server 4.0. This information is retained for reference only. {% endhint %} 2PXE can operate in four different modes: 1. **Configuration Manager Integration –** allows Microsoft Configuration Manager customers to use iPXE to boot the boot images directly from the Distribution Point. 2. **PowerShell Extension –** allows customers who do not use Configuration Manager to boot WinPE images over HTTP or TFTP, using iPXE for HTTP downloads, or TFTP with regular boot loaders. (Do not confuse this with the PowerShell capability of the iPXE Anywhere Web Service.) 3. **DeployR Integration –** boots DeployR boot images (Windows PE or Linux), finding the DeployR server through the StifleR infrastructure service. 4. **Referral (WebServiceOnly) –** redirects all requests to the iPXE Anywhere Web Service, which also handles licensing. Used by System Integrators to point to an already existing 2PXE infrastructure. Each mode is handled by what is called a "request handler". For more information about each request handler and how to configure it after installation, see [Configuring the 2PXE Request Handlers](/2pxe-server/4.0/configuration/2pxe-config-file/configuring-the-2pxe-request-handlers.md). ## Planning a Proof of Concept (POC) It is recommended that a 2PXE POC be conducted in a test lab environment. If a test lab is unavailable, a POC can be executed in a production environment with minimal risk, but it should be limited to specific subnets from which you want clients to boot. The objective for a 2PXE POC is to demonstrate how 2PXE can provide iPXE boot services to network clients. It is important that the POC is driven by clear requirements. These requirements should be clearly defined and include test plans for validation. ### Before the POC It is recommended that all 2Pint Software components are installed and verified in a separate lab environment before they are implemented in a production environment. Once tested and verified in the lab, they can then be tested in the production environment. If a test lab is unavailable, the POC can be executed in a production environment in a controlled manner. Review the [Prerequisites](/2pxe-server/4.0/planning/prerequisites.md) and [Planning Your Implementation](/2pxe-server/4.0/planning/planning-your-implementation.md) information before installing 2PXE. {% hint style="info" %} PXE is a broadcast-based network protocol. On any given subnet, it is important that only one PXE server services clients that attempt to PXE boot. {% endhint %} ### Lab Testing Environment A lab environment is typically the best environment to test 2PXE. If possible, the server on which you plan to install the 2PXE service should be on the same subnet as the clients you plan to PXE boot. This is because PXE is a broadcast-based protocol that is not routable. For PXE booting clients to reach a PXE server on another subnet, [IP Helpers](/2pxe-server/4.0/configuration/dhcp-configuration.md) have to be added to your router configuration, or [DHCP Scope Options](/2pxe-server/4.0/configuration/dhcp-configuration/using-dhcp-scope-options.md) must be added to your DHCP scope to redirect clients to the IP of the PXE server. All major virtualization platforms, such as Hyper-V and VMware, support PXE booting clients, but using physical client hardware that represents the makes and models you support is a far more conclusive test. ### Production Testing Environment It is possible to test 2PXE in a production environment, but as mentioned above, it is important to only test on subnets that will not be impacted by installing a new PXE server. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://documentation.2pintsoftware.com/2pxe-server/4.0/planning/planning-your-implementation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.