Keeping Microsoft windows devices up-to-date has been a challenge I have been dealing with for a long time now. Within Microsoft Endpoint Configuration Manager/ConfigMgr getting grips on your updates was and is not an easy experience which you configure once and never have to touch again.

If you in todays world are using Microsoft Endpoint Manager/Intune to manage your Windows 10 Modern Workplace, you are most probably using Windows Update for Business (WUfB). With Windows Update for Business in use you use the Windows Update service from Microsoft and only provision the policy about behavior to the client.

This post describes where we are coming from in the ConfigMgr world, and what needs to change in order to adopt Windows Update for Business. I will go into more detail explaining my default configuration which I use when configuring the WHfB functionality for new and existing environments. Keep in mind, that I describe a baseline, and sometimes deviations must be made depending on customer requirements. Personally I think it’s important that you know which settings to use, which settings not to use (anymore) and how different settings can (badly) influence each other.

*Windows Update for Business architecture*

Disclaimer: This post reflects the status of Configuring Windows Update for Business settings as of March 30, 2021. Functionality may and will change, even right after this post has been published.

Where are we coming from?

The concept when managing software updates with ConfigMgr in a nutshell is that you implement one or more Windows Server Update Service (WSUS) servers which contain a subset of the updates provided by Windows Update. These WSUS servers become part of the ConfigMgr hierarchy, and from that point forward we can configure the WSUS server (which is called a Software Update Point, or SUP) from the ConfigMgr console and don’t have to use the WSUS admin console anymore. The first thing you then let your SUP do is download a subset of the catalog from Windows Update based on a selection made by the Administrator.

ConfigMgr clients then instruct the Windows Update agent to scan against that catalog hosted on WSUS/SUP and report back if they need a software update listed in the catalog. Based on this inventory information the Administrator can then decide to deploy the necessary updates to the client reporting that they need the patch. This can be accomplished by creating Software Update Groups (SUG) which contain a set of software updates and where the Administrator can define when and how the software updates must be installed. The software updates in the SUG can be downloaded and distributed to your distribution points as a package, and by deploying the SUG to a collection the clients receive policy to download an install the patches.

Creating the SUG can be automated by creating Automatic Deployment Rules (ADR), which can be used to automate the process of creating the SUG and the deployment. The success you can accomplish with this process depends on a lot of factors, like ConfigMgr client health, ConfigMgr device hygiene, the Windows Update Agent on the client and more components which must fully aligned with each other.

The added value that ConfigMgr provides is that you can optimize the network bandwidth needed since you only download the software update once (into the software update package) and use the software distribution mechanism in ConfigMgr to distribute the software update to the clients on the LAN, avoiding that these clients reach out to Windows Update individually which might cause the network bandwidth to fill up.

A client device today doesn’t necessarily have to be in the LAN of the company managing the device, and companies have implemented alternatives to keep managing those devices even when not residing in the LAN, like setting up VPN connections or by extending ConfigMgr to the internet by using Internet Based Client Management (IBCM) or by using the more recently introduced Cloud Management Gateway (CMG) functionality. While implementing this functionality makes the ConfigMgr functionality work again, having your devices downloading the software updates directly from Windows Update either under supervision from the ConfigMgr infrastructure, or by moving the functionality provided by ConfigMgr to the functionality provided by Windows Update for Business (WUfB) is a scenario which is used more and more.

Windows Update for Business enables IT administrators to keep the Windows 10 devices in their organization always up to date with the latest security and Windows features by directly connecting these systems to Windows Update service. The behavior of these clients can be governed using Group Policy Objects, or by using Mobile Device Management solutions like Microsoft Endpoint Manager/Intune. When using Windows Update for Business in LAN environments, it’s advised to use and configure Peer to Peer (P2P) technologies to optimize the necessary bandwidth. Ideally in this case, one client downloads the software update, and shares the data with other clients on the same network.

Since the introduction of Windows 10, Microsoft has been struggling with how to make the Windows Update experience fit with the requirements from its customers. This makes finding the right and most current information troublesome and confusing. Microsoft changed the way they named functionality along the way and they also modified how updates are delivered, by optimizing the necessary download sizes and reducing the amount of software updates. Today we are talking about quality updates which are released on a monthly basis and contain fixes and security updates and we have feature updates which are released twice a year updating Windows 10 to a new version. We used to have Servicing Stack Updates (updates to the Windows Update mechanism itself), which caused some issues because quality updates were depending on them, but now these servicing stack updates have been integrated in the quality updates installation as well, removing this dependency on each other. At time of writing Windows 10 feature update 21H1 is around the corner.

This new way of managing software updates with WUfB, which Microsoft refers to as Windows as a Service (WaaS) requires administrators to unlearn what they have been doing for a long time and requires them to re-think and re-learn the concepts and understand the why’s of how to handle things in today’s world. Failing to do so, will result in unpredictable software update installation states, bad user experience, risking that systems are not patches with critical security updates and loose of control.

Managing Windows Update for Business using Microsoft Endpoint Manager

There are a lot of settings involved when configuring your clients for WUfB, some of these settings still relate to functionality available in older versions of Windows. Due to this is quite hard to understand and configure which settings are necessary and fit with the most current version of Windows 10. 20H2 at time of writing. Microsoft must keep older configuration settings available though since they support multiple Windows 10 versions at the same time.

I have been struggling with this as well, mainly due to the fact that the ” best practices” have changed a lot during the Windows 10 lifetime. And settings which I configured 1 year ago, are not necessarily best practices today. It’s therefore advisable to revisit your WUfB settings per Windows feature update and make sure that your settings are still relevant for the majority of the OS versions that you are managing.

In order to make it clear for myself on how the current WUfB settings in my tenant must be configured I started searching the internet for some best practices from Microsoft. I found these best practices in a Microsoft paper titled: “Optimizing Windows 10 Update Adoption”, which is part of the Windows 10 Update Baseline.

The paper, which contains 44 pages explains how to configure WUfB in both a Group Policy and MDM managed environment. Personally I found the paper confusing at some times, and therefore decided to write this blogpost detailing my specific Microsoft Endpoint Manager configuration based on the recommendations in the paper, extended with some other best practices I found while reading about this topic. I’ve written down my findings in a spreadsheet detailing my settings, where they come from and how they are configured. You can download a spreadsheet with my findings from my GitHub page here: WUfB – Best Practises – MEM translation.xlsx

Some interesting outcomes from the paper are:

In order for WUfB to successfully update a device, the device must be active for 6 hours a day where the device must be continuously connected for 2 hours.
Specifying “working hours” for all your employees isn’t working anymore, especially nowadays where during the pandemic people have very flexible working hours. It’s therefore better to let Windows self determine what the best timeslot is to start installing software updates. Microsoft calls this Intelligent Active Hours and learns this based on user activity on the device.
Microsoft recommends to configure deadlines, where you specify how quickly you want a Quality update or Feature update to be installed within your organization.
If you configure your Power settings right, you will be able to use the sleep status of the device to update the system, at times that the user isn’t using it.
By using delivery optimization you can optimize how clients within the same network share their data instead of each device individually downloading the software update.
Depending on how your devices are configured, you might want to consider to also install software updates on metered networks.
The paper advises to change the detection frequency to every 6 hours (which is 22 hours by default) – More on that later…

In the paper it becomes clear that only configuring your Windows 10 update rings but that you also need to configure settings like Power Options and Delivery optimization. The combination of these settings will result in software update installation being installed in a predictable manner.

Windows 10 update rings

Depending on the size of the organization you have to decide on whether to use one or more update rings. There is already lots of information written on how to design and implement your update rings which I advise you to read as well. In a nutshell the idea behind update rings is that you have multiple groups of users which receive updates after each other. You usually start with a small test group, usually the IT department which get software updates first, by doing so they can verify if the software update doesn’t break things and gets installed correctly. After this first verification, you normally would send the same update to a representative set of users within your organization. This representative set of users should be users who use the primary applications in use within your organization to make sure that these applications don’t break after installing either the Quality of Feature update. Having a representative set of business users experiencing the software update is crucial, if you don’t have this implemented I strongly advise to reconsider this. After this verification in the second update ring, the software update is suited for broad deployment to the rest of the organization.

I use the same mechanism for rolling out other changes in the organization as well, for example when rolling out Microsoft 365 Apps updates, new Configuration Profiles or Compliance policies, new Conditional Access policies, application updates and any other update which might affect the end users of the device.

Managing Windows 10 update rings

Once your Windows 10 update rings have been created and deployed, you can manage the update ring. The following options are available for managing your update rings.

Pause, Resume and Extend

You can pause the installation of a quality or feature update in an update ring. If you pause the installation of a quality or feature update in an update ring you prevent that assigned devices receive the quality or feature update if they check in after you have set the pause.

When you pause a deployment ring, that pause will stay active for a maximum of 35 days or is lifted if you use the Resume option. Once those 35 days are passed the deployment ring becomes active again automatically, unless you used the Extend option which extends the pause period at that time to 35 days.

You would normally use the pause functionality if you discover that a quality or features update is causing issues on your devices and you want to prevent the software update from being installed on any future devices. Which devices receive the pause state in time depends on their check-in with the system. It might be that systems install a software update even though you paused the update ring, that’s because they haven’t singed in with the system yet to receive this new configuration for the update ring.

Uninstall

By using the Uninstall option you can initiate an uninstall of the latest feature update or quality update for that deployment ring. This works both for an active or paused update ring. Use this option only if really necessary since it will start the removal as soon as the device checks in, and restarts the device when necessary to successfully uninstall the software update.

There are some situation that you must be aware of when you decide to uninstall an feature or quality update, these are described here: Configure Windows 10 update rings policy in Intune. Please read the scenarios carefully before you decide to use the uninstall option.

My recommended Windows 10 update ring settings

Based on my investigation and experience my recommended Windows 10 update ring settings are as followed:

Setting name	I24 – W10 – UR – Broad – v.1.0
Servicing Channel	Semi-Annual Channel
Microsoft product updates	Allow
Windows drivers	Allow
Quality update deferral period (days)	0
Feature update deferral period (days)	0
Set feature update uninstall period (2 – 60 days)	30
Automatic update behavior	Auto install and reboot without end-user control
Restart checks	Allow
Option to pause Windows updates	Disable
Option to check for Windows Updates	Disable
Require user approval to dismiss restart notification	No
Remind user prior to required auto-restart with dismissible reminder (hours)	4
Remind user prior to required auto-restart with permanent reminder (minutes)	15
Change notification update level	Use the default Windows Update Notifications
Use deadline settings	Allow
Deadline for feature updates	7
Deadline for quality updates	3
Grace period	2
Auto reboot before deadline	Yes

Windows 10 Update Ring settings

When working with multiple update rings you can modify the update referral period, Microsoft recommends 2 to 3 days as a configuration for this, but it really depends on your organization. Personally I think that 3 days is the minimum which you might want to configure for your first ring to experience the updates (the deadline for quality updates is set to 3 days and for feature updates to 7 days). Then after 3 days the second Ring (with your representative set of business users) starts, where after another 4 days the broad deployment automatically starts.

Ring 1: Quality update deferral period: 0 days, Feature update deferral period: 0 days

Ring 2: Quality update deferral period: 3 days, Feature update deferral period: 7 days

Ring 3: Quality update deferral period: 7 days, Feature update deferral period: 14 days

Microsoft also recommends to configure a deadline of 3 days for a quality update, a deadline of 7 days for a feature update and a grace period of 2 days. The grace period specifies the number of days the device has for Windows to find a minimally interruptive automatic restart time before the restart is enforced. This is especially useful in cases where a user has been away for many days (e.g. on vacation) so that the device will not be forced into an immediate update upon the user’s return.

Also notice that the Automatic update behavior is set to “Auto install and reboot without end-user control” which is the implementation of Intelligent Active Hours. With this setting enabled you cannot configure the Active hours start and Active hours end setting.

Power Settings

I use the following configured power settings in a Device Restrictions Configuration Profile which is assigned to my Modern Workplace users.

Based on my investigation and experience my recommended Power Settings are as followed

Category	Setting name	I24 – W10 – CP – Power Settings – v1.0
Battery	Battery level to turn Energy Saver on	40%
Battery	Lid close (mobile only)	Sleep
Battery	Power Button	Not Configured
Battery	Sleep Button	Not Configured
Battery	Hybrid sleep	Enable
Plugged In	Battery level to turn Energy Saver on	40%
Plugged In	Lid close (mobile only)	Sleep
Plugged In	Power Button	Not Configured
Plugged In	Sleep Button	Not Configured
Plugged In	Hybrid sleep	Enable

Power settings overview

By setting the actions of the Power and Sleep button to not configured, users can change these settings themselves. You want to create a situation where devices go into sleep mode first, which gives the system more time to install any software updates if needed. By enabling Hybrid sleep you create a combination of sleep and hibernation where if the machine loses power, its state is written on the hard disk as well, preventing users from losing information.

Modifications to the Windows 10 MDM Security Baseline

In order for the Power settings profile to work correctly and if you are using the Windows 10 MDM Security baseline you have to reconfigure the settings for “Standby states when sleeping while on battery” and “Standby states when sleeping while plugged in” to Not configured instead of Disabled.

*Modifications to the security baseline*

It’s obvious that if you don’t change these settings, the settings in the Power settings won’t be effective.

Delivery Optimization Settings

I use the following delivery optimization settings, below a screenshot of my Delivery Optimization Configuration Profile.

Based on my investigation and experience my recommended delivery optimization settings are as followed

Category	Setting name	I24 – W10 – CP – Delivery Optimization – v1.0
	Download Mode	HTTP blended with peering behind same NAT (1)
	Restrict Peer Selection	Not Configured
Bandwidth	Bandwidth optimization type	Not Configured
	Delay background HTTP download (in seconds)	300
	Delay foreground HTTP download (in seconds)	60
Caching	Minimum RAM required for peer caching (in GB)	4
	Minimum disk size required for peer caching (in GB)	32
	Minimum content file size for peer caching (in GB)	10
	Minimum battery level required to upload (in %)	60
	Modify cache drive	Not configured
	Maximum cache age (in days)	7
	Maximum cache size type	Not Configured
	VPN peer caching	Not Configured
Local Server Caching	Cache server FQDN	Not Configured
	Delay foreground download Cache Server fallback (in seconds)	0
	Delay background download Cache Server fallback (in seconds)	0

Delivery optimization configuration profile settings

These settings can serve as a baseline for a normal company using Windows Update for Business on their Modern Workplace. Your company or configuration might be different, for example because you decided to install a Local Caching Server in your LAN environment. If so, you need to configure the corresponding settings.

Additional settings

Below are some additional settings you can set based on the topics discussed in the paper.

Metered connections

If you want to allow the download of software updates while using metered connections, you have to enable the option using the Update/AllowAutoWindowsUpdateDownloadOverMeteredNetwork CSP. Below a screenshot of setting this setting using a Catalog Setting in Microsoft Endpoint Manager.

*Metered network settings Settings catalog*

Detection frequency

Update: April 1st, 2021: Rudy Ooms pointed my on the fact that the suggested setting for Detection frequency is only available if you are using a WSUS infrastructure, therefore setting the option below will not work on your Modern Workplace managed by MEM/Intune

By default, the Windows Update clients checks every 22 hours for any update being available. The recommendation from the paper is to reduce this to 6 hours which is aligned with the remark that a device needs to be active for at least 6 hours a day, with a timeframe of 2 hours where it’s continuously connected in order for it to receive updates.

Windows 10 Feature updates (Preview)

With Windows 10 feature updates in Intune, you can select the Windows feature update version that you want devices to remain at, like Windows 10 version 20H1 or version 20H2. Intune supports this functionality starting with version 1803 or later.

Windows 10 feature updates policies work with your Windows 10 update ring policies to prevent a device from receiving a Windows feature version that’s later than the value specified in the feature updates policy.

This is especially handy if you want to skip the update released in the first half of the year, since that update only has a servicing timeline of 18 months, and only want to deploy the updates which come out in the second half of the year, which have a servicing timeline of 30 months. Keep in mind that the 30 months servicing timeline is only applicable to Enterprise and Education versions of Windows 10, so if your devices run on Windows 10 Pro you can use the functionality as well, but not for the same purpose.

What new functionality can we expect?

As I mentioned earlier, Microsoft is constantly changing and adding functionality. Also this year, during its Microsoft Ignite event Microsoft announced a lot of upcoming updates related to Windows Update for Business. I already blogged about the announcements at Microsoft Ignite related to my line of work here: Modern Workplace Management key takeaways from the Microsoft Ignite March 2021 announcements

Windows Update for Business Deployment Service

During Microsoft Ignite, Microsoft announced the Windows Update for Business Deployment service, a set of extended functionalities giving administrators even better ways to manage Windows Update for Business. It’s expected that these new functionality will be released in H1 2021 (so that’s soon).

The following functionality was announced, as described in the following article: Announcing the Windows Update for Business deployment service

Schedule update deployments to begin on a specific date (ex: deploy 20H2 to these devices on March 14, 2021)
Stage deployments over a period of days or weeks using rich expressions (ex: deploy 20H2 to 500 devices per day, beginning on March 14, 2021)
Bypass pre-configured Windows Update for Business policies to immediately deploy a security update across your organization when emergencies arise, see the following article for more information and a demo: Expedite security updates in Microsoft Endpoint Manager admin center
Ensure coverage of hardware and software in your organization through deployments that are tailored to your unique device population through automatic piloting
Leverage Microsoft ML to automatically identify and pause deployments to devices which are likely to be impacted by a safeguard hold
Manage driver and firmware updates just like feature updates and quality updates, as announced in the following article: Introducing a new deployment service for driver and firmware updates

Known Issue Rollback (KIR)

Known Issue Rollback allows you to quickly return an impacted device back to productive use if an issue arises during a Windows update. It only supports non-security bug fixes, as Microsoft mentions that In the context of security fixes, older code is typically more vulnerable or exploitable as the reason.

When Microsoft decides to rollback a bug fix in an update because of a known issue, they make a configuration change in the cloud. Devices connected to Windows Update or Windows Update for Business are notified of this change and the rollback takes effect with the next reboot.

This is a very welcome addition, since we have seen some recent issues where an update caused blue screens on devices. By using KIR known issues are automatically rolled back and administrators therefore don’t necessarily have to pause or uninstall their Quality updates.

See the following article for more information: Known Issue Rollback: Helping you keep Windows devices protected and productive

Don’t forget Office

As described in my article about the M365 Apps admin center titled: “A first look at the Microsoft 365 Apps admin center” you can use servicing profiles if you use Microsoft 365 Apps for enterprise. With servicing plans you can also create a similar approach for updating your devices in a controlled way.

Monitoring

Having monitoring in place is a must have, there are always situations where machines don’t update as supposed to and you should therefore have monitoring in place to give you an idea on what’s going on. For this you can use the dashboards in the Microsoft Endpoint Manager admin console, but it’s better to configure Update Compliance.

During my research for this article I found the following lengthy article explaining what needs to be done in order to configure and user Update Compliance, the article is titled: Update Compliance with Intune, and is written by Jeff Gilbert, a Senior Premier Field Engineer working at Microsoft.

Conclusion

I hope this article gives you a good idea on how you can get more grips on updating your Modern Workplace with Windows Update for Business and Microsoft Endpoint Manager. As Microsoft has to support different OS versions, and each OS versions has its own features the options you can configure in the management tooling don’t necessarily have to be the best options for the current version of your modern workplace.

Please also make sure that you review your Windows Update for Business policies at least twice per year, make sure to understand whether “best practices” have changed, or that new functionality has become available which can help you in your operational tasks.