clientIdentityMatch / correlation Question

[sauk]

RE:

If clientIdentityMatch=100 , the BigFix Server performs an additional check before assigning a new ComputerID to a registering Client to avoid creating cloned computer entries. This means that the BigFix Server tries to determine if the information about the rolled-back Client sufficiently matches the data held for that ComputerID. If the identity of the Client is matched, the Client keeps using the old ComputerID and its identity is not reset.

With this new setting what information is compared? I did a test by deleting the computer id in the windows registry but the client still reset, i thought it would match the hostname

[steve]

You can’t delete the ComputerID to test this. It is intended to prevent a computer from duplicating when it is rolled back to a previous VM snapshot or reverting to an alt-disk after patching. The logic requires that the ComputerID and client certificate are the same, and then compares additional details like hardware UUID/serial number and OS UUID. The exact data compared varies by platform based on what is available.

---

Related:

• https://www.ibm.com/support/knowledgecenter/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Installation/c_list_of_advanced_options.html
• BigFix 9.5 Patch 7 is now available

[sauk]

Hi Thanks for your reply. Is there any documentation on what is checked on Windows?

Reason for asking is that we are currently using BF 9.2 Patch 8.(on linux) So i want to see if this feature will help us as we got many duplicate computers on windows Citrix servers so im hoping the parameter will help

[vnovik]

Hello sauk,

ClientIdentityMatch feature is available in 9.5.7
You might find a description of that feature here:
https://www.ibm.com/support/knowledgecenter/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Installation/c_list_of_advanced_options.html

Regards,

Vitaliy

[sauk]

Hi Yes seen that but there are no details on what is compared. I need to find out what is checked on windows

[adzm]

clientIdentityMatch

sauk,

Did you find anything out? I am very interested in this option for our Citrix provisioned servers.

[sauk]

Hi

Just upgraded a few hours ago and set clientIdentityMatch to 100

So now I’m waiting to see if the are duplicated. Will let you know

[adzm]

Sauk,

I am also curious if you figured out details on what is compared. I am on the Citrix team and don’t have direct support to BigFix support. It sure would be nice if there was more documentation out there.

Thanks

[sauk]

Hi I need to really get some details as to what is being compared, After setting this I am still seeing duplicates on Citrix
and AIX.

[adzm]

We get duplicates every time a provisioned Citrix server is rebooted.

[sauk]

What i noticed in the logs was that when the citrix server is rebooted the register request has

Body=0&SequenceNumber=0

It should at a min be Body=1111111&SequenceNumber=0

Where 1111111 should be the actual computer number. I believe with Citrix the Computerid and seq registry keys are not set

So for Citrix i have passed back to the Citrix team to ask what they are doing at Citrix server restart

I am also seeing duplicates for AIX but I have opened a new post for that as I see the computer id but a message in the relay log

Sat, 18 Nov 2017 00:56:44 +0000 - /cgi-bin/bfenterprise/clientregister.exe (2529154816) - The re-registration request for Comp
uterID 12374642 failed. Client identity missing in the registration request

[steve]

These sound like VDI use cases, which the identity match feature does not help with. If every reboot reverts the server to a base image (that many servers would use), then you will get a new computer every time because the computerID is being reset to 0 (or some common value) every time. And there would be no knowledge of anything that server did after establishing its own computerID.

As I mentioned above, identity match works for rollbacks of VMs that have a maintained life. From a technical perspective, this means that each server must establish its own computerID and corresponding client certificate, and that info must be maintained across reboot/rollback. If those two things are retained, then identity match will allow the computer to not be duplicated even when the SequenceNumber reverts back to an older value.

In the scenario sauk describes, identity match isn’t even involved because the computer does not present itself as the same system (computerID) after the reboot. If the BigFix parts of the registry and filesystem can be preserved in the user/server-specific data across a reboot, then the duplication would not happen, even without using clientIdentityMatch.

[sauk]

Hi Steve thanks for the reply. Our primary use of BigFix is for ILMT.

So from what I can see if the computer id is the same which in the case of my AIX servers it is the other thing is the Certificate.

Is there a way of checking what client certificate was used when the computer tried to register? and then duplicated?

[adzm]

I am curious if there are any workarounds for a Citrix setup? I am thinking of trying to dump registry entries to a persistent D:\ drive then import them on boot up? If we have besclient as a delayed service start up maybe we would have enough time before check in. Would like to see if you have any other workarounds first.

We have many other agents that can handle a provisioned non-persistant image setup. These agents multiple checks or configuration places other than a registry entry that will not persist.

[sauk]

For Windows the registry keys are documented on linux/Unix what needs to be preserved?

[steve]

Is there a way of checking what client certificate was used when the computer tried to register? and then duplicated?

You don’t need to check the cert. It exists in the BES Client\KeyStorage directory, and as long as the directories are preserved, then the cert will be preserved.

For Windows the registry keys are documented on linux/Unix what needs to be preserved?

For Linux/Unix see the Red Hat/Solaris and AIX sections of this document:

https://www.ibm.com/developerworks/community/wikis/home?lang=en&escaped_fragment=/wiki/Tivoli%2520Endpoint%2520Manager/page/Common%2520File%2520Locations

Basically, /var/opt/BESClient and /etc/opt/BESClient dirs need to be preserved.

I am curious if there are any workarounds for a Citrix setup? I am thinking of trying to dump registry entries to a persistent D:\ drive then import them on boot up? If we have besclient as a delayed service start up maybe we would have enough time before check in. Would like to see if you have any other workarounds first.

I’d suggest using shutdown and boot scripts to save and reload the registry, and ensuring the BES Client is installed on a persistent drive. That should allow it to retain its identity across reboots.

[adzm]

Steve,

It is not possible to install the application on a persistent drive but if there are configuration files that can be pointed within the client to a different drive we can do that.

[sauk]

Hi

I have no way of testing this due to change freeze but what i would like to test is

1. Upgrade Besserver to 9.5 patch 7 - set clientIdentityMatch=100
2. Upgrade a Besclient to 9.5 patch 7
3. Restart the Besclient
4. Get the citrix guys to use that agent that is started as the base image.

Now when they go back to the base image i would expect the registry key that holds the seq to be wrong however the computer id to be correct and clientIdentityMatch to match the re-imaged client and to not to be duplicated.

I dont know how the citrix to know if step 4 is something that is easy to do.

[steve]

It is not possible to install the application on a persistent drive but if there are configuration files that can be pointed within the client to a different drive we can do that.

The application itself is only about 28MB of installed files in the BES Client directory and BESLib subdir. Everything else is generated by the application running, but lives in the same directory structure under __BESData and KeyStorage directories, or in the registry. It doesn’t really make sense to try and manage a “persistent” device without enabling this data to be persistent, as well.

I understand the challenge here in a VDI/XenDesktop environment, but you may need to look at the value of trying to manage each endpoint vs the source image. If you’re just trying to get visibility of each instance that spins up, you can try to preserve the registry and KeyStorage directories to maintain the identity; but all the history would be lost each reboot, causing the client to re-run things that it has already done (actions, downloads, uploads, etc).

Now when they go back to the base image i would expect the registry key that holds the seq to be wrong however the computer id to be correct and clientIdentityMatch to match the re-imaged client and to not to be duplicated.

If this image is used by only a single virtual computer instance, then it would work. If it is used to create any number of virtual computer instances, then the ComputerID will still get invalidated because we don’t want multiple computers to be able to report as a single entity constantly overwriting each others results.

[sauk]

I understand the challenge here in a VDI/XenDesktop environment, but you may need to look at the value of trying to manage each endpoint vs the source image. If you’re just trying to get visibility of each instance that spins up, you can try to preserve the registry and KeyStorage directories to maintain the identity; but all the history would be lost each reboot, causing the client to re-run things that it has already done (actions, downloads, uploads, etc).

In our case we are using ILMT so we need to be able to scan the servers for IBM software. I dont really understand VDI/XenDesktop so im a bit confused as to what solution to propose especially if its mandated by IBM that it has to run