Much appreciated, please keep it under consideration. With sufficient warnings, I think this would be useful because once the BES client is tied up in an action, it won’t execute any new actions that we might send to take corrective actions. Even if we were to “stop” the offending action, the client is still tied up waiting for the external process. Nothing short of restarting the BES client can clear it, and even then we may have trouble with subsequent actions because the stuck external process has the __Download folder locked.
In my environment, I’ve already had to implement a process that is crude and I hate very much. I have a scheduled task running every half, checking with qna.exe to find processes that are child processes of besclient.exe, and have been running more than 2 hours, to kill them.
Just to clarify, you can regain control of the client by stopping the action, though you may have issues clearing the __Download folder as you described. Stopping an action will cause the client to detach from the process, which is what the new timeout option will do with disposition=abandon.
I can’t recall if this behavior changed at some point, but maybe in an earlier version you tested with, it didn’t behave this way. It does in 9.2+, though.
Where the Timeout would be helpful in our case, but which may not be what this update allows, is this:
We have a baseline that uninstalls older Office installs using those MS scrubber scripts. Most of the time, all is well, but sometimes, the scrubber will complete, but will remain running in BF; so it never moves on to the next component in the baseline (installing Office 365). A reboot will kick off the next component, but it would be great if after 30 minutes for example, the component would move on to the next.
Can you tell me if this feature will help with this scenario?
It may help, since it would allow the client to continue on with the action even if the scrubber stays running. But if the scrubber is running out of the __Downloads directory, then it would prevent later actions from starting their downloads. You can move the scrubber scripts to another temp directory and run it from there to prevent that problem.
I also added one feature missing from the original post which should be very helpful for those managing systems in different countries/encodings, or just files in different character set encodings.
The updated WebUI configuration that directly accesses the database is available in 9.5.5 and higher platform versions. You need to use the task “Deploy WebUI Database Configuration” (ID #2687) (after upgrading the platform) to enable the new config for auto patch.
Looking for some examples of the new “Run As User” command, I don’t see it when I go to compile a Task, I only see run. This functionality is supposed to be in 9.5.7. Is there a special way to invoke this command? Thanks.
The IBM BigFix team is releasing a Windows Agent and Relay binary refresh for BigFix 9.5 Patch 7 (v9.5.7.94).
This version includes all of the previously announced 9.5.7 functionality and adds support for the BigFix Agent and Relay on Windows 10 Fall Creators Update (release id 1709).
IBM recommends upgrading any existing v9.5.7.90 Agents and Relays to v9.5.7.94 for any systems that are currently running the Windows 10 Fall Creators Update. The recommended environment will have v9.5.7.94 Windows Agents and Relays reporting to v9.5 Server.
Actions to Take
Upgrade any current 9.5.7 Windows Agents and Relays using the 9.5.7 upgrade Fixlets as soon as possible.
The upgrade Fixlets for the Agents and Relays are available in BES Support version 1371 (and later).
Note: This release includes an updated version of the upgrade Fixlets, but the Windows Installation Generator on support.bigfix.com will still contain the older Windows Agent binary to allow users to install the original version of v9.5.7.90. Complete coverage of all the Agents installation methods will be available starting from 9.5 Patch 8.
Question 1.
Is it required to upgrade the relays ONLY if they are running on Windows 10 Build 1709
OR
The relays should be UPGRADED to 9.5.7.94 BEFORE deploying the agent upgrade REGARDLESS of what OS the Relays are running?
And for those of us at 9.5.5 for our BES Infrastructure? We have no relays on Win10. Are we supposed to upgrade any Win10 1709 endpoints to 9.5.7.94 even though our Infrastructure is at 9.5.5?