There was recently a lively discussion on the Veeam R&D forums that inspired me to write this post. The essence of the disagreement on there was about Veeam’s inability to support new Windows Feature Updates sooner. I won’t repeat all of my points on the topic as they’re available for reading freely on the R&D forums already. What I do want to focus on however, is providing support to the thinly-stretched sysadmin who needs to get a grip on the Windows Update Lifecycle, to avoid issues with the Veeam Agent, and other applications that don’t have ‘Day One’ support for a new Operating System (Yes, Feature Updates are considered upgrades).
So, what is a feature update? Please the quote below directly from Microsoft’s own documentation.
Feature updates: Previously referred to as “upgrades,” feature updates contain not only security and quality revisions, but also significant feature additions and changes. Feature updates are released as soon as they become available.
Microsoft Learn – November 2022 (Link)
Prior to the beliefs of some, these aren’t ‘security’ updates and, provided you’re on a supported feature update version, there’s no reason to jump onto these before you’ve performed your own validation that it’s acceptable.
Controlling Updates via Group Policy
Now we understand why it’s acceptable to delay feature updates, how do we achieve this? Some organisations might have SCCM or Intune deployed, or even a managed service provider’s RMM solution, but these tools can often have costs associated with them in the form of subscriptions or licensing. We’re going to look at how we achieve device compliance using nothing more than Group Policy.
Prerequisite – Administrative Templates
Depending on your domain controller’s operating system, you might not have the appropriate administrative templates to manage the settings you require, so be sure to head over to Microsoft and grab the latest versions of the administrative templates you’ll require, whether Windows 10 or 11.
If you’ve never installed an administrative template before, you should create a central store within your domain to hold your administrative templates, typically this would be something like the below:
\\<DOMAIN>\SYSVOL\<DOMAIN>\policies\PolicyDefinitionsStore your administrative templates in this folder ready to be read by your domain controller’s group policy tools. For more information on the central store, read Microsoft’s documentation here.
With our templates in hand, we can begin to define our policies.
Group Policy Configuration
In this section, we’ll look at the settings we need to configure, but it’ll be down to yourself to determine if you want to create multiple policies to varying scopes, for example if you want to release the feature update to the IT admin machines 30 days earlier than the rest of the organisation, or if you just want a single policy for all.
Begin to create your new Group Policy Definition and proceed to the following location:
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Preview Builds and Feature Updates are receivedNote: Microsoft have changed the name historically between Group Policy Definitions and so the name might vary slightly within your own group policy definitions.
There are three radio buttons relating to the category, whether to be "Not Configured", "Enabled", or "Disabled". This is set to "Enabled", implying the settings are to be enforced.
There are three options available within this configuration category.
The first is "Select the Windows readiness level for the updates you want to receive", this supplies a dropdown menu that lists options for preview releases as well as a couple of Semi-Annual Channel options, with "Semi-Annual Channel (Targeted)" being the selected option.
The second option is labelled "After a Preview Build or Feature Update is released, defer receiving it for this many days:", I have entered a value of "180" into the text field, ensuring feature updates aren't provided for 180 days after initial release.
There is a third option labelled "Pause Preview Builds or Feature Updates starting:". There is a text field and supporting text advising formatting, the formatting being 'YYYY-MM-DD', or better described as "Four digits for the year, then a dash, then two digits for the month, then another dash, then two digits for the day" with an example date of '2016-10-30'
From here, we define the number of days a feature update can be delayed, up to a maximum of 365 days. How long a feature update is supported depends on the version of Windows and edition, as well as if you’re on the Long-Term Servicing Branch (LTSB) or current branch. Full lifecycle information is available from Microsoft here. But at a minimum, expect 18 months of support for Windows 10, and 24 months of support for Windows 11. Depending on your application lifecycles, and how quickly the developers of these agree to support your new operating system feature update, this will impact the delay you will require. Veeam for example, typically supports new versions within 90 days, so I would set a policy of 120-150 days for my internal IT team, and then add 30-60 days before it gets deployed to the rest of the business, to ensure stability.
And what if you are about to roll out a feature update and you discover something has broken, or you haven’t updated all relevant agent/endpoint software in time? You don’t need to change the deferred policy; you can simply push a ‘pause’ on feature updates being deployed. Within the same path as above, there’s also an option to pause updates, this accepts a date input, and will pause updates for 35 days from this date, to prevent the policy being accidentally left enabled, should you require more time, you can change the date on this to continue to pause updates for longer.
Bonus Content: Windows Update Baseline Toolkit & Additional Policy Settings
Microsoft offer a Windows Update Baseline Toolkit to make it easier for sysadmins to get up and running with the Windows Update policies they want to use, but I’ve avoided talking about it earlier in this article because it currently only supports Windows 10. Check it out for yourself here.
There are two options, the first one is "After a quality update is released, defer receiving it for this many days", with a number field provided, I've inputted a value of 10 into this, to ensure quality updates are delayed 10 days, as this is a policy for my stable ring of endpoints.
The second option is "Pause Quality Updates starting". This has an optional text field that needs a date configured with the 'YYYY-MM-DD' format, or better described as "Four digits for the year, a dash, then two digits for the month, another dash, then two digits for the day".
Other than the policies defined in the previous section, you can also configure Quality Update delays, though for a lesser time period of up to 30 days, I would typically enforce quality updates for my endpoints to be deferred about a week past whenever I release them to my IT team.
On the flip-side, though my previous have focused on delaying updates, you can also use the GPOs to enforce deadlines for patching, to prevent those users that never shut down their machines from becoming a security risk. This has a nice, multi-layered approach, whereby the device can initially attempt to update outside the “active hours”, however upon expiration of the deadline it can begin to force update attempts during active hours. To read more about enforcing deadlines, check out Microsoft’s article here.
In summary, with the built-in group policy options provided by Microsoft, it is possible to create (and enforce) a reliable update experience for endpoints, without requiring additional costs, or constant IT management overheads.
