Bigfix version is 10.0.7.52. I have a number of systems showing in two different baselines that are showing applicable, but when I look at the component applicability it is much lower. I have tried a send refresh on the systems in question, and resent the baseline but the same systems keep showing up as relevant. I cannot get the systems in question to drop out of applicability for the baseline even though I know they are not relevant.
When I resend the baseline, it reports “not relevant”, but the systems in question are still applicable.
Hi,
baselines have their own relevance; then, when deployed, each component is evaluated and deployed, if applicable.
So, you could have a baseline relevant on a computer (because, for instance, the baseline relevance is true) but very few components applicable.
I have opened a case with Bigfix Support. Let’s see where it goes.
It doesn’t make sense that I send the baseline to the systems reporting applicable, and the action comes back as not relevant for every system. These systems should be dropping out of applicability but they are not.
When I create a baseline - it has its own Relevance statement
When I add a component - Each one of the components has its own Relevance statement.
On the baseline, in the Components Tab, you can check/uncheck "Baseline will be relevant on applicable computers where this component is relevant"
You mentioned that all of the components have this option checked.
On the “Applicable Computers” Tab, you will see all of the Relevant Computers - even if they have one relevant component.
On the “Component Applicability” Tab, you will see all of the Relevant Components - what do you see in the “Applicable computer count”?
Then added 2 components to the baseline - each one of them is relevant to a specific computer. I’ve marked only one of them with the option “Baseline will be relevant on applicable computers where this component is relevant”
The change has been replicated to all of the Subscribed Computers, and then the “Applicable Computers” and “Component Applicability” changed accordingly.
As you can see at first when I created the Baseline without the components - It showed as relevant because of the Baseline’s relevance statements.
When I’ve added components with additional relevance statements and checked/unchecked “Baseline will be relevant on applicable computers where this component is relevant” option - The change should be replicated to all of the subscribed computers and then report back to the Root Server.
Please check that all of the computers are able to receive new content and report correctly.
How do you check that the systems have received the new content? Support has me collecting usageprofiler logs and debug logs. What do you do if they are not receiving the new content? Do you reset the BES client using fixlet 1976 TROUBLESHOOTING: Reset the BES Client? I have sent a send refresh and resent the baseline.
Fixlet 1976 removes the KeyStorage folder - so the clients you target will reappear as new clients.
The old clients will remain in the cosole, still reporting themselves as relevant until housekeeping removes them (although that housekeeping culd be manual).
I think Support is going to be in a better position to give advice, given the debug and profiler logs.
I’d be checking under __BESData, under whichever site contains the baseline, that the .FXF file for this baseline is up to date (matches the copy on the Server site). If there is an older copy of the baseline there, the client may be failing to gather an updated version of the site.
If the content on the client is up to date, perhaps there’s a problem in the evaluation loop; that should be clear in the profiler log.
I was told to delete sitedata.db after stopping the BESClient service. c:\Program Files (x86)\Bigfix Enterprise\BES Client__BESData\sitedata.db"
This reset seems to have worked. I see the systems dropping out of the baseline relevance.
This is a bug that L3 is going to be looking at.
Does anyone have a Bigfix Task that deletes the sitedata.db? I am guessing it is not possible since the BES Client Service has to be stopped before deleting the sitedata.db.
I am being told by support that there are 3 SiteData.db files on the client directory, the -wal and -shm are the working ones, the SiteData.db is synched periodically and when the client stops. These DBs can get out of sync. One cause is an unattended shutdown or AV. I don’t think either of these are what is happening in my case. I am waiting for and analysis that will look at the 3 DBs and point out the out of synch problems.
I’m running the same version of BigFix, and seeing a similar behavior.
In your environment, if you check the list of relevant fixlet for one of the systems, are you seeing relevant content from the external patches for windows site(Not the baseline components)?
However, we have noticed that the fixlets will become not relevant after a few days(Without any manual action taken).
Support is blaming the overload of some of our relays and they didn’t want to check anything else until we distribute the load evenly but now that I am reading your case it sounds similar to what we are experiencing.
I am seeing that systems are not relevant for any of the components in the baseline, but they are not evaluating out of the baseline. I have to delete the sitedata.db file to get them out of the baseline. This continues to happen. I do not have a fix yet.
After working with L3 Support, it was determined that there was an opsite that was not synchronizing on the endpoints. It turns out that the opsite was for a service account used for Qradar integration. Once I unsubscribed all of the computers from the opsite, the baseline started to evaluate correctly.
The opsite version in the database was not incrementing and was stuck at version 2, and the endpoints were expecting a higher version. We don’t know how they got out of sync. However, at some point the AD account for the service account was disabled. I don’t know if that had anything to do with it.
I’ve seen that symptom before, but only after rolling the BFEnterprise to an earlier versions (restoring a backup, rolling back a snapshot, or something along those lines). This could also happen at a Relay level if the relay were rolled back to an earlier state.
Besides unsubscribing all the computers, another option would be to make changes to the opsite (log on with that account and create empty actions or add Fixlets to the opsite), to increment the root server’s version to a higher version than seen by clients; we also have some SQL commands that could increment the opsite and force it to propagate a new version.
Yes L3 made all of the same suggestions regarding the fix. Since the service account had been disabled for several months, it seemed best to unsubscribe the computers from the site.
