Question

What does the error Host's UUID does not match expected UUID for that host ID mean while trying to activate licenses from FlexNet Operations, and in what scenario will this error will be reported?

Answer

This is an investigation of possible scenarios that could result in the error that is being seen where the UUID of the server is not matching the record within FlexNet Operations Cloud.

A customer has reported a growing number of instances where the server sends a request to the back office but gets a response that, when processed, results in an error that the UUID does not match. This indicates that the record that FlexNet Operations has for the server, where the UUID is contained, is somehow different from the UUID contained in the server database.

Generally, the flow is, the server sends a request to FlexNet Operations and if the request does not contain a UUID, then FlexNet Operations will create one and send it back in the response. The server will process this into the TS and it will be used in subsequent requests to the back office.

If the request already contains a UUID but there is no record of the hostid in FlexNet Operations, then the record for the hostid will be created with the UUID in the request, rather than a new one generated.

Why is the UUID of the Server Changing?

To answer this we need to look at possible scenarios and see how this could possibly happen:

1. The server is using both a UAT and Production back office. It is possible that the server has activated a license from a UAT FlexNet Operations during some testing period. In this case, a UUID will be generated in the database of the UAT FlexNet Operations and returned back to the trusted storage of the license server. If the server trusted storage is then removed and the server now talks to the production FlexNet Operations, this will also generate a UUID that will be returned back to the trusted storage of the license server. If the license server then talks to UAT again, we will get the issue. This scenario does not seem likely for a production system, i.e. the likelihood of a customer machine talking to both UAT and Production back offices.
2. The server has been cloned. Another possibility is that the customer is cloning the host of the server in such a way that there are two license servers running that have the same hostid and both are talking to FlexNet Operations. It is possible that the first instance of the server has a UUID that FlexNet Operations currently has in its database. The server is then obsoleted in FlexNet Operations, removing that record, and a new server is started on a clone of that first host. This will then get a new UUID. If the first server comes along with its original UUID, then we will get the error.
3. The hostid changes on the server. There are occasions where the hostid of the server will change. This is due to which network card is actually being used by the server. For example, if the server is a laptop that is docked in a docking station and is using the docking station MAC address, then the MAC address could possibly change when the laptop is undocked, i.e. it will use the inbuilt WiFi card for the MAC address. In this instance, the capability request being sent to the server will contain a UUID that does not match the hostid that is stored in the FlexNet Operations database. The mitigation to this is to set the ACTIVE_HOSTID value in the startup script so that it points at the network adapter that is always there, the WiFi adapter for example.

NOTE: These are the scenarios that we are aware of. There may be other scenarios that are not as apparent.

How Can I Resolve This Issue?

For the first two scenarios listed, the simplest way to resolve is to clear the server trusted storage and allow the server to perform a capability request/response with the back office. This should cause the correct UUID to be assigned to the server trusted storage.

NOTE: In scenario 2, the clone detected flag will most likely also be displayed due to the time stamps on the cap requests/responses.

For the 3rd scenario, the mitigation is, as already mentioned, to set the ACTIVE_HOSTID so that it is always using the same hostid.