Odd BES Client Behavior

We have been seeing a problem with Windows 10 systems running Build 1903. If they evaluate certain WMI queries, they hang. This has been covered in another forum posting.

Part of the problem was that the site that originally hosted the content could not be transferred to HCL after BigFix was purchased by them since it was coming from the IBM XForce servers.

Fine. I still have non-1903 Windows 10 systems out there, and some of my Console Operators wanted to be able to keep the Defender analysis running, so I added an exclusion to the site to prevent Win10.1903 systems from subscribing to the content.

Thinking (root of my problem?) that IBM might eventually delete the content off their XForce servers, I thought it might be better to transfer the content to a Custom Site. So I did this. I created a “Windows Defender” custom site, copied the Relevance clauses over to it, and added the Analysis to the site. Presto.

Not so fast.

I got a message today from one of the Console Operators that the 1903 problem was back. I remoted into one of the 1903 test boxes and enabled Debug Logging to level 10000 and restarted the BES Client (it wasn’t reporting to the server any longer, or processing information either). I started tailing the Debug Log on the client and shortly there after I watched it hang up trying to process the following …

Fri, 20 Sep 2019 15:16:44 -0400 Evaluate file actionsite/Subscription for CustomSite_Windows_Defender.fxf
Fri, 20 Sep 2019 15:16:44 -0400 Complete file actionsite/Subscription for CustomSite_Windows_Defender.fxf: 594 microseconds
Fri, 20 Sep 2019 15:16:44 -0400 Evaluate file actionsite/Unsubscription for CustomSite_Windows_Defender.fxf
Fri, 20 Sep 2019 15:16:44 -0400 Complete file actionsite/Unsubscription for CustomSite_Windows_Defender.fxf: 1056 microseconds

followed shortly by …
Fri, 20 Sep 2019 15:19:59 -0400 Evaluate unprocessed file CustomSite_Windows_Defender/Fixlet 1582565.fxf

and the BES Client process stopped processing until I killed the besclient.exe process.

I verified that the Relevance for the Custom Site “Windows Defender” was EXCLUDING the 1903 computers the same as with the External site the content originally came from.

The Site Subscription Relevance was as follows …

RELEVANCE CLAUSE : (Windows of Operating System) AND (exists value "ReleaseID" whose (it as string < "1903") of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" of native registry)

RELEVANCE CLAUSE : (if (name of operating system starts with "Win") then platform id of operating system != 3 else true) AND (if exists property "in proxy agent context" then (not in proxy agent context) else true) AND (if exists property "android" of type "operating system" then (not android of operating system) else true)

When I used the QNA tool to evaluate both clauses, the first returns FALSE and the second one TRUE.

Can someone please explain to me WHY THE COMPUTER WAS EVALUATING CONTENT FROM A SITE IT SHOULD NOT HAVE BEEN SUBSCRIBED TO? That seems like a total violation of everything I’ve come to expect from BigFix clients. Why is the client wasting it’s valuable and limited cycle times evaluating content like this? In my mind, the client should never have even downloaded the content since it should not have been subscribed to the site!

@TimRice, was the BESClient actionsite content in synch with the Server?
I mean, it appears that BESClient is not changing the applicability for Windows Defender site, so I’m wondering if it is still evaluating an old version of the custom site.
If it is not the case, you may want to check the subscription status for the site within SitaData.db file in __BESData folder: you can use SiteDataReader.exe (https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/SiteDataReader) to extract data from SiteData.db in a readable way, then check the subscription status for Windows Defender in the actionsite output.