I am finding that after applying the October 2020 Critical patches to Win2016 (1607) that Bigfix client 9.5.15 isn’t always detecting pending reboot.
I have been using “Pending Restart” as relevance for checking reboot and issuing reboots as part of a baseline flow for the past few years.
I have found several systems now not reporting ‘pending reboot’ but the servers otherwise are pending CBServing reboots.
The client registry has:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending]
And when the system is rebooted, it goes into a nice slow windows is shutting down - please wait and then on startup it is counting percentage of updates complete, etc.
When i run in qna the query for the registry:
Q: exists key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending” of registry
A: False
T: 3898
ok so this appears to self clear the pending reboot, given time.
It just took over 45 mins after patching was reported to be complete before it actually cleared the pending reboot registry completely. A reboot after the registry cleared was quick and did not appear to be pending anything.
Is the system 64 bit? Just thinking that maybe your QNA was being subject to Wow64 redirection so was actually checking “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending” instead of “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending”.
Your relevance would need to use the “native registry” inspector to check the 64 bit hive
Q: exists key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending” of native registry
For checking where you don’t know if its 32 or 64 bit keys, you can check both using
Q: exists keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending" of (registries ; native registries)
Over the past 1-2 years Microsoft has been releasing more and more “mis-shapen” updates - it doesn’t happen every month but it does happen quite frequently. I dug into that and it doesn’t have anything to do with BigFix as I was able to re-producing by patching server outside of BigFix manually - you install one of those patches, you check and OS says it’s pending reboot; you reboot the box and it comes back but when you check it again it says “pending reboot” - if you check the “PendingFileRenameOperations” of “HKLM\System\CurrentControlSet\Control\Session Manager” at that stage you’d see some kind of print.dll showing up as the reason for the pending reboot. At that stage if you reboot the machine a second time, it all goes away and machine is not pending a reboot anymore but it just requires 2 separate reboots for it to clear.
The problem we faced is because on certain machines we had an automatic reboot job that just does not work (it has relevance “pending restart” and reapply with X time in between) BUT because as far as the BF agent the status of the OS never changes (it reboots the machine with the “OS state” in Pending restart; by the time the OS loads back up and BF agent starts its evaluates, the OS is in the same state) the client never marks the first execution as complete and proceed with “reapply”. We’ve raised that through Support/AVP/PMs but the response we got is that HCL would only consider changing the client code to better identify such scenarios if Microsoft officially documents this behaviour as “expected”/“acknowledged”, otherwise they’d consider it as “Microsoft bug” and they wouldn’t build BigFix to accommodate others’ bugs (and rightly so)…
I am not sure that is what you are experiencing - my suggestion is to try to reproduce it outside of BigFix by manually applying the patches but thought I’d share it.
