Hi MaxMatV​, In addition to the service side licensing issue addressed by the two commands you pasted above, an additional issue was identified in Windows itself that result in the same challenge. This was addressed recently. From memory, this was address in 2D/3B (3B = the March cumulative update) but it may have been in 3D/4B (4B = April cumulative update). 

If after installing the latest April CU you are still experiencing issues, please open a support case as this explicit challenge should now be addressed fully and thus would require additional investigation.

You can do this today with Autopatch. When you create a Feature Update rollout, you get gradual rollout groups that have a deadline that you set - so you can set a 2 week deadline, and during the period before the deadline they can install it whenever they want. Windows feature updates overview | Microsoft Learn You can also, at any time, create a new Feature Update Deployment and select the option "make available to users as an optional update" and let them install it on their own without setting any specific deadlines, Configure Windows Feature Update Policies - Microsoft Intune | Microsoft Learn

Hi admin_mike​, To the best of my knowledge, this is correct. There are a handful of approaches you can use here to account for this although keep in mind that GPOs contain a lot of metadata and thus that 8MB is probably not truly indicative of the size of the policy. Also, note that from memory, the limit is a policy size limit for OMA-URI and not directly related to AppLocker.

Options to consider:

1. Break up the policy into more granular policies and individually target them.
2. Review the rules and get rid of stale/outdated ones and/or duplicate ones.
3. Move from hash rules (which take up the most space) to publisher-based rules.
4. Move to Application Control for Business (fka WDAC). This is probably the recommended approach here as Application Control for Business provides a much stronger level of protection.

Another possibility here is to review your strategy for rules. The general recommendation is to use an allow listing approach instead of a block listing approach. This may reduce the number of rules needed in an environment. This recommendation goes for both AppLocker and Application Control for Business.

BlueSakura​ Thaks for the questions. Because this group is focused on Windows, Intune, and Windows 365, this question is better asked in the Teams forums. I recommend posting that question here: Microsoft Teams | Microsoft Community Hub. 

Hello ITJMPA​ - Since our office hours group here is focused on Windows and Intune, I'd recommend that you post this question to the Driving Adoption discussion board.

lalanc01​ Good question and timely with the recent changes! Starting with the April 2026 update for Windows 11 25H2, Microsoft removed the clean-install restriction — Smart App Control (SAC) can now be toggled on/off from Windows Security > App & browser control at any time, without reinstalling.

So the short answer: you can now enable it post-provision on unmanaged devices, but for enterprise-managed devices, App Control for Business is the recommended path.

lalanc01​ This comes up a lot during IE-to-Edge migration. Here's the quick breakdown:

• Trusted Sites / Security Zones: These are only honored in IE Mode tabs within Edge. Standard Edge (Chromium) tabs do not use Windows Security Zones. So if you have apps running in IE Mode that depend on Trusted Sites, keep those zone policies. For everything else in regular Edge, they can be removed.
• Proxy settings: Transition to Edge-specific proxy policies via Intune Settings Catalog or Administrative
• Templates (Microsoft Edge > Proxy settings). The legacy IE/Windows Internet Options proxy settings only apply to IE Mode.
• General guidance: Audit which apps still need IE Mode using the Enterprise Mode Site List. For those apps, keep the relevant IE policies. For everything else, migrate to native Edge policies in Intune and remove the legacy IE settings.
•  

The Settings Catalog in Intune has comprehensive Edge policy coverage that replaces most legacy IE configuration needs.

Hope this helps.

lalanc01​ 

Here's how it works:

- Windows Autopatch and Windows Update Client policies are applied to devices via Intune. As long as the device remains enrolled in Intune and has connectivity, policies continue to apply regardless of how often a user logs in. However, if the device loses connectivity or goes offline for extended periods, it won't check in to receive new policies or updates.

- License assignment: M365 E5 licenses are user-based. If a licensed user is removed or the license is unassigned, the device may lose access to features that require that license (like Autopatch enrollment). Group-based licensing in Entra ID can help automate this.

- The scenario you're describing — devices stopping patch compliance when users stop logging in — is more likely related to the devices going offline/not checking in rather than license removal. Check the last check-in dates in the Intune portal for those devices. Devices that haven't checked in for 30+ days won't receive new update policies.

I'd recommend checking the Intune device compliance and last sync dates to narrow down whether it's a connectivity or licensing issue.

Hi CyberSec26​ - The best place to track out of band updates for Windows would be Windows release health and the Windows message center.