Windows 10 Update Ring

andreas bright 561 Reputation points


We have configured our update ring like the image below, and If I am correct then the latest Windows 10 feature update should also be installed within 14 days. If 14 days has gone, it will be forced installed, correct ? If yes, then it does not happen... (I know I can force a feature update with the feature update policy)


One other thing is the image below, as you can see there are many errors, I am not able to figure out why, because to me it seems like these clients have installed patches correctly. I am not able to click the error, and If I look at the machine I cannot find any issue. Is there a known problem when it comes to reporting ?


Thanks for answers


Microsoft Intune
Microsoft Intune
A Microsoft cloud-based management solution that offers mobile device management, mobile application management, and PC management capabilities.
4,720 questions
{count} votes

3 answers

Sort by: Most helpful
  1. Crystal-MSFT 46,086 Reputation points Microsoft Vendor

    @andreas bright , For the setting "Feature update deferral period (days)", it specify the number of days for which Feature Updates are deferred.

    Deferrals work by allowing you to specify the number of days after an update is released before it is offered to a device. That is to say, if we set it as 14 days, the device will not install a feature update that has been released for less than 14 days.

    To troubleshoot update deployment, we can try Intune compliance reports for updates in the following link:

    Hope it can help.

    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

  2. Jason Sandys 31,186 Reputation points Microsoft Employee

    You have a deferral as well as a deadline configured (both at 14 days). Deferrals work as noted by @Crystal-MSFT but do not force the feature update to be installed. Deadlines do force them to be installed. Both are measured from the time when they are released by Microsoft thus having them both configured to 14 days is a problematic at best configuration. You should choose to set either deferral or deadline, or configure the deferral to be less than the deadline.

    I know I can force a feature update with the feature update policy

    This is not correct. The feature update policy specifies a maximum feature update version to update targeted systems to. It does not override the deferral or deadline policies in place.

    For complete Windows Update reporting, you need to implement Update Compliance:

    0 comments No comments

  3. Oliver Kieselbach 241 Reputation points MVP

    I think not everything is correctly outline until now. I'll give it a try:

    Feature deferral tells nothing more than wait x days until you are allowed to get a specific update. Example: 14 days deferral and an example release date 01.01.21 for feature x, will result in the following. Your client will start looking for the feature x on 15.01. (14 days later according your deferral). That does not mean it will get it immediately on 15.1. as it needs to search for it first, then download it, and then do the background install without reboot. The download itself can take several days if you are unlucky and have bad connections. To summarize, the client starts 14 after release to look for the feature X, after download, it will install in background according to your "Automatic update behavior" policy (this policy can have values of "Notify download", "Auto install at maintenance time", "Auto install and restart at maintenance time", "Auto install and restart at scheduled time", or "Auto install and reboot without end-user control").

    Assume you have set "Auto install at maintenance time", the install behavior is:
    Updates download automatically and then install during Automatic Maintenance when the device isn't in use or running on battery power. When restart is required, users are prompted to restart for up to seven days, and then restart is forced.

    Again an example, 14 days after release the client searched, found it (was not on a blacklist by MS aka Safeguard hold) needed 1 day for download and then did the install in the background on the next day (maintenance window reached and not in use or running on battery). Resulting in 14+1+1=16 days after release the feature x is installed in the background at maintenance time. Here it might be that the device never enters the maintenance time window, which can be defined by it's own or is always running on battery or in-use. Default maintenance time here is, everything outside 8 AM to 5 PM (policy key word ActiveHours). Now if the client was successful in installing, had some time after 5PM and not in-use for example, the Automatic install behavior gives you 7 days for a restart until it is forced. This is 7 days after the 16 days, as it is counted after the background install finished.

    Finally, our Deadline policies are coming into play. The install at maintenance time may never be successful as the device is only used in active hours and did not get the chance to install, as it never entered maintenance time. Deadline setting gives you now control to force this install in the background, even if the device never entered the maintenance time. E.g. you defined 2 days (possible values are only 2-30 days and not like the deferral up to 365), then the device will install after 2 days the feature x in the background regardless of the maintenance time. On top you can now define the final restart behavior with the deadline. The default is the 7 days after install in the background. If you set the Grace period in the Deadline setting you can control this in a range from 0-7 days. So, for example you can set also 2 days, then the notifications and final reboot are happening not after the default 7 days, the reboot will be done automatically after 2 days. To pick up our example from above, you would end up in 16 days after release finishing the background install, as described, and 2 days after this the final reboot will happen. This will make 18 days in total for our example. Keep in mind that this might not be reflected in real world like this. Download takes very individual time and depends also on Delivery Optimization settings etc. and safeguard holds may block you for a very long time...

    Deferral 14 days -> client starts looking, may face a safeguard hold from MS, needs time to download
    Automatic update behavior -> background install (not a reboot) will be tried according your settings e.g. during maintenance time (respecting in-use and battery power)
    Background Install finished -> Restart kicks in with 7 days default, controlled by deadline for your needs, you may lower the time window

    To get some insights about safeguard holds and your efficiency about Delivery Optimization (both are effecting your time to install on your devices), you really should implement the Update Compliance solution.


    0 comments No comments