This is a topic I have been meaning to post about for a while. It’s a bit of a gem I found and anyone who works with Configuration Manager especially if deploying operating systems should know about. I first came across this problem when setting up operating system deployment through System Center 2012 Configuration Manger.
This is the problem where if you have more than one machine with the same UUID (Universally Unique Identifier) also known as a GUID (Globally Unique Identifier) it becomes a massive pain when booting from PXE to deploy an OS. In theory every machine is supposed to have a different UUID a bit like every machine is supposed to have a different MAC address which is unique to that machine. However in the real world this isn’t always the case. Although I am yet to come across a duplicate MAC address I have come across plenty of duplicate UUIDs. Mainly on ASUS machines. Unfortunately the first set of machines I was working with (yes you guessed it!) was a set of ASUS machines. So it took me a bit of time to work out what the problem was. At first I assumed a problem with the deployment server as I hadn’t by this point successfully deployed an OS using Configuration Manager. However once I tried a machine with a unique UUID I found out that there was no problem with the deployment server but a problem with the machines themselves.
It’s quite easy to spot a generic UUID. Some manufactures will just use one which looks like this: 03000200-0400-0500-0006-000700080009. Pretty unimaginative aye? This is where the problem lies. When the machine tries to boot from PXE the Windows Deployment Service looks at the UUID to see if there is any deployments available to that machine. However if you have more than one machine with the same UUID it will just look at the last machine added to Configuration Manager with that ID. Which most of the time isn’t the machine you are working on! Especially when you have 25 machines with the same UUID. This means that the machine will fail to boot to PXE due to WDS thinking there is no deployments available.
The first fix I came across which got me half way there is covered here on TechNet. First you have to open up Regedit and navigate to:
Next you have to create a Multi-String Value registry entry and call it ‘BannedGuids’. In this registry entry you need to add the problem UUID (which for me was the one stated above). More than one problem GUID/UUID can be added here by inserting one per line. Below is a screen shot of how it should look with the added registry entry.
This fix basically tells the windows deployment server that if it gets a request from any GUID you have specified in this registry entry to ignore the GUID and use the MAC address of the requesting machine as the identifier. This is fantastic! Problem solved! Right? . . . or not.
This now allows the machine to boot into PXE but when you come to choose a task sequence to run you will get a message along the lines of ‘No Task Sequences Available’. This is because Configuration Manager now checks its database to check which if any deployments are available to the machine. And yes you guessed it! Configuration manager uses the UUID to identify the machine. Meaning that the machine it looks up in the database may not be the one you are working on . . . how annoying.
After doing some searching the best I could find was a few people with the same problem. And the best advice Microsoft give is to contact the hardware manufacturer and see if a patch is available for the BIOS to change the UUID. Basically their saying it’s not our problem. Some manufactures do provide a patch to change the UUID so it is actually unique. I couldn’t find anything obvious and didn’t have the time to wait around while support twiddled their fingers.
After being at a loose end for a while I came across a piece of information which was just what I was looking for. A way to make Configuration Manager use the MAC address of the machine instead of the UUID much like we did with the Windows Deployment Service. This fix involves changing 2 stored procedures in the configuration Manager database.
To apply this little fix you first need to login to Microsoft SQL Server Management Studio which is hosting the database for you Configuration Manager. Next you need to expand Databases and then again expand you Configuration Manager database. Under here you need to go to Programmability > Stored Procedures. In here there are 2 procedures you need to modify NBS_LookupDevices and MP_GetClientIDFromSmbiosID.
Before you do anything it is always wise to create a backup. A database backup is advised as a good measure whenever you have to make alterations.
First navigate to NBS_LookupDevices and right click Modify. Here you need to edit this line:
ON xref.MachineID = aux.ItemKey AND aux.SMBIOS_GUID0 = @SMBIOS_GUID
and change it to:
ON xref.MachineID = aux.ItemKey AND aux.SMBIOS_GUID0 = @SMBIOS_GUID + '.'
It should look like this.
Once you have done this click Execute at the top which will apply the changes you have just done.
Second navigate to MP_GetClientIDFromSmbiosID and again right click Modify. You need to change this line:
WHERE  (M.SMBIOS_GUID0 = @vchSmbiosID)  and (IsNull(M.Obsolete0,0) != 1)
and change it to:
WHERE  (M.SMBIOS_GUID0 = @vchSmbiosID + '.')  and (IsNull(M.Obsolete0,0) != 1)
It should again look like this.
Again click Execute to apply the changes.
And that’s it! You should now find when you boot into PXE in the background it will use the MAC address as the identifier rather than the UUID. This means that it will display the task sequences assigned to that machine allowing you to deploy an operating system.
This fix was originality designed for System Center 2007 Configuration Manager. But I have tried and tested it on System Center 2012 and 2012 R2 and it still seems to work like a charm.
The only note is if you run a service pack update or you upgrade Configuration Manager to a newer version you have to reapply the changes to the stored procedures.
