Error "Host's UUID does not match expected UUID for that host ID"
Error "Host's UUID does not match expected UUID for that host ID"
Question:
What is the error "Host's UUID does not match expected UUID for that host ID" means while trying to activate Licenses from FlexNet Operations and in what scenario 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 FNOC.
A customer is reporting that they see more and more of this issue, 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 would indicate that the record that FNO has for the server, where the UUID is contained, is somehow different from the UUID contained in the server DB.
Generally, the flow is, the server sends a request to FNO and if the request does not contain a UUID then FNO 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 FNO 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:
The server is using both a UAT and Production back office. It is possible that the server has activated a license from a UAT FNO during some testing period. In this case, a UUID will be generated in the DB of the UAT FNO and returned back to the TS of the license server. If the server TS is then removed and the server now talks to the production FNO, this will also generate a UUID that will be returned back to the TS 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.
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 2 license servers running that have the same hostid and both are talking to FNO. It is possible that the first instance of the server has a UUID that FNO currently has in its DB. The server is then obsoleted in FNO 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.
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 FNO DB. 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.
Please note, these are the scenarios that we are aware of, there may be other scenarios that are not as apparent.
How to resolve the issue?
For the first 2 scenarios listed the simplest way to resolve is to clear the server TS 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 TS. Please 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.
You wrote "This means if at any point of time, the UUID information at client changes it will not match with the information present in server TS". Could you explain under what circumstances the UUID information changes? We have customers reporting this error, and we are clueless as to what causes it (the hostid has not changed)
