- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
- Show or hide users on the logon screen with Group Policy - Thu, Mar 2 2023
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
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
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
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
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 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.
Subscribe to 4sysops newsletter!
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.
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…
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!).
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.
You obviously have to test it. In company with 1700 workstations, 90% on Win10, DO save us a lot of internet bandwidth. We are using DO configured as connected cache on SCCM distribution points.
https://docs.microsoft.com/sr-latn-rs/mem/configmgr/core/plan-design/hierarchy/microsoft-connected-cache
As far as I'm concerned, we can shut down WSUS and rely solely on Connected Cache (DO). But some obsolete minds are stopping that. For them, WSUS is god.
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.