Skip to main content

P2P PXE Process & Troubleshooting Guide

Updated

Contents

  1. Overview
  2. The PXE Boot Data Flow
  3. Log Entries
  4. Troubleshooting
  5. Further Considerations

1. Overview

This guide is aimed at describing the Adaptiva PXE boot process and to serve as a troubleshooting aid in the event that PXE is not functioning correctly within a subnet.

The Adaptiva PXE solution does not require any DHCP Scope options and these should be removed where used for any previous PXE solutions.

IP Helpers are only required for IP addressing (DHCP) where not local, and in the event where DHCP Snooping or IP Source Guard are in place) and are not required for local PXE.

This guide assumes that PXE has already been configured within the P2P PXE perspective and the appropriate devices have been targeted to provide a local PXE responder (RVP).

2. The PXE Boot Data Flow

The following flowchart shows the data flow for a successful PXE request. The orange items on the left reference the appropriate troubleshooting section to locate should an item in the flowchart not be executed successfully. Please correspond each numbered item in the blue boxes with the appropriate log entries in section 3 below.

An Inline Wireshark capture will be included - using a display filter is necessary to reduce the view to the appropriate events.

In the display filter enter bootp (not bootparams) and hit return.

 

 

3. Log Entries

The following log entries are logged in the PXE.log on the RVP for a successful PXE deployment. Where the log entries differ for Legacy BIOS/UEFI or for Required/Available deployments, these are separated respectively.

It is important to ensure that when checking the PXE.log file, that you are checking the RVP for the same subnet on which you are attempting to PXE boot. The RVP for the current subnet can be located in the network topology and is indicated by a green icon in the Client ID column for the subnet in question. An example of this is shown below: 

#1 Client PXE boots from NIC

A DHCP DISCOVER broadcast is sent on UDP67 from the client and received by the local subnet RVP

Legacy BIOS:

UEFI:

Initial Client DHCP Discover, Wireshark view

  1. At this point the PXE client is requesting an IP address
  2. PXE Client Mac address

DHCP Server Offer

  1. 172.15.2.15 is the IP address DHCP server is offering the PXE Client

#2 RVP Sends Request to Server

Server validates boot request. The machine MAC is queried against collection membership, assigned task sequence deployments and associated boot images.

#3 Server sends response back to RVP

Response contains whether the machine is entitled to boot. If it is, it also returns the deployment ID and the boot image ID. If not allowed to boot (abort: true) then the reason for the abort is returned.

#4 RVP sends offer to client

A DHCP OFFER broadcast is sent on UDP68, offering a PXE boot service.

RVP Sends offer to client

Client Accepts Offer and sends DHCP request as a broadcast

DHCP Server confirms the DHCP request and assigns the IP to the client

#5 RVP performs content discovery for boot image

RVP begins process of locating boot image returned from server.

#6 Client sends PXE Request to RVP

A unicast message on UDP 4011 is sent from the client directly to the RVP requesting PXE boot files

Legacy BIOS:

UEFI:

Client sends unicast on port 4011 to the RVP requesting the PXE file boot files

#7 RVP acknowledges the request to client

A DHCP ACK is returned to the client on UDP 4011 and direct on UDP68 containing the boot server and boot program (DHCP options 66 and 67)

Legacy BIOS – Required (Mandatory) Deployment:

Legacy BIOS – Available (Optional) Deployment:

UEFI – Required (Mandatory) Deployment:

UEFI – Available (Optional) Deployment:

Legacy BIOS:

UEFI:

4. Troubleshooting

#1 DHCP Discover not received by RVP

The DHCP Discover is a broadcast sent on the local subnet. Ensure that:

  • The client is connected to the local network via a wired connection.
  • The RVP that is being observed is the RVP for the same subnet on which the PXE request is taking place.
  • The RVP for the subnet is in the P2P PXE target collection (Set in the P2P PXE Perspective)
  • Broadcasts are permitted on the subnet and not blocked by the switch.
  • DHCP Snooping/IP Source Guard is not enabled on the switch.
    • DHCP Snooping/Source Guard block any DHCP broadcasts that are not from an authorized source. This security protocol should either be disabled, or you should considering using the Adaptiva Remote PXE option in conjunction with an IP Helper to forward the DHCP broadcasts to an authorized PXE source RVP device.

 

#2 SmsBootPackageIdRequest message not received by Server

The SmsBootPackageIdRequest message can be observed in the SentRecvMsg.log on the RVP and in the adaptiva.log on the Adaptiva Server. If the message is either not sent to the server, or the server does not receive it, check the following:

  • The Adaptiva server is online and available and the AdaptivaServer service is started and responsive.
  • There are no firewalls blocking messaging on standard Adaptiva client->server and server-> client messaging ports (see port spreadsheet for details).
  • The Adaptiva server is not backlogged and is able to respond timely to boot package ID requests (check the current buffer size and notification table count).

 

#3 Client does not receive SmsBootPackageIdReply from Server

Please see troubleshooting item #2 above.

 

#4 Client receives an abortpxe.com message

An abortpxe.com message would be shown in the PXE.log on the RVP and also on screen on the PXE client during a PXE attempt. Receipt of an abortpxe.com file indicates that the PXE process itself is functioning normally and that the server found the client to be not entitled to PXE boot. The exact reason for returning the abortpxe.com can be found in the SmsBootPackageIdReply message in the PXE.log and SentRecvMsg.log on the RVP and can be for a number of reasons. These can include:

  • The target resource is not targeted with a valid task sequence deployment
  • The deployment is a required deployment, has already been run on the target device and the last PXE advertisement flag has not been cleared.
  • There is no resource for the PXE client in ConfigMgr and Unknown Computer support is not enabled.
  • The PXE approval workflow was instructed to return an abort.

 

#5 RVP does not send DHCP offer or DHCP Offer is not received by client

After receiving the DHCPDISC, the RVP will reply with a DHCPOFFER. If the DHCP Offer is not received by the PXE client then ensure the following:

 

#6 Boot Image cannot be located

Ensure that the boot image for any applicable task sequences has been distributed to the office in which the PXE attempt is being made.

Note: If a PXE boot is attempted without the boot image already present, it will be downloaded on demand, but depending on the speed of the link and size of the boot image, this will probably take longer than the 28 second timeout and the PXE attempt will fail until the boot image is available.

 

#7 PXE request not sent to RVP

After receiving the DHCP Offer, the client will send a unicast message on UDP 4011 to the IP address of the machine that sent the offer with a PXE request. If the RVP does not receive the PXE request then ensure the following:

  • Check DHCP Scope options 60, 66 and 67 are not in place on the subnet.
    • DHCP Options 60, 66 and 67 specify settings for PXE from the DHCP server, such as boot server and boot file name and if any are set it would cause the PXE request to be sent to the specified server for the specified file, regardless of where the offer came from.
  • There are no other current or legacy PXE services in place on the subnet.
    • Other PXE services would also respond to a DHCPDISC with an offer and if their offer is received before the offer from the RVP, would cause the PXE request to be sent to that server instead.
  • UDP Port 4011 is not blocked via client-side firewall (such as Windows firewall)
  • Occasionally if clients are connected through a VoIP phone system, this can have unpredictable sporadic behavior with PXE. To rule out, cable the RVP and PXE client directly rather than through the phone system to see if the issue is resolved.
  • Occasionally if the RVP has multiple NICs and has an active connection on both, the PXE request may be received by a different NIC than the offer was sent on and can cause the request to not be received. To rule out during testing, ensure that only one NIC is active.

 

#8 DHCP ACK is not sent by RVP or DHCP ACK is not received by client

The DHCP ACK is sent after the unicast message is received on port 4011. If the ACK is not sent then it is probably due to the unicast message not being received. Please ensure items from #7 above have been checked.

 

#9 Boot Image Transfer does not start or fails

If the boot image transfer does not start or fails, ensure the boot image is available within the office and consult the TFTP log on the machine elected to serve the boot image (indicated by the following line in the PXE.log):

The TFTP log may show an error indicating a problem with starting the TFTP Server or creating the BCD file. Ensure the ADK files are available within .\<AdaptivaClientInstallDir>\data\p2ppxe and that the .bcd file has been created. Certain versions of the ADK are required/unsupported, ensure the bcdedit file selected is a supported version. See the Adaptiva knowledge base for more details on bcedit and ADK supported versions.

 

4. Further Considerations

#1 Remote PXE

If you have network security such as DHCP Snooping or IP Source guard, or something similar, which blocks local DHCPDISCOVER broadcasts at the network switch level, then the local RVP client will not receive the PXE request.  To address this scenario, a configuration option called Remote PXE is available in which Adaptiva P2P PXE clients can provide PXE services to clients on another network.  For more information on how to configure this, please see the Remote-PXE option in the Adaptiva OneSite OSD User Guide.

For the majority, the PXE boot process is the same but with the remote RVP machine handling & responding to the PXE request (Steps 2,3,4,5 & 7).  The only difference is that at Step 5, the Remote RVP will communicate with the local RVP to the PXE Client’s subnet, to locate clients with the boot image cached in that office local to the PXE client.  The Remote RVP machine will then provide the IP address of one of the local sources to the PXE client as the boot server in step 7.

This brings the benefit of being able to respond to a PXE request using a remote trusted client, but still downloading the boot image from a local peer.

#2 Increasing the speed of the TFTP Transfer

During an Adaptiva peer-to-peer PXE boot, the boot image is transferred from a peer client using trivial file transfer protocol (TFTP). This TFTP transfer can often appear slow, especially for large boot images.

The reason for this is due to the protocol and the amount of data retrieved at any one time. The data is retrieved based on a defined block size. The default block size for TFTP is 512 bytes, but the default for Adaptiva peer-to-peer PXE is 1024 bytes. These blocks are transmitted it a single IP packet and the small delay in between sending each block adds time to the overall process. This default setting can be overridden by using a system configuration policy and applied to a target collection of devices. By increasing the size of the block being retrieved, the overall transfer time is shortened. This results in a much quicker PXE boot process and improved user experience.

In order to modify the default block size a new system configuration policy needs to be created. The following steps should be undertaken to create the system configuration policy:

 

  1. In the Adaptiva Workbench, navigate to the Misc folder and enter the System Configuration Perspective
  2. In the System Config Settings Task Navigator, select Create New Client Settings Policy
  3. In the Name textbox, enter a name for this policy (i.e. TFTP Block Size)
  4. Optional: Enter a description for this policy
  5. In the ‘Target groups for this policy’ section, either drag in (from the SCCM Collections Explorer), or click ‘Add Collection’ and select from the list, a collection to target with this setting.
    1. Note: It is advisable to select the same collection as the Peer-to-Peer PXE target collection to ensure maximum coverage.
  6. In the ‘All Client settings in system’ section, navigate to SystemConfig > Tftpserver and drag Pxe blk size from the ‘All Client settings in system’ section, into the ‘Overridden client settings by this policy’ section, on top of the ‘SystemConfig’ text.
  1. In the ‘Config setting details’ pane on the right, enter a value in the ‘New Value’ box.
    1. Note: This value should be divisible by 8
    2. Note: Certain systems, especially virtual machines, cannot accept a block size above a certain threshold, and this varies by environment so experimentation may be required to find an optimum number.
    3. Note: It’s advisable not to exceed 16384.
  2. After setting the correct value, make sure to click Apply within the Config setting details pane.
  1. In order for this setting to apply to the existing boot image, from within Tftpserver in the All Client settings in system section, also drag across on top of SystemConfig the setting Update existing bootimg blk size.
  2. Set the value to true and click Apply in the Config settings details pane.
  3. At the top of the window, click Save to send the policy out and apply the settings.
    1. Note: An Adaptiva client restart is often required in order for this setting to get applied.

#3 Password protecting the PXE boot process

In a native ConfigMgr environment, the PXE feature of the distribution point role can have an optional password specified. This password needs to be entered immediately after booting into WinPE during a standard PXE boot, before the selection of a task sequence can occur.

 

This security feature prevents unauthorized imaging of machines, and prevents accidental deletion of data if the machine were to perform a network boot by mistake.

The password is set during configuration of the Adaptiva-enabled boot image, during the point at which bootable media is created in order for the variables.dat and TsmBootstrap.ini to be copied onto the mounted wim.

 When creating the bootable media, on the Security page, enter the desired password in the ‘Specify a password to protect task sequence media’ section.

If the password needs to be changed at a later date, the boot image configuration process would need to be completed again, new task sequence media would need to be created with the new password, the new variables.dat and TsmBootstrap.ini would need to be copied into the mounted wim and the boot image updated on the distribution points.

For more information on configuring the boot image for use with Adaptiva Peer-to-Peer PXE and OSD, please refer to the Adaptiva OneSite OSD User Guide.

Comments

0 comments

Please sign in to leave a comment.