Abstract
Somewhere on the system board of virtually every Wintel computer in existence there is a programatically accessible identifier (a 128-bit number). In theory, this identifier is unique to each system board and may be used to differentiate this particular computer from every other computer. In practice, you cannot rely on this being the case and therefore this identifier is useless.
Detail
In the SMBIOS System Information table (Type 1) there is a field called UUID which is described as "Universal Unique ID number. If the value is all FFh, the ID is not currently present in the system, but is settable. If the value is all 00h, the ID is not present in the system."
So let's assume your program reads this value (either directly or via WMI Win32_ComputerSystemProduct, for example) and the value is not all FFh or all 00h; what two properties would you expect of this universally unique identifier? I suggest you'd want it to be (a) a unique value, and (b) an unchanging value.
Oh dear.
I've probably seen more SMBIOS UUIDs than you've had hot dinners, and I can tell you that the UUID is not always unique and not always constant.
Sometimes the UUID has some kind of "obviously" non-unique place-holder, such as a repeated pattern. For example, it might be 58585858585858585858585858585858 (58 hex = ASCII 'X') or it might be 00020003000400050006000700080009. (And don't forget that, although it looks like a pretty obvious pattern, when read in little-endian byte order, as the SMBIOS UUID field should be (another sorry tale of woe), the UUID you will get is {03000200-0400-0500-0006-000700080009}.) You might write some code that could detect some of the more obvious patterns and discard the UUID as probably non-unique when you find them. By the way, both of these examples are from real computers.
Sometimes there is no discernable pattern in the UUID - it looks random. That is good. Except when you find that somehow every computer at that customer site has exactly the same "random" UUID.
Again, sometimes the UUID looks truly random, and no two computers appear to have the same UUID. And then you restart the computer and now you have a new UUID, completely different to the one the computer had last time you looked! This is pretty rare, but I've seen it happen. A more common problem is that, for some reason, someone in the organisation changed the UUID, maybe deliberately, maybe unintentionally.
I think that for the majority of computers the UUID is a unique constant. But because some computers have bad UUIDs, and because you cannot always tell the good from the bad just by looking at the UUID, the only safe thing to do is assume that all computers have bad UUIDs. And that's a shame. I guess a few people spoiled it for everyone.
Perhaps I misunderstood the SMBIOS documentation. To be fair, it doesn't actually say "if present, this value will be unique to this system board and will never change." It's rather terse on the subject. But it does say, "Universal Unique ID number." So, you know, I assumed the ID would be unique. Perhaps they meant to say, "Potentially Universal Unique ID number. Look, we are just providing somewhere to put a 128-bit number, and if someone sets it to a unique value, and they don't change it, then it will be unique and constant."
It occurs to me that someone might attempt to defend the SMBIOS UUID by saying that it is the responsibility of computer manufacturers to ensure that this field is correctly set, and if the value isn't unique the issue should be taken up with them. I don't mean to be rude, but get real! Imagine you are a little independent software company and you are fortunate to sell your product to a multinational company. They roll it out across the 14 countries in which they operate, onto their 50,000 computers of 57 different brands. There are problems with your product because you were foolish enough to rely on the SMBIOS UUID being a unique constant. But don't worry, just tell MegaCorp to take it up with their computer suppliers. "Right oh, will do" will not be the cheery response from MegaCorp. (This is a purely hypothetical example.)
My advice is, by all means obtain the SMBIOS UUID and show it to the user, but don't write code that relies on the value being unique and constant, because it may not be either.
