Initiate Software Scan failing on Win 10 (1809)


FYI - I have two Windows 10 (1809) machines that fail the BFI Initiate Software Scan task. The source release date is 2019-01-04. The failure occurs in the following section:

// ******** Application Usage Scan With Paths - SUA only ********

I have traced the issue to the absence of an Image Path in some Instances of Application Usage Summaries. This causes the Singular expression refers to nonexistent object error.

There doesn’t appear to be any pattern, since other Instances with the same name do have image paths.

Yup, we got a problem.

For end user as a workaround recommend to change the setting “_BESClient_UsageManager_EnableAppUsageSummaryPath” from 1 to 0. This will disable failing part for now. Application Usage gathered by BFI in version 9.2.14 is not affected. Disabled function will be used starting from upcoming 9.2.15 release.

I am running 9.2.14, by the way. Are you saying that this issue will be corrected in 9.2.15?

No, it will be a problem in 9.2.15 :slight_smile: but it is not in 9.2.14
In 9.2.14 you can switch setting to 0 and there is no impact at all, as that setting starts to be used in 9.2.15

Now that 9.2.15 is released, are our options:

  1. Stay on 9.2.14 until the Win10 issue is corrected in 9.2.16


  1. Change “_BESClient_UsageManager_EnableAppUsageSummaryPath” from 1 to 0 for all Windows 10 systems. Then upgrade to 9.2.15.

I was reading the detailed release notes and saw no mention of this (which makes me thankful I visit this forum often!).

It is really a defect not on LMT/BFI side, rather underlying BigFix platform.
We are investigating to find the root cause on our side, but platform “Changes between and” suggests they had issue. What version of BESServer are you running ?


If newer, maybe they introduced some regression.

It does not occur on all windows 10 machines. I think, I had this issue in my test environment, but when I disabled “_BESClient_UsageManager_EnableAppUsageSummaryPath" and than re-enabled it back, it seem to solve the problem for me.

Ah, so more on the BES Client side. We are at BES Client 9.5.10.

Did you notice this issue in you environment? ?

I didn’t dissect anything and noting seems to have caused issues where it was observed by myself or brought to my attention.

Looking at my “Initiate Software Scan” action, out of close to 11K endpoints, I see that the scan has failed on 17%; mostly Win10.

So I guess the answer is yes… :frowning_face:

Have you updated your besclient recently?

We upgraded from 9.5.8 to 9.5.10 in February 2019; we upgraded BFI to 9.2.14 in January 2019. So maybe I set that setting on my Win10 systems and kick off the 9.2.15 “Initiate Software Scan” action and see if the results are better. I gather there is no harm in doing that before upgrading BFI.

If “_BESClient_UsageManager_EnableAppUsageSummaryPath" set to 0 will help, please take one of endpoints where it fixed the problem and set it back to 1, see if that will remain working.

So the test is to set to “0”, run the scan, verify success, set to “1”, run the scan, verify success (hopefully). Do I have the correct?

I just did that in my client that was failing the relevance. It is now functional.

Apparently, disabling and re-enabling the setting removed the invalid, empty image path entries in the instances of application usage summaries.

The new version 9.2.15 Initiate Software Scan action looks much different than 9.2.14. I will let the current action run again and see if there are any issues with the previously failing Windows 10 systems.

Then what we really need to do, which is a lot easier for me at least, is to set them to “0”… then set them back to “1”? No scan’s in between? If that is the case, I can get to that sooner…

I’m not sure. I had mine set to “0” for a few scans. In my small environment, I run the Initiate Software Scan as a daily policy action.

What you might consider doing is running this relevance on one of the problematic machines:

concatenation "%0a" of (image paths of instances of application usage summaries)

This should confirm that the error situation exists on that machine.

Next, update the setting to “0”, and run the relevance.

Finally, back to “1”, and run the relevance.

That could tell you if you need to wait for a scan.

The result of that relevance being either an insane amount of file paths (good) or a single error line (bad)? Would that be correct?

Yes - that was my experience.

If you evaluate (names of it, image paths of it) of application usage summaries, some of the lines being returned have no image paths, which leads to the error in the original relevance.

@MichalPaluch Following up on this issue, after setting _BESClient_UsageManager_EnableAppUsageSummaryPath to 0, and then back to 1, I confirmed that the scans on those machines are now completing without error.

1 Like