Common policy configuration mistakes for managing Windows updates
Published Jan 19 2021 07:58 PM 34.1K Views
Microsoft

Misconfigured policies can prevent devices from updating and negatively affect monthly patch compliance. Explore common policy configuration mistakes that can hinder update adoption and result in a poor experience for your end users—and get guidance on how to review your Windows update policies to confirm your devices are configured correctly. Alternatively, you can leverage the Update Baseline tool to automatically apply the recommended set of Windows Update policies to your devices.

Set deadlines (with a grace period)

One of the most powerful resources that IT admins can use to support patch compliance is setting deadlines. A deadline is the number of days before a device is forced to restart to ensure compliance. Deadlines provide a balance between keeping devices secure and providing a good end user experience.

Deadlines work in coordination with pause and deferral settings. For example, if you set a quality update deadline of 2 days and a quality update deferral of 7 days, users will not get offered the quality update until day 7 and the deadline will not force restart until day 9. Similarly, if you (or the end user) pause quality updates, the deadline will not kick in until after the pause has elapsed and a quality update is offered to the device. For example, if the end user pauses all updates for 7 days and the quality update deadline is set to 2 days, as soon as the pause period is over on day 7, the deadline kicks in and the device will have 2 days to download, install, and restart to complete the update.

To ensure a good user experience for devices that have been shut off for some time, as when a user of a device is on vacation, we strongly recommend setting a grace period. The grace period is a buffer that prevents deadlines from immediately forcing a restart as soon as a device is turned on.

We also recommend leveraging the default automatic restart behavior. Windows has heuristics to analyze when the user interacts with the device to find the optimal time to automatically download, install, and restart. Allowing auto-restart can therefore improve your patch compliance while maintaining a good end user experience.

We recommend the following settings for deadline policies. You can find these policies in Group Policy under Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify deadlines for automatic updates and restarts or the CSP name listed for each policy setting below.

  • Quality updates (days): 0-7 (3 days is the recommended configuration)
    CSP name: Update/ConfigureDeadlineForFeatureUpdates
  • Feature update (days): 0-14 (7 days is the recommended configuration)
    CSP name: Update/ConfigureDeadlineForQualityUpdates
  • Grace period (days): 0-3 (2 days is the recommended configuration)
    CSP name: Update/ConfigureDeadlineGracePeriod

    Note: We strongly recommend the sum of a feature update/quality update deadline and the grace period to be no less than 2. Setting a value lower than 2 can cause a poor end user experience due to the aggressive timeline.

  • Auto-restart: Disabled is the recommended configuration.
    CSP name: Update/ConfigureDeadlineNoAutoReboot

How to set deadlines for automatic updates and restarts using Group PolicyHow to set deadlines for automatic updates and restarts using Group Policy

For more information, see Enforcing compliance deadlines for updates in Windows Update for Business.

Make sure automatic updates are set up correctly

Automatic updates are another policy where misconfigurations affect patch compliance. Within the Configure Automatic Updates policy in Group Policy (see below for the Configuration service provider (CSP) equivalent), you can define when and if to require end user interaction during the update process.

As a rule of thumb, requiring end user approval of updates negatively impacts patch compliance and success rates by a significant percentage. To simplify the update process, we therefore recommend either not configuring this policy at all or, if configured, selecting “4 – Auto download and schedule the install.” This allows the update to download and install silently in the background and only notifies the user once it is time to restart.

We also recommend setting the scheduled installation time to “Automatic,” rather than a specific time to restart, as the device will then fall back to the configured restart policies, such as active hours, to find the optimal time to schedule the restart (like when the user is away).

We strongly recommend not requiring the end user to approve updates for the smoothest update process as this can create bottlenecks in the update process. This includes avoiding configuring “2 - Notify for download and auto install” and “3 - Auto download and notify for install.”

If you do choose to use values 2 or 3, the following policy conflicts may arise and prevent updates from successfully being applied or may significantly degrade the end user experience.

  • If "Configure Automatic Updates” is set to 2 or 3 and
    "Remove access to use all Windows Update features” is set to Enabled:

    The end user will be unable to take action on Windows Update notifications and will, therefore, be unable to download or install the update before the deadline. When the deadline is reached, the update will automatically be downloaded and installed.

  • If "Configure Automatic Updates” is set to 2 or 3 and
    " Display options for update notifications” is set to (2) Disable all notifications including restart notifications:

    The end user will not see notifications and, therefore, cannot take action without going to the Windows Update Settings page. Thus, the user will be unlikely to download or install the update before the deadline at which time the device will be forced to restart without any warning.

How to configure automatic update settings using Group PolicyHow to configure automatic update settings using Group Policy

The CSP equivalent of the above recommended configurations for "Configure Automatic Updates" in Group Policy would be:

  • Update/AllowAutoUpdate = 2 (Auto install and restart. Updates are downloaded automatically and installed when the device is not in use.)
  • Update/ScheduledInstallDay = 0 (Every day)
  • Update/ScheduledInstallEveryWeek = 1
  • Or simply not configuring the policy

Ensure that devices can check for updates

Frequently, we see the policies listed in this section misconfigured during the initial setup of a device and then never revisited. If left misconfigured, they can prevent devices from updating. As a result, we recommend that you review the following policies to ensure they are configured correctly. You can find these policies in Group Policy under Computer Configuration > Administrative Templates > Windows Components > Windows Update or the Update Policy CSP listed for each policy setting below.

Do not allow update deferral policies to cause scans against Windows Update
CSP name: Update/DisableDualScan

If a device is configured to receive updates from Windows Update, including DualScan devices, make sure this policy is not set to Enabled. To clean out the policy, we recommend you set this policy to Disabled.

Specify intranet Microsoft update service location
CSP name: Update/AllowUpdateService

We see a significant number of devices unable to update due to bad Windows Server Update Services (WSUS) server addresses, often because a replacement WSUS server is provisioned with a different name. As a result, double-check to ensure that the WSUS server address is up to date. Devices that are misconfigured to ping an address that is expired or no longer in service won’t receive updates.

Additionally, scan failures can occur when devices require user proxy to scan their configured WSUS server and do not have the proper proxy policy configured. for proxy scenarios, see Scan changes and certificates add security for Windows devices using WSUS for updates.

Configure policies to ensure a good end user experience

The following policies can negatively affect your end user experience:

Remove access to “Pause updates” feature
CSP name: Update/SetDisablePauseUXAccess

Enabling this policy can benefit your monthly adoption rate, but also prevents users from pausing updates when necessary. If you have set deadlines that may cause a mandatory restart, disabling this policy will give end users the power to protect their work. For example, if a device is in the middle of a process that must run for consecutive days, the end user may want to make sure that their device is not forced to restart during the process.

Remove access to use all Windows Update features
CSP name: Update/SetDisableUXWUAccess

Leveraging this policy will remove the end user's ability to use the Windows Update Settings page. This includes their ability to check for updates or interact with notifications, and can lead to policy conflicts. Note that, if this policy is left alone, checking for updates simply prompts a scan and does not change what the user is offered if you have configured Windows Update for Business offering policies on the device.

Display options for update notifications
CSP Name: Update/UpdateNotificationLevel

We recommend this setting is configured to 0 (default). If set to 1 or 2, this setting will disable all restart warnings or all restart notifications, limiting the visibility that your end user has to an upcoming restart. This can result in restarts happening while the end user is present with no notifications due to the deadline being reached. Enabling this policy is recommended for kiosk or digital signage devices only.

Apply recommendations with the Update Baseline

To implement the recommendations outlined above, we provide the Update Baseline tool which allows you to import our full set of Windows update policy recommendations into Group Policy Management Center. The Update Baseline toolkit is currently only available for Group Policy. A Microsoft Intune solution to apply the Update Baseline is coming soon. Download the Update Baseline and review the documentation included to view and apply our full list of policy configuration recommendations.

Try out our policy recommendations for yourself to see how you can improve your patch velocity. Let us know what you think by commenting below or reaching out to me directly on Twitter @ariaupdated.

 

9 Comments
Copper Contributor

Great article! It's helpful to know the Microsoft recommended update settings. I also downloaded the Update Baseline tool and am evaluating the GPO recommendations. Our company is trying to move away from GPO's and to use Intune policies instead. I imported the gpreport.xml to Intune GPO Analytics, but it shows that only 55% of the settings are Intune MDM Supported. Any chance the Intune team can work on adding support for all those settings? 

Microsoft

@Ian55 actually the reason it is such a low % supported is because a lot of the things Update Baseline is setting is disabling policies or attempting to get the default behavior. Ideally, as stated in the article - you just leverage the default behavior and then only configure offering policies and deadlines. :) 

Copper Contributor

Thanks, Aria.

That's quite helpful, and you have no idea how convenient the timing is! At least the time when I found it, I'm not sure when it was written. :)

Emanuel

Copper Contributor

Very helpful but when will we have Baseline settings for Intune? 

Copper Contributor

Thanks for this guidance.  We're making changes because of it.

 

One significant typo - the CSP name for Feature and Quality deadlines appear to be reversed

Copper Contributor

In our environment we have the following settings:

 

Quality Updates: 2 days

Feature Updates: 21 days

Grace Period: 7 days

Auto download and schedule install update: 6am Don't autorestart until end of grace period: enabled

 
From what I understand for Quality update, a restart is required after the automatic install at 6am which triggers the 7 days grace period to kick in.
 
For Feature updates a restart is never required. When it installs it restart, you never get a grace period but you get the 21 days of notifications from the deadline.
 
Unless in both cases you boot Windows past either deadline, you should get a grace period for both?

 

Is this correct?

 

Thank you,

Alex

Microsoft

@Alexandre Gauthier thanks for reaching out. Grace period actually applies for both feature updates and quality updates. Note, in either case when restart is pending (for a feature or quality update) the end user will have the grace period length of time to update before the deadline is forced. 

 
Microsoft

This is a detailed description of the compliance deadline behavior.This is a detailed description of the compliance deadline behavior.

Copper Contributor

Hello,

Trying to verify a configuration setting and behaviors - if we set the DeferQualityUpdatesPeriodInDays = 13, ConfigureDeadlineForQualityUpdates = 3, and  ConfigureDeadlineGracePeriod = 0, what will result?  Assumption is:

  • Updates will install on Monday (i.e for June 2023, on June 26 following update release on June 13) due to DeferQualityUpdatesPeriodInDays setting
  • Installation will be forced after 3 days, potentially during "Active Hours" on June 29 (assuming no inactive time before then)
  • Reboot will be forced immediately after installation due to ConfigureDeadLineGracePeriod = 0

If we want to avoid unprompted reboots, but still ensure reboot within 3 days of patch installation, we should instead set the ConfigureDeadLineGracePeriod = 3 correct?  To be clear this is all with using CSP settings manually, no GPO in effect,

 

Co-Authors
Version history
Last update:
‎Feb 02 2023 10:47 AM
Updated by: