Has anyone seen multiple or twice reboot for patch deployment for sep 2019, if yes were you able to find out which patch is required multiple reboot.
I saw this for servers that we pilot on, it was not all servers but they rebooted but still reported back “pending reboot” and once I did a second reboot it came back completed.
I did not single out the patch but it was impacting multiple OS’s - 2008, 2008R2, 2012, 2012R2 and 2016
1 Like
I think it is the Servicing Stack updates that does this.
1 Like
We are seeing this also. 2/3 of patched servers are still pending restart, but show fully patched. Annoying when you have tight patch windows.
1 Like
are you applying the Servicing Stack before the September updates?
Thus far, I’ve had to reboot many systems 3 or 4 times before all the updates report back as completed.
1 Like
Yes, there is a patch that is behaving irregularly, last time this happened was April 2019. I had this raised through AVP because our reboots are happening through an Open Policy that is set to reapply every 15 mins if the machine is within a patching window and is in “Pending Reboot” state. The problem is that because of the OS comes back automatically in “Pending Reboot” after the reboot the BF agent doesn’t realize that the machine has rebooted at all and never “reapplies” the reboot policy. The answer I got was that this is not a documented behaviour from Microsoft and respectively HCL would not be willing to change the agent to accommodate for such, which is fair enough “why structure your product around the bugs of others?” but it just doesn’t help us! We are left considering creating a 2nd reboot policy OR using the new Pending Restart Exclusion settings of the Client to disregard the problematic dll that requires multiple reboots.
3 Likes
Yeah, that sounds like a tough issue with drawbacks no matter how it’s handled.
If this doesn’t work let me know and I’ll dig up my notes, I’ve dealt with it before. For the reboot policy, you might consider something like
pending restart AND not exists action whose (last active time of it > boot time of operating system
This should go relevant once every reboot while it’s pending a restart, and should have the post-action reboot set on it.
1 Like
Thanks for this but just wanted to ask because it doesn’t seem this “last active time of action” inspector is documented very well - is that going to check the “last active time” for any action or just for the action which the relevance statement is in (i.e. the reboot policy)?
Just the action being evaluated (so, itself).
This has been annoying us for several months now as well. Tight maintenance windows and 2 and 3 reboots for a majority of our Windows vms. Just this month we added an in-house “task” fixlet as a component to the end of our baseline that has the BigFix restart command in it: “restart 5” (5 for delayed seconds). As well as the normal post action restart once the baseline completes to reboot a vm twice within a few minutes of completing patching. So far this has help 100% for our DEV and QA tiers. I except the same for our PROD tier this weekend.
What I found was most Windows hosts were requiring a second reboot to complete a file rename operation task. This link from IBM helped the most in discovering this:
https://www.ibm.com/support/pages/determining-if-restart-needed
you might look at excluding certain items using the _BESClient_ActionManager_PendingRestartExclusions setting. We use it to exclude Symantec, Print Spooler, Temp files, etc:
Service Stack doesn`t need a single reboot. We can apply CU after installation of SSU.
We are having the same problems and finding that pendingFileRenameOperations value in regsitry is being populated after each patch cycle, it fails to clear the entry even after multuple reboots. When checked we find that is mostly points local printer/spooler dll’s i.e (XXXXXX ??\C:\Windows\system32\spool\DRIVERS\x64\3\New\tsprint.dll) Check for the presence of a value in this key…
“PendingFileRenameOperations” of key “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager” of registry
Clearing that then allow the task to report back as compelted.
You can check for that with (exists keys “Session Manager” whose ( value “PendingFileRenameOperations” of it as string contains “spool”) of keys “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control” of ( x32 registry; (if exists x64 registry then x64 registry else nothing) ))
but the better bet is to exclude those keys with:
setting “_BESClient_ActionManager_PendingRestartExclusions”="\spool;" on “{now}” for client
2 Likes
We are also facing similar issue, can you confirm if its happening for every machines or specific like Win 7 or Win 10 or servers