WUfB, introduced together with Windows 10, comprises two components. First, it includes group policies that control how computers request their patches from Windows Update. The other component is delivery optimization, which uses PCs as a cache for downloaded updates. But this also works in conjunction with WSUS.
The group policies essentially allow the admin to defer feature and quality updates separately for a period of time. The option of switching between service channels via GPO, which was initially crucial, has largely shrunk in importance now that there is only the semiannual channel (SAC) for computers that are used in production.
By linking GPOs to OUs, WUfB can use the latter as distribution rings. The computers will then receive all updates provided by Windows Update after the respective deadline. There is currently no method for approving or rejecting certain updates.
Approving patches from Windows Update ^
At Ignite, Microsoft announced that WUfB will offer these features in the future, with the addition of the WUfB Deployment Service. It should enable admins to explicitly approve any content for specific devices, whether feature and quality updates or drivers.
Since we are talking about a service in the Microsoft Cloud, the managed devices must be joined to Azure Active Directory. This can also be done via a hybrid configuration, in which the objects of the local AD are synchronized with Azure AD. The update policies are then assigned to devices in AAD groups.
Rollout of updates in phases ^
Another feature announced by Microsoft is the option to install updates according to a schedule. For examole, this would allow the upgrade to Windows 10 20H2 to be scheduled for a specific date on selected devices. Deployment staging will also be supported. So you could install an update on a certain number of PCs each day.
The deployment service is intended to work with the existing WUfB and will thus respect configured deferrals of updates. However, these can also be overridden for critical patches.
Integration with Endpoint Manager and Update Compliance ^
The service will also be integrated with Endpoint Manager so that admins will not have to switch all devices over to the new patch management system at once. This way, certain PCs can be patched through Intune or by co-management with SCCM using the WUfB Deployment Service, while other machines can continue to be patched using the standard procedure with Endpoint Manager.
In addition to the targeted approval of updates, Microsoft mentions reporting and monitoring as further features to be added. An extension for Update Compliance, another service in the cloud, will serve this purpose.
Automation via PowerShell ^
The announcement of the WUfB Deployment Service does not explicitly state which console admins can use to manage the updates. However, due to its integration with Endpoint Manager, it is likely to be operated with the Intune interface.
There are also REST APIs via Microsoft Graph as well as a PowerShell SDK. This presentation at the virtual Ignite shows a few basic operations using the corresponding cmdlets.
Availability and licensing ^
A preview of the WUfB deployment service will be available in the first half of 2021. Companies will need a user license for Microsoft 365 or Windows 10 E3 for the respective devices in order to use the service.
After the preview of Server 2022 gave no indication that WSUS will be improved or developed further in any way, the new WUfB service represents a further step toward the migration of Microsoft's patch management to the Cloud. WSUS will so far be reserved for updates for other products such as Office, as the new cloud service is still limited to the OS.
Known issue rollback ^
Microsoft has also announced details about a new update deployment feature, called Known Issue Rollback, which allows certain fixes to be undone if they cause problems. Only non-security updates are covered by this feature. For example, an entire cumulative update will not be rolled back, but a specific fix can be disabled in a finely granular manner.
However, it is not up to the user to roll back individual fixes at will. Rather, Microsoft will decide whether an update is faulty based on the diagnostic data it collects from the devices. Only then does it activate the old code, which is retained after an update (this began in Windows 10 2004).
While this happens automatically for machines when they are updated using Windows Update (for Business), admins in managed environments must use a group policy to achieve this.
Subscribe to 4sysops newsletter!
Microsoft will attach a link to the download location for the required ADMX file in the KB article of the faulty update. Since the old code is only maintained for a limited time by known issue rollback, the associated GPO can be removed again relatively soon.