HEAT Discovery - How is the ClientID generated per discovered asset

Version 1

    Details

    How is the ClientID generated per discovered asset


    Resolution

     

    This is how the Discovery client agent obtains the client id. This process is common to all platforms: AIX, HP-UX, Linux, OS X, Solaris and Windows. Except that not all platforms have a motherboard UUID. This process may change in future releases of the Discovery client agent.


    Every time the client agent starts it follows this process. It does not matter if this is the first time the client agent has run on this computer, or it has already run many times before, or some previous client agent version has already run many times before. When the client starts, this is what it does.


    Get the motherboard UUID


    Did we get the motherboard UUID? It isn’t always present, especially on older computers. Sometimes the client agent cannot get it – sometimes it’s in an area of memory inaccessible to the client agent. We may be able to use the LANProbe device driver to get at this memory (on Windows). It can also depend on the operating system. In short: we cannot always get the motherboard UUID.

     

    Now look at the motherboard UUID, does it look likely to be unique? For example, if the UUID is 00020003000400050006000700080009 we can be pretty sure it is not actually a unique number. (That’s a real example: it’s the UUID in some Alienware laptops.) There is code in the client agent that attempts to recognize a bogus UUID, and discard it.

     

    One thing you can’t tell by looking: is the motherboard UUID unchanging? Is it the same UUID you got last time you looked for it? You would think that if a motherboard UUID was to be of use to anyone, it would at least be unique and unchanging. But in reality, it may not be. The Compaq Evo Notebook had a motherboard UUID that was different every time you switched it on. We know to ignore the UUID on a Compaq Evo Notebook. [IgnoreUUIDinComputers]

     

    At this point, we may or may not have motherboard UUID. One last thing: if we got a UUID we change its byte order. This is to keep the bytes in the UUID in the same order as we used in earlier Discovery client agent releases.

     

    If we have a valid motherboard UUID, that’s what we will use for the client id for this computer. BUT, there is another step later where we may combine this value with a value derived from a disk serial number. So you need to read on.

     

    If we did not get a motherboard UUID, and if the user hasn’t disabled the option via a client.xml setting [ComputerSerialNumberforClientId], we next get the computer make, model and serial number. We get this from the same place (usually) as we got the motherboard UUID: the SMBIOS tables.

     

    Again, we do not always succeed: sometimes the SMBIOS data is not there, or we cannot access it.

     

    Sometimes the computer make and model are there, but not the serial number. All three elements must be present or we ignore them all.

     

    Now look at the serial number. Is it unique? Oh boy. You would think a sensible thing to do would be to leave the field empty if no serial number was set. But that is not what computer hardware/BIOS developers do. What they do is put a helpful string in there instead, like “Not Available”. Or they might misspell it “Not Avaiable” Or they might put “123456789” or “012345678” or “0123456789” or “1234567890” or “123456890”. Did you notice the missing 7 in that last one? And so on.

     

    Again, there is code in the client agent that tries to identify bogus serial numbers. As you can imagine, this is heuristic: it’s not guaranteed to recognize all possible bogus serial numbers. It looks for patterns and if it finds one it says, this looks unlikely to be a valid serial number and discards it.

     

    Of course, the problem is if we do not identify a bogus serial number the client id may not be unique (because there may be more than one of these computers at a site with identical “serial numbers.”

     

    If we have the computer make, model and serial number we pass them through a digest algorithm to produce the client id. BUT, there is another step later where we may combine this value with a value derived from a disk serial number. So you need to read on.

     

    If we did not get the client id from the motherboard UUID and we did not get the client id from the computer make, model and serial number, or we will be combining the disk model and serial number with the client id, and the user has not disabled the option via a client.xml setting [DiskSerialNumberforClientId], we next try to get a disk model and serial number (we don’t bother with the disk make).

     

    We don’t mind which disk we use, hard disk or CD ROM. It’s just the first disk we find in the system with a model and serial number.

     

    Again we apply the tests for bogus serial numbers.

     

    If we have a disk model and serial number, and we already have a client id from the motherboard UUID or the computer make, model and serial number, we now combine this client id with the disk model and serial number, via a digest algorithm. We do this because maybe we didn’t know that the motherboard UUID is actually not unique – it makes it a little more likely that the client id will be unique. This combining step may be skipped by a setting in client.xml [CombineDiskSerialNumberWithClientId].

     

    If we have a disk model and serial number and we don’t already have a client id from the motherboard UUID or the computer make, model and serial number we now pass the disk model and serial number alone through a digest algorithm to produce the client id.

     

    To summarize where we are now: the client id is one of these

     

    1. Motherboard UUID + digest of disk      model/serial number
    2. Motherboard UUID alone
    3. Digest of computer make, model and      serial number + digest of disk model/serial number
    4. Digest of computer make, model and      serial number alone
    5. Digest of disk model/serial number      alone
    6. None of the above

     

    What determines which of these methods form the client id is the availability of valid data and the user specified settings in client.xml.

     

    If we have a client id formed from any of these sources (except f), that is the client id for this client. Job done. It doesn’t matter what was used last time or what is recorded in local.xml or anything else. The client id is the value obtained from the motherboard UUID or computer make, model and serial number or disk model and serial number or a combination of these as described above.

     

    What if we have f? What if we could not get any of these values, or we did not try to get them because they were disabled in client.xml?

     

    In this case we fall back on the final method, which is as follows.

     

    Is there a client id recorded in local.xml? If there is, use that for the client id.

     

    Actually, it’s not quite that simple. We also look to see if a client id revision number has been specified in client.xml [ClientIdRevision]. If it has it must match the client id revision number in local.xml, or we won’t use the client id from local.xml. The point of this is to provide a mechanism for the user to force client agents to generate a new client id when they are using this final client id generation method. If they change the client id revision number in client.xml, the clients will generate a new id next time they start.

     

    If there is no client id in local.xml, or the client id revision has changed, generate a “random” number and use that for the client id.

     

    The “random” number is derived from a MAC address, if we can find one, and if it is not disabled via a setting in client.xml [MACforClientId], and a system timer (the high-frequency timer QueryPerformanceCounter under Windows and the gettimeofday tv_usec value otherwise).

     

    Next time we get to this point there will be a client id in local.xml: the random number we generated this time. So we will use it for the client id next time and we won’t need to generate a new random number.

     

    A final summary of all possible sources of the client id:

     

    1. Motherboard UUID + digest of disk      model/serial number
    2. Motherboard UUID alone
    3. Digest of computer make, model and      serial number + digest of disk model/serial number
    4. Digest of computer make, model and      serial number alone
    5. Digest of disk model/serial number      alone
    6. The client id already present in      local.xml
    7. A “random” number

     

    This is the order of preference with a being the first choice and g the last choice.

     

    Whatever the method used to determine the client id, once it has been determined it is recorded in local.xml.

     

    The principle is: we prefer to generate the client id from the hardware and not rely on a value stored on disk. But the last resort is to use the value stored on disk, and if there is none to use a random number and store it on disk for next time.

     

                                                                                                                                      We are always trying to improve on this process to achieve the twin goals that the client id be unique and never change. Paradoxically, this means the client id generated by one version of the client agent may change when the next version is released.