I’m seeing this more and more where it’s bothering me. I deploy custom content which requires a reboot. I have a post action to reboot. No one is logged in. I watch the system reboot after the install. And the status remains “Pending Restart”. If I reboot a second time, the status usually changes to Complete.
I’ve noticed at the end of the BigFix Content this final line: action requires restart "0e12458b30dc68c269fdef445fdd68f7882cb96d"
I’ve read a bit about it but it wasn’t all that clear. Does this basically tell the OS that if reboots aren’t directly related to this fixlet, then disregard? And if so, how does it know based off the SHA1? I mean what if I have multiple downloads?
It sounds like your custom package needs more than one reboot sometimes to complete the installation.
Have you taken a look at the flags that remain after you reboot the machine? This thread may be useful.
I’ve rebooted it twice in this particular example and it still says “Pending Reboot”. Again, this happens with other content. I’m trying to learn how to better the process. I’ll check out the other thread. Thanks!
To expand a bit: If I know my action needs a restart (installing a app for example that if done manually, pops up a message saying a restart is needed), it sounds like I should include action requires restart as the last line of the Action Script?
To take that further, what does the trailing SHA1 add and is this only usable when there is a single download?
We’ve recently started experiencing the same issue. In only a few cases does it ever change to Complete, in most cases no number of reboots clears out the Pending Restart. This is a new issue that has just started showing up in our environment.
Indeed, the trailing value for the restart actionscript command is used as an identifier, which can be quite useful. In fact, the reference guide for pending restart uses
pending restart <string>
as it’s variable.
Additionally to what @jonbisch points out, then, you don’t even have to use a sha value; you could literally use
action requires restart “this is my custom action”
The advantage of using a sha value is obvious if you have binaries that need to be downloaded/executed, but in some cases you just want to change a value and trigger a restart, in which case you can use any old string value.
Thank you. That is a bit more clear. Kind of a two step with the action and relevance.
Regarding using the sha value, in my example, I have a 32- and 64-bit MSI. So I’m thinking that means I can’t use the sha value since there are two and should instead use a string value?
You can use anything you like - consider it a comment. You can use the x32 download’s sha value, or the x64, or any kind of message.
There are two main reasons to set a string for the action requires restart command. If you are curious as to which BigFix things flagged a restart, you can read them out of the Registry.
More commonly, if you want a Fixlet to only run once and then not be relevant again until the system has restarted, you can check in the Relevance for not pending restart "MY_RESTART_IDENTIFIER". That can help prevent things like two different operators trying to install the same patch in different actions, or one person getting impatient and sending an action twice - whichever action runs first sets the pending restart flag, making the redundant actions non-relevant until the reboot happens.
I think I stumbled upon a “poor mans” fix to the Pending Restart issue… Note that this observation is limited to my machine; I’ll collect more data as our patching window progresses.
We have our Windows 10 Baseline which, in this example, has the Adobe Flash update (KB4093110) and the Cumulative/Delta updates (KB4093107). We normally have the CU listed first in the BL but this time we had the Adobe listed first.
Our patching runs for two weeks with retry one time on failure. Here is what happened.
The CU was installed first and the system rebooted. Shortly after, Adobe was installed and the system rebooted. There were no failures. This leads me to believe that the Adobe patch isn’t relevant until the CU is installed.
The “Happy Accident” here is that my endpoint returned a status of Complete instead of Pending Restart as many do. Unfortunately I don’t think my end users will feel the same.
We find that the way Microsoft does their updates more and more require multiple reboots. The Cumulative Quality Rollups for example are often incompatible with the .NET Framework updates, and Flash Player Win10 patches often require their own reboot as they won’t install with the CU.
We have effectively added multiple reboots to our processes, with a 24 hour notification before enforcing the reboot. Users do have the option to specify a client setting that allows up to 10 days before a reboot is enforced, for machines that run simulations or other long-term tasks (usually REMS related).
Thanks for sharing your experience. I know that Microsoft seems to be off the lease lately and I’m unsure how we combat that. Installing monthly patches should not be like playing Mouse Trap. And if I’m showing my age… Mouse Trap was coming up with the most difficult and complex process to perform a relatively simple task.
Not sure what Mouse Trap is, but here we feel like we’re playing Whack-a-mole
Even most of our Windows servers have had to be restarted multiple times in order to become compliant. At this point we perform a restart when entering our maintenance window if a restart is pending, as well as permitting an unlimited number of restarts during the three hour maintenance window that the server owner can define.
That being said, we do limit the retry rate on patch baselines to 3 times so that we don’t end up rebooting excessively, and we also monitor our patch pilots very closely to catch issues before they go to production.
But yeah, Microsoft patching has gotten a lot more convoluted over the last year and a half it seems (some would say the last decade, I’m sure), and reading the known issues part of the rollups in particular can be critical to efficient patching.
With the above efforts (longer maintenance windows, reboot prior to window if needed, up to 3 reboots in the baseline) we have been able to reach compliance for the vast majority of endpoints the first time we patch, but it’s definitely been a long, iterative process.
We are having issues with this patch KB4093107, patch is getting deployed but when system reboots complete patch rolling back to previous state and becomes relevant. We tried two times attempt but still the same error.
BigFix current version is 9.2.7…
is it the old version issues … if yes then many computers have updated this patch. why for few machines…
please suggest what could the issue.
Sounds like a specific machine issue, not a general deployment issue. 14081 is an SXS error, which also points to the patch not getting fully installed.
Remember that the “pending restart” flag does not equal a success flag; when the action runs to completion the pending restart flag is set, and the action becomes non-relevant until the pending restart flag is cleared.
I’d wager you have a SxS issue on that machine, which will have to be resolved. There are plenty of resources for this on TechNet, and googling the error message is probably your best bet.
For reference:
ERROR_SXS_ASSEMBLY_MISSING
14081 (0x3701)
The referenced assembly could not be found.
