With Windows 10 1903, Microsoft introduced a new Group Policy setting to speed up the distribution of updates. It overrides a number of older options. In addition, they will soon deprecate several Windows Update settings, giving admins less control.

Microsoft has repeatedly introduced new concepts to determine when to download and install updates and when to restart the computer. These concepts are reflected in a long list of settings, some of which are mutually exclusive or no longer have any effect in Windows 10.

The aim of all methods is to get security-critical updates to computers as quickly as possible and to set the reboots in such a way that they will not interrupt users' work or even cause them to lose data.

Countdown starting with the release of an update ^

The primary goal of the new setting Specify deadlines for automatic updates and restarts is to ensure update distribution as quickly as possible. Therefore, the configured deadlines relate to the patch release dates.

A new setting for Windows Update allows you to force the installation of patches within a certain period

A new setting for Windows Update allows you to force the installation of patches within a certain period

All previous options for controlling reboots only began counting from the point at which the update was installed and a restart was pending.

This applies, for example, to Specify the deadline before a pending restart will automatically be executed outside of active hours. Microsoft only introduced this setting with Windows 10, and it is the predecessor of the new option.

Both options let you set your own deadlines for quality and feature updates, up to a maximum of 30 days (the default is 7 days). After the deadlines expire, users can no longer postpone restarting their computers, and updates will take effect immediately afterward.

However, the new setting offers two additional options. First, you can set an additional "grace period" so that users do not have to restart their computers immediately after a long absence, for example, after returning to work from a holiday.

Interaction with active hours ^

Furthermore, the option Do not restart automatically until end of grace means that computers will only be updated after a manual reboot within the set period. If you do not check this box, Windows will try to find a convenient time for a reboot outside of the "active hours."

After the grace period expires, Windows Update will force users to reboot even during working hours.

This option has the same effect as the setting Turn off auto-restart for updates during active hours. However, this requires a static definition of the active hours.

To prevent restarts during active hours, specify the start and end times

To prevent restarts during active hours, specify the start and end times

Since version 1903, Windows 10 determines the active hours automatically based on user activity. If you want to use this feature, you should therefore avoid defining fixed start and end times.

Converting from notifications to reminders ^

During the defined period, the update client changes the way it interacts with the user. In the first few days, it uses toast notifications to alert the user to a pending update.

After that, it automatically switches to the Engaged restart reminder, where the user can initiate a reboot immediately, schedule it for a specific time, or simply postpone it.

After a few days, Windows 10 switches to the insistent reminder

After a few days, Windows 10 switches to the insistent reminder

You can explicitly configure the switch from the toast notification to the more urgent version using the setting Specify Engaged restart transition and notification schedule for updates. Here you set the time for the notification change yourself.

Up till now, you could configure the changeover of upcoming update notifications exactly, but the new option disallows this

However, if you use the new setting to plan the restart, it will override the configuration for this transition. The new option is therefore much more robust than the previous one, which always deactivated itself in case of conflicts.

New setting deactivates four old ones ^

The goal is largely to determine the behavior of the update installation and the reboot with a single setting. This is also demonstrated by the fact that it eliminates another important option. Until now, it was possible for users to prevent reboots as long as they were logged in. However, this no longer applies with the new setting.

In summary, the new setting overrides four previous ones if they are enabled. These are:

  • Specify the deadline before a pending restart will automatically be executed outside of active hours
  • Specify Engaged restart transition and notification schedule for updates
  • Always automatically restart at the scheduled time
  • No auto-restart with logged-on users for scheduled automatic update installations

Various update settings outdated ^

A recent Microsoft white paper contains a table with Group Policy Object (GPO) and mobile device management (MDM) settings for Windows Update that the vendor recommends you should disable. They are either obsolete or will be phased out in the near future.

GPO and MDM settings for Windows Update that Microsoft recommends you no longer use

GPO and MDM settings for Windows Update that Microsoft recommends you no longer use

Interestingly, this also includes the configuration of automatic updates. As is well known, this setting is required for clients who get their updates from WSUS. Thus, group policies in this respect only catch up with the settings app where automatic update configuration has already disappeared with previous versions of Windows 10.

The GUI no longer provides configuration of automatic updates

The GUI no longer provides configuration of automatic updates

The Microsoft document does not detail the impact of this decision, but in another section, it says that in case of delayed updates, you should check whether Dual Scan was intentionally deactivated, and hence, clients switched back to WSUS.

Outlook ^

This means Microsoft apparently considers Dual Scan to be the preferred configuration. Thus, the big picture for the new update management becomes visible. Users should generally obtain OS updates via Windows Update and restrict WSUS to other products such as Office. WSUS support for the Unified Update Platform has not been available to date and may never come, which further confirms this.

Client configuration will boil down to a single setting described above, which sets deadlines for installing the updates. It completely defines the system behavior during this phase. It's possible to adjust the power options via GPO to increase the maintenance window for patch management as a complementary action.

The goal of these changes is to speed up update distribution by disallowing admins from explicitly approving patches as in WSUS. And users can only delay rebooting their computers up to a maximum of 30 days after an update's release.

The same timeframe is available to admins in Windows Update for Business (WUfB) to postpone quality updates. However, the recommendation in Microsoft's white paper is two to three days. Overall, there's no additional deferral gained by this because with the new setting, the clock is ticking from the time Microsoft releases an update.

WUfB also only grants a 30 day delay from the release of a quality update

WUfB also only grants a 30 day delay from the release of a quality update

The new setting's importance is also clear because Microsoft has updated the servicing stack of older Windows 10 versions (1709 and later) to support it there also. But to configure it, you need the .admx templates for 1903 or 1909.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads by becoming a member!

1+
avatar
Share
5 Comments
  1. Yanta 4 weeks ago

    This sounds pretty scary. One of the key benefits of WSUS is to reduce bandwidth consumption. OK, I only have a dozen PCs to manage, but I don't want them all arbitrarily downloading anything, especially Microsoft patches which are almost always flawed.

    So if I read this correctly, WSUS is essentially dead from a Windows SSU, CU, patch and features updates perspective?

    If that's true I'm going to have to find a different way to block Microsoft from taking control of my PCs and let me decide when I feel it is safe to install something. I just don't have the time to deal with patches that break more than they fix every month.

    I feel sorry for big organizations. This could be a nightmare. Microsoft pushes a broken patch to 500 PCs that the sys admins can no longer manage via WSUS and all hell breaks loose...

    0

    • Wolfgang Sommergut 4 weeks ago

      WSUS won't go away over night but the trend seems to be clear. Bandwidth management will be taken over by delivery optimization, a feature of Windows Update for Business (WUfB). And admins will have up to 30 days to test new updates (I'm not talking about feature updates here!).

      0

      • Yanta 4 weeks ago

         

        DO is hardly "optimized". Say I have 500 PCs, and a gigabit infrastructure. Can I set up DO to roll out in groups? Or is it either on or off? Because if it's the latter, my network just got flooded with 500 PCs potentially sharing patches around the same time.

        It was one of the first things I turned off.

        So - the future - one pc can't be designated as the pc to pull updates for everything, and then distribute those. It's going to be an all in mess where every pc downloads potentially everything, and if one pc is missing something it will share via DO?

        When I first read about DO it seemed like a bad idea, and it still does.Obviously I need to read more about It.

        0

  2. Martin 2 weeks ago

    We had a flooded bandwidth problem with DO between one of our sites and the main office. We use VPNs to connect, the tunnels are with slow speed and DO pretty easily floods them. WSUS has a lot of problems too, but they can be managed unlike DO. DO seems like a fine idea, but it still has to grow a lot to become useful in any scenarios.

    Explicitly approving patches is a must for admins. We use some veeery old software in our company which means that we first must do extensive testing before applying a patch. So far we have a huge problem with new Office versions and we do magic to keep using 2016 without some of the updates. Microsoft makes this more and more difficult which is not good. I guess we are just a small company (about 700 people) and Microsoft doesn't give a sh*t about such.

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account