Forum Discussion
oryxway
Dec 27, 2024Iron Contributor
How to block 24H2 to be installed on Windows 11
We are not pushing any 24H2 but I see that there are several devices that are already getting it and updated. I am not sure how they got it. All these devices are managed in Intune.
Can this be the reason that it is getting its updates? Feature Update deferral period which is set to 0 and I cannot block it or stop it or go beyond 30 days. So, I am not sure how they are getting into some of the computers?
These are the Update Rings settings
8 Replies
Sort By
- KevinBGISCopper Contributor
Did you ever figure this out? I am notice similar situation.
- tschlappingerCopper Contributor
What settings were configured for the feature update? Normally, it should only deploy the version specified there.
- oryxwayIron Contributor
I am not pushing 24H2 at all. Mine is set to Windows 11 23H2
- patrickmaurerCopper Contributor
Good day,
Maybe I can help you with this. A few weeks ago, I had a case with Microsoft regarding something similar to your question.
You can set a Feature Update deferral period, for example, 30 days, to postpone the update to 24H2 for 30 days after its release in the "Update Rings" policy.
If you want more control, it’s best to set this to 0 and configure an additional "Feature Updates" policy. With this policy, you can plan your 24H2 release. If you configure this policy, including the deferral in the "Update Rings" policy, it may cause a conflict. Therefore, you should set the deferral to 0 when using the Feature Updates policy.
More information: https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-feature-updates#limitations-for-feature-updates-for-windows-10-and-later-policy- oryxwayIron Contributor
I tried to increase this to 160 days as I do not want to upgrade it to 24H2 due to so many issues. I had it set to 0 as per MSFT suggestions but decided to increase it.
well.... this is how msft recommends it to be set to zero... if you want to be sure the device stays on a certain build maybe looking at this policy/csp: targetreleaseversion to define on which build the device needs to stay
- oryxwayIron Contributor
As 24H2 is a problem child we do not want to go to this update. Which is why I want to block it until it becomes more stable.
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#targetreleaseversion did you also implemented this then to ensure the devices stay at 23h2?