No Assigned Task Sequence when initiating deployments caused by duplicate SMBIOS GUIDs (System UUIDs) in System Center Configuration Manager 2007

No Assigned Task Sequence when initiating deployments caused by duplicate SMBIOS GUIDs (System UUIDs) in System Center Configuration Manager 2007

  • Comments 13
  • Likes

This article is regarding an issue we originally blogged about over at The Configuration Manager Support Team Blog regarding issues with PXE booting caused by duplicate SMBIOS GUIDs.. At the time that we wrote the article we really didn’t have a good solution or workaround on the ConfigMgr/WDS side to fix the issue. Since the issue was a problem caused by an OEM not adhering to industry standards, the only recommendation we could make was contacting the OEM for a fix at the hardware level.

Although the recommendation is to still fix the root cause of the issue by obtaining and running a fix from the OEM, we have recently discovered a feature of WDS called BannedGUIDs that allows us to work around the issue. This is especially useful in environments where there may be a large amount of duplicate SMBIOS GUIDs or where a BIOS fix or utility is not currently available from the OEM vendor. The below article outlines the issue and how to use the WDS workaround.

Note: We are planning to publish the below article as a KB article. If not already available, it should be available soon as KB2591483.

 

No Assigned Task Sequence when initiating deployments caused by duplicate SMBIOS GUIDs (System UUIDs) in System Center Configuration Manager 2007

 

Symptoms

When trying to start a ConfigMgr 2007 OSD Task Sequence on a PC, ConfigMgr fails to find a Task Sequence to run on the PC.

  1. If booting from boot media, the follow message well appear after booting into WinPE:

    There are no task sequences available for this computer.
    Examining the SMSTS.log obtained from X:\Windows\Temp\SMSTSLog will show the following message:
    No assigned task sequence. TSMBootstrap
    Setting wizard error: There are no task sequences available for this computer. TSMBootstrap

  2. If booting from PXE, the PXE boot screen will show the following message:

    TFTP Download: smsboot\<arch>\abortpxe.com
    PXE Boot aborted. Booting to the next device...
    The SMSPXE.log on the PXE Service Point server will contain the following messages at the time the PXE boot was attempted:
    MAC=<Mac_Address> SMBIOS GUID=<SMBIOS_GUID> > Device found in the database. MacCount=x GuidCount=y smspxe
    ProcessDatabaseReply: No Advertisement found in Db for device smspxe

If the PC is Known (either an existing client or prestaged via the Import Computer Information Wizard), it has been verified that the Task Sequence Advertisement is targeted to a Collection that the PC is a member of.

If the PC is Unknown, it has been verified that the Task Sequence Advertisement is targeted to a Collection with the Unknown Computer objects (x64 Unknown Computer and/or x86 Unknown Computer) and that the PC is truly unknown and does not exist in the ConfigMgr database.

 

Cause

This problem can be caused by more than one PC in the environment having the same SMBIOS GUID. ConfigMgr refers the SMSBIOS GUID as System UUID. Similar to a MAC Addresses being unique to a NIC card, the SMBIOS GUIDs should also be unique on each PC. Two PCs should not have the same SMBIOS GUID. The SMBIOS GUID is stored in the PC's BIOS.

The problem occurs because when the ConfigMgr database is queried for available Task Sequence that are advertised to that PC, it does so first by using the PC's SMBIOS GUID. Each record in the ConfigMgr database records the PC's SMBIOS GUID under the attribute System UUID. If it does not match a record with the SMBIOS GUID, it then uses the MAC Address instead.

However, if multiple PCs have the same SMBIOS GUID in the environment, when the query on the SMBIOS GUID is done on the ConfigMgr database, it may find the record for a PC other than the one that the Task Sequence is advertised to. If the Task Sequence is not also advertised to the PC that it found, it will return back that there are no task sequences available for the computer.

NOTE: Do not confuse the SMBIOS GUID with the SMS GUID. They are two separate, different, and distinct items. The SMBIOS GUID is a unique hardware identifier used universally, whereas the SMS GUID is a unique ConfigMgr client ID used exclusively by SMS/ConfigMgr.

To see if the problem exists in the environment, create a query or collection in ConfigMgr based on the suspected duplicate SMBIOS GUID using the System UUID attribute. If more than one PC has the same SMBIOS GUID, then the problem exists.

To obtain the SMBIOS GUID from a PC having the problem, use one of the below methods:

  • At a command prompt, run the command:

    wmic

    When the prompt

    wmic:root\cli>

    appears, type in the command:

    csproduct get uuid

    The SMBIOS GUID for the PC should be displayed.

    Please note that in scenarios where the PC does not have a bootable OS, the PC can be boot into WinPE via PXE or boot media, and then the above commands run from a command prompt window running in WinPE.

  • On most PCs the SMBIOS GUID appears next to GUID: at the PXE boot screen. To pause the PXE boot screen so that the SMBIOS GUID can be copied down, hit the Pause/Break key on the keyboard while at the PXE boot screen. This can be done even if a PXE server does not exist in the environment. However to view the PXE boot screen, PXE booting must be enabled in the BIOS of the PC and either F12 may need to be hit to get to the PXE boot screen or the NIC may need to be temporarily set as the first boot device on the PC.

  • For PCs that successfully boots into WinPE from boot media but fails to receive an advertised Task Sequence, the SMBIOS GUID will be displayed in the SMSTS.log next to the line

    Setting SMBIOS GUID =

  • For PCs that do not successfully boot from PXE, the SMSPXE.log on the server hosting the PXE Service Point can be examined for the PC's SMBIOS GUID. The line that contains this information will be something as follows:

    MAC=<Mac_Address> SMBIOS GUID=<SMBIOS_GUID> > Device found in the database. MacCount=x GuidCount=y

    Note: Ignore the lines in the SMSPXE.log with all Fs for the MAC Address:

    MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=<SMBIOS_GUID> > Device not found in the database. smspxe

    These lines are the PXE Service Point performing a self-check on itself by performing a PXE request to itself to make sure the PXE Service Point is up and operational.

To create a query based Collection that finds all PCs with a particular SMBIOS GUID:

  1. In the ConfigMgr console, navigate to Site Database --> Computer Management --> Collections

  2. Right click on Collections and choose New Collection

  3. On the General page of the New Collection Wizard, give the Collection a name next to the Name: textbox and then click on the Next > button.

  4. On the Membership Rules page of the New Collection Wizard, click on the yellow Query icon.

  5. Under the General tab of the Query Rule Properties window, give the query a name next Name: textbox and then click on the Edit Query Statement... button.

  6. In the Query Statement Properties window, click on the Criteria tab, and then click on the yellow starburst button.

  7. In the Criterion Properties window, make sure that the Criterion Type: is set to Simple value and then click on the Select... button.

  8. In the Select Attribute window:

    • Next to Attribute class:, select System Resource

    • Next to Alias as:, leave at the default of <No Alias>

    • Next to Attribute:, choose System UUID

  9. In the Select Attribute window, click on the OK button.

  10. In the Criterion Properties window, make sure that the Operator: is set to is equal to.

  11. In the Criterion Properties window, next to the Value: text box, enter in the full SMBIOS GUID obtained from the PC. Make sure to enter all 32 characters and the 4 dashes that are part of the SMBIOS GUID.

  12. In the Criterion Properties window, click on the OK button.

  13. In the Query Statement Properties window, click on the OK button.

  14. In the Query Rule Properties window, click on the OK button.

  15. On the Membership Rules page of the New Collection Wizard, click on the Next > button.

  16. On the Advertisements page of the New Collection Wizard, click on the Next > button.

  17. On the Security page of the New Collection Wizard, click on the Next > button.

  18. When the New Collection Wizard completes, click on the Close button.

The newly created Collection should display all of the PCs affected by the duplicate SMBIOS GUID. Repeat the above steps if more than one set of duplicate SMBIOS GUIDs exist in the environment.

 

Resolution

Please note that this problem is caused by an OEM vendor not adhering to industry standards. It is not an issue with ConfigMgr.

There are two possible solutions to the problem

  1. Obtain a BIOS update or utility from the OEM hardware vendor that fixes the duplicate SMBIOS GUIDs and gives each PC a unique SMBIOS GUID.

  2. To work around the problem, use the BannedGUIDs registry entry of WDS as described in the following TechNet articles:

    Windows Deployment Services Registry Entries
    http://technet.microsoft.com/en-us/library/cc733103(WS.10).aspx#banned

    How PXE Requests Work
    http://technet.microsoft.com/en-us/library/cc725614(WS.10).aspx#Banned

    The BannedGUIDs registry entry "ignores" any SMBIOS GUIDs that have been entered under the key and instead uses the PC's MAC Address.

    Please note that this solution does not actually fix the root cause of the problem and only works around it. When possible, it is recommended to use Solution #1. However in environments where there may be a large amount of duplicate SMBIOS GUIDs or where a BIOS fix or utility is not currently available from the OEM vendor, the BannedGUIDs registry can be used to work around the issue until the duplicate GUIDs issue can be permanently resolved.

For both solutions, use the methods described in the Cause section to discover what PCs are affected by duplicate SMBIOS GUIDs.

 

Frank Rojas
Support Escalation Engineer

Comments
  • We got the vendor to provide a BIOS update to modify the UUID.  The DDR in SCCM still displays the old UUID.  How do we get the UUID reflected on the DDR?  We've tried HW inventory and reinstalling the client.

  • The best way is probably to delete the record of the PC in the ConfigMgr 2007 Admin console, and then force the PC to report hardware inventory again via the "Harware Inventory Cycle" action. This should recreate the record in ConfigMgr 2007 with the new information. You may also have to run the "Discovery Data Collection Cycle" action for it to recreate the record properly. You should not need to reinstall the client.

  • I have a strange issue with my pxe. Newly imported PC´s do not pxe boot. Reinstallations do pxe boot!

    If i restart the WDS service on the sccm server then the next newly imported PC´s can pxe boot. But after that the issue is back.

    I have this in my smspxe.log

    MAC=70:F3:95:19:34:3C SMBIOS GUID=57A17D00-FDF9-11E0-91C2-904C19ABCEC4 > Device not found in the database. smspxe 12/6/2011 1:03:13 PM 2304 (0x0900)

    I have made a query for its SMSBIOS GUID but it finds nothing. This makes me think this is not just a matter of a duplicate. As i mentioned this seem to happen with every newly imported PC.

    I have reinstalled WDS/PXE point twice but it does not seem to have helped.

    Any idea what could be wrong here?

  • Your probably running into the PXE cache issue as mentioned in the article. See KB2019640.

  • Banning the GUID did the trick to be able to PXE boot, but I am still not able to image those computers with the duplicate GUID. The configMgr db does not recognize those computers. I created a collection and query for all of those computers with duplicate GUID (over 700) and then I advertised my image to that collection but still no success. I always get the message "There is no task sequence available for this computer".

    I am waiting on the OEM hardware vendor to see if they have a patch that creates a unique GUID for each of those computes.

    I read an article the other day about a way to fix my problem by editing the ConfigMgr database to make it look for MACs instead of GUID, but I am not confident with doing that....

    I would like to know if any of you have tried that fix.

    At his point offline imaging is the only choice I have.

  • Although I have heard about the fix regarding modifying the stored procedure in the ConfigMgr database, we normally do not recommend directly editing the database except for extreme cases where there is no workaround or other fix. Based on the information you have given, I cannot really say what is going on. However is you open a case with CSS we can take a look at it and see if we can get it working without having to modify the database.

  • My SCCM 2007 SP2 R3 server does not have the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE probably because it doesn't have WDS installed.

    It is normal, i need to create this key yet?

    Thank you.

  • I am curious to know if anybody out there has tried this fix to the duplicated SMBIOS GUID issue:

    <URL Removed>

    I am still trying to figure out how to be able to image with Configmgr those computers with the same SMBIOS GUID. I was able to make them PXE boot by banning the GUID, but when boot to ConfigMgr wizard I can make them see the task sequences. I have not tried to solution mentioned in the link above (I am tempted since nothing seem to work) and I am very cautious modifying the DB.

    Thank you.

  • The above blog post is an updated version of the original blog post that the above link mentions. The above blog post contains the additional workaround of using the BannedGUIDs registry key. Microsoft does not suggest making changes directly to the DB except in extreme circumstances, and this is not one of them. Additionally the changes mentioned on the above link regarding modifying the ConfigMgr DB would only get you past the PXE boot and is the equivalent of using the BannedGUIDs registry key. I would not recommend modifying the DB.

  • Hi,

    I have been suffering the same issue and I have solved it modifying two stored procedures following the instructions of this post:

    <URL Removed>

    Regards

  • Thank you for your input. However pelase be aware that modifying the stored procedures is not only not supported by Microsoft, but also puts your environment in an unsupported scenario. The modified stored procedures have not been thoroughly tested by Microsoft. Changing them may result in unknown and unexpected behaviors. We strongly recommend against modifying the stored procedures for these reasons. There is also no reason to modify the stored procedures as there is a fully supported solution which is to use the BannedGUIDs registry entry of WDS.

  • Yes but as mariorami points out, the BannedGUIDs entry works only to fix the PXE part. It doesn't fix the issue where the task sequence isn't found. Is there a supported fix for this? We have a lot of scale and till devices with this problem and it's driving me nuts.

  • Frank.  I am running into a scenario were it is not a OEM issue.  I had my task sequence fail (domain join failed) and it is in a workgroup.  There are now two client entries for the same machine, with the same GUIID (only one shows up in the console, but I can see two in v_R_System).  I am not using PXE boot, are there any workarounds to get SCCM to honor the deployment?  I am using SCCM 2012 SP1 CU2.

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