Plan Automatic Updates Settings

Article
08/31/2016

Applies To: Windows Server Update Services, Windows Small Business Server 2011 Standard, Windows Server 2008 R2, Windows Server 2003 with SP2, Windows Server 2008 R2 with SP1

You can specify a deadline to approve updates on the WSUS server. The deadline causes client computers to install the update at a specific time, but there are a number of different situations, depending on whether the deadline has expired, whether there are other updates in the queue for the computer to install, and whether the update (or another update in the queue) requires a restart.

By default, every 22 hours minus a random offset, Automatic Updates polls the WSUS server for approved updates. If new updates need to be installed, they are downloaded. The time between each detection cycle can be manipulated from 1 to 22 hours.

You can manipulate the notification options as follows:

If Automatic Updates is configured to notify the user of updates that are ready to be installed, the notification is sent to the System log and to the notification area of the client computer.
When a user with appropriate credentials clicks the notification area icon, Automatic Updates displays the available updates to install. The user must click Install to start the installation. A message appears if the update requires the computer to be restarted to complete the update. If a restart is requested, Automatic Updates cannot detect additional updates until after the computer is restarted.

If Automatic Updates is configured to install updates on a set schedule, applicable updates are downloaded and marked as ready to install. Automatic Updates notifies users who have appropriate credentials by using a notification area icon, and an event is logged in the System log.

At the scheduled day and time, Automatic Updates installs the update and restarts the computer (if necessary), even if no local administrator is logged on. If a local administrator is logged on and the computer requires a restart, Automatic Updates displays a warning and a countdown for the restart. Otherwise, the installation occurs in the background.

If the computer must be restarted, and any user is logged on, a similar countdown dialog box is displayed, which warns the user about the impending restart. You can manipulate computer restarts with Group Policy.

After the new updates are downloaded, Automatic Updates polls the WSUS server for the list of approved packages to confirm that the packages it downloaded are still valid and approved. This means that, if a WSUS administrator removes updates from the list of approved updates while Automatic Updates is downloading updates, only the updates that are still approved are actually installed.

Expired and unexpired deadlines

If the client computer contacts the server after the update deadline has passed, it will try to install the update as soon as possible. WSUS administrators can set update deadlines to a date in the past to have client computers install the update immediately.

If the deadline has not passed, the client computer will download the update and install it the next time an installation occurs. For example, if the client computer downloads an update with a deadline of 6:00 A.M., and the scheduled installation time is 3:00 A.M., the update will be installed at 3:00 A.M. Likewise, if a user starts an installation before a (downloaded) update's deadline, the update will be installed.

Deadlines and updates that require restarts

Updates that have deadlines and require restarting the computer will cause a forced restart at the time of the deadline, no matter when the update was actually installed.

Following is an example of client computer behavior with an unexpired deadline:

Update 1, which has no deadline but requires a restart, is installed at 1:00 A.M., and the computer is not restarted.
Update 2, which has a deadline of 6:00 A.M. and does not require a restart, is downloaded and installed at 3:00 A.M.
The computer is restarted at 6:00 A.M. (the deadline of Update 2).

Following is an example of client computer behavior with an expired deadline:

Update 1, which has no deadline but requires a restart, is installed at 2:00 A.M., and the computer is not restarted.
Update 2, which has a deadline of 1:00 A.M. and does not require a restart, is downloaded and installed at 3:00 A.M.
The computer is restarted after Update 2 is installed, at 3:00 A.M. (the first possible restart time).

WSUS updates and deadlines

A WSUS update (an update that is required for WSUS to continue functioning correctly) has installation priority over other kinds of updates. If an update with a deadline is blocked by a WSUS update, the deadline will apply to the WSUS update, as in the following sequence of events:

Update 1, which is a WSUS update with a deadline of 6:00 A.M., and Update 2, which is a non-WSUS update with a deadline of 2:00 A.M., are both downloaded at 1:00 A.M.
The next scheduled installation is at 3:00 A.M.
The installation of Update 1 starts at 2:00 A.M.

If the deadline of a blocked update has expired, the WSUS update that is blocking it will be installed immediately.

Automatic Updates scenarios

The following scenarios explain how registry settings affect updates on client computers.

RescheduleWaitTime

The following behaviors apply for the RescheduleWaitTimeEnabled registry setting if a scheduled installation is missed because the client computer was turned off.

If the setting is present and it is not set to 1: Automatic Updates waits until the next scheduled day to perform the installation.
If the setting is present and set to 1: Automatic Updates waits for the number of minutes specified in RescheduleWaitTime after the service start time to perform the installation.
If the setting is absent: Automatic Updates waits for one minute after the service start time to perform the installation, regardless of the RescheduleWaitTime value.

The following rules apply to the RescheduleWaitTimeEnabled registry setting:

When a scheduled installation is missed, it is rescheduled for the system startup time plus the value of RescheduleWaitTime.
Changes in the scheduled installation day and time by using the Control Panel or Group Policy take precedence over the rescheduled time.
The rescheduled time has precedence over the next calculated scheduled day and time if the next calculated scheduled day and time is later than the rescheduled time. The next calculated scheduled day and time is calculated as follows:
1. When Automatic Updates starts, it uses the current schedule to calculate the next scheduled day and time.
2. The resulting day and time value is then compared to the ScheduledInstallDate.
3. If the values are different, Automatic Updates performs the following actions:
- Sets a new next calculated scheduled day and time in Automatic Updates.
- Writes the new next calculated scheduled day and time to the ScheduledInstallDate registry key.
- Logs an event that states the newly scheduled installation day and time.

The following examples show how you can use the RescheduleWaitTime value.

Example 1: Installation must occur immediately following system startup

This example shows the consequences of setting RescheduleWaitTime to 1.

Update installations are scheduled to occur at 3:00 A.M every day.
The RescheduleWaitTime registry value is set to 1.
Automatic Updates finds and downloads an update that is to be installed at 3:00 A.M.
The logged-on user does not notice the ready to install prompt because the user does not have administrative privileges on the computer.
The user shuts down the computer.
The user restarts on the computer after the scheduled time has passed.
When Automatic Updates starts, it recognizes that it missed its previously set scheduled installation time and that RescheduleWaitTime is set to 1. It therefore logs an event with the newly scheduled time, which is one minute after the current time.
If no user logs on before the newly scheduled time (one- minute interval), the installation begins. Because no user is logged on, no delay or no notification occurs. If required, Automatic Updates restarts the computer.
The user logs on to the updated computer.

Example 2: Installations must occur fifteen minutes after the Automatic Updates service starts

This example shows the consequences of setting RescheduleWaitTime to 15.

Update installations are scheduled to occur at 3:00 A.M every day.
The RescheduleWaitTime registry value is set to 15.
Automatic Updates finds and downloads an update that is to be installed at 3:00 A.M.
The local administrator ignores the prompt to install the update and shuts down the computer.
The local administrator restarts on the computer after the scheduled time has passed.
When Automatic Updates starts, it recognizes that it missed its previously set scheduled installation time, and that RescheduleWaitTime is set to 15. It logs an event that uses the newly scheduled time (fifteen minutes after the current time).
The local administrator logs on before the newly scheduled time.
After Automatic Updates runs for 15 minutes, it starts the scheduled installation.
The local administrator is notified by the countdown timer five minutes before the installation begins.
The timer expires and the installation proceeds.

NoAutoRebootWithLoggedOnUsers

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

When the NoAutoRebootWithLoggedOnUsers registry value is set to 1, the restart countdown dialog box will change as shown in the following table.

Users who have administrator credentials	Users who do not have administrator credentials
The Restart Later button is active.	The Restart Later button is inactive.
The Restart Now button is active if the logged-on user is the only administrator who is logged on at the time that the restart dialog box displays.	The Restart Now button is active only if the logged-on user is the only non-administrator who is logged on at the time that the restart dialog box displays. However, the Restart Now button is inactive if the user’s local security policy prohibits the computer from restarting.
The restart countdown progress bar and the text below the progress bar does not display.	The restart countdown progress bar and the text below the progress bar does not display.

Example 1: Non-administrator user on a workstation

In this scenario, the network is considered to have the following conditions:

Updates are scheduled to be installed every day at 3:00 A.M.
Users are running as non-administrative users.
NoAutoRebootWithLoggedOnUsers is set to 1.
The user is assigned Shut down the system privileges through Group Policy.

Resulting client computer behavior:

Automatic Updates detects and downloads an update and sets the scheduled installation time to 3:00 A.M.
The logged on non-administrative user leaves the workstation locked at the end of the day.
The scheduled installation starts at 3:00 A.M.
The update requires a computer restart. Automatic Updates displays a message that states a restart is required.
At 9:00 A.M., the user unlocks the workstation and notices the restart prompt.
The user cannot click Restart Later to dismiss the dialog, but the user can click Restart Now because no other users are logged on to the computer. The user can accept the prompt to restart the computer at a convenient time.

Example 2: Non-administrator user on a server

In this scenario the network is configured to have the following conditions:

By default, users who do not have administrative privileges cannot restart server computers that run a Windows Server operating system. This rule is enforced by local security policies.
Multiple non-administrator users are logged on at the time the scheduled installation begins.
The installation requires that the computer be restarted.

Resulting client computer behavior:

Users are notified of the installation.
When the installation requires a computer restart, all logged-on users are notified that the computer must be restarted.
Event ID 21 is written to the system event log:
Non-administrator users cannot click Restart Later.
Because non-administrator users cannot restart the server, the Restart Now button is disabled.
If new users log on, they receive the notification that the server must be restarted.
Users log off.

Every time a user logs off, Automatic Updates tests to see if any users are still logged on.

When there are no logged-on users, Automatic Updates writes Event ID 22 to the system event log and begins the restart procedure.

Summary of behavior for NoAutoRebootWithLoggedOnUsers settings

The following table shows the resulting behaviors when NoAutoRebootWithLoggedOnUsers is 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 after installation.	Automatic restart immediately after installation.
Single user with administrative privileges	Restart notification allows user to initiate the restart or postpone restart. This notification does not have a countdown timer. The user must initiate the system restart.	Restart notification allows user to initiate the restart or postpone restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.
Single user with restart privileges but no other administrative privileges	Restart notification allows user to initiate, but not postpone, the restart. This notification does not have a countdown timer. The user must initiate the system restart.	Restart notification allows user to initiate, but not postpone, the restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.
Single non-administrator without restart privilege	Restart notification does not allow the user to initiate or postpone the restart. This notification does not have a countdown timer. The user must wait for an authorized user to initiate the system restart.	Restart notification does not allow the user to initiate or postpone the restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.
Administrator while other users are logged on	Restart notification does not allow the user to initiate the restart, but it allows the user to postpone the restart. This notification does not have a countdown timer. The user must initiate the system restart.	Restart notification allows the user to initiate or postpone the restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator with restart privilege while other users are logged on	Restart notification does not allow the user to initiate or postpone the restart. This notification does not have a countdown timer. The user must initiate the system restart.	Restart notification does not allow the user to initiate or postpone the restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.
Non-administrator without restart privilege while other users are logged on	Restart notification does not allow the user to initiate or postpone the restart. This notification does not have a countdown timer. The user must wait for an authorized user to initiate the system restart.	Restart notification does not allow the user to initiate or postpone the restart. This notification has a five-minute countdown timer. When the timer expires, the automatic restart begins.

After all users log off, Automatic Updates will restart the computer to complete the installation of the update.

Interaction with other Group Policy settings

If the Remove access to use all Windows Update features Group Policy setting is enabled (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\WindowsUpdate\DisableWindowsUpdateAccess), Automatic Updates does not notify the logged-on user of a pending update and the user cannot install updates. When this policy setting is enabled, the Automatic Updates service runs, and the scheduled installations occur as configured.

If the Remove links and access to Windows Update Group Policy setting is enabled (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoWindowsUpdate), Automatic Updates continues to obtain updates from the WSUS server. User accounts that have this policy setting enabled cannot download updates that are not approved on the WSUS server. If this policy setting is not enabled, local administrators can install unapproved updates from the Microsoft Update website, even if you have specified that Automatic Updates should get approved updates from the WSUS server. In Windows Vista, enabling this policy setting will dim the Check for updates option in the Windows Update application.

You can override these policy settings by configuring the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\ DisableWindowsUpdateAccess policy setting.