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.
Recently when working on a Windows 7 machine I realized it was not installing Windows Updates deployed from the SUP in SCCM 2012 R2.
When checking WUAHandler.log or UpdatesDeployment.log I kept seeing the error 0x8007000e
The error 0x8007000e translates to Not enough storage is available to complete this operation.
The fix was to update the Windows Update Agent from https://support.microsoft.com/en-us/kb/3112343
Windows Update Client for Windows 7 and Windows Server 2008 R2: December 2015
Issues that are fixed in this update
- Assume that you use Software Update agent to apply software updates or determine the software update compliance in System Center Configuration Manager 2007 R2. Windows Update agent scans client computers periodically. In this situation, the scan fails and generates a “Not Required” state for all updates. Additionally, you receive an “8007000E” error message.
After installing this and restating the Windows 7 client machine, I initiated a Software Update Scan cycle from the ConfigMgr agent:
The WUAHandler.log on showed that the agent successfully completed the scan and I was able to install all deployed Windows Updates.
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.
On Server 2012 R2 I was unable to synchronize software updates in my ConfigMgr Current Branch environment. Server Manager kept reporting that the WSUS service was stopped. Each time I would restart the service, it would stop again.
When checking the ConfigMgr logs:
Wsyncmgr.log Sync failed: WSUS server not configured. Please refer to WCM.log for configuration error details.. Source: CWSyncMgr::DoSync
WCM.log Remote configuration failed on WSUS Server.
I previously had no issues with my SUP. Last change was that it was patched as it was a new environment. Upon more research I had applied patch KB3159706
To fix this there were some post update tasks to do which I did not do:
Load up cmd prompt:
cd “C:\Program Files\Update Services\Tools\”
“wsusutil.exe postinstall /servicing”
Then open up Server Manager, add roles and features wizard, in the features section under .Net Framework 4.5, then under WCF Services, select to install HTTP Activation
After this I had to restart my ConfigMgr site server which had the WSUS installed and it was fixed (same issue after restarting the WSUS service, I needed to do a full reboot)
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.
In ConfigMgr 1602, I was using Offline Servicing to schedule some updates in my Windows 10 wim. It failed. Taking a look in OfflineServicingMgr.log I found:
WIM::MountWIMImage returned code 0x80070005
Image Mount failed with error 5
Schedule processing failed
Error code 0x80070005 is also known as “ACCESS DENIED.”
I resolved this by removing the Read Only attribute from the .wim file I was using. It was originally like this when I copied it from the ISO.