none
Getting SCCM to ignore the UUID? RRS feed

  • Question

  • This is driving me crazy!

    Executing LookupDevice(03000200-0400-0500-0006-000700080009, 00:1B:B9:A6:95:35)    smspxe    05/08/2008 14:38:38    5496 (0x1578)
    Executing LookupDevice(03000200-0400-0500-0006-000700080009, 00:1B:B9:A6:95:35)    smspxe    05/08/2008 14:38:38    4008 (0x0FA8)
    CDatabaseProxy :: LookupDevice succeeded: 3443 20 3472 1    smspxe    05/08/2008 14:38:38    5496 (0x1578)
    MAC=00:1B:B9:A6:95:35 SMBIOS GUID=03000200-0400-0500-0006-000700080009 > Device found in the database. MacCount=1 GuidCount=20    smspxe    05/08/2008 14:38:38    5496 (0x1578)
    CDatabaseProxy :: LookupDevice succeeded: 3443 20 3472 1    smspxe    05/08/2008 14:38:38    4008 (0x0FA8)
    MAC=00:1B:B9:A6:95:35 SMBIOS GUID=03000200-0400-0500-0006-000700080009 > Device found in the database. MacCount=1 GuidCount=20    smspxe    05/08/2008 14:38:38    4008 (0x0FA8)
    [172.016.000.024:67] Recv From:[000.000.000.000:68] Len:548 19cc12c    smspxe    05/08/2008 14:38:42    5924 (0x1724)
    [172.016.000.024:67] Recv From:[000.000.000.000:68] Len:548 19cb114    smspxe    05/08/2008 14:38:42    3676 (0x0E5C)
    Ignoring req from [000.000.000.000:68] Dest Server:[172.016.000.004]    smspxe    05/08/2008 14:38:42    5924 (0x1724)
    Ignoring req from [000.000.000.000:68] Dest Server:[172.016.000.004]    smspxe    05/08/2008 14:38:42    3676 (0x0E5C)
    [172.016.000.024:4011] Recv From:[172.016.001.191:68] Len:548 1bfffe4    smspxe    05/08/2008 14:38:42    3676 (0x0E5C)
    [172.016.000.024:4011] Recv From:[172.016.001.191:68] Len:299 1c010ec    smspxe    05/08/2008 14:38:44    388 (0x0184)
    Executing GetBootAction(3443, BACKUP)    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    vLastPXEAdvertisementID is NULL    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    vLastPXEAdvertisementTime is NULL    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    GetBootAction: MAC:00:00:E8:82:17:F2 SMBIOS:03000200-0400-0500-0006-000700080009 SMSID:GUID:072D3738-7873-4D04-A829-AEE4EFA2AB32 LastAdv:    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    Advertisement results: OfferId:NBS2019A OfferTime:23/07/2008 09:50:00 PackageID:NBS0019B BootImageID:NBS001A1 PackageVer: PackagePath:\\BACKUP\SMSPKGD$\NBS001A1\ Mandatory:0    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    Advertisement results: OfferId:NBS2019A OfferTime:23/07/2008 09:50:00 PackageID:NBS0019B BootImageID:NBS001A1 PackageVer: PackagePath:\\BACKUP\SMSPXEIMAGES$\SMSPKG\NBS001A1\ Mandatory:0    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    Advertisement results: OfferId:NBS2019A OfferTime:23/07/2008 09:50:00 PackageID:NBS0019B BootImageID:NBS001A1 PackageVer: PackagePath:\\BACKUP\SMSPKGD$\NBS001A1\ Mandatory:0    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    Advertisement results: OfferId:NBS2019A OfferTime:23/07/2008 09:50:00 PackageID:NBS0019B BootImageID:NBS001A1 PackageVer: PackagePath:\\BACKUP\SMSPXEIMAGES$\SMSPKG\NBS001A1\ Mandatory:0    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)
    ProcessDatabaseReply: Found optional advertisement(s): NBS2019A    smspxe    05/08/2008 14:38:44    4008 (0x0FA8)

    I have 20 identical machines with the same (vendor malformed) GUID of "00020003-0004-0005-0006-000700080009" including a couple others from around the school. From the log it is taking it as "
    03000200-0400-0500-0006-000700080009" despite what i've told it. The MACs are all different and i've imported with just the mac and later with the uuid too as correctly entered but it still interprets it.

    I've now got a front desk machine in one classroom imported to a particular collection that is being judged as one from the 20 and being given the advertisement NBS2019A from that classrooms collection when it should be recieving a very different one!

    This 20 pc classroom has yet to be SCCM'd - i'm doing this over the summer you see, gradually capturing and deploying PCs through PXE/CD/USB Stick or whatever from the previous Ghost & Sysprep system we were using.

    I've gone through the whole deleting accounts, restarting PXE Service etc and i'm no more the better for it. If i could just get it to not bother with the UUID we'd be fine as the MACs are all unique despite the shoddy UUIDs. I guess this is a good listen to keep with major vendors rather than the shop down the road!
    Tuesday, August 5, 2008 2:22 PM

Answers

  • I was having the same issue, this is a better option:

    Banned GUIDs

    Various system builders and vendors have failed to implement GUIDs correctly per the PXE spec. The most common errors occur when no GUID is set or when several computers have the same GUID. The duplicate GUID problem seems to be more prevalent on x64-based computers. Because it is difficult to change the GUID on a computer, Windows Deployment Services filters known “bad” (not valid) GUIDs. To configure this behavior, you first must identify any duplicate GUIDs and then add the GUIDs to the BannedGuids registry key (see Windows Deployment Services Registry Entries). Then, if a computer with a banned GUID attempts a network boot, the GUID will be stripped from the packet so that the packet will contain only the MAC address of the client.

    Banned GUIDs

    The registry location of the banned GUIDs is as follows:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE

    • 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).

      Make sure you put in the smbios guid as it appears when you attempt a pxe boot, not as it shows up in the smspxe.log with some of the characters flip flopped, also dont put in the {}, just the guid. Works like a charm.
    Friday, December 4, 2009 1:20 PM

All replies

  • What service did you try?  I know when my SCCM cache got all messed up I was stuck on restarting the wrong service to clear it.  Try restarted the wdsserver and ccmexec service.  The steps I would do is, remove the old computer accounts, restart the services, import the computer accounts with just MAC addresses and try it again.

     

    Hope this is helpful!

    Tuesday, August 5, 2008 3:20 PM
  • I was only restarting the wds service, but i did try the ccmexec as well but no joy. I've ended up removing the accounts of those machines with the intention of pushing out a Ghost image with the agent embedded on it.
    Thursday, August 7, 2008 5:53 PM
  • Sorry to bump an old thread, but I am affected by this issue as well.  This is common with older Dell systems as there wasn't really a standard for System UUID's as there are for MAC IDs.  Keep in mind, this is different from the GUID that is generated by SCCM/SMS .. the System UUID is put in place by the OEM.  Restarting SMS/SCCM services will not do anything because it will not change what is reported from the desktop systems.

    I've already tried to get in touch with Dell to see if they have a utility that can fix this but they have no idea.

    Thanks!!
    Terry

    Thursday, November 12, 2009 9:26 PM
  • i believe the problem was with Dell Optiplex Gx260's (and Gx60) and you should be able to resolve this with a bios update from http://support.dell.com

    some relateed info > http://www.pcreview.co.uk/forums/thread-633009.php


    my SCCM step by step Guides > http://www.windows-noob.com/forums/index.php?showtopic=1064
    Friday, November 13, 2009 7:55 AM
    Moderator
  • Sccm only knows about the uuid if you enter it, right?
    How about just not entering it, and just input the mac address?
    "Everyone is an expert at something" Kim Oppalfens Configmgr expert for lack of any other expertise. http://www.scug.be/blogs/sccm
    Friday, November 13, 2009 9:49 PM
    Moderator
  • Niall:

    The issue is primarily being experienced on GX270s and GX280s ... i'm pretty sure that they all have up-to-date BIOSs but i'll definatly check that out to be sure :)

    Kim,

    That is what we are doing now, when we use the Import Computer Information wizard, we enter in only the MAC ID and the Computer Name.  The problem is that when you boot the machine too PXE, both the MAC ID and SMBIOS/System UUID is picked up by the system and used to search for advertisements.  The only viable solution in our environment right now is to delete the systems that have the duplicate records so we can proceed with imaging.  The other option is bootable media for when this happens, though its not practical for our environment.
    Friday, November 13, 2009 11:44 PM
  • I was having the same issue, this is a better option:

    Banned GUIDs

    Various system builders and vendors have failed to implement GUIDs correctly per the PXE spec. The most common errors occur when no GUID is set or when several computers have the same GUID. The duplicate GUID problem seems to be more prevalent on x64-based computers. Because it is difficult to change the GUID on a computer, Windows Deployment Services filters known “bad” (not valid) GUIDs. To configure this behavior, you first must identify any duplicate GUIDs and then add the GUIDs to the BannedGuids registry key (see Windows Deployment Services Registry Entries). Then, if a computer with a banned GUID attempts a network boot, the GUID will be stripped from the packet so that the packet will contain only the MAC address of the client.

    Banned GUIDs

    The registry location of the banned GUIDs is as follows:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE

    • 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).

      Make sure you put in the smbios guid as it appears when you attempt a pxe boot, not as it shows up in the smspxe.log with some of the characters flip flopped, also dont put in the {}, just the guid. Works like a charm.
    Friday, December 4, 2009 1:20 PM
  • I've figured out the root cause of the issue and how to fix it, provided that your system was built by Dell, or another manufacturer that uses a similar method to Dell.

    The cause of the problem is twofold:

    1. The BIOS is not updated to the latest version
    2. The Service Tag has not been entered into the BIOS

    On GX270/280s, the SMBIOS GUID is derived from the Service Tag to ensure that the number is unique.  However, when the Service Tag is not present, a generic GUID of 4C4C4544-0000-2010-8020-80C04F202020 is used, rather than a unique GUID which is required by apps such as SMS/ConfigMrg, Zenworks, WDS, etc.  When a motherboard is swapped out, most often the dell tech does not add the Service Tag to the BIOS once the swap is complete.  If you do board swaps yourself (like I do) its the last thing you think of. 

    Resolution

    Two things need to be done to resolve this:

    1. Ensure that the BIOS is flashed to the latest version
    2. Enter the Service Tag in the BIOS

    For newer systems, its relatively easy to enter the Service Tag, however for older GX270/280 systems, you will need the CD that came with the shipped motherboard in order to change it.  If you DON'T have it, you can do the following:

    1. Download ASSET_A209.COM and SVCTAG.EXE from FTP://ftp.dell.com/utility
    2. Create a bootable Floppy or USB Stick and copy the two files to the root.  For simplicity i rename ASSET_A209.COM to ASSET.COM
    3. Boot the affected machine from the Floppy/USB
    4. Before attempting to setting the Service Tag, type Asset and press Enter.  Only proceed with the steps below if the Service Tag field is BLANK
    5. You will need to type the following to add the Service Tag to the BIOS : ASSET /S <Service_Tag>
      1. Example: Asset /s 1234567
    6. Before you press Enter, ensure that you have typed in the Service Tag correctly from the front or back of the machine.  Once you have set the Service Tag, you cannot change it again, so I urge you to please read carefully!!!!
    7. After triple-checking that the Service Tag is correct, press Enter then press Y to confirm the change
    8. After the change is done, you can type Asset and press Enter to confirm that the Service Tag is listed correctly
    9. Restart the PC and then attempt to PXE boot the machine to confirm that the SMBIOS GUID has been changed

    I stress, please follow these steps carefully, and ensure that you verify that the Service Tag is entered correctly

    If your affected systems are not Dell, the same overall fix may apply .. but you will need to get in touch with the manufacturer to see if they tie in a Service Tag, Serial Number, Model Number or any other kind of unique number from the BIOS into the SMBIOS GUID

    • Proposed as answer by nuttyrat Tuesday, January 5, 2010 8:38 PM
    • Edited by nuttyrat Tuesday, January 5, 2010 8:45 PM Made it more Generic, neglected the fact that not everyone uses Dell .. .OOPS! :)
    Tuesday, January 5, 2010 8:38 PM
  • marshbomb,

    I like that, that is an elegant second option to the problem for systems that do not have Service Tag dependancies like Dell systems seem to do.  I'll have to find some time to test this !!!!

    Tuesday, January 5, 2010 8:40 PM
  • I know this is an old post now, but I just wanted to say thank you VERY much for this. Your registry tweak works a treat!!

    Thursday, August 9, 2012 10:28 AM
  • I realize that this is an old post but I have a couple of concerns, We are having this issue using Datalux IPX-E901 series All in ones with MSI motherboards. All  the machines have the same UUID in the bios, 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09. I was able to get one machine to boot to the Pxe boot on our SCCM 2012 DP but now no more will boot. We are wondering if the fix posted here is valid for 2012 and what else it could effect.  These are the last machine I need to test in my implentation of SCCM for OSD. Any help would be greatly appriciated.
    Friday, December 21, 2012 2:50 PM