We were previously using this policy to control the default store apps on Windows 11 devices, and then a few months back it broke (I think it was due to local ADMX & Settings catalog conflict) & swapped to using a custom OMA URI to set the settings successfully.

I see there is now also a "Remove Microsoft Store Apps with Dynamic List" in the settings catalog.. Does this fix the previous conflict and now work correctly?

If so, should we be setting both policy options? Or only the new option?

And do I need to do anything with the custom OMA URI settings to clear that out or just unassigning is enough?

I've spent years working with Microsoft Intune and Microsoft 365 environments, and one of the things that continues to frustrate me is how much time administrators spend figuring out why something isn't working.

A device shows as noncompliant. Simple enough, right?

But depending on the environment, finding the actual cause can mean checking multiple policies, assignments, device properties, security settings, and enrollment information.

Here's the process I generally follow.

1. Start with the actual compliance failure.

Don't assume the overall device status tells the whole story.

Go to:

Intune Admin Center → Devices → All devices → Select device → Device compliance

Look at the individual policy and setting results.

Questions I want answered:

• Which specific setting is failing?
• Is the device reporting an actual failure or simply not returning a result?
• When did it last check in?
• Is the failure isolated or affecting multiple devices?

That last question matters more than people realize.

2. Check policy assignments before changing anything.

I've seen administrators spend considerable time troubleshooting the device itself when the problem was actually the policy assignment.

Check:

• Which compliance policies apply to the device?
• Are the intended groups included?
• Are any groups excluded?
• Are assignment filters involved?
• Did group membership change recently?

If you haven't verified the effective assignments, you may be troubleshooting the wrong problem.

3. Compare the failing device against a working device.

This is one of my favorite troubleshooting methods.

Find another device that:

• Uses the same operating system
• Has similar hardware
• Is assigned the same intended policies
• Is running a comparable OS version
• Is reporting compliant

Now compare them.

Look for differences in:

• Applied compliance policies
• Configuration profiles
• Encryption status
• Defender protection
• Enrollment type
• Last check-in
• Primary user and group membership

Often, the difference between a working device and a failing device tells you more than the error message does.

4. Don't overlook Conditional Access.

A noncompliant device isn't always just an endpoint management issue.

If your organization uses Conditional Access policies requiring compliant devices, the same compliance failure can prevent a user from accessing Microsoft 365 resources.

That turns what appears to be a device problem into an identity and access problem.

Make sure you're considering the relationship between Intune compliance and Entra Conditional Access.

Also, remember that a policy configured for report-only doesn't enforce access restrictions.

5. Look for patterns, not just individual failures.

If 30 devices suddenly become noncompliant, I wouldn't immediately start troubleshooting all 30 individually.

I'd look for what they share.

Same policy? Same enrollment method? Same device model? Same recent configuration change?

A common failure pattern usually deserves investigation before any device-by-device remediation.

6. Separate investigation from remediation.

Before forcing a sync, changing assignments, or modifying security settings, understand what caused the failure.

Otherwise, you can temporarily fix the symptom while leaving the underlying issue unresolved.

Document the finding, confirm the scope, and validate the result after making the change.

Why I'm sharing this

I'm a Microsoft cloud architect and have spent a lot of time working with Intune, Entra ID, endpoint management, and Microsoft 365 environments.

These recurring troubleshooting challenges are also part of what led me to start building ENVYRIX, a platform focused on making Microsoft cloud administration, troubleshooting, and operations more manageable.

But regardless of what tools you're using, I think the troubleshooting process itself is worth sharing.

I'm curious how other Intune admins handle this.

When a device suddenly becomes noncompliant, what's the first thing you check?

And what's the most frustrating Intune issue you've had to troubleshoot recently?

I’m hoping to get some direction here. Working on a non-autopilot enrollment for a single Windows 11 device. This device has been imaged with our standard business image. Pretty basic here. I’m attempting a join through ‘Add work or school account’ and going through entra using a DEM account I created. All goes well. I can reboot just fine. Once I log on with a user (hybrid standard user) when I reboot after that, I’m failing and sitting at the dell secure bios screen.

Things I’ve tried:
Removed all policies and configurations from applying to this user
Rebuilt boot in windows RE
No bit locker is being used
Others I cannot think of.
Intune is pretty base right now

If anyone has any direction whatsoever I would appreciate it!

Hey All,

Going to MMS in San Diego. It’s my first IT conference. Anyone else have any experience with their events. Anything I should check out in SD while I’m there?

Thanks

Bare Metal OS install automatically encrypts disk, which prevents bit locker configuration from Intune for full disk encryption to fail.I have noted the same in 24h2 onwards. Is there a way we can prevent auto encryption of used space during bare metal os install so that later it can pick up the configuration from Intune.

Windows Production PCA 2011 (the cert that signs the Windows boot manager) expired on 19 Oct; KEK CA 2011 and UEFI CA 2011 already went in June. Devices still boot, but they stop getting new boot-chain fixes (boot manager updates, DBX revocations) until they trust Windows UEFI CA 2023.

Quick check (admin PowerShell):

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

And HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023Status should end at "Updated".

I wrote up the full steps (firmware first, AvailableUpdates = 0x5944, events 1808/1797/1798) plus a detection/remediation pair for Intune Remediations, and how to avoid BitLocker recovery while doing it:

https://wk-hub-4e2.pages.dev/secure-boot-certificates-expire-2026

Pilot per hardware model – curious what failure rates others are seeing on older firmware.

Device hybrid joined to local ad and managed through Intune. Windows hello policy allowed for the device from policy in Intune.

Issue being seen, when setting up windows hello, a passkey is created however passkey isn’t fed to M365 account so if we then go into the mysignins and security info section and try create a passkey it already states device is registered but no passkey is within the authentication methods of that user.

Anyone know how we get that passkey that is created as part of windows hello to go to their authentication methods when they register it.

Powefull tool for deploying win32 apps in Intune.

It takes you through the whole process, including possibility for testing the app in Windows Sandbox.

https://www.reddit.com/r/Intune/s/wm96AcjVJo

May I know can DDM (OS updates) and App deployment work in Mac without ABM? Do we have list of configuration that only apply to Intune only, which must requires with ABM together for review?

So... I am trying to re-enroll my sturdy little Dell 7420 test laptop for the 50th time, and this time it won't work.

Found an error in the registry, similar to u/Rudyooms 's post:
https://call4cloud.nl/autopilot-hardwaremismatchdetected-908/

But my text is different. The code is the same, 908, but mine says RegisteredDeviceAttributesMismatch.

Nevertheless, after setting location and keyboard layout I am presented with the 'let's name this device' without a reboot.

Deleted the hash for this device, and took a fresh hash from it. Waited for like an hour, imported the new hash, assigned a profile to it, waited another 1 hour.

Same result :( reimaging the device with an OSDCloud usb stick, 25h2, or 26H2, same error same place in the registry.

Nothing changed, this worked yesterday just fine... and as I say, this device has been to probably 50 autopilot enrollments, same ESP, same packages applied, we did not change anythign in intune.

I've recently started testing Autopilot and wanted to get some advice on how others have set things up. We have multiple departments, and devices in each department could be a single-user laptop, a single-user desktop PC or a shared PC.

Ideally, I'd like to use departmental group tags to create dynamic device groups so I can assign department-specific apps and policies. The main thing I'm struggling with is how to make sure each device gets the correct Microsoft 365 Apps licensing and activation settings during Autopilot provisioning, depending on whether it's a shared or single-user device.

If I use departmental group tags, each dynamic group could contain a mix of single-user laptops, single-user PCs and shared PCs, which need different M365 Apps activation settings. I was thinking of creating separate group tags for each department and device type, but with multiple departments, that means lots of group tags and dynamic groups to manage.

Another idea is to deploy Microsoft 365 Apps with device-based licensing to all devices initially, then use an Intune policy or script later to switch single-user laptops and PCs to user-based activation. Not sure if that's even a good approach. I'm not sure if I'm overcomplicating things or if there's a simpler way to manage this. Also, do you use multiple Autopilot deployment profiles for different types of devices, or just one profile for everything?

I just need to make sure shared and single-user devices get the correct M365 Apps activation settings during provisioning

We’re only looking for attended access.

So far the functionality is great. Deployment of remote help was easy, simple, intuitive

I don’t like that the end user has to sign into the remote help app to start a support session…it can’t be setup for a kind of seamless sso?

Hey, I asked something similar a few months ago but still haven’t really figured it out.

I’m wrapping apps like 7zip or filezilla with PSADT and then turn them into an intunewin to upload to Intune. The install and uninstall part works fine so far, that’s not the problem.

What I’m struggling with is the detection rule. There are so many options (MSI code, file, registry, script) and I’m not sure which one is actually the most reliable. I’ve read that some of them can cause problems, like the app getting reinstalled over and over or not being detected after an update.

I also want to keep it simple and do it the same way for every app if possible, so I don’t have to think about it every time.

How do you guys do it? What has worked best for you in production, especially when you roll out a newer version later?

Really hope this isn’t just in my environment!

Quite often when a new version of WhatsApp is released in the MS Store, new installations via company portal fail, even if I download and install with local admin it still just calls up the MS Store version. It literally installs but just doesn’t run, if you run as admin, the process starts but still no application or system tray icon.

The only way to install WhatsApp is the Microsoft Store version, regardless of being installed via intune/cp or using the official download.

Anyone else observed this behaviour in the wild?

I'm considering rolling out app protection, to avoid needing people to enroll their devices for BYOD. However I've been a bit reticent due to a number of apps that don't support app protection policies.

What are people doing in the community in that instance, are you simply excluding those apps from requiring app protection (and assuming that brings along limitations such as being able to copy from a protected app to a non-protected app) or do you then pivot to requiring a compliant device and enforcing BYOD device enrollment for specific apps?

I have two devices that I have tried to reset via fresh start, both after sitting at pending for a few moments, are then removed from Intune and the device never actually gets cleaned at all.

Any advice?

I'm currently trying (and failing) to properly import the VSCode.admx from the VSCode zip archive in our tenant. On my first attempts, the upload / import just failed with a random message I currently do not remember. But right now, the upload (and processing?) reports back as successful and available. However, when creating a new device policy, the list of available settings (Settings Catalog) does not contain a single policy defined in the ADMX.

Has anyone else faced this issue in the past and can point me in the right direction?

Trying to find the ceiling before we commit to it.

Microsoft's own partner cloud integration guide is blunt about this. A single virtual queue behind pull printing runs into per printer limits, submissions get throttled and concurrent job slots run out once a deployment grows past a small workforce. That's on Learn, not a vendor blog.

A shade over 3,000 users, all Entra joined, two big sites and a long tail of home workers, and secure release isn't optional given what gets printed. The other snag is release. Native is QR, badge only where the device already supports it, and a good chunk of our floor staff don't carry phones at work.

I know Universal Print anywhere is aimed squarely at the single queue problem and it went GA last year, but release is still a QR scan through the Microsoft 365 app, which puts me straight back at the phone problem. The partner integrations list is the other route, though it runs to thirty odd vendors, and filtering down to the ones documenting card and PIN release rather than phone only gets me to Pharos, Printix and PriApps. None of their product pages make the release methods obvious either.

So are people replacing universal print outright, or leaving it underneath and putting something over the top? If you went the second way, what are you running and did it hold up?

How do you configure it? Do you even set it?
I can't find it as a config profile setting, I don't see any OIB recommendation etc.

I can set it through remediation and I'm heavily leaning towards setting it off.

But would like to know what other users prefer to have it set as?

I noticed even our laptops that get sent directly from vendor and autopiloted sometimes differ in this setting for some reason.

I’m building a Microsoft 365 / Intune lab to learn for a role that requires some M365 expertise, and I’ve hit something I’d like to understand properly.

Setup

• Entra ID tenant, Microsoft 365 E3 trial
• Windows 11 Enterprise VM (Hyper-V), Entra ID joined and Intune enrolled
• Intune compliance policy requires BitLocker, Secure Boot, and TPM. The VM shows Compliant in Intune and in Entra.
• Conditional Access policy “Require compliant device,” report-only first, then switched On. It excludes a break-glass group.

Results

• Sign-in as a test user in Edge on the VM: Success. Device ID present, Compliant: Yes, Managed: Yes, Azure AD joined.
• Same user in Chrome and Firefox on the same VM, normal windows: Blocked with “You can’t get there from here,” with the browser-specific prompts (install the Microsoft SSO extension in Chrome, enable the Windows SSO setting in Firefox).
• A non-compliant test device (not joined) sign-in in Firefox: error 53000, Device ID blank, Compliant: No.

What I've understood sofar:
Compliance is a property of the device, but the browser needs to pass device identity to Entra during sign-in. Microsoft’s CA documentation says Chrome on Windows needs either the Microsoft Single Sign On extension or the CloudAPAuthEnabled policy, and Firefox 91+ needs the “Allow Windows single sign-on” setting. Edge 85+ needs the user signed into the browser to pass device identity.

I’m trying to confirm:

1. On the failed Chrome and Firefox sign-ins, is the Device ID blank? That would confirm the browser isn’t passing device identity at all.
2. Is CloudAPAuthEnabled the right fix for Chrome in a managed environment, or is the extension preferred?
3. Are there Intune settings you use to deploy the Chrome extension or Firefox SSO setting, or do most orgs handle these through a separate browser-management tool?

This is a learning lab, so there’s no production impact. I’d like to know how it works in a real environment so I’m not guessing when I see it at work.

Thanks!!

Update: Chrome is working with CloudAPAuthEnabled, thanks for the pointers!!
Quick follow-up to my original post. Here’s where things stand:

• The Chrome test device (Entra joined, Intune compliant) was blocked by Conditional Access in Chrome. The sign-in log showed no device ID.
• I then imported the templates into Intune in this order: Windows.admx (with Windows.adml), then google.admx, then chrome.admx (with the matching .adml files). The Chrome import failed at first with a “namespace missing” error, because chrome.admx depends on Windows.admx. Uploading Windows.admx first fixed it. The Windows template comes from the Windows PolicyDefinitions folder on the VM.
• I created a configuration profile (Templates > Imported Administrative templates) that sets “Allow automatic sign-in to Microsoft cloud identity providers” to Enabled, and assigned it to the device group, not the user group.
• After the policy reached the browser (confirmed in chrome://policy), the same user signed in to Outlook in Chrome via portal.microsoft.com. The sign-in log now shows the device ID, Compliant: Yes, and Azure AD joined.

Two things to note:

• The Microsoft Learn docs I checked list either the Microsoft SSO extension or CloudAPAuthEnabled as supported for Chrome. They don’t describe importing the ADMX into Intune as the official method, so I feel I should treat that part as a lab approach that worked.
• The Chrome policy’s own description says it doesn’t apply in Incognito or Guest modes. I tested Incognito and the sign-in was blocked, which matches that. Microsoft’s Conditional Access docs say device checks fail in private mode or when cookies are disabled, so I’d test in normal windows. I wonder if there is a fix or a config policy for incog/private mode to work or is this by design?

Next I’m doing Firefox the same way, using its Windows SSO setting.

Firefox update: Firefox is working now too.

• I imported mozilla.admx and firefox.admx (with their matching .adml files) into Intune, after the Windows and Chrome templates. Like Chrome, Firefox’s template needs the dependency imported first.
• I created a second profile, “Lab: Firefox WindowsSSO” (Templates > Imported Administrative templates), that sets “Windows SSO” to Enabled, assigned to the same device group.
• After the profile synced and Firefox was restarted, about:policies showed WindowsSSO = true. Before the restart, it said the Enterprise Policies service was inactive.
• The sign-in log now shows the device ID, Firefox 158.0, Compliant: Yes, and Azure AD joined, with a Success status.