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.
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.
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.
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:
To create a query based Collection that finds all PCs with a particular SMBIOS GUID:
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.
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
For both solutions, use the methods described in the Cause section to discover what PCs are affected by duplicate SMBIOS GUIDs.
Frank RojasSupport Escalation Engineer
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?
I am curious to know if anybody out there has tried this fix to the duplicated SMBIOS GUID issue:
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.
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.
I have been suffering the same issue and I have solved it modifying two stored procedures following the instructions of this post:
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.