(714) 572-5600 info@aisconsulting.net
For years I’ve been asked a question about a nagging scenario on some Windows clients:

Why does BigFix show the computer in a state of Pending Restart even after it’s been rebooted?

As far back as I can remember, BigFix had an answer.  To paraphrase:

A status of Pending Restart is a way of BigFix telling you as the operator that one or several flags have been set on the client causing it to report as needing a reboot.  These flags aren’t necessarily set by BigFix though.  They can be set by other processes as well, but BigFix reads them and let’s you know.  Invariably this often leads to a case of ‘shooting the messenger’ with BigFix being blamed for misreporting or not working properly.  In reality, it just takes a little digging to find out that in many cases, BigFix is not the culprit, but rather to use a more apt metaphor: It’s the ‘canary in the coalmine’.

Brad Sexton of HCL’s BigFix team gets right to the heart of the matter in his great article which you can read here:


There’s also a similar write up on this BigFix Wiki page which can be incredibly helpful:


They both make a similar point:  On Windows clients, a Pending Restart can sometimes be the result of the existence of a specific registry key or a certain value in an key.  Both the Wiki and Brad outline which keys are involved so you can go straight to the computer and figure out the root cause of the status.

This works well for detecting the issue, but as I was recently asked this same question by a customer, I thought I would take it a step further and provide them with some content that could help identify and clear whichever one of these registry keys was the culprit.  When I first read Brad’s post, I tried to click through to the analysis he linked, but was unsuccessful so I decided to create my own.  I wasn’t able to upload it to bigfix.me so I’m including a link to a google drive folder where I’m sharing it:



Downloading from a random link, especially nowadays can be a recipe for disaster.  To somewhat mitigate this, I’m including the sha256 hash of the file in that drive as a safety precaution:
sha256: fb056280fa3154f234b763b14f540377599e57033afec3a7e9c6624142872e05

If you still don’t feel confident enough to download it from this URL, feel free to send me a message with your email address and I will reply with it as an attachment. In either case, the analysis description tells you everything you need to know about what it looks for:












As well as the properties it includes:

A quick look at the analysis results easily identifies where the trouble might be coming from:

Keen-eyed observers will note that the analysis contains one additional property that is not included in Brad’s original post.  This is thanks to testing by my colleague Don Poor who realized there were some cases where none of these were present, but the system still reported as being in Pending Restart status. But as all analyses do, it only provides information, not remediation.  I also created a task that actually clears any of the listed registry keys if they are present and/or have the values that might cause the issue.  I was able to upload the task to bigfix.me.  You can find it here:


A word of warning is appropriate at this time:

Because some of these keys and values can indicate legitimate scenarios that require a reboot of the computer, employing the task to clear them is something you should only do as a last resort.  If you have restarted the system several times and are still seeing this status, it may indicate that one of these keys is not being cleared correctly.  In such a case using the task might be appropriate.

If you do decide to use it, you’ll be happy to know that it has some features that provide an audit trail of its use.  It writes a running log file that indicates when it was used, by who and what keys were detected and subsequently deleted.  As is the case with the BES Client log, this particular log will be stored on the client itself.  This is what it looks like when a key or value is not found:

And here is what it looks like when it does find something that it has to delete:

These can all be customized by the owner using parameters at the beginning of the task:

As an additional feature it also provides a way for operators to disable the logging of the task’s actions in the BESClient logfile to limit publishing its actions to the task’s own logfile.

As with all BigFix content, both the task and analysis are completely customizable.  If you find a better way to do this, then I encourage you to do two things:

  • Modify it and make it yours. That, after all is what makes BigFix such a versatile and powerful tool:  Everything can be improved.
  • Let me know so I can update the content and this article for myself as well as others.