As @jgstew states, the first thing to check is whether there are any files in the _Download folder. There’s a separate _Download folder for each Site on the client. The Site in use should be whatever site contains the baseline that was the source for action 307107 in this case. You’ll find the _Download folder at \Program Files (x86)\BigFix Enterprise\BigFix Client\__BESData\[sitename]\_Download.
It’s very like that the folder will still have the files in it, indicating what installer process is “stuck”. I’ve seen that occur fairly frequently in my own custom content, but also in the default BigFix content for installing Chrome, Java, and several other packages. What usually happens is that the installer has encountered some error condition, is trying to prompt for an input or acknowledge, but since it’s running under Services it does not have access to the interactive desktop and there’s nowhere for its message to go.
You’ll likely need to kill the installer process for whatever you find still in the download folder. If there are no files there at all, the installer may have moved itself to another location but still used the download folder as its “current working directory”. Some installers extract to the TEMP folder and execute from there, cleaning up the source archive that was in the download folder but if the process is still active and has the download folder as its CWD the folder can’t be cleared.
You mentioned procmon and process explorer, I’d try using “handle” (also from Sysinternals) to list open file handles and their associated processes. Using
handle _Download
should show you which process has the folder locked.
The best way to fix this is to correct the underlying problem with the installer (whatever that problem may be). If that’s not possible, and the Fixlet(s) in question are custom content, you could swap out the “wait” or “waithidden” for “run” or “runhidden” and enforce a timeout, described at Running a command with a timeout
If you’re finding that this happens with a lot of different processes, with IBM default content, or for whatever reason you don’t want to handle it on a case-by-case basis, you can checkout the BESChildKiller Tasks and Analyses that I posted to BigFix.me - they’re linked later in that thread at Running a command with a timeout . It sets up a Scheduled Task to run periodically (15 minutes, if I recall) to look for BES child processes that are running longer than a specified timeout, and kills those processes. I previously had an RFE out for this functionality and it looks like it’s been accepted and scheduled for a future release, but in the meantime I’ve had this task running on a few hundred hosts for a couple of months and it’s working pretty well for me. Of course your mileage may vary…