I do see a number of entries in the PendingFileRenameOperations registry key.
So I may have a Chicken-and-Egg problem. During my Patch Window, I have a Policy Action running to trigger the actual reboots. The logic on this Policy Action checks whether any of my baselines are still trying to execute, and when they are finished it executes to trigger a reboot. The Reboot policy action has a Relevance that includes
not pending restart "PatchWindowRestartPoller"
The Action Script is simple -
action requires restart "PatchWindowRestartPoller"
So the system runs its patch baselines, and when they are finished this restart polling fixlet executes. It sets the pending restart, and its post-action triggers the reboot (with a delay for the user). I’m depending on the reboot to clear the pending restart for PatchWindowRestartPoller. But if another external check (like PendingFileRenameOperations) prevents this action’s pending restart from getting cleared, this restart polling fixlet won’t execute again to trigger the second reboot.
I can’t say I’ve encountered this as a problem before, so before I start changing my polling logic, I just want to be clear that I’m understanding this correctly. Is it true that after rebooting, the BES Client will not clear the BESPendingRestart registry keys and re-evaluate any of the actions that were previously Pending Restart, if there are any other items that are still Pending Restart?
I understand the client should be relevant for the “Pending Restart - Not Triggered by a BES Action” fixlet, but I think it still should have moved ahead with clearing the older BESPendingRestart values.