Justin Chalfant's Blog

Justin Chalfant's Configuration Manager Blog

PXE Boot Gotcha’s in a Configuration Manager 2012 Hierarchy – No Advertisements Found

PXE Boot Gotcha’s in a Configuration Manager 2012 Hierarchy – No Advertisements Found

  • Comments 5
  • Likes

Scenario:

I was recently working with a customer who had a CAS and 9 primary sites. We were noticing machines were receiving abortpxe when attempting to PXE boot. This happens when the machine PXE booting does not have a OSD task sequence targeted to it.

The interesting thing was there was a OSD task sequence targeting the “All Unknown Computers” and “All Desktops and Servers” collection for PXE and Media based deployments. In theory, this would mean that any machine that’s ever PXE booting should have a task sequence targeting it.

Troubleshooting:

The first thing I did was look at the SMSPXE.log on the DP the machine was PXE booting from. I noticed the following (Notice ItemKey=16787541 this is referring to the ResourceID of a ConfigMgr Client):

  • Client boot action reply: <ClientIDReply><Identification Unknown="0" ItemKey="16787541" ServerName=""ServerRemoteName=""><Machine><ClientID/><NetbiosName/></Machine></Identification><PXEBootAction LastPXEAdvertisementID="" LastPXEAdvertisementTime="" OfferID="" OfferIDTime="" PkgID="" PackageVersion="" PackagePath="" BootImageID="" Mandatory=""/></ClientIDReply>
  • XX:XX:XX:41:A1:A2, 4C4C4544-0057-3410-8039-C7C04F465631: no advertisements found

The first thing I did was go to the Devices node added the ResouceID column on the CAS and search for “16787541” the ItemKey from the SMSPXE.log. I went to the properties of the device and verified that device did infact have a task sequence targeting it.

The client we were looking at was assigned to site 001 but was using a PXE enabled DP from site 002. This customer often had machines roam to other locations that could be part of another primary site.

The only database that is treated as being definitive for a PXE enabled distribution point is the database of the primary site that the PXE enabled distribution point is in.  That means that a PXE enabled distribution point in a hierarchy will only know of task sequence deployments to KNOWN clients if it’s in the same site as the distribution point.

We also had a few unknown machines that were unable to boot. This was for older Dell laptops. It ended up being caused and duplicate SMBIOD GUID’s. When a machine PXE boots it check if there is a Mac address or a SMBIOS GUID for the device. If there is not, the device would be considered an unknown machine. Since some of these machines has duplicate SMBIOS GUID’s, it would think the device is a known machine and the other machine with the same GUID would sometimes be assigned to a different primary site. This would cause the machine to not see the task sequence deployment.

Workaround:

There are a few workarounds for this scenario:

  1. Use site based bootable media (Will need to be created for the site the client you need to image is assigned to)
  2. Have a process so that if you have a client from Site 001 and they roam to Site 002 location then you re-assign the client to site 002 before trying to PXE boot the machine from a site 002 PXE enabled DP.
  3. Have multiple PXE enabled DP's for each site that needs to be PXE booted at each physical location. (Yes, probably not feasible)
  4. Design your primary sites so that machines will rarely need to be imaged outside of the site where the machine is assigned.
  5. Delete the record from the ConfigMgr console for the client you need to PXE from other sites prior to PXE booting. This will cause the client to become unknown then it will be able to PXE from any site in the hierarchy.
  6. Run the task sequence from software center.

This behavior is by design and won’t likely change.

Comments
  • Do you have any idea why Task sequence won't update after deploying?

  • What do you mean by won't Update?

  • Ever ran into TFTP Open Timeout?

  • @ help. This is likely an issue outside of ConfigMgr is there any activity in the SMSPXE log when you get this error. If you machine is in a separate subnet than the PXE enabled DP you likely need IP Helpers configured.

  • Sorry to get back to you know Justin. Didn't do much with SCCM in awhile. Right now, I still get the error and unable to to located the SMSPXE log.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment