In this post I will be discussing on how to change source service to WSUS for feature update rather than pausing it. If you are not ready with deploying feature update, then changing the source service to WSUS (if configured) is a better option rather than pausing the feature update using update ring settings in Intune.
Why do we need to block feature update from WUfB deferral policies
We know that once Windows Update for business policies are applied either via Intune, GPO or SCCM, all latest updates get installed on the device. These updates are not just limited to quality updates but feature updates as well.
If organization is not ready to deploy feature update for Windows 10 or Windows 11 devices, however they are ok with deploy quality updates when WSUS as standalone or WSUS integration with Configuration manager is done using Software update point. There should be some provision of not getting feature update.
Once you enable deferral policies ie. Update ring settings, both quality updates and feature updates are targeted. You control the behaviour of feature update in 2 ways:
- Using Feature update deferral policies.
Under MEM Admin center, edit any existing Update ring and you will be able to see “Feature update deferral period (days)” which allows a maximum value upto 365 days. Hence, feature update will apply on targeted devices after 365 days of release date.
- Using pause feature update
You can pause the feature update and quality update as well within the update ring settings. However pause will stay for 35 days only and there after it will automatically resume. Though you can keep on extending the pause before 35 days to extend it again for next 35 days.
Both above mentioned settings doesn’t allow a full control of not getting feature update applied through deferral policies. Means, once WUfB policies are applied, feature updates are targeted automatically and its not an easy fix using update rings to block / pause infinitely.
Don’t pause feature update – use policy source service classes of Windows update
Rather than delaying the feature update or keep on pausing the feature update, there is a better option in terms of a policy which Microsoft has recently released.
You can specify various source service for feature updates.
Use Group Policy for changing source service
There is a group policy which can control this behaviour. Create new group policy or edit existing one and navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service > Specify source service for specific classes of Windows Updates
This policy gives options to specify different source service such as “Windows Update” vs “Windows Server Update services (WSUS)” to be used differently for feature update and quality update. Once selected, devices will scan against the specific source which you selected in policy.
Following classes can be used to specify the source service:
- Feature Updates
- Quality Updates
- Driver Updates
- Other Updates
If you are not seeing this policy, then you need to update your ADMX templates to latest version.
This configuration can help organization to decide how you wanted to control your patches. For example, you can continue using quality updates, driver updates and other updates to use Windows Update via WUfB deferral policies while keep on using WSUS / SCCM for feature update.
This policy will have no effect if WSUS is not configured.
Note: When using this policy, make sure not to use Dual Scan policy (Do not allow update deferral policies to cause scans against Windows Update). If both policies are configured, you will not get updates from Windows Update.
Use Intune Policy CSP for changing source service
Change source service can also be done using Policy CSP for Intune ie. by using Configuration Service Provider (CSP). We need to use custom OMA-URI settings to apply the same.
For corresponding Group policy with name “Specify source service for specific classes of Windows Updates” we can use following Policy CSP – Update:
- Update/SetPolicyDrivenUpdateSourceForOther
- Update/SetPolicyDrivenUpdateSourceForFeature
- Update/SetPolicyDrivenUpdateSourceForQuality
- Update/SetPolicyDrivenUpdateSourceForDriver
Default value for all these setting is 0 which means “Windows Update”. If you wanted to point a specific update to WSUS, apply the value 1.
Create Configuration Profile for setting source service
Login to MEM Admin center and navigate to Home > Devices > Configuration profiles. Create profile with Platform selected as “Windows 10 and later”and Profile type as “templates” and select Template name as “Custom”, click on Create.
Under Basics page, specify name “Windows Update – set source service” and click Next.
Under Configuration Settings > OMA-URI Settings, click on Add.
Specify following for Feature Update:
Name: Scan Source for Feature Updates
Description: Devices will scan against WSUS
OMA-URI: ./Vendor/MSFT/Policy/Config/Update/SetPolicyDrivenUpdateSourceForFeature
Data Type: Integer
Value: 1
0 means Windows Update, 1 means WSUS
It is always recommended to specify other policies as well, don’t just go with 1 policy. Hence, create 3 other OMA-URI settings as well.
Create OMA-URI setting for SetPolicyDrivenUpdateSourceForOther
Name: Scan Source for other Updates
Description: Devices will scan against Windows Update
OMA-URI: ./Vendor/MSFT/Policy/Config/Update/SetPolicyDrivenUpdateSourceForOther
Data Type: Integer
Value: 0
Create OMA-URI setting for SetPolicyDrivenUpdateSourceForDriverUpdates
Name: Scan Source for Driver Updates
Description: Devices will scan against Windows Update
OMA-URI: ./Vendor/MSFT/Policy/Config/Update/SetPolicyDrivenUpdateSourceForDriver
Data Type: Integer
Value: 0
Create OMA-URI setting for SetPolicyDrivenUpdateSourceForQualityUpdates
Name: Scan Source for Quality updates
Description: Devices will scan against Windows Update
OMA-URI: ./Vendor/MSFT/Policy/Config/Update/SetPolicyDrivenUpdateSourceForQuality
Data Type: Integer
Value: 0
We can see now all 4 OMA-URI Settings are created, click Next.
Click Next under scope tags.
Under Assignments page, target it to existing devices / groups.
Don’t specify under applicability rules. Verify settings under Review + Create and click on Create.
Verify CSP policies if applied correctly
Once next sync happens, policies will be applied. You can verify the MDM policy section through registry key location Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update
Eventually above mentioned PolicyManager registry keys are going to apply at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState
Here we can see following values are showing as we expected:
- SetPolicyDrivenUpdateSourceForDriverUpdates : 0
- SetPolicyDrivenUpdateSourceForFeatureUpdates : 1
- SetPolicyDrivenUpdateSourceForOtherUpdates : 0
- SetPolicyDrivenUpdateSourceForQualityUpdates : 0
You may also check the status by using Advanced Diagnostic Report which can show you what was the default value and current value. This reports gives you a good idea how your policies are managed, check section Managed policies by opening MDMDiagReport.html.
Note: Avoid having both CSP policies and Group policy as this can create conflict and Group policy will override. It is always preferred to resolve the conflict by making Intune policy blocking group policy, by using MDMWinsOVERGP setting in case there is a conflict with a specific setting.
Important Links
Use Windows Update for Business (WUfB) and Windows Server Update Services (WSUS) together
