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
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.
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
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.
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
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.
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.
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 Linux/Unix see the Red Hat/Solaris and AIX sections of this document:
Basically, /var/opt/BESClient and /etc/opt/BESClient dirs need to be preserved.
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.
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.
I have no way of testing this due to change freeze but what i would like to test is
Upgrade Besserver to 9.5 patch 7 - set clientIdentityMatch=100
Upgrade a Besclient to 9.5 patch 7
Restart the Besclient
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.
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).
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.
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