hi all ,
we patched KB4019472 this weekend . After reboot, clients are pending restart status. why they are waiting secont reboot ?
client version : 9.2.7
MS17-MAY: Cumulative Update for Windows 10 Version 1607 - Windows 10 Version 1607 - KB4019472 (x64)
is there any comment for this issue ?
I have seen several occasions where BigFix considers a system to need rebooting almost immediately after logging in after a reboot!
Usually this is because of a windows patch, not BigFix itself.
There are two registry keys BigFix uses to determine if a boot is needed, one due to BigFix and one due to Windows.
http://www-01.ibm.com/support/docview.wss?uid=swg21506002
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.
We have an similar issue with AIX Systems. The knowledge base articles almost refert to windows systems.
As anyone an idea how to reset the “restart pending” status on AIX ?
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?
Can anyone please help how to fix this?
Hi Mike! Any chance you have a copy of that article someplace? The hyperlink goes nowhere 
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.
http://www-01.ibm.com/support/docview.wss?uid=swg1IV90936
Note that the misspellings and missing letters are in the help article. Mind blowing.
Hmmm, sorry to take so long to see this - but the link worked for me. I made a pdf of it and will try to attach it to this post.
IV90936_ WINDOWS 10 MACHINES CONTINUE TO REPORT PENDING REBOOT.pdf (118.5 KB)
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).
You can refer to this KB for the latest information regarding the handling of re-boots and pending re-starts:
https://support.hcltechsw.com/csm?id=kb_article&sys_id=e145eb401b617f4077761fc58d4bcba5
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.
fyi, Patch order for Microsoft updates should be:
I created a fixlet with the same relevance as “Restart Needed - Triggered by a BES Action” and added this as the BigFix Action Script:
runhidden shutdown.exe /R /T 10 /C "BigFix is initiating a restart of the system to complete patching"
We put one of these fixlets at the start and end of our patching baselines to ensure no machines have a restart pending.
@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