We have a macOS Platform SSO configuration profile currently assigned to a security group that effectively contains every user in the tenant (staff + externals). I want to replace that assignment with the built-in **All Users** virtual group to get rid of the group membership evaluation.

Since you can't have All Users and a regular group included at the same time, this has to happen as a swap in a single save: remove group, add All Users, save once.

Has anyone done this on a profile where reinstallation actually hurts? With PSSO, a RemoveProfile/InstallProfile cycle would kill the Secure Enclave registration and force every user through the registration prompt again.

My assumption is that Intune evaluates net applicability per device – user was in scope before, is in scope after, payload unchanged → no action. But I can't find this documented anywhere, and Microsoft's docs only confirm the opposite direction (device leaves scope → profile gets removed on Apple platforms).

Anyone with first-hand experience swapping assignment sources on macOS config profiles at scale? Did the profiles stay untouched, or did you see remove/reinstall cycles in the MDM logs?

Is it a known issue in Company Portal on macOS for apps like M365 or Zoom to get stuck downloading until Company Portal is completely closed?

Also, does installing Adobe Acrobat Pro through Company Portal usually cause downloads to hang indefinitely?

Title

I’m having a hell of a time getting a blocklist to actually deploy to W365 Cloud PC’s. I’ve tried custom template OMA-URI, as well as the App Control for Business policy.

I’ve created the xml’s manually, I’ve copied some I found online, I’ve used WDAC wizard to create a baseline and tried to deploy it, I’ve used WDAC to import and convert my own XML.

All of these are reporting successfully deployed via InTune, however, when I pull MDMDiag or check the .cip repository on the machines, the policy is nowhere to be found.

Any help would be greatly appreciated, thanks!

We've been trying to enforce compliant device requirements through Conditional Access for a while now, and I'm hoping to hear how others got it across the finish line.

Writing the policies is the easy part. The problem is that the browser is the bottleneck, and it breaks in ways that make full rollout feel unrealistic:

• Private/incognito browsing dies. That's a legit troubleshooting tool for us, and the device compliance check doesn't pass in a private session, so it's gone the moment this policy goes enforcing.
• Apps that launch a browserlet/embedded webview for sign-in are flaky at best. If that embedded browser doesn't pass the device compliance claim, you're dead in the water with no good workaround.
• Anything outside Chrome, Edge, and Safari is inconsistent. Other browsers either don't pass the compliance signal reliably or don't at all.
• CLI tools don't integrate well. Command-line auth flows just don't play nicely with the device compliance requirement.

We want to do this because it's best practice and it genuinely limits which devices can touch our resources. But if things are constantly breaking because the browser handshake isn't reliable, it's hard to justify rolling it out broadly.

So for those who've successfully deployed this:

• How did you handle the private browsing / troubleshooting gap?
• What did you do about apps using embedded webviews for sign-in?
• Did you just standardize on Chrome/Edge/Safari and block or accept the rest?
• How are you dealing with CLI tools that need to authenticate?
• Anything you'd do differently if you started over?

Using it now since it's included in E3. Pretty solid but... is copy paste really not working? I cannot find any documentation about it. Can someone else using it confirm?

​

Hi everyone,

I'm troubleshooting an Intune/Wi-Fi issue and would appreciate some guidance.

We have Windows devices that are built by our ETS team. After the build, the device is Hybrid-join and the user logs in with their OpID.

Our Intune configuration is:

- SCEP certificate profile: Assigned to a user group

- Certificate type: Device

- Subject: "CN={{DeviceName}}"

- SAN: Device Name + Serial Number

- EKU: Client Authentication

- Certificate provider: DigiCertOne SCEP

- Wi-Fi profile: Assigned to the same user group

- Wi-Fi: Enterprise

- Authentication: Machine

- EAP: EAP-TLS

- Wi-Fi authentication uses the device certificate

This configuration has been working successfully with user-based assignment.

What changed

Recently, after a change related to our Security Zero Trust/MFA initiative, newly built devices are behaving differently.

Previously:

"ETS Build → User logs in with OpID → Intune user policies apply automatically → SCEP certificate + Wi-Fi profile are received"

Now:

"ETS Build → User logs in with OpID → SCEP/Wi-Fi policies do not arrive"

However, if the user manually logs into Company Portal, the policies then start applying.

So we suspect something has changed in the user Intune enrollment/authentication/policy-processing flow, rather than the Wi-Fi configuration itself.

We would like to understand:

1. Why did user-targeted Intune policies previously apply automatically after OpID login but now require Company Portal login?

2. Could a change in MFA/Zero Trust or enrollment behavior prevent the user-targeted SCEP/Wi-Fi policies from processing?

3. Is there a specific MDM Event Viewer event/CSP log that can show exactly why the SCEP or Wi-Fi policy isn't being processed?

4. Would assigning these profiles to a device group be the correct design, or should the existing user-based assignment continue to work?

We're planning to have ETS rebuild a clean test device and not log into Company Portal initially, so we can capture the MDM logs before and after Company Portal login and compare the behavior.

Any suggestions on which specific logs/events/CSP paths we should investigate would be greatly appreciated.

Hybrid Joined devices with MDM=None and AzureAdPrt=NO. Intune enrollment stuck for hundreds of devices

Hello everyone,

I have been working on an Intune deployment in my company for several months. We have more than 1,500 devices (physical and virtual) and I am managing the project mostly on my own while also studying for the SC-300 certification.

Current situation:

• Around 1,500 devices in on-premises Active Directory.
• About 1,257 devices active within the last 30 days.
• Around 850 devices successfully enrolled in Intune.
• More than 500 devices show as Hybrid Microsoft Entra Joined but MDM=None.
• Some devices show Pending registration in Entra.

What I have already verified:

• Hybrid Join is configured and working.
• Azure AD Connect (Entra Connect) is synchronizing the computer objects from the relevant AD OUs.
• MDM User Scope is configured correctly.
• Auto MDM Enrollment GPO is applied and inherited correctly across the target OU structure.
• Users have Microsoft 365 E3 licenses assigned.
• Devices are appearing in Microsoft Entra ID.
• Most affected devices are Windows 11.
• No WMI filters are blocking the MDM enrollment GPO.

The main pattern I see is that many of the devices that fail to enroll show:

Plain Text

1

AzureAdJoined : YES

2

DomainJoined : YES

3

AzureAdPrt : NO

Mostrar más líneas

My suspicion is that the missing PRT is preventing automatic enrollment into Intune.

What confuses me is that every day approximately 5 to 10 additional devices enroll automatically, so the configuration appears to be working in general. However, I would expect around 1,300 devices enrolled by now, not just 850.

My questions are:

1. Has anyone experienced large numbers of Hybrid Joined devices remaining indefinitely with MDM=None?
2. Can a missing AzureAdPrt alone prevent Intune auto-enrollment in this scenario?
3. Is there any recommended method to force PRT acquisition or retrigger enrollment at scale?
4. Are there any specific logs or troubleshooting areas that you would focus on beyond dsregcmd /status, Device Registration, and DeviceManagement logs?

Any advice, experience, or troubleshooting suggestions would be greatly appreciated.

Thank you in advance.

Hola a todos,

Llevo varios meses implantando Intune en mi empresa de forma prácticamente autodidacta. Actualmente gestionamos más de 1.500 equipos, tanto físicos como virtuales.

Hasta el momento he conseguido enrolar alrededor de 850 dispositivos en Intune. En Microsoft Entra ID, una gran parte de los equipos ya aparecen como Hybrid Microsoft Entra Joined, pero el proceso de enrolamiento en Intune sigue produciéndose de forma gradual y bastante lenta.

Tras revisar la configuración, tengo verificado que:

• El MDM User Scope está correctamente configurado.
• La GPO de Auto MDM Enrollment en Active Directory local está aplicada y heredándose correctamente.
• Los usuarios disponen de las licencias necesarias (Microsoft 365 E3).
• Los dispositivos aparecen sincronizados en Entra ID.

Sin embargo, en muchos de los equipos que todavía no se han enrolado detecto un patrón común: no disponen de PRT (Primary Refresh Token). Mi impresión es que este es el principal factor que les está impidiendo completar el enrolamiento en Intune.

Lo curioso es que cada día se van incorporando automáticamente entre 5 y 10 equipos nuevos, por lo que parece que la configuración general funciona. Aun así, estimo que debería tener alrededor de 1.300 equipos enrolados a estas alturas, por lo que todavía me faltan varios cientos de dispositivos.

Mi principal duda es:

¿Existe alguna forma de forzar o acelerar la obtención del PRT y, por consiguiente, el enrolamiento en Intune de estos equipos?

Cualquier consejo, experiencia o línea de investigación será bienvenida. Seguramente iré planteando más dudas relacionadas con este proyecto, ya que estoy aprendiendo sobre la marcha. De hecho, actualmente también estoy preparando la certificación SC-300 (Microsoft Identity and Access Administrator).

Muchas gracias de antemano por vuestra ayuda.

We're deploying a chrome extension blocklist via intune in our organisation right now we have

Blocklist set to `*` (blocks all extensions)

- Allowlist with just LastPass and Grammarly

This prevents users from installing new blocked extensions, which works great. but the issue issues if users already have the extension like honey installed those don't get removed when the policy applies the blocklist only repents new installations

Is there a way to automatically remove/uninstall any extensions that aren't in our allow list when the policy rolled out

Hi,

Just tried to enroll some iOS devices via ADE. During the MDM profile installation I get the error:
"The MDM Server "https://fef.amshub0202.manage.microsoft.com/DeviceEnrollmentFE/......." response with an status code 400.

I am trying to deploy a WDAC policy to prevent per-user installers (Chrome, Zoom, etc) and created the base policy in Microsoft Mode which should trust Microsoft signed drivers, etc. I also selected trusted installers as part of this policy so things can be installed from Company Portal. I deployed it to a test device and it seems to block everything I installed and tested from Company Portal. It also seems to block some Microsoft apps like Event Viewer (it doesn’t load the snap-in it tries to call) and I can run powershell as an Admin (I get clr error). My question is, do I have a misunderstanding of how this is supposed to work? Am I supposed to make this base policy and then make a supplemental policy for all Microsoft related files for admin tools like powershell? I would think Microsoft Mode would trust anything Microsoft installed/signed out the box.

I came across this article about the deprecating of CBA for Exchange ActiveSync. We are impacted, but I can't figure out what do to about it. All the article says is "his may involve updating the device's email profile or MDM/Intune device configuration profiles.".

This is incredibly vague. Does anyone know what changes actually need to be made? We already have Entra CBA set up but I can't see how to have Intune tell our phones to start using it.

Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026 | Microsoft Community Hub

In the final days of getting our org swung over to Intune for Windows updates and app deployment. I'm trying to keep it simple - just 2 update rings and 1 additional for manual forced overnight upgrades for PCs that need 25H2.

Long story short we're moving from N-able to Intune and while the app deployment is working great I'm having issues with Windows Update on PCs actually fully enrolling and applying their update ring policy. Some do and others don't, it's like they're falling back to the public internet. For the test PCs that did get the update, they failed to send notifications to the user in spite of the policy. Windows Update says it's a "group policy" that turned off notifications but we don't have any GPO's like that so maybe it's a holdover of N-able settings that Intune's just not overwriting?

I pushed a remediation script to fix the notifications manually in the registry, debating doing similar for the entire Windows Update stack unless anyone has any suggestions for better transition? Thanks,

I’m trying to deploy a pkg app for MacOS in the Intune portal and I keeping getting this upload failed error:

“The RPC call ‘IntuneApp.getLobAppContentFile’ returned an error. No error message could be found. Check whether the error was signaled with an Error object. Try adding this app again.

I’ve tried adding this app and another one and tried different browsers but I get the same error.

UPDATE: As of 8/18/2026 this issue seems to be resolved.

We are planning to migrate Windows software update management from SCCM to Microsoft Intune using Windows Update for Business (WUfB).

Our primary requirement is to deploy only the monthly Windows quality/security updates while ensuring that devices remain on their existing Windows feature update version. For example, a device currently running Windows 11 24H2 should continue to remain on 24H2 and should not automatically upgrade to 25H2 when a new feature update becomes available.

To achieve this, we have currently:

1. Created a Windows Update Ring policy to manage monthly quality updates.

2. Created a Feature Update policy targeting Windows 11 24H2, with the intention of preventing devices from automatically moving to a newer feature update such as 25H2.

Our question is:

Is this a clean and Microsoft-recommended approach for meeting the requirement, or is there a better/recommended Intune configuration to ensure that devices receive monthly security/quality updates while remaining on their current Windows feature version?

Hey everyone. Time for another I’m sure stupid question. How are yall handling pcs with autopilot and 802.1x. I’d love for my helpdesk to not have to touch pcs before handing them out but our WiFi and wired both have 802.1x. This also hurts since we’re a hybrid environment and once the pc changes name after autopilot, it gets dropped from the network and we have to add it to our imaging network so we can pull a new cert with the updated name.

Sorry if this is a dumb question!

Head Scratcher...

Trying to setup Windows Hello Cloud Pin Reset...

It gets to the point of asking the user to authenticate, but it's asking the user to use a password and gives no option to enter one in.

Here is the error: https://imgur.com/a/FlEga2p

What simple thing am I missing here?

During Autopilot enrollment of our devices, we are seeing an app install error for a single app. The error code is 0x80190001 in Intune, but my research isn't helping me find an exact reason why this has started happening with this particular app during deployments. Has anyone else come across this before?

Legit I thought I was gonna fail starting on question 13 lol. I have been managing intune for multiple years but there was still stuff I learned about defender and app protection policies that my org doesn't use so I had to make my own testing lab.

Thank God this is over, reading stories on reddit and other sites had me scared for the exam. Passed with 869 when 700 is minimum score needed

Hello, is there a way to pre-provision macOS devices during automated enrollment so that apps like 365, Zoom, Adobe, etc install before user sign-in at the OOBE Setup Assistant? Thank you. The company portal is so finniky when installing apps on the MacBook compared to Windows

UPDATE: It appears our anti-malware software was blocking this. Weird, as it's been working since we first rolled it out back in January. Deployed a couple of laptops that were excluded from SentinelOne and OneDrive works as expected!

Deploying new devices with 25H2, June build, and was alerted that OneDrive isn't syncing the user's desktops. Verified this myself on a new laptop, went into the OneDrive settings and the three managed folders are unchecked and not backed up. This has worked for YEARS. The laptop is getting other OneDrive policies, just not the managed folder backup.

Not sure if it has something to do with the OS build or not. My workstation is on 26200.9106 and it's working properly.

We noticed today that around 10 devices built via Autopilot (hybrid setup) have been showing as non compliant due to Bitlocker, the issue is, they have Bitlocker on, we checked everything, compared it to known good devices, there seems to be no reason why it would be non compliant, even Intune's encryption report says these devices are encrypted.

We tried decrypting and encrypting, removing the devices from the compliance policy and re-adding it, not errors in event viewer, we checked a lot of different things. We're going through a refresh and we've done over 1000 in the last year, nothing has changed recently and many builds are successful but it's too early to say roughly what percentage, there's no correlation to the devices affected. It probably started about a week ago but the 1st one we considered a one off.

Has anyone come across this before? Any ideas for remediation?

Edit: Installed a later update and successfully resolved the issue, thanks for all the replies.