Troubleshooting PXE boot issues in Configuration Manager 2012

What does this guide do?
Helps administrators diagnose and resolve PXE boot failures in System Center 2012 Configuration Manager(ConfigMgr 2012 or ConfigMgr 2012 R2).

Who is it for?
Administrators who help diagnose and resolve PXE boot issues.

How does it work?
We’ll begin by explaining some background information about PXE. Then we’ll take you through a series of troubleshooting steps that are specific to your situation.

Estimated time of completion:
15-30 minutes.

Understanding PXE Boot and Configuration Manager

PXE boot in System Center 2012 Configuration Manager (ConfigMgr 2012 or ConfigMgr 2012 R2) enables administrators to easily access the Windows Preinstallation Environment (WinPE) across the network via the Preboot Execution Environment (PXE). PXE is an industry standard created by Intel that provides pre-boot services within the devices firmware that enables devices to download network boot programs to client computers.

Configuration Manager relies on the Windows server role Windows Deployment Services (WDS) via the WDS PXE provider. In ConfigMgr 2012, the SMS PXE provider (SMSPXE) registers with the WDS service and supplies the logic for the PXE client requests.

Before troubleshooting PXE related problems in ConfigMgr 2012, it is important to understand the basic processes involved, how they work and how they interoperate with each other. This troubleshooter assumes you possess an understanding of these processes, however if you would like a general overview you can select that option below or you can continue on straight to troubleshooting.

Understanding PXE Boot and Configuration Manager

PXE boot in System Center 2012 Configuration Manager (ConfigMgr 2012 or ConfigMgr 2012 R2) enables administrators to easily access the Windows Preinstallation Environment (WinPE) across the network via the Preboot Execution Environment (PXE). PXE is an industry standard created by Intel that provides pre-boot services within the devices firmware that enables devices to download network boot programs to client computers.

Configuration Manager relies on the Windows server role Windows Deployment Services (WDS) via the WDS PXE provider. In ConfigMgr 2012, the SMS PXE provider (SMSPXE) registers with the WDS service and supplies the logic for the PXE client requests.

Before troubleshooting PXE related problems in ConfigMgr 2012, it is important to understand the basic processes involved, how they work and how they interoperate with each other. This troubleshooter assumes you possess an understanding of these processes, however if you would like a general overview you can select that option below or you can continue on straight to troubleshooting.

PXE Service Point Installation

We will first look at the processes involved in the installation of the SMSPXE provider. In all instances in this document we are using System Center 2012 Configuration Manager R2 Cumulative Update 2 (ConfigMgr 2012 R2 CU2) and a remote site system installed on Windows Server 2012 with the Distribution Point (DP) role installed.

First, installation is initiated by selecting the Enable PXE support for clients option on the PXE tab of the Distribution Point properties. When PXE support is enabled, an instance of SMS_SCI_SysResUse class is created.

SMSProv.log:PutInstanceAsync SMS_SCI_SysResUseSMS Provider04/09/2014 11:30:131552 (0x0610)CExtProviderClassObject::DoPutInstanceInstanceSMS Provider04/09/2014 11:30:131552 (0x0610)INFO: '' is a valid FQDN.SMS Provider04/09/2014 11:30:131552 (0x0610)


In the WMI namespace Root\SMS\Site_RR2 (where RR2 is the site code of the site), the SMS_SCI_SYSResUse class contains all the site systems roles on the primary site server. You can run the following query in WBEMTEST to identify all the DPs on that site server:

SELECT * FROM SMS_SCI_SysResUse WHERE rolename like 'SMS Distribution Point'
Changing the properties of these roles via the SDK will alter the site control file and configure the DP. The IsPXE property name is a member of the props property and is set to 1 when the DP is PXE enabled.

The SMS Database Monitor component detects the change to the DPNotificaiton and DistributionPoints tables and drops files in

Smsdbmon.log:RCV:UPDATE on SiteControl for SiteControl_AddUpd_HMAN [RR2 ][19604]RCV: UPDATE on SiteControl for SiteControl_AddUpd_SiteCtrl [RR2 ][19605]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\RR2.SCU [19604]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\RR2.CT0 [19605]RCV: UPDATE on Sites for Sites_Interop_Update_HMAN [RR2 ][19606]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\RR2.ITC [19606]RCV: UPDATE on DistributionPoints for DP_Properties_Upd [15 ][19607]RCV: INSERT on PkgNotification for PkgNotify_Add [RR200002 ][19608]RCV: INSERT on PkgNotification for PkgNotify_Add [RR200003 ][19609]RCV: INSERT on DPNotification for DPNotify_ADD [15 ][19610]RCV: UPDATE on SiteControlNotification for SiteCtrlNot_Add_DDM [RR2 ][19611]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\15.NOT [19607]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\RR200002.PKN [19608]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\RR200003.PKN [19609]SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\\15.DPN [19610]Site Control Notification.

The Distribution Manager component on the primary site server then initiates the configuration of the remote DP:

ConfigureDPSMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)IISPortsList in the SCF is "80".SMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)IISSSLPortsList in the SCF is "443".SMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)IISWebSiteName in the SCF is "".SMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)IISSSLState in the SCF is 448.SMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)DP registry settings have been successfully updated on RemoteDp.contoso.comSMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)ConfigurePXESMS_DISTRIBUTION_MANAGER04/09/2014 11:30:263776 (0x0EC0)

In the SMS DP Provider log on the remote DP we can see the following information about the PXE install, where initially the PxeInstalled reg key is not found:

Smsdpprov.log[66C][Thu 09/04/2014 11:30:28]:CcmInstallPXE [66C][Thu 09/04/2014 11:30:28]:RegQueryValueExW failed for Software\Microsoft\SMS\DP, PxeInstalled[66C][Thu 09/04/2014 11:30:28]:RegReadDWord failed; 0x80070002

The Visual C++ Redistributable is installed:

Smsdpprov.log[66C][Thu 09/04/2014 11:30:28]:Running: C:\SMS_DP$\sms\bin\vcredist_x64.exe /q /log "C:\SMS_DP$\sms\bin\vcredist.log"[66C][Thu 09/04/2014 11:30:28]:Waiting for the completion of: C:\SMS_DP$\sms\bin\vcredist_x64.exe /q /log "C:\SMS_DP$\sms\bin\vcredist.log"[66C][Thu 09/04/2014 11:30:39]:Run completed for: C:\SMS_DP$\sms\bin\vcredist_x64.exe /q /log "C:\SMS_DP$\sms\bin\vcredist.log"

WDS is installed:

Smsdpprov.log[66C][Thu 09/04/2014 11:30:39]:Created the DP mutex key for WDS.[66C][Thu 09/04/2014 11:30:39]:Failed to open WDS service.[66C][Thu 09/04/2014 11:30:39]:WDS is NOT INSTALLED[66C][Thu 09/04/2014 11:30:39]:Installing WDS.[66C][Thu 09/04/2014 11:30:39]:Running: ServerManagerCmd.exe -i WDS -a[66C][Thu 09/04/2014 11:30:39]:Failed (2) to run: ServerManagerCmd.exe -i WDS -a[66C][Thu 09/04/2014 11:30:39]:Running: PowerShell.exe -Command Import-Module ServerManager; Get-WindowsFeature WDS; Add-WindowsFeature WDS[66C][Thu 09/04/2014 11:30:39]:Waiting for the completion of: PowerShell.exe -Command Import-Module ServerManager; Get-WindowsFeature WDS; Add-WindowsFeature WDS[66C][Thu 09/04/2014 11:31:35]:Run completed for: PowerShell.exe -Command Import-Module ServerManager; Get-WindowsFeature WDS; Add-WindowsFeature WDS[66C][Thu 09/04/2014 11:31:35]:Successfully installed WDS.

TFTP read filters are configured:

Smsdpprov.log[66C][Thu 09/04/2014 11:31:35]:Setting TFTP config key as: System\CurrentControlSet\Services\WDSSERVER\Providers\WDSTFTP[66C][Thu 09/04/2014 11:31:35]:Configuring TFTP read filters[66C][Thu 09/04/2014 11:31:35]:SetupComplete is set to 0

The REMINST share is created and WDS is configured:

Smsdpprov.log[66C][Thu 09/04/2014 11:31:35]:RegQueryValueExW failed for Software\Microsoft\Windows\CurrentVersion\Setup, REMINST[66C][Thu 09/04/2014 11:31:35]:RegReadDWord failed; 0x80070002[66C][Thu 09/04/2014 11:31:35]:REMINST not set in WDS[66C][Thu 09/04/2014 11:31:35]:WDS is NOT Configured[66C][Thu 09/04/2014 11:31:35]:Share (REMINST) does not exist. (NetNameNotFound) (0x00000906)[66C][Thu 09/04/2014 11:31:35]:GetFileSharePath failed; 0x80070906[66C][Thu 09/04/2014 11:31:35]:REMINST share does not exist. Need to create it.[66C][Thu 09/04/2014 11:31:35]:Enumerating drives A through Z for the NTFS drive with the most free space.[66C][Thu 09/04/2014 11:31:37]:Drive 'C:\' is the best drive for the SMS installation directory.[66C][Thu 09/04/2014 11:31:37]:Creating REMINST share to point to: C:\RemoteInstall[66C][Thu 09/04/2014 11:31:37]:Succesfully created share REMINST[66C][Thu 09/04/2014 11:31:37]:Removing existing PXE related directories[66C][Thu 09/04/2014 11:31:37]:Registering WDS provider: SourceDir: C:\SMS_DP$\sms\bin [66C][Thu 09/04/2014 11:31:37]:Registering WDS provider: ProviderPath: C:\SMS_DP$\sms\bin\smspxe.dll [66C][Thu 09/04/2014 11:31:37]:DoPxeProviderRegister[66C][Thu 09/04/2014 11:31:37]:PxeLoadWdsPxe[66C][Thu 09/04/2014 11:31:37]:Loading wdspxe.dll from C:\Windows\system32\wdspxe.dll[66C][Thu 09/04/2014 11:31:37]:wdspxe.dll is loaded[66C][Thu 09/04/2014 11:31:37]:PxeProviderRegister has suceeded (0x00000000)[66C][Thu 09/04/2014 11:31:37]:Disabling WDS/RIS functionality[66C][Thu 09/04/2014 11:31:39]:WDSServer status is 1[66C][Thu 09/04/2014 11:31:39]:WDSServer is NOT STARTED[66C][Thu 09/04/2014 11:31:39]:Running: WDSUTIL.exe /Initialize-Server /REMINST:"C:\RemoteInstall"[66C][Thu 09/04/2014 11:31:39]:Waiting for the completion of: WDSUTIL.exe /Initialize-Server /REMINST:"C:\RemoteInstall"[66C][Thu 09/04/2014 11:31:50]:Run completed for: WDSUTIL.exe /Initialize-Server /REMINST:"C:\RemoteInstall"[66C][Thu 09/04/2014 11:31:50]:CcmInstallPXE: Deleting the DP mutex key for WDS.[66C][Thu 09/04/2014 11:31:50]:Installed PXE[66C][Thu 09/04/2014 11:32:03]:CcmInstallPXE[66C][Thu 09/04/2014 11:32:03]:PXE provider is already installed.[66C][Thu 09/04/2014 11:32:03]:Installed PXE

On the remote DP we can now see the following values added in HKLM\Software\Microsoft\SMS\DP:    


Note how PxeInstalled and IsPXE are set to 1.

If we look at the remote DP’s file system there is a new log in C:\SMS_DP$\sms\logs:

SMSPXE.logMachine is running Windows Longhorn. (NTVersion=0X602, ServicePack=0)Cannot read the registry value of MACIgnoreListFile (00000000)MAC Ignore List Filename in registry is emptyBegin validation of Certificate [Thumbprint B64B9DAF9BFB76A99DC050C21E33B3489643D111] issued to 'e728f6ce-29a6-4ac3-974e-ba3dc855d9a4'Completed validation of Certificate [Thumbprint B64B9DAF9BFB76A99DC050C21E33B3489643D111] issued to 'e728f6ce-29a6-4ac3-974e-ba3dc855d9a4'

The Distribution Point should now be PXE enabled and ready to accept incoming requests.

Adding Boot Images to a PXE Enabled DP

Whenever a new PXE enabled Distribution Point has been configured, there are additional steps that need to be completed to enable full functionality. One of these is that you must distribute the x86 and x64 boot images to the new PXE enabled DP. To do this, navigate to Software Library -> Operating Systems -> Boot Images -> Boot Image (x86) then right-click and select Distribute Content -> Add the Boot Image to the PXE enabled DP.

Repeat this process for Boot Image (x64).

Once this has been done, Distribution Manager will start processing the request and initiate the distribution to the remote DP:

DistMgr.logFound notification for package 'RR200004'Used 0 out of 30 allowed processing threads.Starting package processing thread, thread ID = 0x152C (5420)Start adding package to server ["Display=\\\"]MSWNET:["SMS_SITE=RR2"]\\\...Attempting to add or update a package on a distribution point.Successfully made a network connection to \\ \ADMIN$.CreateSignatureShare, connecting to DPSignature share exists on distribution point path \\ \SMSSIG$Share SMSPKGC$ exists on distribution point \\ \SMSPKGC$Checking configuration of IIS virtual directories on DP ["Display=\\\"]MSWNET:["SMS_SITE=RR2"]\\\Creating, reading or updating IIS registry key for a distribution point.Virtual Directory SMS_DP_SMSSIG$ for the physical path C:\SMSSIG$ already exists.Created package transfer job to send package RR200004 to distribution point ["Display=\\\"]MSWNET:["SMS_SITE=RR2"]\\\.StoredPkgVersion (9) of package RR200004. StoredPkgVersion in database is 9.SourceVersion (9) of package RR200004. SourceVersion in database is 9.

Package Transfer Manager (the DP is remote) then initiates sending of the content:

PkgXferMgr.logDeleteJobNotificationFiles deleted 1 *.PKN file(s) this cycle.Found send request with ID: 105, Package: RR200004, Version:9, Priority: 2, Destination: REMOTEDP.CONTOSO.COM, DPPriority: 200Created sending thread (Thread ID = 0x1140)Sending thread starting for Job: 105, package: RR200004, Version: 9, Priority: 2, server: REMOTEDP.CONTOSO.COM, DPPriority: 200Sending legacy content RR200004.9 for package RR200004Finished sending SWD package RR200004 version 9 to distribution point REMOTEDP.CONTOSO.COMSent status to the distribution manager for pkg RR200004, version 9, status 3 and distribution point ["Display=\\\"]MSWNET:["SMS_SITE=RR2"]\\\StateTable::CState::Handle - (8210:1 2014-09-10 13:19:12.087+00:00) >> (8203:3 2013-11-26 15:43:48.108+00:00)Successfully send state change notification 7F6041B0-3EE2-427F-AB72-B89610A6331CSending thread complete

SMS Distribution Point Provider then deploys the WIM to the remote install directory:

Smsdpprov.log[468][Wed 09/10/2014 14:09:59]:A DP usage gathering task has been registered successfully[99C][Wed 09/10/2014 14:19:07]:Content 'RR200004.9' for package 'RR200004' has been added to content library successfully[99C][Wed 09/10/2014 14:19:07]:Expanding C:\SCCMContentLib\FileLib\E8A1\E8A136A1348B4CFE97334D0F65934845F2B4675D0B7D925AB830378F4ECF39B9 from package RR200004[99C][Wed 09/10/2014 14:19:07]:Finding Wimgapi.Dll[99C][Wed 09/10/2014 14:19:07]:Found C:\Windows\system32\wimgapi.dll[99C][Wed 09/10/2014 14:19:07]:Expanding RR200004 to C:\RemoteInstall\SMSImages

SMSPXE discovers the new image:

SMSPXE.logFound new image RR200004PXE::CBootImageManager::QueryWIMInfoLoaded C:\Windows\system32\wimgapi.dllOpening image file C:\RemoteInstall\SMSImages\RR200004\boot.RR200004.wimFound Image file: C:\RemoteInstall\SMSImages\RR200004\boot.RR200004.wimPackageID: RR200004ProductName: Microsoft® Windows® Operating SystemArchitecture: 0Description: Microsoft Windows PE (x86)Version: Creator: SystemDir: WINDOWSClosing image file C:\RemoteInstall\SMSImages\RR200004\boot.RR200004.wimPXE::CBootImageManager::InstallBootFilesForImageTemporary path to copy extract files from: C:\RemoteInstall\SMSTempBootFiles\RR200004.


Ensure that these boot images have been configured to deploy from the PXE enabled DP. Right click the boot image and select Properties -> Data Source and select Deploy this boot image from the PXE-enabled distribution point.

The PXE Boot Process

The example boot process described here involves three machines: The DHCP server, the PXE enabled DP and the client (an x64 BIOS computer). All are located on the same subnet.

In the PXE boot process, the client must first acquire TCP/IP parameters and the location of the TFTP boot server. Once a device is powered on and completes the POST, it will begin the PXE boot process (usually prompted via the boot selection menu).

  1. The first thing the PXE firmware will do is send a DHCPDISCOVER(a UDP packet) broadcast to get TCP/IP details. This will include a list of parameter requests, and below is a sample network trace with the parameter list from a DHCPDISCOVER packet:
    The PXE client then identifies the vendor and machine specific information so that it can request the location and file name of the appropriate boot image file.
  2. The DHCP server and the PXE enabled DP then sends a DHCPOFFER to the client containing all of the relevant TCP/IP parameters.
    In the example DHCP offer below, note that it does not contain the server name or boot file information because this is the offer from the DHCP server rather than the PXE enabled DP.
  3. The client then replies with a DHCPREQUEST once it has selected a DHCPOFFER. This contains the IP address from the offer that was selected.
  4. The DHCP server responds to the DHCPREQUEST with a DHCPACK which contains the same details as the DHCPOFFER. The server host name and the boot file name are not provided here:
  5. At this point we still don’t have the boot file information, however now the client has an IP address. The PXE client next sends a new DHCPREQUEST to the PXE enabled DP after also receiving a DHCPOFFER from the earlier DHCPDISCOVER broadcast.
  6. The PXE enabled DP sends a DHCPACK which contains the BootFileName location and the WDS network boot program (NBP).
Downloading The Boot Files

  1. Once the DHCP conversation has completed, the client will start the TFTP session with a read request: 
    The server responds with the tsize and then the blksize. The client will then transfer the file from the server.

    NOTE The size of these blocks is the blksize, and in this case it is set to 1456 bytes. The blksize is configurable on Windows Server 2008 and up. See the following Knowledge Base article for more details:

    975710 - Operating system deployment over a network by using WDS fails in Windows Server 2008 and in Windows Server 2008 R2

    Here we can see the end of the DHCP conversation and the start of the TFTP transfer:
    When the WDS network boot program (NBP) has been transferred to the client computer, it will be executed. In our example it starts by downloading The NBP dictates whether the client can boot from the network, whether the client must press F12 to initiate the boot and which boot image the client will receive.

    NBPs are both architecture and firmware specific (BIOS or UEFI). On BIOS computers the NBP is a 16-bit real-mode application, therefore it is possible to use the same NBP for both x86-based and x64-based operating systems.

    In our case (an x64 BIOS machine), the NBP is located in the following directory on the PXE enabled DP:
    The files perform the following functions: – x86 and x64 BIOS: Requires the end-user to press the F12 key for PXE boot to continue (this is the default NBP).

    PXEboot.n12 – x86 and x64 BIOS:
    Immediately begins PXE boot (does not require pressing F12 on the client). – x86 and x64 BIOS:
    Allows the device to immediately begin booting by using the next boot device specified in the BIOS. This allows for devices that should not be booting using PXE to immediately begin their secondary boot process without waiting for a timeout.

    Bootmgfw.efi – x64 UEFI and IA64 UEFI: The EFI version of or PXEboot.n12 (in EFI, the choice of whether or not to PXE boot is handled within the EFI shell and not by the NBP). Bootmgfw.efi is the equivalent of combining the functionality of, PXEboot.n12, and bootmgr.exe. – x86 and x64 BIOS: A special NBP developed for use by Windows Deployment Services that serves the following general purposes:
    ◦Architecture detection
    ◦Pending devices scenarios

    Wdsmgfw.efi – x64 UEFI and IA64 UEFI: A special NBP developed for use by Windows Deployment Services that serves the following general purposes:
    ◦Handles prompting the user to press a key to continue PXE boot
    ◦Pending devices scenarios
  2. The NBP downloads the operating system loader and the boot files via TFTP, which include the following: 
    ◦ smsboot\x64\
    ◦ smsboot\x64\bootmgr.exe
    ◦ \SMSBoot\Fonts\wgl4_boot.ttf
    ◦ \SMSBoot\boot.sdi
    ◦ \SMSImages\RR200004\boot.RR200004.wim

  3. A RAMDISK is created using these files and the WinPE WIM file in memory. 
  4. The client boots from the RAMDISK.

WinPE Boot

Once WinPE has booted, the TS boot shell is initiated from the SMS folder that is included in the WinPE image (this folder is injected into the boot WIM when it is imported into Configuration Manager). You can see this process logged in SMSTS.log which is located in X:\Windows\Temp\SMSTS\.
To access this log in WinPE, enable the command prompt on the boot image. You can do this by right-clicking Boot Image -> Properties -> Customization -> and checking Enable command support (testing only). You can then access the command prompt by pressing F8 in WinPE.
Here is the initial TS boot shell process:

SMSTS.log==============================[ TSBootShell.exe ]==============================Succeeded loading resource DLL 'X:\sms\bin\i386\1033\TSRES.DLL'Debug shell is enabledWaiting for PNP initialization...RAM Disk Boot Path: NET(0)\SMSIMAGES\RR200004\BOOT.RR200004.WIMBooted from network (PXE)Network(PXE) path: X:\sms\data\Found config path X:\sms\data\This is not a fixed non usb diskBooting from removable media, not restoring bootloaders on hard driveX:\sms\data\WinPE does not exist.X:\_SmsTsWinPE\WinPE does not exist.Executing command line: wpeinit.exe -winpeThe command completed successfully.Starting DNS client service.Executing command line: X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:X:\sms\data\The command completed successfully.

Followed by the Task Sequence Manager boot strap:

SMSTS.log==============================[ TSMBootStrap.exe ]==============================Command line: X:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:X:\sms\data\Succeeded loading resource DLL 'X:\sms\bin\i386\1033\TSRES.DLL'Succeeded loading resource DLL 'X:\sms\bin\i386\TSRESNLC.DLL'Current OS version is 6.2.9200.0Adding SMS bin folder "X:\sms\bin\i386" to the system environment PATHPXE Boot with Root = X:\Executing from PXE in WinPELoading TsPxe.dll from X:\sms\bin\i386\TsPxe.dll

Once TSPXE is loaded it downloads the TS variables using TFTP:

SMSTS.log TsPxe.dll loadedDevice has PXE bootedVariable Path: \SMSTemp\2014.{0C616323-A027-41B0-A215-057AF4F1E361}.boot.varSuccesfully added firewall rule for TftpExecuting: X:\sms\bin\i386\smstftp.exe -i get \SMSTemp\2014.{0C616323-A027-41B0-A215-057AF4F1E361}.boot.var X:\sms\data\variables.datExecuting command line: "X:\sms\bin\i386\smstftp.exe" -i get \SMSTemp\2014.{0C616323-A027-41B0-A215-057AF4F1E361}.boot.var X:\sms\data\variables.datProcess completed with exit code 0Succesfully removed firewall rule for TftpSuccessfully downloaded pxe variable file.Loading Media Variables from "X:\sms\data\variables.dat"Loading Media Variables from "X:\sms\data\variables.dat"Found network adapter "Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)" with IP Address Media Variables from "X:\sms\data\variables.dat"Loading variables from the Task Sequencing Removable Media.Loading Media Variables from "X:\sms\data\variables.dat"Succeeded loading resource DLL 'X:\sms\bin\i386\1033\TSRES.DLL'Setting SMSTSMP TS environment variableSetting _SMSMediaGuid TS environment variableSetting _SMSTSBootMediaPackageID TS environment variableSetting _SMSTSHTTPPort TS environment variableSetting _SMSTSHTTPSPort TS environment variableSetting _SMSTSIISSSLState TS environment variableSetting _SMSTSLaunchMode TS environment variableSetting _SMSTSMediaPFX TS environment variableSetting _SMSTSPublicRootKey TS environment variableSetting _SMSTSRootCACerts TS environment variableSetting _SMSTSSiteCode TS environment variableSetting _SMSTSSiteSigningCertificate TS environment variableSetting _SMSTSUseFirstCert TS environment variableSetting _SMSTSx64UnknownMachineGUID TS environment variableSetting _SMSTSx86UnknownMachineGUID TS environment variable

At this point TSPXE locates the Management Point (MP) and downloads policy before presenting the user interface for the user to select the optional Task Sequence:

SMSTS.log site=RR2,RR2, MP=http://ConfigMgrR2.CONTOSO.COM, ports: http=80,https=443certificates are received from MP.CLibSMSMessageWinHttpTransport::Send: URL: ConfigMgrR2.CONTOSO.COM:80 CCM_POST /ccm_system/requestRequest was successful.Downloading policy from http://ConfigMgrR2.CONTOSO.COM.Retrieving Policy Assignments:Processing Policy Assignment {7898f153-a6de-43e9-98c3-ca5cc61483b0}.Processing Policy Assignment {fba19677-0e9b-490d-b601-07e247979bd4}.Processing Policy Assignment {6306ca4c-e7ed-4cf5-8419-af9b1695a909}.Processing Policy Assignment {05a027ff-e9cf-4fa1-8bd8-4565481061e2}.Processing Policy Assignment {b3c991f6-9f83-43c3-875c-f60c4492d278}.…Successfully read 152 policy assignments.

Lastly, the collection and machine variables are downloaded and the Welcome Page is activated:

SMSTS.log Retrieving collection variable policy.Found 0 collection variables.Retrieving machine variable policy.Downloading policy body {01000053}-{RR2}.Response ID: {01000053}-{RR2}Reading Policy Body.Parsing Policy Body.Found 0 machine variables.Setting collection variables in the task sequencing environment.Setting machine variables in the task sequencing environment.Running Wizard in Interactive modeLoading Media Variables from "X:\sms\data\variables.dat"Activating Welcome Page.Loading bitmap 
Checking Common Issues

Before beginning any troubleshooting on the PXE Service Point, review the KB articles below to see if the issues discussed could possibly be causing your issue. Note that this is not an exhaustive list, however it does contain some of the more common issues seen.

Did this solve your problem?

Verify IP Helpers

If the DHCP server, the client computer, the ConfigMgr 2012 server running Windows Deployment Services (WDS) and the PXE enabled Distribution Point (DP) are all on the same subnet or VLAN then IP Helpers are not required. Otherwise, if either the DHCP server, the client computer, or the ConfigMgr 2012 server running WDS and the PXE enabled DP are on separate subnets or VLANs, which is usually the case in most environments, IP Helpers must be configured on the routers. This process varies and is dependent on the router hardware manufacturer, however a general overview is outlined in the TechNet article below:

Configuring Your Router to Forward Broadcasts:

IF additional information is needed for properly configuring IP Helpers on your routers, please contact the hardware manufacturer of the router.

IP Helpers are necessary because the PXE request generated by the client computer is a broadcast that does not travel outside of the local subnet or VLAN. If the DHCP server and/or the WDS/PXE enabled DP are not on the same subnet or VLAN as the client computer, they will not see or hear the PXE request broadcast from the client, thus the servers will not respond to the PXE request. To have the PXE request broadcast traverse between subnets or VLANs, the PXE request broadcast needs to be forwarded by the router to DHCP and WDS/PXE Service Point servers so that they can properly respond to the client’s PXE request.

An alternative to using IP Helpers is setting DHCP options on the DHCP server, specifically DHCP ptions 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Boot file Name). However, DHCP options can be problematic and may not work reliably or consistently. Furthermore, the use of DHCP options to control PXE requests in ConfigMgr 2012 is not supported by Microsoft. Therefore, the recommended and supported method for PXE booting client computers that are on remote subnets is by use of IP Helpers.

For additional information regarding DHCP Options not being recommended or supported, please see the articles below:
Using DHCP Options 60, 66, and 67:
259670 - PXE client computers do not start when you configure the Dynamic Host Configuration Protocol server to use options 60, 66, 67

IMPORTANT Before continuing, it is imperative that you verify that the routers have IP Helpers configured AND that the DHCP server does NOT have DHCP Options 60, 66, or 67 configured. Not meeting both of these criteria will cause problems with the PXE Service Point. When checking DHCP options, make sure to check options at both the server and scope levels.

Note that in certain instances, configuring DHCP options 60, 66, and 67 may make it appear that the PXE boot process is proceeding further along than before these options were configured, however in most cases it is simply proceeding further down an incorrect path.

IMPORTANT The only exception where a DHCP Option needs to be used is when DHCP and WDS reside on the same server. In this instance, DHCP Option 60, and only DHCP Option 60, needs to be set. DHCP Options 66 and 67 should still NOT be set in this scenario. This is detailed in the next section titled Co-hosting DHCP and WDS on the Same Server.

Did this solve your problem?

Special Consideration When Co-Hosting DHCP and WDS on the Same Server

When DHCP and WDS are co-hosted on the same computer, WDS needs a special configuration so that it can listen on a specific port. This configuration is outlined in the following TechNet article under the section Windows Deployment Service and Dynamic Host Configuration Protocol (DHCP)

Planning for PXE Initiated Operating System Deployments:

Note that according to the article above, the following two actions need to be completed when WDS and DHCP are co-hosted on the same server:

  1. The value UseDHCPPorts needs to be set to 0 in the following registry location:
  2. You need to run the following WDS command:
    WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes
However, a problem with the above recommendations is that in order to run the WDSUTIL command, WDS has to be configured. This goes against the best practice of NOT configuring WDS when installing a ConfigMgr PXE enabled DP, however the two settings being specified via the WDSUTIL command (UseDHCPPorts and DHCPOption60) can be configured using alternate methods that do not require the WDSUTIL command, and therefore do not require that WDS be configured. To configure these settings without having WDS enabled, complete the following steps:

  1. The UseDHCPPorts switch for WDSUTIL is actually the equivalent of setting the registry key UseDHCPPorts to a value of 0 in the following location:
    Therefore, using the UseDHCPPorts switch is not needed as long as the registry key has been manually set as described above. Please note that if WDS has not been installed, this registry key may not be present.
  2. The DHCPOption60 switch configures an option for the DHCP service, not the WDS service, therefore instead of using WDSUTIL to set this DHCP option, an equivalent DHCP command can be used to set the same option. This can be done by using the netsh command as described in the following MSDN article:

To summarize what’s in the article above, close any DHCP consoles that are open and then run following two commands from an elevated command prompt (Run As Administrator):

netsh dhcp server \\<DHCP_server_machine_name> add optiondef 60 PXEClient String 0 comment=PXE support netsh dhcp server \\<DHCP_server_machine_name> set optionvalue 60 STRING PXEClient 

where <DHCP_server_machine_name>  is the name of the DHCP/WDS server (without the brackets <>).

These two commands set up and enable DHCP Option 60 on a DHCP server. If after running the above two commands an option named Unknown is displayed in the DHCP console instead of 060 PXE Client, reboot the server so that these settings can take effect. After the reboot, the option should display correctly. This usually only occurs if a DHCP console was left open when the two commands were run.

NOTE If DHCP is ever moved to another server and removed from the server hosting WDS, the steps above need to be reversed. To reverse the above steps, complete the following on the WDS server:

  1. Run the following command from an elevated command prompt:
    REG ADD "HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE" /v UseDHCPPorts /t REG_DWORD /d 1 /f
  2. From an elevated command prompt, run the following two commands:
    netsh dhcp server \\<DHCP_server_machine_name> delete optionvalue 60
    netsh dhcp server \\<DHCP_server_machine_name> delete optiondef 60 PXEClient
    where <DHCP_server_machine_name>  is the name of the DHCP/WDS server (without the brackets <>).

    In the two commands above, the first disables DHCP option 60 while the second removes DHCP option 60 completely.

Did this solve your problem?

Troubleshooting DHCP Discovery

There are a number of important points to consider before starting to troubleshoot the initial DHCP discovery stage of the PXE booting process:

  • If you can’t see the MAC address or the DHCPREQUEST of the device you are attempting to boot in SMSPXE.log then there is a likely a router configuration issue between the client and the Distribution Point (DP). 
  • Do not use DHCP options 60, 66 and 67, this is not supported
  • Test whether the device can boot when plugged into a switch on the same subnet as the PXE enabled DP. If so the issue is likely with the router configuration.
  • Ensure the DHCP (67 and 68), TFTP (69) and BINL (4011) ports are open between the client computer, the DHCP server and the PXE DP.

At this stage of the process there are no logs to refer to, but usually when the PXE boot process fails before WinPE has booted a PXE error code will be displayed. Examples of the errors you might see include the following:

PXE-E51: No DHCP or proxyDHCP offers were received.

PXE-E52: proxyDHCP offers were received. No DHCP offers were received.

PXE-E53: No boot filename received.

PXE-E55: proxyDHCP service did not reply to request on port 4011.

PXE-E77 bad or missing discovery server list.

PXE-E78: Could not locate boot server.

There are a number of web pages that document these error codes. For example: Symantec’s list of PXE error codes and their meaning. 

This will help narrow down the focus of the troubleshooting, although it may be necessary to capture a network trace of the issue with a network monitoring tool such as Netmon or WireShark. The network monitoring tool will need to be installed on the PXE enabled DP and a computer connected to a mirrored port on the switch. For more details on configuring mirrored ports, please refer to the manual provided by the manufacturer of the specific switch or routing device.

The typical procedure is to start the network traces on both the DP and the machine connected to the mirrored port and then attempt to boot the device via PXE. Once completed, stop the trace and save it for further analysis. Here is a sample trace of a DHCP conversation captured from the PXE enabled DP:


You can see that the initial DHCPDISCOVER by the PXE client is followed by a DHCPOFFER from the DHCP server and the PXE DP. The request from the client ( is made and then acknowledged by the DHCP server ( Once the PXE client has an IP address( it sends a request to the PXE DP ( which acknowledges it with the network boot program details.

Capture a simultaneous network trace on the client and the DP to see if the conversation is occurring as expected.

  • Ensure that the DHCP services are running and available.
  • Verify that the WDS service is running on the DP.
  • Make sure there are no firewalls blocking the DHCP ports between the server and the client.
  • Verify that the client computer is able to boot when on the same subnet as the DP.
  • Ensure IP Helpers are configured correctly if booting from a different subnet than the DP.

Did this solve your problem?

Troubleshooting TFTP Transfer

If the error on PXE boot refers to TFTP then you likely have a problem transferring the boot files. Examples of these errors include:

PXE-E32: TFTP open timeout.
PXE-E35: TFTP read timeout.
PXE-E36: Error received from TFTP server.
PXE-E3F: TFTP packet size is invalid.
PXE-E3B: TFTP Error - File not Found
PXE-T04: Access Violation

Monitoring the network using Netmon or Wireshark is a good plan to try and troubleshoot these errors. Here is an example of the data captured from a PXE client when a TFTP Open timeout occurs:


Here the client is sending read requests for the

file but is not receiving a response. This indicates that something is preventing the Acknowledgment from being received by the client. Here is what it should look like:


Troubleshooting steps to try:

  • Reduce the block size on the PXE enabled DP (see
  • Verify that the WDS service is started on the Distribution Point (DP).
  • Ensure that the TFTP port is open between the client computer and the DP.
  • Verify that the permissions on the REMINST share/folder are correct.
  • Check the WDS logs for additional TFTP errors.
  • Verify that the RemoteInstall\SMSBoot\x86 and \x64 folders contain the following files:
  • The fonts exist in SMSBoot\Fonts:
  • The boot.sdi file exists in the RemoteInstall\SMSBoot directory:
Did you solve your problem?
WinPE Boot Issues - Drivers

The most common issues that occur during this phase are driver related. On the whole, the latest version of WinPE contains the vast majority of network and mass storage drivers, however there will be occasions where a needed driver is not included and thus it needs to be imported into the boot WIM. There are a couple of important points to note here regarding this:

  • Only import the drivers you need. Don’t simply import every driver you have into the boot image.
  • Only consider adding NIC or mass storage drivers. It is not necessary to include other drivers.

The SMSTS.log file (located in X:\Windows\temp\SMSTS) is the most useful resource to troubleshoot these issues (remember to enable the command prompt during boot so you can examine this file). If you do not see a line logged with a valid IP address similar to the one below then you probably have a driver issue: 

SMSTS.logFound network adapter "Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)" with IP Address

To confirm this, simply press F8 and run IPCONFIG at the command prmpt to determine whether the NIC is recognized and if it has an IP address.

WIM Files

Also make sure both x86 and x64 boot images exist on the Distribution Point. You can see the WIMs in the following directory (they will also be in the content library):

Ensure that they have been marked Deploy this boot image from the PXE-enabled distribution point in the properties of the boot image.

Did this solve your problem?

Configuration Manager Policy Issues

Another common issue with PXE booting is with Task Sequence deployments. In the example below, the Task Sequence is deployed to an unknown computer but it is already in the database. The first symptom is that the PXE boot is aborted:


Upon further investigation you will notice the following in SMSPXE.log:

SMSPXE.logClient lookup reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777299" ServerName=""><Machine><ClientID/><NetbiosName/></Machine></Identification></ClientIDReply>MP_LookupDevice succeeded: 16777299 1 16777299 1 000:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: device is in the database.Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16777299" ServerName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" packagePath="" BootImageID="" Mandatory=""/></ClientIDReply>Client Identity: 00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: SMSID= OfferID=, PackageID=, PackageVersion=, BootImageID=, PackagePath=, Mandatory=000:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: no advertisements found00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: No boot action. Aborted.00:15:5D:00:19:CA, 32E5B71A-B626-4A4B-902E-7F94AD38B5B3: Not serviced. 

We can see here that when the NBS stored procedures ran, they found no available policy and thus the boot action was aborted. The reverse can also be true (i.e. when a machine is unknown but the Task Sequence is deployed is to a collection of known machines).

Troubleshooting steps to try:

  • Verify that the computer you are attempting to boot exists in a collection that is targeted with a Task Sequence deployment.
  • Ensure that you have checked the Enable unknown computer support PXE setting on the Distribution Point.
  • If you are deploying the Task Sequence to unknown machines, verify that the computers do not already exist in the database.

Did this solve your problem?


Your PXE boot issue is resolved.


It appears that we are unable to resolve your issue by using this guide. For more help resolving this issue please see our TechNet support forum or contact Microsoft Support.


Article ID: 10082 - Last Review: Sep 18, 2016 - Revision: 80