> 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/troubleshooting/custom-entries-in-winpeshl.ini.md). # Custom entries in WinPEShl.ini Using custom entries in WinPEShl.ini to run custom actions before or after the machine boots. ### The default setup 2PXE writes a new WinPEShl.ini file into the %ProgramData% directory each time it starts: one for x86 boot images and one for x64 boot images. {% hint style="danger" %} **Configuration Manager compatibility** The ConfigMgr-specific examples and progress UI references on this page are retained for reference only. Configuration Manager integration is not currently supported by 2PXE Server 4.0. {% endhint %} **NOTE:** The WinPEShl.ini file is only transferred by default if the underlying configuration requires it. This is normally only the case for ConfigMgr-related environments, and not for other types of custom iPXE Anywhere Web Service scenarios. However, the same file can be retrieved and injected if required. The following text is written into WinPEShl.ini by default for an x64 boot image (the x86 file uses different paths): `[LaunchApps]`\ `%SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe` The x86 file with its default paths: `[LaunchApps]`\ `%SYSTEMDRIVE%\sms\bin\i386\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %SYSTEMDRIVE%\sms\bin\i386\TsBootShell.exe` The first command initializes TsProgressUI.exe in WinPE to show the ConfigMgr progress UI. This is done so that the second command, iPXEWinPEClient.exe, can show progress. The second command initializes the network drivers in a way that guarantees that the network is available by the time the command exits. This seems like a trivial task, but it is harder than most people realize, because WinPE environments often include extra drivers for special hardware, which can be complicated to sort out. The third command runs iPXEWinPEClient.exe again, but skips the network initialization, so that it only contacts the iPXE Anywhere infrastructure to report back and get any command line required from the server-side PowerShell script in the iPXE Anywhere Web Service. The fourth command runs TsBootShell.exe, which starts the whole OSD process. ### Custom example to troubleshoot with cmd.exe as first step If you want to modify the content of these WinPEShl.ini files, you can edit the files directly in 2PXE's %ProgramData% directories, but the changes only last until the service restarts. To make the change permanent, change the **WinPEShlConfiguration\_x64** and **WinPEShlConfiguration\_x86** settings in the **Configure 2PXE** configuration editor (see [Configuring 2PXE Server](/2pxe-server/4.0/configuration/2pxe-config-file.md)). These settings are only shown when **Show advanced** is turned on. Each setting is a multi-line text box. Enter the WinPEShl.ini content exactly as it should appear in the file, one command per line. After making changes, click **Verify** and then **Save**, and restart the "2Pint 2PXE Server" service when prompted. The following example adds a step to **WinPEShlConfiguration\_x64** that launches cmd.exe before TSBootShell.exe starts: ``` [LaunchApps] %SYSTEMDRIVE%\sms\bin\x64\TsProgressUI.exe,/register:winpe %windir%\system32\wpeutil.exe,InitializeNetwork %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %windir%\system32\cmd.exe /c start "Paused TS: Close this to continue" /wait cmd %SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe ``` The corresponding entry for **WinPEShlConfiguration\_x86**: ``` [LaunchApps] %SYSTEMDRIVE%\sms\bin\i386\TsProgressUI.exe,/register:winpe %windir%\system32\iPXEWinPEClient.exe,/NetworkInit %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit %windir%\system32\cmd.exe /c start "Paused TS: Close this to continue" /wait cmd %SYSTEMDRIVE%\sms\bin\i386\TsBootShell.exe ``` Note that the x86 and x64 settings match the architecture of the machines booting, NOT the server itself. ## Custom Example to use with TSBackground When using Onevinn's (Johan Schrewelius's) TSBackground app, the syntax needs to be changed slightly to prevent it from crashing. For more information about TSBackground, see . \[LaunchApps]\ %windir%\system32\wpeutil.exe,InitializeNetwork\ %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit\ x:\sms\pkg\sms10000\TSBackground\TSBackground.exe Given the above, the following would be the **WinPEShlConfiguration\_x64** value: ``` [LaunchApps] %windir%\system32\wpeutil.exe,InitializeNetwork %windir%\system32\iPXEWinPEClient.exe,/SkipNetworkInit x:\sms\pkg\sms10000\TSBackground\TSBackground.exe ``` --- # 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/troubleshooting/custom-entries-in-winpeshl.ini.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.