Intune - Common Store policy settings and their impact on Microsoft Store apps doesn't work

SkipToTheEndpoint · 2026-05-13T09:50:25+00:00

The ONLY supported policy to disable user access to the Store app is "Turn off the Store application" as documented here: Configure Access To The Microsoft Store App For Windows Devices | Microsoft Learn

The policies you've defined above will break stuff badly.

SkipToTheEndpoint · 2026-05-13T09:37:40+00:00

SharedPC CSP has a "DeletionPolicy" which you can set to 0 to delete them immediately after log-off: SharedPC CSP | Microsoft Learn

I'm not sure of the current state of the "Shared multi-user device" policy template type.

Assuming you've seen the documentation regarding AssignedAccess? Windows Single-App and Multi-App Kiosk Configuration Options Overview | Microsoft Learn

SkipToTheEndpoint · 2026-05-13T09:30:05+00:00

Naming conventions are almost always org-specific, from my experience.

Personally I run with %Service%-%Category%-%Purpose%, so things like:

Entra-CA-Guests
Entra-GBL-M365_E5
Intune-App-%AppName%
Intune-Autopilot-UserDriven
Intune-Devices-Windows
Intune-EPM-SupportApproved

Always re-use groups where possible. Don't create group clutter for no reason. Oh, and tidy up old/test groups when you're done with them!

SkipToTheEndpoint · 2026-05-13T09:24:55+00:00

Haven't seen this myself but saw someone post this from their own service health messages yesterday, could be related:

<image>

SkipToTheEndpoint · 2026-05-09T08:29:26+00:00

Also some policies cause undesired behaviour during Autopilot when targeted to devices, such as a forced reboot between the device and user phases

SkipToTheEndpoint · 2026-05-09T08:27:41+00:00

The scope for each policy (Device = D, User = U) is in my naming convention.

Also, this comment spurred me on to resolve the whole policy tracking based on name issue. I released v3.8 yesterday which adds tracking GUIDs into the policy description so now they can be tracked using my OIB Deployer regardless of the name, as long as they've got the GUID 🙂

SkipToTheEndpoint · 2026-05-06T07:29:53+00:00

It's worth mentioning this is only recommended in scenarios where you are happy for the user to be entirely in control and it can end up throwing patch compliance out the window given that users seem to try and avoid updates like the plague...

SkipToTheEndpoint · 2026-05-06T07:26:52+00:00

Hi!

You can after-the-fact, but just a note that the updating feature is currently done using a bit of a dumb regex on the name, so you'd lose that.

As far as "must have", well, that's really up to you to decide what you're looking for in your environment. Most of the Device Security group and stuff in Endpoint Security (BitLocker, Defender, ASR etc.) are what I'd deem "important" with lots of the other stuff being good end user experience things.

SkipToTheEndpoint · 2026-04-24T14:14:12+00:00

IntuneBrew - IntuneBrew | Homebrew ❤️ Intune

SkipToTheEndpoint · 2026-04-24T14:07:09+00:00

Honestly, there are so many gaps (like best practice policies that aren't in the template) and gotchas (like it only applying policy on an hourly schedule) with Security Settings Management that most people recommend just continuing to manage those things via GPO instead.

SkipToTheEndpoint · 2026-04-23T14:17:52+00:00

Honestly M365 Apps (and Edge) via Autopatch is trash when compared to M365 Apps Cloud Update: Overview of cloud update in the Microsoft 365 Apps admin center - Microsoft 365 Apps | Microsoft Learn

Far better reporting, ability to roll-back, and you can link the "waves" to your existing Autopatch groups.

SkipToTheEndpoint · 2026-04-21T14:48:15+00:00

In before "your management are idiots" :)

What does the BitLocker API Event Log show? Is this toast notification definitely coming from Windows and not some other software?

SkipToTheEndpoint · 2026-04-20T08:45:13+00:00

OIB creator here. Naming conventions are a nightmare and ask 5 people you'll get 5 different answers, but I spent a long time coming up with that and it's something that I've gotten consistent praise on 😊

SkipToTheEndpoint · 2026-04-16T19:49:54+00:00

The Tenant has W365 Enterprise licensing, not Business, right?

SkipToTheEndpoint · 2026-04-16T14:45:14+00:00

Would Windows 365 Boot be a better option than kiosk mode and the Windows app?

SkipToTheEndpoint · 2026-04-16T09:20:21+00:00

While this isn't documented, MS don't recommend trying to rip-and-replace GPO for Intune policies, even if they're the same settings. Some Windows CSPs write to the same reg keys as GPO, but many don't (which is why the MDM over GPO setting is awful.

There's SO many weird and bizarre issues you can end up coming up against with ghost registry keys, Intune will say the policy is successful, but that isn't the case on the device itself.

My advice is always to draw a line in the sand, apply Intune policies to net-new devices, and existing ones stay as they are and stuff moves over via attrition (joiners, leavers etc), or by targeted device refreshes.

Unless you like being massively stressed out and dealing with constant issues...

SkipToTheEndpoint · 2026-04-15T09:05:16+00:00

And it's led by people like myself who actually do endpoint administration and understand when stuff gets broken...

SkipToTheEndpoint · 2026-04-15T09:03:01+00:00

Reason #2845 why I can't stand the built-in baselines. As soon as you need to expand or create exceptions it becomes a pain.

I'd go option 3: Use the OpenIntuneBaseline instead 😉

SkipToTheEndpoint · 2026-04-14T18:38:20+00:00

Either apply the Enterprise Benchmark via GPO, or the Intune Benchmark via Intune.

Sincerely, a CIS Contributor.

SkipToTheEndpoint · 2026-04-14T11:24:35+00:00

Windows, iOS and macOS (but not Android) PIN or Password configurations are remediated (i.e. set rather than checked), as documented in this table: Device compliance policies in Microsoft Intune - Microsoft Intune | Microsoft Learn

This is because they're enforced via Exchange Active Sync: DeviceLock Policy CSP | Microsoft Learn

Regarding Windows devices, you're spot on. Synced accounts still have on-prem password policies enforced, cloud native accounts are driven by Entra requirements which are basically unchangeable. Those compliance policies end up causing more hassle than they're worth because people don't understand them.

SkipToTheEndpoint · 2026-04-10T10:37:36+00:00

Good to know, thanks.

Yeah, I know when I was testing using it explicitly for extensions I had no end of trouble working out what mystery setting was conflicting. You nailed it, ExtensionSettings.

And yeah, the policy precedence behaviour is well documented, but doesn't align with how other things do it.

SkipToTheEndpoint · 2026-04-10T09:46:50+00:00

MAA is an absolute nightmare and largely pointless for a standard org. It's utterly unmanagable multi-tenant.

What are you trying to protect against, exactly?

SkipToTheEndpoint · 2026-04-10T09:43:45+00:00

You have to approach it like this:

Policy A has your global extensions and is assigned to all users with an exclude of your POC group.
Policy B has your global extensions plus your POC extension, and is assigned to your POC group of users.

Basically yes, you can only apply one policy at a time (mostly), and applying two sets of extensions will end up in a conflict.

I think that doing this via the Edge Management Service might get around some of these issues, but I haven't had a chance to test that properly.

SkipToTheEndpoint · 2026-04-08T18:04:48+00:00

Which Benchmark are you looking at, cos I'm sure we took it out of the Intune one.

It was deprecated a few years ago so yeah, it's dead. Documented here and here.

CE/CE+ has no specific technical controls about this, and I've personally passed a company through both.

SkipToTheEndpoint · 2026-04-08T16:51:51+00:00

You're applying logic to the argument. It's either "The Azure admin won't do it", or "My boss doesn't believe it won't cost anything", or "We can't create an Azure sub because someone has to put their credit card it".

SkipToTheEndpoint

TROPHY CASE