As part of my BigFix Server deployment, I use a custom post install script to create a property called “_Office-Location” using the BigFix API. This is visible within the “Manage Properties” UI within the Console. I also use the post install script to create a site called “USA”, again using the API. This site includes the following subscription clause:
_Office-Location equals USA
When I deploy BigFix Clients I include a preconfigured besclient.config which contains:
[Software\BigFix\EnterpriseClient\Settings\Client_Office-Location]
value = USA
Therefore, based on the above, as soon as the computer reports into BigFix Server (and appears in the Console) it should automatically show as subscribed to the “USA” site. However, this is not the case. The computer appears in the general “Computers” view within the “All Content” domain, but it does not show as subscribed to the “USA” site.
I have reviewed the client logs and confirm communication to the BigFix Server is working. I can see log entries showing reports posted successfully. So this is not a communication issue.
Interestingly, if I edit the “USA” site, and change the subscription clause so it uses “contains” rather than “equals”, suddenly this begins working and the computer is subscribed properly. If I then edit the site once more, and change it back to use “equals” the subscription persists. By editing the site I see that upon saving it a command is issued to the client computers, causing them to re-evaluate, and actions are captured in the client log showing relevance to the “USA” site, and subscription commands to join it. It seems that by saving the site it has somehow caused an action to force the clients to re-evaluate. Whereas, it would appear that by creating the site originally via the API did not force the clients to evaluate it.
Does anyone have any explanation for the behaviour I am seeing here? Is this a bug, or is it working as designed? My feeling is that if the site exists then the client should subscribe to it automatically, and this editing of the site post-creation should not be needed to “force” the evaluation.
Note. I mentioned I changed the relevance from equals to contains. But I can guarantee that the string is absolutely just USA (with no spaces or other characters around it) and should therefore be a match by using the “equals” clause. I don’t see this being any cause (more a red herring). It just appeared to be necessary to do something so that I could click on “Save Changes”, to cause the action to force the clients to re-evaluate.
I am aware that properties and client settings are two different entities. Could the behaviour I am seeing result from some disconnect between the _Office-Location property I create using the API, and the client setting called _Office-Location that I am setting during client installation? Is BigFix somehow unable to link the two, which leads to it not matching the client setting value to the property defined in the site subscription relevance?
My BigFix Server is deployed on RHEL 7, using DB2 database.