Advertised SCCM OS deployment task sequence does not PXE boot on a new machine

You may be having trouble deploying an operating system to a brand new machine even after you have advertised an OS deployment task sequence to it’s correct MAC address.

You might be receiving any one of the following errors:

  • PXE Boot aborted. Booting to next device
  • MAC=70:71:BC:88:C3:BC SMBIOS GUID=00000011-4918-8015-BF5A-888888888788 > Device found in the database. MacCount=1 GuidCount=1
  • The SMS PXE Service Point intructed device to boot normally since it has no PXE advertisement assigned
  • The SMS PXE Service Point instructed device to boot normally since it has no PXE advertisement assigned

Generally on any machine the MAC address and the SMBIOS GUID (System Management BIOS) (aka System UUID) need to be unique. The SMBIOS GUID is stored in the computer’s BIOS. The SMS GUID is separate to this altogether which is at the software level, what I am explaining here is at the machine hardware level.

Sometimes OEM (Original Equipment Manufacturers) computer vendors release machines with an SMBIOS GUID exactly the same as others and if you already have another machine in your SCCM database with the same SMBIOS GUID, SCCM won’t allow another machine with the same SMBIOS GUID. This is what gives you the error GuidCount=1, SCCM has found another machine with the same SMBIOS GUID in it’s database.

For example, imagine you have a brand new machine with the same SMBIOS GUID as an existing machine, if you have an OS task sequence advertised to this machine’s MAC address only as a direct collection membership, when your machine PXE boots, the order of events are: 1): the SCCM database is queried first for available task sequences that are advertised to that machine by SMBIOS GUID, if it doesn’t match up with a record in SCCM, 2): the MAC Address is used. SCCM looks at both the MAC address and SMBIOS GUID together, so in the case of my example the MAC address is okay, however the SMBIOS GUID is not okay (it’s already assigned to another machine) and SCCM throws a wobbly.

Duplicate SMBIOS GUID.

You can setup the this query in SCCM to display all machines and their SMBIOS GUID’s to prove that SCCM isn’t lying and does actually have duplicate SMBIOS GUID’s:

select SMS_R_System.Name, SMS_R_System.MACAddresses, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.SMBIOSGUID from  SMS_R_System

Resolution: This needs to be fixed at a hardware level. You will need to contact the OEM vendor for a fix.

Alternative resolution: Another solution if you’re using Windows Deployment Services with SCCM, you can setup a BannedGuids registry entry for WDS which strips the SMBIOS GUID from the network packet of the machine which is PXE booting before the network packet is passed to SCCM. SCCM only sees the MAC address.

I haven’t tested this yet, however it sounds very promising. The registry location of the banned GUIDs is as follows:


  • Name: BannedGuids
  • Type: REG_MULTI_SZ
  • Value: GUID strings, with one string per line. The correct format is as follows: {1acbf4473993e543a92afadb5140f1c8}, which should match what you see when you perform a PXE boot on a client (without dashes).


  1. Great article! the registry fix works by the way, except the format I used included the dashes, without them didn’t seem to work for me.

  2. it support

    thanks – that worked for us!
    and the command is wdsutil /set-server /BannedGuidPolicy /Add /GUID:xxxxxx

  3. Nice post. I used to be checking constantly this blog and I am impressed! Very helpful information specifically the ultimate part :) I care for such information much. I used to be seeking this particular information for a very long time. Thanks and best of luck.

Leave a Reply to it support Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s