I recently applied a hotfix to my SCCM Current Branch environment. When attempting to PXE boot a machine, the smspxe.log reported:
RequestMPKeyInformation: Send() failed.
PXE::MP_InitializeTransport failed; 0x80004005
PXE::MP_ReportStatus failed; 0x80070490
PXE::CPolicyProvider::InitializePerformanceCounters failed; 0x80070002
PXE::MP_LookupDevice failed; 0x80070490
I first tried unchecking the PXE option on the distribution point to remove Windows Deployment Services and then re-enabling PXE support on the distribution point. This was the same issue. After troubleshooting more I tried to open up http://fqdn/sms_mp/.sms_aut?mplist in IE and it displayed a 403.4 Forbidden Access error. My management point is not set to use HTTPS.
I checked the IIS logs on my management point and saw consistent 403.4 forbidden access on directories such as SMS_MP and ccm_system. In IIS on those virtual direcories, I checked the SSL Settings and noticed they were set to “Require SSL”. This is strange because my management point is in HTTP.
The fix was to uninstall the management point and then reinstall it. Keep an eye on MPSetup.log in your SCCM site server logs for when the MP has uninstalled and then re-add the role.
PXE started working again without any errors.
When at a new client site (SCCM Current Branch 1706) and trying to PXE boot a machine by importing the client MAC address into a collection where the task sequence is deployed, the smspxe.log was showing:
, : Not Serviced
, : device is in the database
, : no advertisements found
The device was in the database because I imported it as I am not using Unknown Computer support. There was an advertisement targeted to the MAC address as I deployed my task sequence to the collection which the client was a member of.
The actual issue was that the Boot Image was not distributed to the PXE server as it was a new boot image. Once the boot image was distributed the client could PXE boot without issues.
If you run into this issue, check in the console in Monitoring\Distribution Status\Content Status and make sure the Boot Image is on the PXE enabled DP’s that you are using.
When PXE building a machine with SCCM 1602, the machine did not get a response from WDS. It had the error “No response from Windows Deployment Services server“.
When checking smspxe.log there were no errors and even showed the MAC address of the client communicating with the PXE point/WDS.
After troubleshooting, the easiest fix was to simply restart the Windows Deployment Services service and watch the service start successfully by examing the smspxe.log
Once restarted the client could PXE boot fine.
Using SCCM 2012 R2 and PXE OSD:
When PXE imaging a brand new Surface 4, it would fail at the start and reboot. Pressing F8 to load up a command window and read the X:\Windows\temp\smsts.log it showed “Failed to get client identity (80004005)”
This error is because the date and time is wrong in the BIOS. Only problem with the Surface 4 is that you can’t change the date and time in the BIOS.
The fix was to boot the Surface 4 up into the OEM Windows 10, I realised the date and time was wrong in there so I changed it and applied the latest firmware MSI from https://www.microsoft.com/en-au/download/details.aspx?id=49498
After a few restarts and when the firmware was successfully updated, the imaging process worked fine.
I had an issue in a ConfigMgr 2012 R2 environment with a CAS and multiple Primary Sites. In this site we would import the MAC address of a machine into a collection with the OSD task sequence deployed. When PXE building a machine it would fail on abortpxe.com
When I checked the smspxe.log it said:
Client lookup reply:
XX:XX:XX:XX:XX:XX, XXXXXXXX-xxxx-xxxx-xxxx-xxxxxxxxxxxx: device is in the database.
XX:XX:XX:XX:XX:XX, XXXXXXXX-xxxx-xxxx-xxxx-xxxxxxxxxxxx: no advertisements found
The machine was definitely in the collection with a task sequence assigned. Even if I deleted the computer object out of the DB in the Primary Site, smspxe.log still showed “XX:XX:XX:XX:XX:XX, XXXXXXXX-xxxx-xxxx-xxxx-xxxxxxxxxxxx: device is in the database.”
On the Primary Site the machine was added to, I ran a query to search for the MAC address which found no results.
select distinct SMS_R_System.Name, SMS_R_System.MACAddresses, SMS_R_System.SMBIOSGUID, SMS_R_System.IPAddresses
from SMS_R_System where SMS_R_System.MACAddresses = ##PRM:SMS_R_System.MACAddresses## order by SMS_R_System.MACAddresses
I ended up connecting to the CAS, then did a search for “Resource ID” which was the “ItemKey” above in the SMSPXE.log. It found a machine which was originally joined to the Primary Site I am trying to PXE build from, but was currently assigned to another Primary Site and marked as inactive.
After deleting that object from the CAS in the ConfigMgr console, the machine could build successfully.
This happened in a SCCM 2012 R2 SP1 CU3 environment:
When Deploying an OSD task sequence via PXE, at the PXE boot screen the client was stuck on PXE – TFTP Download: smsboot\x64\pxeboot.n12 ……….
First thing I checked was the smspxe.log on the distribution point. I could see it was in a loop with the line “Looking for bootImage XXX00AA1”
In the ConfigMgr console, I checked Monitoring\Distribution Status\Content Status and verified that the boot image was successfully distributed to the distribution point. It was, but obviously there is an issue.
I went to Administration\Overview\Distribution Points and selected the distribution point having the issue, clicked on Content tab, typed in the boot image name or package ID and clicked Redistribute. Once the boot image had redistributed successfully, I cleared the PXE flag and PXE booted the client again.
It was able to successfully boot and run the Task Sequence.
I was recently trying to PXE build a machine and was getting the error “PXE-E52: proxyDHCP offers were received. No DHCP offers were received”
I checked the SMSPXE.log on my SCCM 2012 R2 Distribution point and I could see that the machine MAC address was in the log, but it wasn’t getting an IP. I checked the DHCP Scope in my DHCP Console for this particular VLAN and noticed this icon which meant “DHCP server alert. No addresses are available from server scopes because the maximum (100 percent) of the addresses allocated for use are currently leased. This represents a failure of the DHCP server on the network because it is not able to lease or service clients.” https://technet.microsoft.com/en-us/library/gg722802(v=ws.10).aspx
I increased the scope and now the machine could PXE boot successfully.
SCCM 2012 R2:
I had an issue today where a task sequence was failing on a particular machine with the error “Failed to get client identity (80004005)”. Other machines were building today with the same task sequence and PXE point.
First thing I checked before the machine restarted during the task sequence was the SMSTS.log by pressing F8. I loaded up CMtrace.exe in the cmd window and browsed to X:\Windows\Temp\SMSTS.log and the error in interest was Failed to get client identity (80004005)
After finding out a bit more information about the machine, I had heard that a Dell technician came out to replace the motherboard. Previously to that it was working. When checking out the BIOS settings I noticed that the date and time was incorrect. The date was set to 08/08/15 (MM/DD/YY) and time was set to 09:32:48PM. It is currently 03/08/2016 and 01:58PM. After setting the correct date and time in the BIOS and clearing the PXE flag the machine imaged successfully.
In my environment I import machines MAC address and machine name into a collection and have the task sequence advertised to that collection. I am not using unknown computer support.
I was trying to PXE boot a client and it kept failing. It would hang on:
Error: PXE-E53: No boot filename received
I initially thought it was a network problem and checked the network configuration on the switches and it was OK. I tested a few other machines and they were able to get an IP from DHCP then contact the PXE service point. So it had to be something linked to this particular client.
On my PXE service point I opened up the SMSPXE.log and searched for the MAC address of the problem client noticed this error:
MAC_ADDRESS: device is not in the database. SMSPXE
MAC_ADDRESS: Not serviced.
I deleted the client and re-imported the client into the collection and it could now PXE boot.
MAC_ADDRESS: device is in the database.
MAC_ADDRESS: using advertisement ZZZZZZZZ
While in the middle of doing an SCCM 2007 to SCCM 2012 migration, my SCCM 2012 PXE Task Sequences would fail after the image had applied and the client was downloading and installing additional applications.
First thing I did before the image failed was to press F8 to load up a command prompt, then type in CMTrace so I could view the logs easily.
The log of interest was the cas.log which told me that the machine was unable to find any distribution points when locating the software. I knew the boundary was correct and that the boundary group was correct also.
The number of discovered DPs(including Branch DP and Multicast) is 0
Anyway, I double checked the boundary groups in SCCM 2012 and noticed that the SCCM 2007 running migration jobs automatically created a boundary group for the SCCM 2007 distribution point and assigned the boundaries I was using to it. This caused my clients unable to locate software to download and install additional programs.
I had migrated everything I needed from 2007 to 2012, so I simply stopped the 2007 migration job and deleted the automatically created 2007 boundary groups.
I then reimaged the machine and the cas.log looked good and could find the distribution point it needed to download the additional software for the Task Sequence.