> 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/overview.md).

# Overview

Visit the 2Pint Software support Knowledge Base, which contains many useful troubleshooting articles.

If something is not right, ensure that the settings in 2PXE are set correctly. Open the **Configure 2PXE** configuration editor (see [Configuring 2PXE Server](/2pxe-server/4.0/configuration/2pxe-config-file.md)), turn on **Show advanced**, and check the following values for your integration type.

#### For Configuration Manager integration:

{% hint style="danger" %}
**Configuration Manager compatibility**

The Configuration Manager troubleshooting steps on this page relate to an integration that is not currently supported by 2PXE Server 4.0. They are retained for reference only.
{% endhint %}

1. Set **Integration mode** to **MEMCM**.
2. Set **SQL Server configuration method** to **ServerInstanceAndDB** and enter the **SQL Server instance** and **SQL Server database** of the Configuration Manager database. If you need a custom connection string, choose **Advanced** and enter the **SQL Server connection string** instead.
3. Make sure **EnableiPXEBootLoaders** is turned on.
4. Make sure **RunHttpServer** is turned on.
5. Optional: Turn on **Enable ConfigMgr unknown machine support**.
6. Click **Verify** and then **Save**, and restart the service when prompted. If the problem continues, stop the service and run it interactively as described below.

#### For PowerShell integration:

1. Set **Integration mode** to **PowerShell**.
2. Make sure **EnableiPXEBootLoaders** and **RunHttpServer** are turned on. The built-in 2PXE web service serves wimboot, boot.sdi and the boot images from the RemoteInstall folder, so IIS is not needed.
3. Turn off **UseEmbeddedBootSDI** if you do not have the boot.sdi file integrated in the boot image.
4. Copy your boot images to the `Sources` subfolder of the RemoteInstall folder (by default `C:\ProgramData\2Pint Software\2PXE\RemoteInstall\Sources`), one folder per boot image.
5. Edit the 2PXE PowerShell scripts and make sure they return the names of those folders. See [PowerShell Request Handler](/2pxe-server/4.0/configuration/2pxe-config-file/powershell-request-handler.md).
6. Make sure the firewall allows incoming TCP traffic to the 2PXE web service (ports 8050 and 8049). 2PXE creates these rules automatically; see [Firewall Considerations](/2pxe-server/4.0/planning/firewall-considerations.md).
7. Click **Verify** and then **Save**, restart the service when prompted, and check the event logs for errors.

### Running the service interactively

Ensure that the service is stopped before doing this.

You can run the service directly from a console, or by double-clicking the executable in Windows Explorer. This starts the service in a command prompt window, which makes troubleshooting simple, because you can watch each boot request as it is processed.

When running in interactive mode, all debug logging is sent to the console window. This greatly helps when you run into issues, or when you want to showcase the technology. Note that the console runs under the account of the user running it, not the service account (SYSTEM by default), which can lead to access violations.

Note also that booting can be much slower, because writing to the console takes longer than the actual actions. This mode should only be used for testing or troubleshooting, and is best used while booting a single system.

As an example, the following screen shows the executable running in interactive mode, failing to bind to the HTTP port because the port is already being used by another process (the 2PXE service itself).

![](https://content.gitbook.com/content/FSXaKC2Zqibd4KXt4dvD/blobs/2e1scWcUPpkq0ZiheYpU/58.png)

### Logs and events

2PXE Server 4.0 writes its logs to Windows event logs instead of a log file. In Event Viewer, they are under **Applications and Services Logs** > **TwoPintSoftware** > **iPXEAnywhere.2PXE**:

| Log                                        | Contents                                                                                                                                                                                                  |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Main** > **Operational**                 | Service startup, configuration, licensing, certificate and boot handling events, including errors and warnings. Start here.                                                                               |
| **Main** > **Debug**                       | Detailed events about each request. Turned off by default.                                                                                                                                                |
| **Audit** > **Operational**                | One event for each PXE decision: which request handler responded to a device, or aborted or ignored it, the boot file sent to it, and requests ignored because **Respond to PXE requests** is turned off. |
| **Logger** > **Operational** and **Debug** | Messages from the built-in web service and the .NET components it uses (shown with a `LOGGER:` prefix).                                                                                                   |

To turn on the Debug log:

1. In Event Viewer, select **View** > **Show Analytic and Debug Logs**.
2. Right-click **Main** > **Debug**, and select **Enable Log**.

Or, from an elevated command prompt:

```
wevtutil sl "TwoPintSoftware-iPXEAnywhere.2PXE-Main/Debug" /e:true
```

The Debug log is very detailed, so turn it off again when you have finished troubleshooting (`/e:false`). When you send a support request, export the relevant logs (right-click the log, and select **Save All Events As**).

### Helpful Logs & Files:

The following files in WinPE are helpful for troubleshooting issues on the client side. If you send a support request, have them ready to send.

* **smsts.log** in x:\Windows\Temp\SMSTSLog\\
* **2PSiPXEWinPEClient.log** in x:\Windows\Temp
* **smstftp.log** in x:\Windows\Temp
* **ipxews.ini** in x:\Windows\System32

### Errors & Issues

There are many things that can go wrong in 2PXE. If the machine is not booting, it is likely that a configuration setting is invalid. Check the [valid configuration combinations](/2pxe-server/4.0/configuration/2pxe-config-file.md#valid-configuration-combinations), and if you cannot find the issue, turn on the Debug log (or run the service interactively), try to boot an image, and send the exported event logs or console output to 2Pint Software support. Include any PowerShell scripts in the email, along with screenshots or an export of your settings from the **Configure 2PXE** configuration editor. Email the files to <support@2pintsoftware.com>, or use the 2Pint Software online forums.

Note: Add all the files to a .zip file; otherwise, the email might get caught in a spam or antivirus filter.


---

# 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/overview.md?ask=<question>&goal=<user_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.
