> 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/configuration/2pxe-config-file/deployr-request-handler.md). # DeployR Request Handler The DeployR request handler PXE boots devices into DeployR boot images. Instead of using scripts or a Configuration Manager database, 2PXE finds the DeployR server through the StifleR infrastructure service and builds its boot menu from the boot images that DeployR has generated. ## Requirements * **Integration mode** set to **DeployR**. * **Use Infrastructure** turned on, with **StifleR web service URL** pointing to the StifleR server that DeployR is registered with (**Infrastructure settings**). 2PXE uses the infrastructure service to find the DeployR server. If more than one DeployR server is registered, 2PXE uses the approved server that is marked as the default. * **EnableiPXEBootLoaders** and **RunHttpServer** both turned on (both are on by default). If either is turned off, 2PXE does not boot the device, and writes an event to the 2PXE event log saying that the DeployR request handler requires iPXE boot loaders. ## How it works 1. 2PXE asks the StifleR infrastructure service for the DeployR server's URL and the list of DeployR boot images. The list is cached for 15 minutes. If the request fails, 2PXE keeps using the previous list (if it has one) and tries again after one minute. If no boot images are returned, it also checks again after one minute, so newly generated boot images appear quickly. 2. The device boots into iPXE. The user must press the boot key (**AcceptBootKeyEFI**/**AcceptBootKeyBIOS**) within **iPXEF12PromptTimeout**, otherwise the device exits to its next boot device. 2PXE then shows a boot menu. The menu lists **Boot to** *name* for each DeployR boot image that has been generated and matches the device's architecture (x86, x64 or ARM64), followed by **Reboot Computer** and **Exit to next boot device**. 3. When a boot image is selected, iPXE downloads it directly from the DeployR server: * **Windows (WinPE) boot images** are booted with wimboot, using the **wimbootParams** setting. * **Linux (Fedora) boot images** are booted with shim, the Linux kernel and initrd, and the image's `squashfs.img` as the root file system, using the **KernelParams** setting. If 2PXE cannot find a DeployR server, or DeployR has no boot images, 2PXE writes an event to the 2PXE event log and does not boot the device, so the device continues with its next boot device. ## Custom task sequence variables 2PXE can also supply custom task sequence variables, using the add variables script (by default `PowerShellExtensionAddVariables.ps1` in the 2PXE installation folder). The script receives the same `$SessionData` values as the boot images script, and returns a `Zipper.Zpxe.WCFServer.VarDataObject` whose `VarInfo` property is a hash table of variable names and values: ```powershell param($SessionData) $VarDataObject = New-Object Zipper.Zpxe.WCFServer.VarDataObject $variables = @{} $variables.Add("MyCustomVariable", "TheActualValue") $VarDataObject.VarInfo = $variables $VarDataObject ``` DeployR requests these variables from 2PXE (with a `POST` to `/2PXE/var` on the 2PXE web service) and adds them to the task sequence, unless 2PXE is integrated with the iPXE Anywhere Web Service. ## Settings used by the DeployR request handler | Setting | Description | | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **DefaultMenuItemId** | The menu item selected by default. Set it to the full ID (GUID) of a DeployR boot image, which you can copy from the boot image's address in the DeployR dashboard, or to `exit` (the default) or `reboot`. | | **EnableMenuCountdown** | How long, in milliseconds, the menu waits before choosing the default item. `0` waits until an item is selected. | | **AcceptBootKeyEFI**, **AcceptBootKeyBIOS**, **AcceptBootTextEFI**, **AcceptBootTextBIOS**, **iPXEF12PromptTimeout** | The key the user presses to boot from the network, the prompt text, and how long (in milliseconds) to wait for it. | | **KernelParams** | The Linux kernel parameters used for Linux boot images. | | **wimbootParams** | The wimboot command line used for Windows boot images. | | **EnableDeployRDebugLogging** | Turns on debug logging in the DeployR client, by adding a debug logging configuration file to the boot image when it is downloaded. | | **Add variables script** | Path to the PowerShell script that returns custom task sequence variables. See above. | | **DefaultExitString** | The iPXE command used when **Exit to next boot device** is selected or the menu fails. | These settings are only shown when **Show advanced** is turned on. See [Configuring 2PXE Server](/2pxe-server/4.0/configuration/2pxe-config-file.md) for descriptions of all settings. --- # 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/configuration/2pxe-config-file/deployr-request-handler.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.