I’m certainly no BigFix expert, not by a long shot but some logic continues to elude me…
If I have a patch schedule in place (or an automation plan for patching) and the obvious goal of this schedule is to patch my systems and reboot as necessary… WHY will BigFix NOT reboot if the system is already in a Pending Restart state?
What is the logic there? Its pending restart already, so clearly it needs to be restarted and my Deployment/Schedule is needing it to restart so why is the default response of BF to not restart?
This makes zero sense to me…
Now I’m forced to create a custom exclusion action and try to exclude all of the various reasons windows or apps might put a system in a pending restart state. This seems pretty ridiculous to me and I’m not sure I’ve seen another product function this way for patching.
This is the exclusion list we have now and its not working… 89% of our DEV systems didnt restart last night because something about this isnt working again…
Sorry for my tone… I’m so aggravated by this and why this is so damn difficult…
P.S. Some that I spot checked with a query were pending restart due to a windows installer tmp file delete. I ran into this last month and added tmp to this exclusion but its not working.
1 Like
I can’t speak to what is in the minds of the Developers, but to me it’s Flexibility.
I’m manage BigFix in an Educational Medical Center with Patient Care systems, Basic Science Research systems, and Administrative systems under management. As you might be able to imagine, there are servers that we have to VERY carefully manage the reboots on. In some cases, we have to manage the time of day that the servers reboot (reboot windows must be communicated/coordinated with end users), and in others, it is a sequence issue where servers must be booted in a particular order (Server Automation helps here) for an application environment to function properly.
I personally appreciate that UNLESS I TELL an Action to reboot a computer, by default it will not do so. There are a few patches from Microsoft that have in the past forced reboots, but BigFix usually highlights this behavior in the Description for the patch.
If you want your servers to reboot at any particular stage of your patching process, you simply have to indicate it in the Action and the client will make it happen.
Then when it comes to users laptops, I like the ability to install patches with no forced reboot at the end. We display a Message to the users that their computers are beginning the patching process (don’t shutdown yet), and they get a message when it is completed. They can then choose to reboot or Cancel the reboot and do it manually. Those that forget are “reminded” by a follow-on action a few hours later.
It’s really not very difficult to manage.
3 Likes
The schedules are set to force reboot as are the automation plans - they have steps for pending restart actions.
It simply doesnt work if there isnt an exclusion in place to accommodate the pre-existing restart condition.
That’s really my dilemma here… I’m actually telling BF to restart these systems but it wont because the pending restart condition existing prior.
I feel like I’m missing something important here…
What do your “pending restart” steps look like?
The ActionScript commands “action requires restart” and “action may require restart” do not cause the system to restart, they only flag the action status to be “Pending Restart” rather that Fixed/Failed until a reboot occurs.
To actually reboot the system, the Pist-Action tab of the Action needs to be set to trigger a restart. Are you setting that on the Action? Check the “Settings” area of the Action Summary tab to see.
This past weekend, this affected both Policy Schedules and Automation Plans so here is info from both…
This has always worked BTW for the policy schedules - as long as the exclusions were in place as seen in the screenshot from my 1st post. I only created a new exclusion action recently to add tmp to the list and now it seems to not work at all.
Ah, ok, I think I may see what’s going on.
The client logs should be able to verify, but what I expect is that the first “Restart Endpoint on Pending Restart and Wait for Restart to Complete” is probably never evaluating as completed because of the false-positive Pending Restart based on the Windows PendingFileRenameOperations registry key. Since that component never “completes” it doesn’t move on to the next action for “MS Updates for Automation”.
The BigFix Client attempts to detect whether other things, outside of BigFix, require a restart, based partially on the PendingFileRenameOperations registry key. More and more frequently I’m seeing that key being misused by software that keeps re-creating entries after a reboot, so that the key is never “cleared”.
You can continue trying to add exceptions on the _BESClient_ActionManager_PendingRestartExclusions client setting, but these days I’m finding it more useful to ignore the PendingFileRenameOperations completely and only trigger restarts based on BigFix actions. You could accomplish that by adding a string to the exclusion that matches…everything.
setting "_BESClient_ActionManager_PendingRestartExclusions"=":;" on "{parameter "action issue date" of action}" for client
The colon should match every PendingFileRenameOperation so that the key is ignored. This needs to be set before the first Restart action in your group action, so it will take effect before that component’s completion is evaluated after the first restart.
1 Like
Thank you - so this would be correct?
((not exists setting “_BESClient_ActionManager_PendingRestartExclusions” of client) OR ((not exists effective date of it) OR ((effective date of it <= universal time “Mon, 12 Apr 2021 10:00:00 +0000”) AND ((not exists value of it) OR (value of it does not equal ((":;") as string))))) of setting “_BESClient_ActionManager_PendingRestartExclusions” of client)
setting “_BESClient_ActionManager_PendingRestartExclusions”=":;" on “Mon, 12 Apr 2021 10:00:00 +0000” for client
Can you clarify what you mean here? I apologize for my ignorance here. Do you mean that ALL systems need to restart before this Action will go into affect?
This needs to be set before the first Restart action in your group action, so it will take effect before that component’s completion is evaluated after the first restart.
1 Like
Yeah that logic looks good.
What I’m saying is that to clear the false ‘Pending Restart’ state, you need to have the client setting in effect before you reboot - so reboot after you change that value.
If you built a task for this setting and put it into your policy, you want this setting to change before your first restart in that group, so the first restart can evaluate as Completed and it moves on to the next task.
1 Like
Sorry but one last inquiry about this…
i created the new action and Reported Computers jumped to 1000ish pretty quickly but then slowed to quite the crawl.
It only reported about 100 systems over the entire night two nights ago then only about 50 systems last night.
Why would this process be running so slowly? Or the computers reporting back so slow?
Thanks for all of the help with this…
