Is Windows Automatic Update Client rebooting your system unexpectedly? Read this to “fix” it….

Recently I exchanged e-mail with several people who were complaining that the Windows Update (AU) client on their Windows system was guilty of automatically rebooting their system. They were upset that their system was rebooted even though they had unsaved work open or were using the system when it was rebooted.

Some examples…One person’s Windows Media Center Edition system was rebooted while they were watching their favorite show on TV. Another person, who uses their laptop as an alarm clock when they travel, slept in because they system was rebooted and the alarm clock application didn’t restart. Another person said they were working on a Word doc and went to the restroom only to return to find their system rebooted and the Word doc gone (lucky it is so easy to recover Word docs).

Most of the stories have two things in common:

1. The system was a Windows XP SP2 system with the AU client configured to “Automatically download recommended updates for my computer and install them on a schedule.”
2. A user was logged on to the system and the console wasn’t visible (it was locked or they were away from the console) when the reboot occurred.

The answer is NOT to disable the AU client. You definitely want to keep your system up to date with the least amount of effort…so please don’t disable the AU client…read on….

As it turns out, the reboot is actually expected behavior. You have Automatic Updates on your system configured to “Automatically download recommended updates for my computer and install them” on a schedule. When one or more of those updates requires a reboot, the system gets rebooted.

But let me explain why it does this and how to prevent it from happening again. First, check what AU client settings are currently set on the system. To do this, open the Control Panel and double click on the Automatic Updates icon.

With the recommended setting (“Automatically download recommended updates for my computer and install them” on a schedule), I should expect my system to reboot at approximately 3:00 AM if any installed updates require a reboot. If you have this set to install during your work hours or when you are watching TV, etc…you should expect an automatic reboot during that period if updates are installed and one or more of them requires a reboot.

If the AU client has rebooted your system, you should see a few related events in your system’s event log. One event is logged when updates are ready to install. The event below is logged when the updates are installed and this results in an automatic reboot (notice the time is shortly after the default 3:00 AM install time).

Event Type: Information

Event Source: Windows Update Agent

Event Category: Installation

Event ID: 22

Date: 10/15/2004

Time: 3:02:02 AM

User: N/A

Computer: MY-COMPUTER

Description:

Restart Required: To complete the installation of the following updates, the computer will be restarted within 5 minutes:

- Critical Update for Office XP on Windows XP Service Pack 2 (KB885884)

- Cumulative Security Update for Internet Explorer for Windows XP Service Pack 2 (KB834707)

 

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.

Data:

0000: 57 69 6e 33 32 48 52 65 Win32HRe

0008: 73 75 6c 74 3d 30 78 30 sult=0x0

The key is this line: “To complete the installation of the following updates, the computer will be restarted within 5 minutes…” When you are logged on to the system, whether the console is locked or not, a dialog box pops up with a timer counting down to reboot. If you are logged on as an administrator, you can abort the count down. If the console is locked or you are not in front of the system when the timer appears…it counts down and reboots the system.

This behavior is controlled by a registry entry. A great source of information on the AU client (and Software Update Services) is the “Software Update Services Deployment White Paper. You can download a copy of this paper from here:

https://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx

Page 57 - 59

To prevent Automatic Updates from restarting a computer while users are logged on, the administrator can create the NoAutoRebootWithLoggedOnUsers registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. The value is a DWORD and must be either 0 (false) or 1 (true). If this value is changed while the computer is in a restart pending state, it will not take effect until the next time an update requires a restart.

Summary of behavior for NoAutoRebootWithLoggedOnUsers settings

The following table shows the difference in behavior with NoAutoRebootWithLoggedOnUsers enabled (set to 1) or disabled or not configured (not set to 1).

Scenario following a scheduled installation	With NoAutoRebootWithLoggedOnUsers enabled	With NoAutoRebootWithLoggedOnUsers disabled or not configured
No users logged on	Automatic restart immediately following installation	Automatic restart immediately following installation
Single user with administrative privileges	Restart notification that allows user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that allows user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Single user with restart privileges but no other administrative privileges	Restart notification that allows user to initiate the shutdown but not to postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that allows user to initiate the shutdown but not to postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Single non-administrator without restart privilege	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must wait for an authorized user to initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Administrator while other users are logged on	Restart notification that does not allow the user to initiate the shutdown but does allow the user to postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown but does allow the user to postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator with restart privilege while other users are logged on	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator without restart privilege while other users are logged on	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification does not have a countdown timer. Therefore the user must wait for an authorized user to initiate the system shutdown.	Restart notification that does not allow the user to initiate the shutdown or postpone it. This notification has a 5 minute countdown timer. When the timer expires, the automatic restart begins.

 

Hopefully you are not logged on very often as an administrator, but either way, pick the scenario that matches how you use your system from the grid above and set NoAutoRebootWithLoggedOnUsers to give you the behavior that you are looking for.

IMPORTANT: If you choose to configure your system not to reboot when a security update which requires a reboot is installed, you are taking a huge risk. The fixed code is not actually loaded (in memory) by the system until after the reboot. i.e. the old, vulnerable code is still running until a reboot is completed. If you do not reboot the system for whatever reason (you didn’t realize a security update was automatically installed, you want to wait for a regular maintenance window, you forget, you were on vacation, etc.) your system will still be vulnerable. You also risk system stability by delaying a required reboot. When some files that are in use are replaced but not loaded, and other files that are not in use are replaced, you can get into a mixed binary situation. Depending on the binary, there may be conflicts that cause system instability.

Given this reality, it may be prudent to deal with “unexpected” reboots in order to always be up to date and safe. You need to weigh the risk…

I hope this tip saves you some confusion.