This post is about co-managing the Windows Update policies workload between Configuration Manager and Intune.
Overview
Organizations today are looking for an integrated endpoint management platform which can ensure all devices whether owned by the business or personally owned stay secure, are managed and always up to date.
This demands the most secure desktop and mobile experiences without compromising user flexibility. Configuration Manager Co-Management opens the gateway to interconnect the investments made on-premise while attaching it with the power of modern cloud-based solutions like Microsoft 365 & unlock its full potential.
Configuration Manager supports managing internet based devices via the CMG/IBCM (if installed) and a co-managed device gives you the flexibility to use the solution that works best for your organization by allowing it to be managed concurrently with both Configuration Manager and Intune.
Lean more about co-management here: http://aka.ms/comanagement
Scenario
Your organization is interested to offload the Windows Update policies to Intune, some of the driving factors could be
- Removing dependency of ConfigMgr agent health.
- Updates deployment outside corporate network.
- Always stay up to date matching corporate standards.
Background
When we talk about moving the Windows Update policies workload to Intune, we are leveraging the Windows Update for Business policies, also known as WUfB.
You may be wondering if that’s the case then why not use the Group Policies? This is exactly what Intune is doing, it’s managing the WUfB policies by removing dependencies of GPO & On-Premises infrastructure.
The following diagram provides a conceptual overview of how this works:
The diagram can be roughly divided into three areas:
- The Device Management service syncs update information (title, description, applicability) from Microsoft Update using the Server-Server sync protocol (top of the diagram).
- The Device Management service sets automatic update policies, obtains update compliance information, and sets approvals via OMA DM (left portion of the diagram).
- The device gets updates from Microsoft Update using client/server protocol, but only downloads and installs updates that are both applicable to the device and approved by IT (right portion of the diagram).
Reference: https://docs.microsoft.com/en-us/windows/client-management/mdm/device-update-management
Configuration
You begin with moving the Windows Update policies workload slider to either Pilot/Intune
Starting ConfigMgr 1906 you can stage a workload to a collection.
This triggers a policy update on the client side and increments the Co-management capabilities counter from 1 to 17.
You can verify this in the CoManagementHander.log
Upon a Software Update Scan Cycle, WUAHandler.log also acknowledges the handover to MDM/Intune.
In the backend, it resets the DisableDualScan registry from 1 to 0
This can also be seen in the Local Policy Do not allow update deferral policies to cause scan against Windows Update which changes from Enabled to Disabled
This is the famous Dual Scan policy you may have experienced in the past.
Starting Windows 10 2004 and higher we have an additional set of WUfB policies which are configured by ConfigMgr and modified post the slider moves to Co-Manage the Windows Update workload.
If you click on Check for updates, your device will directly contact Microsoft Update and download and install any applicable updates.
Note: If you deployed the device configuration policy to force MDM over GPO you won’t notice any change against the dual scan registry or group policy which will be blocked.
Intune – Software Update Policies
You may be interested to delay the monthly quality updates by 7 days and the feature updates by 30 days.
For updates management, we need to create Intune Software Update Policies and deploy them as rings. This will implement the WUfB polices and will control the behavior by applying any deferrals
- Launch https://devicemanagement.microsoft.com
- Click Software Updates > Windows 10 Update Rings
- Create an update ring to meet the organization requirements.
Its recommended to create multiple rings for deployment as you would typically do with ConfigMgr starting with a group of testers and then increasing the number of devices in each ring.
Don’t forget to deploy/assign each ring to a target group.
On the target devices, you will see the WUfB polices in the Settings App under Windows Update by clicking View configured update policies
Depending on the WUfB policies configuration, the device can automatically start downloading and installing updates to the device.
What about Office 365 Updates?
These updates are still managed by ConfigMgr. You have the choice to choose between ConfigMgr or Intune, for guidance, refer this link: Co-Management of Office Click-to-Run apps Workload
How about 3rd Party Updates?
The third-party updates can still be managed and deployed by ConfigMgr. Since these updates are not available via Microsoft Updates, for internet facing devices you need to additionally deploy them to CMG/Cloud-DP/Internet facing DP.
Monitoring
Software Update compliance reports in ConfigMgr will report the Windows Updates as Not Required for devices which have moved the Co-Management slider to Intune.
An exception to this behavior is for the Office 365 updates and 3rd party updates which will continue to report their compliance to ConfigMgr.
Thanks,
Arnab Mitra
Update - 1/20/22 - Added screenshot and note to reflect additional WUfB policies configuration changes with ConfigMgr. Additionally, removed reference for Desktop Analytics.