Support Tip: Troubleshooting Windows 10 Update Ring Policies
Published Jun 21 2019 09:02 AM 86.7K Views
Microsoft

Hi everyone, here's another great post by Intune Support Escalation Engineer Mingzhe Li where she talks about how to verify if Intune Software Update Ring policies have been deployed to target clients, as well as offering up some great troubleshooting tips for the same. Be sure you check it out, and if you have any feedback for Mingzhe you can post it in the comments section below.

 

=====

 

When deploying Windows Update Ring policies to Windows 10 devices using Microsoft Intune, if you ever encounter an issue it’s important that you first determine whether the issue is Intune-related or Windows-related so that you can focus your troubleshooting efforts in the right place. As part of that, a key question is whether the Intune policy has been successfully deployed to the target device. Before I jump into that however, let's first get a basic understanding of Windows Update Rings and what their purpose is.

 

Understanding Windows Update Ring Policies

Sometimes there can be a misunderstanding that Intune provides a cloud-based update service like WSUS from which clients can download updates and hotfixes. This is not entirely accurate however, as Windows Update Ring policies only define an update strategy (e.g. block driver installation, set deferral period, set maintenance time, etc.), they don’t actually provide the update infrastructure itself. Think of it as being analogous to certain Group Policies for Windows Update deployed from your on-premises Active Directory. This means that you still need to use your existing update solution such as Windows Update or WSUS to obtain the actual updates.

 

NOTE You can find more information in Windows Update Rings here: https://docs.microsoft.com/en-us/intune/windows-update-for-business-configure.

 

Windows Update Ring policies make use of the Windows Policy CSP to configure the update policies on the Windows clients. Once Intune deploys the Windows Update Ring policy to an assigned device, Policy CSP will write the appropriate values to the Windows registry to make the policy take effect. So now that we know what these policies do, let’s look at how we can verify if the Windows Update Ring settings have been successfully applied.

 

Verifying Windows Update Ring Settings on a Target Device

Let’s begin by assuming that you have deployed a Windows Update Ring policy with the settings shown below:

 

101922-jch-1.png

How do we confirm that the settings have been applied to the targeted device? There are a few different ways we can do that. Typically the status in the portal is sufficient but others are explained should you find them helpful when troubleshooting related issues.

 

1. Check the policy deployment status in the Intune Portal

The first thing you should always do is check the status of the policy in the Intune Portal:

 

101922-jch-2.png

 

101922-jch-3.png

As you can see above, everything looks good and is reporting a success. However, if there are issues or you simply want confirmation, you can also verify the settings on the target device itself and we’ll go through how to do that below.

 

2. Verify that update policies are managed by MDM

On the targeted Windows 10 device, go to Settings -> Updates and Security -> Windows Update -> Advanced Options:

 

101922-jch-4.png

 

Click View configured update policies, then verify that the policy type is Mobile Device Management:

 

101922-jch-5.png

-----

101922-jch-6.png

This confirms that the update policies are configured by our MDM solution, which in this case is Microsoft Intune. However, it's possible that update policy is coming from the on-premises Active Directory, in which case we would see Group Policy as the policy type:

101922-jch-7.png

If this is the case, it won’t matter what update policy you configure in Intune, the applied policy and the observed behavior is still going to be whatever is configured via Active Directory.

 

3. Verify that the Registry keys are properly configured

If the Windows Update Ring policies are successfully deployed by Intune to the target device, you will be able to see those settings in the Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update. Here’s an example from a client running in my lab:

 

101922-jch-8.png

 

These values are configured by the Windows Policy CSP so you can verify that the values of the keys match the settings specified in your Update Ring policy. For more information on each of these see https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update.

 

4. Check the MDM diagnostics report

Another option is to capture and view an MDM diagnostic report from a targeted device and see if you can find the Windows Update Ring policy in it. If you can see the policy settings in the report, this is another indication that the policy was successfully deployed. The Microsoft Helps video below explains how to capture an MDM diagnostic report from a Windows device.

 

 

TIP: The primary purpose of the MDM diagnostic report is to assist Microsoft Support when troubleshooting issues. If you open a support case with Microsoft on Intune and the problem involves Windows clients, it’s always a good idea to gather this report and include it in your support request.

 

Troubleshooting Issues Relating to Windows Update Ring Policy

At this point we have a pretty good idea how to confirm that our Windows Update Ring policy is being successfully deployed, but what do you do if they’re not? Here are a few things to check:

 

  • Is the device properly enrolled into Microsoft Intune? If not, you’ll need to address that before troubleshooting anything specific to the policy.
  • Is there an active network connection on the device? If the device is in airplane mode, or it’s turned off, or if the user has the device in a location with no service, the policy will not apply until network connectivity is established.
  • Have you deployed the Windows Update Ring policy to the correct user/device group? Be sure to double check that the correct user/device really is in that group. This is an easy one that often gets overlooked.
  • Does the deployment of the entire policy fail, or is it that only certain settings are not being applied? If you find yourself faced with a scenario like this where only some policy settings are failing, below are some more things you can check.

The first thing to do is verify that the setting is supported by the Windows version of the target device. To give you an example, I recently worked with a customer who deployed a Windows Update Ring policy but there was an error in the Intune Portal for Block user from scanning for Windows updates:

 

101922-jch-9.png

We started by checking to see what exactly the setting did and what the version requirements were. With a quick check of the doc here, we saw that this is implemented by Policy CSP Update/SetDisableUXWUAccess:

 

101922-jch-10.png

 

By further checking the Windows reference documentation at https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-setdisableux..., we could see that the failed setting is only supported for Windows 1809 and above:

 

101922-jch-11.png

          101922-jch-12.png

Armed with that information, we then verified that the effected devices were running Windows 1803 and could then confirm that the issue disappeared once the device was upgraded to 1809.

 

As was the case here, if you can see that the Windows update policy type is set to Mobile Device Management and the registry key values are correct, it’s usually safe to assume that the problem is not directly related to Intune, but more likely an issue with the Windows client or an associated configuration in the environment. This means you need to start looking in other areas like:

 

  • The Windows OS version on the target device.
  • If and how Windows Update is configured.
  • If and how WSUS is configured.

These are beyond the scope of this article, however a good starting point is to check the Windowsupdate.log. More information on that can be found here: https://blogs.technet.microsoft.com/charlesa_us/2015/08/06/windows-10-windowsupdate-log-and-how-to-v.... Another good resource is the CBS logs under C:\Windows\logs\CBS.

 

For more information on troubleshooting Windows Update and WSUS, see the following:

 

https://support.microsoft.com/en-us/help/10164/fix-windows-update-errors

https://support.microsoft.com/en-us/help/4027322/windows-update-troubleshooter

https://support.microsoft.com/en-us/help/4025764/how-to-troubleshoot-wsus-connection-failures

 

Mingzhe Li

Support Escalation Engineer

Microsoft Intune Support Team

16 Comments
Microsoft

Great article Mingzhe !! Very helpful.

Copper Contributor
Thanks for the posting, Mingzhe - very informative. I'd like to ask what are your thoughts in regards to user-based assignment of update rings. Using user (rather than device) groups for assignment seems appealing to us in that user groups could be easier to administer than device groups. What are the implications, however? For example, you could have different users, possibly with different update rings assigned, logging into the same machine. Is there a precedence of which update settings will persist? Based on the documentation at https://docs.microsoft.com/en-us/windows/deployment/update/waas-servicing-channels-windows-10-update... you cannot always switch channels in the lifetime of a device, so that implies if a user with insider policy logs into a device (e.g. an IT support person), then they could upgrade that device into the insider ring without a possibility to switch back? It seems safer to user device groups to get a more deterministic outcome of update settings, but have you (or anyone reading this) tried user group assignment of update rings and if so, what was your experience?
Microsoft

Hi haimizrael,

thanks for your feedback, really appreciate that. You are right, we also support the update ring to be deployed to a user group. This has the benefit that any device which belongs to that user will get the update ring settings assigned. But you are also right in saying that this could lead to some potential conflicts if we are talking about a shared device (multiple user affinity for one device) especially if the different users have different update ring settings.

This means that if you have a large number of shared devices (multiple users) in your company, in order to avoid potential conflicts, you should assign the update ring policy to a device group instead of user group.

 

Hope this helps.

 

Regards,

Mingzhe 

Microsoft

Great Article!!!

Copper Contributor

Good .

Thanks.

Brass Contributor
 

Great stuff but I can't see that detailed monitoring view anymore. It goes directly to single computer properties. I mean that picture where you have all 11 green status balloons displayed.

Brass Contributor

Hi @J.C. Hornbeck ,

 

Great article!

One thing I'm not sure I understood, when you saying:

This means that you still need to use your existing update solution such as Windows Update or WSUS to obtain the actual updates.

I understand that Intune only manage the policy for the devices in terms of when, what, type of updates etc. and it doesn't store the actual updates, but it does direct the client to get the updates from Microsoft windows update servers. so i'm not sure why I still needs a WSUS or other patching/updating infrastructure.

As far as I understand this is true for both AAD joined and Hybrid joined devices as long as the device is managed by Intune directly or via co-management.

 

Am I missing something?

 

Tnx,

 

Gilad.

Brass Contributor

Thats correct  @J.C. Hornbeck ,

 

If your devices are managed by Intune you could remove your WSUS and instead just use Windows update and a combination of delivery optimisation to deliver updates to EUC devices. 

Copper Contributor

Hello,

 

One of our clients is currently using Autopilot through OOBE experience.

Now they want to update Windows 10 version from 1903 to 2004.


I see that, within Intune, you can upgrade Windows 10 version by using "Windows 10 feature updates", but according to Microsoft Docs (https://docs.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-configure), there's a limitation with Autopilot with OOBE scenarios:

 

Windows 10 feature update policies cannot be applied during the Autopilot out of box experience (OOBE) and will only apply at the first Windows Update scan after a device has finished provisioning (which is typically a day).

 

My question is: Is there any other different way to update Windows 10 version than this? I mean... is it mandatory to go, computer by computer, clicking on Configuration > Windows Update > Check for updates manually to get a new version of Windows 10?


Thanks in advance,


Best regards

Microsoft

Great Article.... A question: Do you know any blocker that might prevent to switch back from Insider Channel to semi-annual channel ?? If so, what would you recommend to fix this issue??

 

Thanks in advance !!

Copper Contributor

Heyie Guys,

Great Article Mingzhe Li. I have a couple of question on WuFB and would you be kind to clarifying those.

 

1. The windows update policy status says Pending for many days, even after many successful sync.
2. The Update status of the client is "Failed" when checked under "Endpoint Manager Admin Center-->Devices-->Windows Update Ring-->End User update stauts"
3. The Update status when checked from Update compliance blade gives me as "Unknown" with "DeploymentError" empty.
4. How do I troubleshoot why this policy is not getting applied on the client? Also, please provide a link to study and understand troubleshooting for clients where policy is applied, updates status in update compliance is "unknown" and deploymenterror is empty.

This has been a new topic for me and I would appriciate your help in understanding the topic.
Thanks in Advance.

 

Copper Contributor

Hi Mingzhe, 

 

Thanks for sharing, I pushed the windows update ring to all device that enrolled in Intune

I saw the Windows update ring policy applied succeeded for most systems and users, however, it failed on a few.

on some system, I saw success to user account but failed to system account.

May I ask the difference between the user and machine scope ?

How to check why the user account succeeded but system account failed ? 

Thx.

Copper Contributor

 You have probably resolved this by now? 

 

Does your devices have a dynamic device group? 

Copper Contributor

Hello, 

 

In our environment SCCM agent has information from SCCM server with WSUS how to get updates through Software Center and 

we don't use any GPOs for this.

We enabled co-management and testing updates on one Pilot Intune group.

However, within configured update policies Type: Group Policy is still visible:

 

update.JPG

When I check update source it does not show WSUS:

 

dddd.JPG

 

Can this be fixed using MDMWinsOverGPO setting in Configuration profile? 

 

Thanks

 

 

 

 

Brass Contributor

Very useful information, thank you. 

Copper Contributor

Hi and thanks for a great article, 

I have been struggling with navigating a way to eradicate the legacy GPOs.  We are experiencing issues relating to how best to get rid off all the existing Windows Update GPO policies that are configured and are hampering Intune's ability to configure WUFB to deploy both Quality and Feature updates.  I have read above about  MDMWinsOverGPO setting in Configuration profile.  Can I ask which configuration profile this is part of and also how is this used on devices?  We really need a way to only on devices we want to co-Manage wipe out all alternative GPO Windows Update configured policies?    

Many Thanks for any assistance.

Version history
Last update:
‎Jun 21 2019 09:10 AM
Updated by: