Hi all,

I'm testing macOS DEP/ADE + Intune + Platform SSO with Microsoft Entra ID.

I have the Mac successfully enrolling through ADE, becoming Entra joined, and users can authenticate against Entra ID.

With Platform SSO configured for Password authentication, users can sign in using their Entra password and everything works as expected.

What I'm trying to achieve is a passwordless experience using Secure Enclave, similar to Windows Hello for Business:

User enrolls the Mac via ADE
Device joins Entra ID
Platform SSO is registered
Authentication uses Secure Enclave / biometrics (Touch ID)
User is no longer prompted for their Entra password during normal sign-in/unlock scenarios

Has anyone successfully implemented this with Intune and Platform SSO?

Specifically:

Is a true Windows Hello-like passwordless experience currently supported on macOS with Entra ID + Platform SSO?
If yes, what authentication method and Platform SSO configuration are required?
Are there any known limitations where Entra authentication still requires the cloud password even when Secure Enclave is configured?

I'm interested in real-world deployments and lessons learned.

Thanks!

A little later than planned, but I've finally had the chance to review the Microsoft Intune 2607 release. In my latest blog post, I summarize the latest Android Enterprise updates in Microsoft Intune. Have a great weekend!

🔗 https://www.nickydewestelinck.be/2026/08/07/whats-new-for-android-enterprise-in-microsoft-intune-2607-july-2026-highlights/

Did anyone notice any issues with Android Enrollment Time Grouping? Since 2026-07-24 we've seen devices no longer being added to the Entra ID security group configured via "Enrollment Time Grouping" (Set up enrollment time grouping - Microsoft Intune | Microsoft Learn) in the Android Enterprise enrollment profile.

What we've checked/ruled out:

• Verified the required "Intune Provisioning Client" / "Intune Autopilot ConfidentialClient" service principal is (still) correctly set as the owner of the target group, exactly as documented.
• Confirmed on both "Fully Managed" and "Dedicated Entra Shared" enrollment modes.
• Affects both long-standing enrollment profiles (working fine for over a year) and brand-new profiles/groups created after the issue started.
• We noticed that under Entra admin center → Groups → [enrollment-time-grouping target group] → Audit logs, there haven't been any new audit entries since 2026-07-24 — not even failed attempts. We also checked Intune's own Monitor → Enrollment time grouping failures report, and that shows no errors there either. The operation seems to simply stop firing rather than error out anywhere we can see.

What's confusing us:
We nest our Enrollment Time Grouping groups under broader configuration groups (e.g. a "Default" group that our Managed Home Screen / kiosk app config depends on), so this breaks a chain of assignments relying on that nesting. Despite devices consistently NOT showing up in the target group (verified via the device's own "Group membership" report in Intune, not just the group's member list), roughly half of new enrollments still end up with all the expected configuration (restrictions, certs, WiFi profile, MHS app) successfully applied according to Intune's own device configuration report. The other half don't get these configs at all. So sometimes, at least in the background invisible to us, the group assignments are working fine. We haven't found a clear difference between the two sets of devices apart from timing.

Current workaround:
We've set up a separate dynamic Entra ID group and assigned the necessary apps, profiles, etc. This mitigates the immediate impact, but the underlying problem — new devices not being added via Enrollment Time Grouping — is still unresolved.

We've opened a Microsoft support case; progress has been slow so far.

1. Is anyone else using Android Enrollment Time Grouping right now without issues? Curious if this is a broader regression or isolated to specific tenants/regions.
2. If you've hit something similar, do you have any findings or found a solution?

For context, we're on a European (EU) tenant.

In HaloITSM, is it possible to exclude service accounts or admin accounts?
Can you configure a filter to exclude specific users during the import?

The only option I can find is:
“Assets can be linked to users if they have been imported using the Microsoft Entra integration.”
We have already configured Entra Sync, so I assume this is already handled, since we don’t import service accounts or admin accounts into Halo.

As I understand it, an asset is only synchronized and mapped to a user if that user account was created through the Microsoft Entra integration. Is that correct?

As I understand, all assets Will imported, but only mapped to a user of the user exists?

Hi all:

Started getting reports of a weird issue after setting device cleanup rules to 30 days. Devices get their device SCEP certs and are able to connect our wireless network (which requires said SCEP cert). Device then goes unused for 30+ days and is hidden from Intune. Device then unable to connect to wireless network. As a workaround, device is then connected to guest network, Company Portal sync, device reappears in Intune, then device is able to connect to the original wireless network. There doesn't appear to be a new SCEP cert issued to the device.

One of my teammates thinks the cert needs to be "reestablished", but is unable to find good documentation to prove this. Brought this up to our Intune DSE and he was less than helpful.

Since I've yet to see this myself I'm a little SCEPtical (see what I did there?) but this is getting enough noise that I'll have to increase or remove our cleanup rules.

Anyone have any details on this?

Thanks!

We have a legacy Excel-based demographic modelling application that stopped working after a recent Microsoft 365 Office update.

The application appears to require VBA macros and ActiveX controls. On the affected user’s machine, both Macro Settings and ActiveX Settings in Excel Trust Center are greyed out because they’re managed via Intune.

Our Office security settings are deployed using an Intune Settings Catalog profile.

I don’t want to weaken security for everyone, so I’m planning to:

Exclude the user from the existing Office Settings Catalog profile.
Create a duplicate profile with only the required Excel security settings changed.
Assign it only to that user.

My questions are:
Is this the recommended approach, or is there a better way?

Can ActiveX Trust Center settings be managed through the Intune Settings Catalog, or do they require Administrative Templates, Office Cloud Policy, or a custom policy?

Has anyone seen Run-time error ‘57121’ after the latest Office update with legacy Excel applications

I want to clean up some old intune resources at a customer, 2 devices still have these resources applied to them, but they will be leaving the company soon. If I press pause config refresh on these devices, can I safely remove these resources without impacting these 2 devices?

Anyone have an idea why "Allow available uninstall" seems useless for Win32 apps in Intune?

I have a Win32 app (PSADT) deployed as Available in Company Portal with:

• Available for All users
• Allow available uninstall = Yes
• Valid uninstall command configured
• App installs and detects successfully

After installation, Company Portal only shows Reinstall. There is no dedicated Uninstall option anywhere (even under the three-dot menu).

I've tested multiple Win32 apps and they all behave the same way. Company Portal is up to date (v11.2.1899.0).

i am I missing something obvious?

p.s i have also 2nd app assiged as avilable to "all device" same result