The above link should give you a lot more insight into this. I have used the second registry key to determine what the system was needing the do and either manually did it or cleared the key a few times to get systems to stop the cycle of rebooting.
I also discovered that if you have a baseline with a lot of fixlets in it, as soon as the first fixlet sets the ‘reboot pending’ flag, the countdown begins if you use the “Reboot Pending” fixlet as a policy to auto-boot systems - Not good - I had to stop doing this just due to this issue.
Currently I just have three policies per baseline, one for users, one for testing, and one for critical systems. Users reboot after 1 day, critical never reboots but the request stays on top, and testing reboots 30 minutes after the baseline completes.
I found one reference to AIX and restarts Forced Reboots via BigFix but I don’t think that is what you are looking for, it’s more of a cautionary tale about using OS restart commands.
Pending restarts on UNIX systems are based on the boot time of the operating system so they are definitely not related. Check and see what the relevance for the following is
I’ve got an really good explanation from IBM Support. Restart pending relies on the boot time which is deposited in /var/opt/BESClient/besclient.config:
grep Boot besclient.config
BootTime = Tue%20Jun%20%206%2013:21:25%20201
where every %20 is a space.
Just stop the client, change the value to an approbiate value and start the client again. Afterwise the client is no longer in “restart pending” state.
Hi Matthias, I am facing the same issue. Even after server is rebooted, status is still “Pending Restart”. And it is not an easy option to go and change config file of hundreds of servers, is it?
I found this in a text file I was using for note-taking -
Is there anything left at value PendingFileRenameOperations under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager key of the registry of that machine after reboot?
and I found this in the following IBM help page
Windows 10, after the reboot, does not dele the key
KLM\Software\Microsoft\Windows\CurrentVersion\ComponentBasedServ
icing\RebootPending but just deletes the value, while Bigfix
controls for the key existence.
The link you provided to the APAR is historical, and related to a particular version of BigFix going back about 4 years that was fixed in the 9.5.5 release (2016).
Generally, it’s good practice to ensure there are no pending re-boots required on any machine before you start your patching, which can sometimes cause multiple re-boots after you patch.
Restart before and after deployment, or monitor the ‘restart needed’ fixlets, or have a report automatically sent to you if there are systems still pending restarts a few days before your next patch deployment cycle.
@GwyndafDavies do you have HCL/IBM documentation supporting putting Cumulative Updates last in the patch order? I’m looking for mine now but I was shown documentation as:
I think the most important is to always start with Servicing Stack - where you go from there may depend on what content is in the patch baselines, what exclusions are needed, and what OS you are targeting. I generally finish up with Cumulative updates in that first wave, but always start with Servicing Stack.
e.g. a typical first wave would look something like this for Windows 10:
1.Servicing Stack
2.Microcode
3.Flash
4…Net
5.Cumulative
6. May have second wave of non-security updates
But Servers could be handled differnely, leaving .NET, SQL and Microcode upates out of the first wave as they may need more rigorous testing.
In your list, I think it may account for multiple Windows versions? The Security Monthly Quality Rollups are generally only for Win 7/8.1/Server 2008/2012