Steve Pruitt at myITforum.com

Have you ever had users complain that their computer rebooted unexpectedly about the time you deployed patches? Maybe it gave them a brief warning, but no chance to postpone? We ran into that, and it took a fair bit of digging to get the answer.

We found out that one of the first things that the patch update program does, even before looking at the options you selected, is to check the PendingFileRenameOperations registry key. If there are any operations pending, it performs a reboot right away. It doesn't matter if these affect the patches or not. It doesn't matter if they have anything to do with patching. If there are any operations pending, you get a reboot. I think it gave a five-minute warning, with no option to postpone or cancel. That's not even long enough to call the Help Desk and get to someone that might know what processes to cancel. This applies to servers as well as workstations, of course.

I found, from looking at BindView reports that showed the pending operations, that there were many machines with pending operations from all sorts of things. Most seemed to be from the printers, others were from AntiVirus or other application updates. Some were from patches applied through baseline updates. Our results won't be the same as yours, but the results are definitely not what I had expected. I never there would be so many!

This was even worse when we were using MBSA for patching. We often had two or three separate updates for each machine, one for each scanner (MBSA, Office and Extended MBSA) with updates that month. At first we made two of the three silent, to minimize hassle for the users. That was fine until an Office update turned out to set pending operations for nearly every computer! In fact, that's what led to learning the real cause of this. Until then there were so few complaints that it never got a whole lot of attention.

What do you do about this?

• It'd be great if you could control what adds to the pending operations and schedule reboots as required. That's easier said than done, based on my personal observations. We never could figure out where many of these came from.
• You can schedule a reboot every night for workstations that have pending operations. If you limit this to machines with no users logged on you can avoid almost all disruption. Then you'd have to report machines that still need a reboot first thing in the morning and do something about them. If you try something like this, remember that this info is updated by hardware inventory. Be sure you're looking at current data!
• If you have workstations that can't be rebooted normally, such as night operations consoles or 24-hour call centers, you'll need to report such machines and contact the users, asking them to reboot. If you have a lot of these you may need a tracking and follow-up procedure.
• You could run a script that nags users to reboot until the Pending Operations registry key is clear.
• You can report servers that need reboots on Friday morning and notify the appropriate teams to please reboot their servers during the weekend maintenance window. That's probably the best way to handle servers. You might do a report earlier in the week with a follow-up on Friday, to give more warning.
• Think seriously about how you do baseline patching, for machines that need old patches reapplied because of application installs or maintenance activities. I'm writing a separate article to address this subject.
• We were able to minimize the impact on workstations by advertising the regular patches beginning late in the evening. This did not eliminate the impact, but it came close enough to serve.

The main thing is being aware that these reports represent a real problem, and what's causing it. If you understand what is setting the pending operations you're well on the way to preventing the problem.