Troubleshooting The PXE Service Point and WDS in Configuration Manager 2007
Troubleshooting The PXE Service Point and WDS in Configuration Manager 2007
Troubleshooting The PXE Service Point and WDS in Configuration Manager 2007
21
One of the issues we troubleshoot the most in CSS are ConfigMgr PXE Service Point installs. This article
is based on 4 years of experience troubleshooting hundreds of PXE Service Point installs. The end
result is what we have found causes the majority of issues on PXE Service Points and what works on
most (if not all) configurations. The article assumes that you are not trying to co-host the ConfigMgr
PXE Service Point with stand-alone WDS on the same server. That is a topic for a completely different
article
A previous version of this article appeared over at The Configuration Manager Support Team Blog site.
That article was actually a major revision of the original article titled ConfigMgr 2007: Troubleshooting
PXE Service Point Issues and WDS service not starting. The below is an updated version of the article
and can be considered version 3 of the article. Besides some minor updates in syntax and formatting,
it mainly contains one major new section covering co-hosting DHCP and WDS on the same server
WITHOUT having to configure WDS. It also contains additional checks when R2 or R3 are installed.
UPDATES
2012-02-07
Added information regarding KBs 979720 and 2578865 which fix the error "PXE-E78: Could not
locate boot server".
Moved text regarding checking KB articles for known issues to the start of the article and gave
it its own section "Reviewing KB Articles of Known Issues" since it's probably best to check KB
articles of known issues before trying to reconfigure and reinstall everything.
This is a general guide on properly setting up and troubleshooting the ConfigMgr 2007 PXE Service
Point.
Common errors that are seen at the PXE boot screen when the PXE Service Point is either not
configured properly or experiencing problems are the following:
PXE-E53: No boot filename received
PXE-T01: The specified file was not found.
PXE-T01: File not found
Setting Up IP Helpers
How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point
The guide is written in chronological order of the actions that need to be taken to properly configure a
working and operational ConfigMgr 2007 PXE Service Point. Refer to the appropriate sections as
needed.
The DNS Server service binds to all ports in the Windows Deployment Services port range on a server
that is running Windows Server 2008 R2 or Windows Server 2008
http://support.microsoft.com/kb/977512
The Windows Deployment Service stops responding when you use a PXE service point on a computer
that is running a System Center Configuration Manager 2007 SP1 or SP2 site server
http://support.microsoft.com/kb/976073
PXE service point role does not work if a DHCP server uses DHCP option 43 in a System Center
Configuration Manager 2007 SP2 environment
http://support.microsoft.com/kb/2578865
Error message when Windows Deployment Service clients cannot obtain the boot image from a
Windows Server 2008 R2-based WDS server: "PXE-E78: Could not locate boot server"
http://support.microsoft.com/kb/979720
Setting Up IP Helpers
If the DHCP server, the client PC, and the ConfigMgr 2007 server running Windows Deployment
Services (WDS) and the PXE Service Point are all on the same subnet or vlan, please proceed to the
section "How To Properly Install and Set Up The PXE Service Point".
Otherwise, if either the DHCP server, the client PC, or the ConfigMgr 2007 server running WDS and the
PXE Service Point are on separate subnets or vlans, which is usually the case in most environments,
the first step to take before trying to install and configure the PXE Service Point and WDS is to set up IP
Helpers on the routers. How to do this varies depending on the router hardware manufacturer, but the
general overview is outlined at the below TechNet article:
Configuring Your Router to Forward Broadcasts
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Updating
For further information on how to properly configure IP Helpers on the routers, please contact the
hardware manufacturer of the router.
IP Helpers are necessary because the PXE request generated by the client PC is a broadcast that does
not travel outside of the local subnet or vlan. It only stays within the local subnet or vlan. If the DHCP
server and/or the WDS/PXE Service Point server are not on the same subnet or vlan as the client PC,
they will not see or hear the PXE request broadcast from the client PC. The servers will therefore not
respond to the PXE request. To have the PXE request broadcast transverse between subnets or vlans,
the PXE request broadcast needs to be forwarded by the router to the DHCP and WDS/PXE Service
Point servers so that they can properly respond to the client PC's PXE request.
An alternative to using IP Helpers is setting DHCP Options on the DHCP server, specifically DHCP
Options 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Bootfile Name). However, DHCP Options
can be problematic and may not work reliably or consistently. Furthermore the use of DHCP Options to
control PXE requests is not supported by Microsoft. Therefore the recommended and supported
method of PXE booting client PCs that are on a different subnet than the DHCP or WDS/PXE Service
Point servers is the use of IP Helpers.
For additional information regarding DHCP Options not being recommended or supported please see
the below articles:
Using DHCP Options 60, 66, and 67
http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Using
PXE clients computers do not start when you configure the Dynamic Host Configuration Protocol server
to use options 60, 66, 67
http://support.microsoft.com/kb/259670
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. For more information, please see the below section "Cohosting DHCP and WDS On The Same Server".
It is IMPERATIVE that before continuing that it has been verified 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 the PXE Service Point not to work correctly. When checking
DHCP options, make sure to check options at both the server and scope levels.
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, but in most cases it
proceeds further down an incorrect path and ends up failing.
2.
The one problem with the above recommendations is that in order to run the WDSUTIL command, WDS
has to be first configured. This goes against the best practice of NOT configuring WDS when installing
a ConfigMgr PXE Service Point. However, the two options 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 WDS to be configured:
1.
The UseDHCPPorts WDSUTIL switch is actually the equivalent of setting the registry key value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE!
UseDHCPPorts
to 0 as described in #1 above. Therefore using the UseDHCPPorts WDSUTIL switch is
duplicated and not needed as long as the registry key has been manually set as described in
the above above TechNet article. Please note that if WDS has not been installed, this registry
key may not be present and therefore cannot be set until after WDS has been installed. Step 7
under the section "How To Properly Install And Set Up A New Instance Of WDS And A PXE
Service Point" explains how to set this registry key.
2.
The WDSUTIL DHCPOption60 switch is actually a setting that sets an option on the DHCP
service, not the WDS service. Therefore instead of using WDSUTIL to set a DHCP option, an
equivalent DHCP command can be used to set the same option. This approach allows the
required DHCP setting to be set without configuring WDS and before WDS is even installed.
This approach can be achieved via the netsh command as described in the following MSDN
article:
Configuring DHCP for Remote Boot Services
http://msdn.microsoft.com/en-us/library/dd128762(WinEmbedded.51).aspx
To summarize and shorten the netsh commands described in the above article, close any DHCP
consoles that are open and then run following two commands from an elevated command
prompt:
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 <>).
The above two commands set up and enable DHCP Option 60 on a DHCP server. Normally
DHCP Option 60 is not set up by default on a DHCP server. The first command sets up DHCP
Option 60 but does not actually enable it. The second command actually enables DHCP Option
60.
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. After the reboot the option should
display correctly. This usually happens if a DHCP console was open when the above two
commands were run.
If DHCP is ever moved to another server and removed from the server hosting WDS, the above actions
need to be reversed. To reverse the above actions take the following two actions on the WDS server:
1.
2.
From an elevated command prompt, run the following two commands to remove DHCP Option
60:
netsh dhcp server \\<DHCP_server_machine_name> delete optionvalue 60
netsh dhcp server \\<DHCP_server_machine_name> delete optiondef 60 PXEClient
How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point
The following section lists the steps to ensure that WDS and the PXE Service Point are installed
properly on a server where WDS and the PXE Service Point have never been installed or where WDS
and the PXE Service Point have been properly uninstalled based on the section "Reinstalling WDS And
The PXE Service Point". If WDS and/or the PXE Service Point is currently installed OR has been
previously installed on the server, please follow the instructions under the section "Reinstalling WDS
And The PXE Service Point" first:
1.
If needed, make sure that IP Helpers have been configured. Additionally, make sure that DHCP
Options 60, 66, 67 have NOT been configured. See the section "Setting Up IP Helpers" for
additional information.
2.
If WDS and DHCP are being co-hosted on the same server, please make sure to go over and
take the actions in the section "Co-hosting DHCP and WDS On The Same Server". Please note
that the registry key value that needs to be configured as described in the section "Co-hosting
DHCP and WDS On The Same Server" will not be available until after WDS is finished installing
in Step 5. Instructions on how to set this registry are in Step 7.
3.
Install, but DO NOT configure, Windows Deployment Services (WDS) on the server that will
host the PXE Service Point.
o
If using Windows Server 2003, WDS is installed via the Add/Remove Windows
Components in theAdd/Remove Control Panel.
If using Windows Server 2008 or newer, WDS is installed via Roles in Server Manager.
When installing in Windows Server 2008 or newer, make sure that both
the Deployment Server and Transport Server are installed.
4.
If prompted to reboot after WDS has finished installing, reboot the server.
5.
Once the server has restarted, DO NOT try to manually configure or start the WDS service.
6.
If WDS and DHCP are on different servers, skip Step 7 and proceed to Step 8.
7.
If WDS and DHCP are being co-hosted on the same server, run the following command from an
elevated command prompt to set the required registry key when WDS and DHCP are co-hosted
on the same server:
REG ADD "HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE" /v
UseDHCPPorts /t REG_DWORD /d 0 /f
In reinstall scenarios of WDS, make sure to rerun the above command as any uninstall of WDS
may have reset the above registry key.
If WDS and DHCP are on separate servers, DO NOT run the above command.
8.
9.
If the server where the PXE Service Point is going to be installed already exists under "Site
Systems", right click on the server and choose "New Roles". Otherwise right click on "Site
Systems" and choose "New" --> "Server".
10. In the "General" page of the wizard, make sure that the NETBOIS and FQDN name of the server
are correct and then click on the "Next >" button.
11. In the "System Role Selection" of the wizard, check "PXE service point" and then click on the
"Next >" button.
12. Review the "PXE Service Point Configuration" dialog windows and then click on the "Yes"
button.
13. In the "PXE - General" window, configure the appropriate options as desired and then click on
the "Next >" button.
IMPORTANT! If ConfigMgr 2007 R2 or R3 is installed at the site and the option "Enable
unknown computer support" does not appear on this page, DO NOT continue. This may be an
indication that R2/R3 is not properly installed at the site. To check the status of R2/R3 being
installed, in the ConfigMgr 2007 console navigate to "Site Database" --> "Site Management",
right click on the site code, and then choose "Properties". The status will be listed under the
"General" tab next to the field "R2 Installed"/"R3 Installed".
If R2/R3 is not properly installed, this could cause the PXE Service Point not to answer PXE
requests due to Unknown computer support not being set up properly. This can happen
regardless if Unknown computer support is desired or not.
To resolve the problem, cancel out of the "New Site Role Wizard", reinstall R2/R3 on the site
server, and then start over at Step 8. If the site server is a child server, R2/R3 may need to be
reinstalled on both the parent and child site servers.
14. In the "PXE - Database" window, change any options as needed. In most cases, settings should
be left at their default in this window. Click on the "Next >" button.
15. Click on the "Next >" button and then on the "Close" button.
16. On the server where the PXE Service Point is being installed, navigate to the ConfigMgr 2007
site server log location using Windows Explorer. Usually the log location will be under one of
the following paths:
o
32bit servers
<drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger
64bit servers
<drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration
Manger\Logs
17. Once the log directory has been located in Step 16, open the log file PXESetup.log using SMS
Trace/Trace32.exe. Monitor this log and verify that the PXE Service Point installed correctly. It
may take a few minutes for the installation to start and finish successfully. If this is the first
time the PXE Service Point is being installed on the server, it may take a few minutes for
the PXESetup.log to appear and be created.
Once installed correctly, the last lines in the log should be "pxe.msi exited with return code: 0"
and "Installation was successful." Verify that the line is for the current date and time frame.
In some circumstances, the last lines will read "pxe.msi exited with return code: 3010" and
"Installation was successful, but a reboot is required." If this is the case, make sure to reboot
the server before continuing.
Do NOT proceed until confirmation has been received in the PXESetup.log that installation has
been successful.
18. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating
System Deployment" --> "Boot Images".
19. If BOTH the x64 and x86 Boot Images are not already on any standard Distribution Point (DP),
make sure to put both Boot Images on at least one standard DP. Monitor the "Package Status"
node and ensure that both the x64 and x86 Boot Images properly install on the standard DP.
20. Place BOTH the x64 and x86 Boot Images on the SMSPXEIMAGES$ DP on the server where the
PXE Service Point was created. Monitor the "Package Status" node and ensure that both the
x64 and x86 Boot Images properly install on the SMSPXEIMAGES$ DP.
21. Once the Boot Images have installed on the SMSPXEIMAGES$ DP, open the Services console on
the PXE Service Point server and ensure that the Windows Deployment Services Server service
has started. Additionally make sure that the RemoteInstall folder has been created on the root
level of the one of the drives of the server (usually the same drive where ConfigMgr is
installed).
22. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating
System Deployment" --> "Task Sequences". Right click on each Task Sequence that will be
deployed via PXE and choose "Properties". Click on the "Advanced" tab and ensure that the
option "Use a boot image:" is checked and that an appropriate boot image for that Task
Sequence is selected.
23. In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Software
Distribution --> "Advertisements". Right click on each Advertisement for Task Sequences that
will be deployed via PXE and choose "Properties". Under the "General" tab make sure that the
option "Make this task sequence available to boot media and PXE" is checked.
Notes:
1.
When the PXE Service Point is installed, it will automatically configure WDS and create the
RemoteInstall folder. Once configured, the PXE Service Point installation will then automatically
start the WDS service. For this reason, manual configuration of WDS in the Windows
Deployment Services console is NOT necessary and should not be performed.
2.
Once the PXE Service Point has configured and started WDS, the Windows Deployment
Services console will still show a yellow exclamation mark and display the message "Windows
Deployment Services is not configured". This is normal and does not indicate a problem. No
action or configuration should be taken in the Windows Deployment Services console.
3.
Regardless of the architecture of the Windows OS being deployed, it is IMPERATIVE that BOTH
the x86 and x64 Boot Image are on BOTH a standard DP and the SMSPXEIMAGES$ DP. Make
sure to verify that this has been done.
4.
Do NOT place any other types of packages other than Boot Images in the SMSPXEIMAGES$ DP.
Placing any other type of packages in the SMSPXEIMAGES$ DP, especially OS images, may
cause WDS not to work correctly.
In the ConfigMgr 2007 Admin Console, navigate to "Computer Management" --> "Operating
System Deployment" --> "Boot Images".
2.
Under each Boot Image, click on the "Distribution Points" node. On the right hand panel, right
click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete"
(where <Server_Name> is the name of the server where the PXE Service Point and WDS is
being reinstalled). If the Boot Image is installed on the standard DP, it is NOT necessary to also
delete the Boot Image from the standard DP.
3.
Under each Boot Image that was deleted, monitor the "Package Status" node under the Boot
Image to ensure that the Boot Image is removed from the SMSPXEIMAGES$ DP. To verify, check
the "Package Status" node under the first "Package Status" node. Once the Boot Image has
been successfully deleted from the DP, "Source Version", "Targeted", and "Installed" will all be
0.
4.
Make sure that no other packages are on the SMSPXEIMAGES$ DP. To check if there are any
other packages on the SMSPXEIMAGES$ DP, on the server where the PXE Service Point is being
uninstalled, navigate to the folderRemoteInstall\SMSImages\SMSPKG. The RemoteInstallfolder
will be on the root level of one of the drives of the server. If the folder is empty, all packages
have been removed. If the folder contains subfolders, there are additional packages on the
SMSPXEIMAGES$ DP that need to be removed:
a.
To determine which packages are on the DP, copy down the folder names. The folder
names correspond to the Package ID of the package that is on the DP.
b.
In the ConfigMgr 2007 Admin Console, navigate to "System Status" --> "Package
Status". On the right hand panel all of the packages in the environment will be listed.
On the far right last column the Package ID will be listed. Match up the Package ID
obtained in Step 1
with the Package Name.
c.
Based on the Package Name obtained in the Step 2, locate the package under one of
the following nodes in the ConfigMgr 2007 console:
d.
Under each package, click on the "Distribution Points" node. On the right hand panel,
right click on the "\\<Server_Name>\SMSPXEIMAGES$" DP and then choose "Delete"
(where <Server_Name> is the name of the server where the PXE Service Point and
WDS is being reinstalled).
e.
Under each package that was deleted, monitor the "Package Status" node under the
package to ensure that the package is removed from the SMSPXEIMAGES$ DP. To
verify, check the "Package Status" node under the first "Package Status" node. Once
the package has been successfully deleted from the DP, "Source Version", "Targeted",
and "Installed" will all be 0.
f.
5.
On the server where the PXE Service Point and WDS are being uninstalled, open
the Services console. Locate the "Windows Deployment Services Server" service, right click on
it, and select "Stop". If the service is already stopped, proceed to Step 6.
6.
In the ConfigMgr 2007 Admin Console, navigate to "Site Management" --> <Site_Code> -->
"Site Settings" --> "Site Systems".
7.
Under "Site Systems", click on the server where the PXE Service Point is being uninstalled. On
the right hand panel right click on "ConfigMgr PXE service point" and choose "Delete". In the
"Confirm Delete" dialog box, click on the "Yes" button.
8.
On the server where the PXE Service Point is being uninstalled, navigate to the ConfigMgr 2007
site server log location using Windows Explorer. Usually the log location will be under one of
the following paths:
a.
32bit servers
<drive_where_ConfigMgr_is_installed>\Program Files\Microsoft Configuration Manger
b.
64bit servers
<drive_where_ConfigMgr_is_installed>\Program Files (x86)\Microsoft Configuration
Manger\Logs
c.
Once the log directory has been located in Step 8, open the log file PXESetup.log using
SMS Trace/Trace32.exe. Monitor this log and verify that the PXE Service Point
uninstalled correctly. It may take a few minutes for the deinstallation to start and finish
successfully. Once uninstalled correctly, the last line in the log should be "SMSPXE
deinstall exited with return code 0", "Deinstallation was successful.", and "Removing
PXE Registry." Verify that the lines are for the current date and time frame.
If the deinstall of the PXE Service Point never kicks off, check the sitecomp.log on the parent
site server to determine why it was not able to start the deinstall. In most cases it is due to file
in use issues, which usually can be resolved by stopping the WDS service (Step 5). A reboot of
the server may also help resolve the issue.
Do NOT proceed until confirmation has been received in the PXESetup.log that deinstallation
has been successful.
o
a.
If using Windows Server 2003, WDS is uninstalled via the Add/Remove Windows
Components in theAdd/Remove Control Panel.
b.
If using Windows Server 2008 or newer, WDS is uninstalled via Roles in Server
Manager.
Reboot the server where WDS and the PXE Service Point were just uninstalled.
Once the server reboot completes and the server comes back up, locate
the RemoteInstall folder on the root level of each of the drives of the server. If it exists
on the drive, rename the RemoteInstall folder (i.e.RemoteInstallOld). On most servers,
only one of the drives will have a RemoteInstall folder. However if multiple instances of
the RemoteInstall folder exist, make sure to rename each instance.
If when renaming the RemoteInstall folder you receive one of the below messages:
Windows Server 2008/Windows Server 2008 R2
This folder is shared with other people
If you rename this folder, it will no longer be shared.
Folder: <drive_letter>\RemoteInstall
Share Name: REMINST
or
Windows Server 2003
You are sharing <drive_letter>:\RemoteInstall\SMSIMAGES as SMSPKEIMAGES$. The
folder will not be shared after you move or rename it. Are you sure you want to
continue?
go ahead and make sure to click on either the "Continue" or "Yes" button.
On the server where WDS and the PXE Service Point were uninstalled, delete the
folders BootImages andPXEBootFiles under %systemroot%\Temp (usually C:\Windows\T
emp). It may be necessary to take ownership of the folders and their subfolders to
successfully delete the folders. In some circumstances, it may be necessary to also
navigate down the folder hierarchy and take ownership from the bottom up.
Reinstall WDS and the PXE Service Point using the instructions in the section "How To
Properly Install and Set Up A New Instance of A PXE Service Point".
1.
To eliminate problems with Unknown Computer Support, advertise the Task Sequence to a
collection that has known existing clients. If necessary, use the Computer Association node to
manually create a client record. For best results, create the record based on the SMBIOS GUID
(System UUID) of the PC and NOT the MAC address.
2.
To eliminate certain issues that can occur with mandatory assignments, do not add a
mandatory assignment to the advertisement of the Task Sequences. Instead the Task
Sequence advertisement should be optional.
3.
Verify the properties of the advertisement and ensure that under the "General" tab the option
"Make this task sequence available to boot media and PXE" is checked.
4.
Verify the properties of the Task Sequence and ensure that under the "Advanced" tab the
option "Use a boot image:" is checked and that a boot image assigned under this option.
5.
Refer to the below two KB articles regarding the SMS PXE Cache:
Client machines may fail to boot into PXE if System Center Configuration Manager Service Pack
2 has been applied
http://support.microsoft.com/kb/2019640
Operating system deployment fails in a System Center Configuration Manager 2007 SP1
environment if you deploy a different operating system to a client within one hour of a
previous deployment
http://support.microsoft.com/kb/969113
During testing is suggested to set the value of the CacheExpire key to 60 (60 seconds = 1
minute). This will minimize PXE booting issues being caused by the SMS PXE cache. The
default of the CacheExpire key is either 0 or 3600, both which are 3600 seconds (1 hour). After
testing is complete, the value of this registry setting will need to be determined based on
environmental conditions.
Please note that each time WDS and the PXE Service Point is reinstalled the value of this key is
reset back to 0.
While attempting a PXE boot on a client PC, perform a live monitor of the log SMSPXE.log with
SMS Trace/Trace32.exe. The SMSPXE.loglog can be found under the MP/client logs of the
ConfigMgr site server hosting the PXE Service Point. The location of the MP/client log files is
usually under one of the following paths:
o
32bit servers
<drive_where_ConfigMgr_is_installed>\Program Files\SMS_CCM\Log
or
%systemroot%\System32\CCM\Logs (usually C:\Windows\System32\CCM\Logs)
64bit servers
<drive_where_ConfigMgr_is_installed>\Program Files (x86)\SMS\CCM\Log
or
%systemroot%\SysWow64\CCM\Logs (usually C:\Windows\System32\CCM\Logs)
2.
3.
Monitoring the SMSPXE.log should show the activity in the log when the actual PXE request is
occurring. If no activity is occurring, this is usually indicative of one of the following problems:
o
The PC is on a separate subnet or vlan from the WDS and DHCP servers and IP Helpers
have not been properly set up
Enabling debug logging on the SMSPXE.log will provide additional information in the log and
could assist in troubleshooting why a PC is not PXE booting. To enable debug logging on the
PXE Service Point server for theSMSPXE.log , create the following registry key on the server. A
value does not need to be created under the registry key:
32bit Windows Server
HKLM\SOFTWARE\Microsoft\CCM\Logging\DebugLogging
64bit Windows Server
HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Logging\DebugLogging
Once the registry key has been created, restart the server for the changes to take effect.
4.
Lines in the SMSPXE.log that show PXE requests that contain all Fs as the MAC address similar
to the below line can be ignored:
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID> >
Received DHCP Request smspxe
Executing LookupDevice(<SMBIOS_GUID>, FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF)
smspxe
CDatabaseProxy :: LookupDevice succeeded: 0 0 0 0 smspxe
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUI=<SMBIOS_GUID > > Device
not found in the database. smspxe
MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID > New
client request. RequestID=<Request_ID>. smspxe
These PXE "requests" is the server doing a self check on itself to ensure the PXE Service Point
is up and responding. They can be ignored.
5.
6.
8.
ConfigMgr uses the Boot Images in the RemoteInstall\SMSIMAGES folder to extract Boot Files
from the Boot Images. In addition to the Boot Images, these Boot Files are also needed by WDS
to successfully complete a PXE boot. These Boot Files are placed in the SMSBoot folder under
the RemoteInstall folder. The process of extracting the Boot Files can be seen by monitoring
the SMSPXE.log while the WDS service is restarted. If errors appear in the log during this
process (besides the error described in Step 5 above), the best course of action is to reinstall
the PXE Service Point and WDS as described in the section "Reinstalling WDS And The PXE
Service Point".
9.
The RemoteInstall\SMSIMAGES folder will contain a subfolder called SMSPKG, which will then
contain subfolders for each Boot Image that has been added to the SMSPXEIMAGES$ DP. Each
subfolder under the SMSPKG folder will have the name of the Package ID of the Boot Image.
If any subfolder exists under SMSPKG that is not the Package ID of a Boot Image, they should
be removed from the SMSPXEIMAGES$ DP via the ConfigMgr 2007 Admin console. Only Boot
Images should be added to theSMSPXEIMAGES$ DP. No other type of packages should be
added to the SMSPXEIMAGES$ DP. This is especially true with Operating System Image
Package or an Operating System Install Package (Windows OS source files). Having
an Operating System Image Package or an Operating System Install Package under
the SMSPXEIMAGES$DP will cause issues with WDS.
Instructions on how to remove additional packages from the SMSPXEIMAGES$ DP are provide
above in Step 4 under the section "Reinstalling WDS And The PXE Service Point". However
make sure not to remove the Boot Images as outlined in the instructions.
10. The RemoteInstall\SMSBoot folder should have three folders listed under it, one for each
architecture type - ia64,x64, and x86. The ia64 folder will be empty since ia64 is not an
officially supported platform for ConfigMgr 2007 OSD. However, both the x64 and x86 folders
should have the following files in them:
abortpxe.com
bootmgfw.efi (x64 only)
bootmgr.exe
pxeboot.com
pxeboot.n12
wdsnbp.com
If the folders are missing, empty, or missing files, then BOTH the x64 and x86 Boot Images
may not have been placed in the SMSPXEIMAGES$ DP. If both the x64 and x86 Boot Images
have been placed on theSMSPXEIMAGES$ DP and the folders still do not exist, are empty, or
are missing files, then there may be another problem occurring. The best course of action is to
reinstall the PXE Service Point and WDS as described in the section "Reinstalling WDS And The
PXE Service Point".
Frank Rojas
Support Escalation Engineer
OSD, ConfigMgr, Operating System Deployment, WDS, PXE, Windows Deployment Services
Comments
Andreas
Hi
I think this one also should be in the trouble shouting guide.
Yesterday I had some tftp timemout issue when pxe booting and had multicasting enable.
The server had both the wds and dns installed on it, so the problem is described in this KB 977512 and
my problem was solved after change the registry key.
Frank Rojas
18 Oct 2011 5:27 PM
Thanks for the suggestion. I am going to add the above KB article you referenced along with a few
other KB articles that should be looked at before any troubleshooting takes place,
mariorami
19 Oct 2011 12:50 PM
Thanks Frank for the great guide. I have been dealing with a problem with a specific model of
computers that do not work consistently with PXE. This is the scenario:
These group of computers (among the rest of PCs, they are members of the same all systems
collection) do not get the F12 option line when booting to PXE; they talk to DHCP, get an IP, connect to
WSD and then with the ConfigMgr server but right before they F12 line, they instead get the abort
message. I have found a work around (I do not like it) that if I remove one of the problematic objects
from the ConfigMgr database, all of them start acting normally when booting from PXE in. That work
around only lasts for about 24 hours. The next morning I have to come and do the same.
When I take a look of the smspxe.log file, this is what I found for one of the computers where the "F12"
line to boot to PXE is not present:
______________________________________
MAC=00:E0:4D:82:3A:1B SMBIOS GUID=03000200-0400-0500-0006-000700080009 > Device found in
the database. MacCount=1 GuidCount=510 smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC)
[010.001.050.113:4011] Recv From:[140.198.043.008:68] Len:303 293f070 smspxe 10/7/2011 9:19:36
AM 5564 (0x15BC)
Executing GetBootAction(70085, SCCM) smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC)
No Boot Action for Device (70085) found smspxe 10/7/2011 9:19:36 AM 5596 (0x15DC)
ProcessDatabaseReply: No Advertisement found in Db for device smspxe 10/7/2011 9:19:36 AM5596
(0x15DC)
_________________________________________
Now, when I compare the previous log with a good known PXE boot object, this is what is in the log:
_____________________
Advertisement results: OfferId:GCC2006E OfferTime:21/03/2011 07:54:00 PackageID:GCC00033
BootImageID:GCC00072 PackageVer: PackagePath:\\SCCM\SMSPXEIMAGES$\SMSPKG\GCC00072\
Mandatory:0
___________________________________
What could be different when both of objects are member of the same collection?
Something I just noticed on the PXE boot screen is that those bad computers have the same GUID.
Could that be part of the problem?
Researching I found a blog suggesting to modify NBS_Lookupdevice instance on the SQL database but
it is something I will rather not to do. I do not feel comfortable making changes to the database.
I appreciate if you can help me straight this up.
Thanks.
Mario