Anyone hit this: Sensitivity Label button in Microsoft 365 apps grayed out & not operational on Jamf-managed Macs, but present on Intune-managed Macs.
Same user, same M365 apps build, same license, same MDM configuration.
I am lost! Anybody an idea?
Anyone hit this: Sensitivity Label button in Microsoft 365 apps grayed out & not operational on Jamf-managed Macs, but present on Intune-managed Macs.
Same user, same M365 apps build, same license, same MDM configuration.
I am lost! Anybody an idea?
Anyone hit this: Sensitivity Label button in Microsoft 365 apps grayed out & not operational on Jamf-managed Macs, but present on Intune-managed Macs.
Same user, same M365 apps build, same license, same MDM configuration.
I am lost! Anybody an idea?
Hey all — hoping someone here has run into this.
We're rolling out Slack for Intune on iOS, and after a successful sign-in the app loops us straight into the public Slack marketing/sign-up flow and pushes us toward downloading the regular consumer Slack app instead — even though Entra sign-in logs show every authentication step succeeding underneath it.
This isn't a Conditional Access or App Protection Policy issue on our side (we've ruled out assignment, CA grant controls, and App Protection data-protection settings one by one). Here's the exact sequence, step by step:
login.microsoftonline.com-style URL. Tap Open.slack.com — "All your people and AI agents working together" / "GET STARTED" / "FIND YOUR SUBSCRIPTION."So the workspace session in step 8 proves the login and SSO handshake genuinely succeeded — I was inside the actual org workspace with my real identity. But instead of staying there or handing that session back to the native "Slack for Intune" app, it drops back into the public marketing/sign-up site, as if none of the previous steps happened.
We've confirmed via Entra ID sign-in logs (checked across multiple devices — iPhone and iPad, multiple browser contexts including Safari/Chrome/Edge, multiple times of day) that:
Has anyone seen this? What are we doing wrong?
Trying to streamline Defender onboarding. About to enable this toggle in Intune. What's the real impact, risk, and any visible changes for end users after it applies?
Trying to streamline Defender onboarding. About to enable this toggle in Intune. What's the real impact, risk, and any visible changes for end users after it applies?
Has anyone gotten AirDrop to work with "Block all incoming connections" enabled via the macOS firewall (managed through Intune)?
If not, is there a secure alternative approach?
We're trying to mirror our Windows default-deny-with-exceptions model on macOS: firewall enabled, policy set to "specific apps only" (AllowSigned/AllowSignedApp = false), with an explicit allow-list of applications — e.g. adding sharingd for AirDrop.
Does this sound like a sound approach, or are there gotchas we're missing (entitlements, code-signing checks, mDNS/Bonjour dependencies, etc.)?
Any real-world experience — good or bad — appreciated.
Has anyone gotten AirDrop to work with "Block all incoming connections" enabled via the macOS firewall (managed through Jamf)?
If not, is there a secure alternative approach?
We're trying to mirror our Windows default-deny-with-exceptions model on macOS: firewall enabled, policy set to "specific apps only" (AllowSigned/AllowSignedApp = false), with an explicit allow-list of applications — e.g. adding sharingd for AirDrop.
Does this sound like a sound approach, or are there gotchas we're missing (entitlements, code-signing checks, mDNS/Bonjour dependencies, etc.)?
Any real-world experience — good or bad — appreciated.
Has anyone gotten AirDrop to work with "Block all incoming connections" enabled via the macOS firewall (managed through Jamf)?
If not, is there a secure alternative approach?
We're trying to mirror our Windows default-deny-with-exceptions model on macOS: firewall enabled, policy set to "specific apps only" (AllowSigned/AllowSignedApp = false), with an explicit allow-list of applications — e.g. adding sharingd for AirDrop.
Does this sound like a sound approach, or are there gotchas we're missing (entitlements, code-signing checks, mDNS/Bonjour dependencies, etc.)?
Any real-world experience — good or bad — appreciated.
We manage a fleet of MacBooks (MDM via Jamf Pro) and are rolling out a policy that enables the macOS firewall, sets it to "Block all incoming connections," and enforces Stealth Mode — non-configurable by the end user.
Reasoning: most of these laptops regularly connect to untrusted networks, so we want to minimize the attack surface when off the corporate network.
Downside: this kills AirDrop (receiving), Universal Control, and AirPlay (receiving), and users are pushing back hard on this.
For those of you managing similar fleets: is "Block all incoming" + Stealth Mode actually necessary/best practice for laptops that roam onto untrusted networks, or is this overkill?
Curious how others have balanced this... Appreciate any real-world experience.
We manage a fleet of MacBooks (MDM via Jamf Pro) and are rolling out a policy that enables the macOS firewall, sets it to "Block all incoming connections," and enforces Stealth Mode — non-configurable by the end user.
Reasoning: most of these laptops regularly connect to untrusted networks, so we want to minimize the attack surface when off the corporate network.
Downside: this kills AirDrop (receiving), Universal Control, and AirPlay (receiving), and users are pushing back hard on this.
For those of you managing similar fleets: is "Block all incoming" + Stealth Mode actually necessary/best practice for laptops that roam onto untrusted networks, or is this overkill?
Curious how others have balanced this... Appreciate any real-world experience.
We're planning to eventually add two requirements to our device compliance policy:
Before enforcing these, I want a solid estimate of how many/which devices would fail — without impacting users.
Our current compliance policy is tied to Conditional Access with fairly short grace periods (e.g. 3 days for "no firewall enabled" before access gets blocked).
My idea: create a separate compliance policy scoped only to these 2 settings, assign it to the same devices, but set the grace period to something long (e.g. 100 days).
That way it still evaluates and reports compliance state, but the long grace period prevents devices from actually going noncompliant and triggering our CA policies.
Questions:
We're planning to eventually add two requirements to our device compliance policy:
Before enforcing these, I want a solid estimate of how many/which devices would fail — without impacting users.
Our current compliance policy is tied to Conditional Access with fairly short grace periods (e.g. 3 days for "no firewall enabled" before access gets blocked).
My idea: create a separate compliance policy scoped only to these 2 settings, assign it to the same devices, but set the grace period to something long (e.g. 100 days).
That way it still evaluates and reports compliance state, but the long grace period prevents devices from actually going noncompliant and triggering our CA policies.
Questions:
About 1000 Shared iPads, Managed Apple IDs and managed by Intune.
Tried with a script via the Graph but logging off multiple cached users makes the iPad lose connection with Intune. Maybe I'm missing something...
Anyone found a reliable way to log off multiple cached users on multiple devices?
Other solutions also welcome of course :)
About 1000 Shared iPads, Managed Apple IDs and managed by Intune.
Tried with a script via the Graph but logging off multiple cached users makes the iPad lose connection with Intune. Maybe I'm missing something...
Anyone found a reliable way to log off multiple cached users on multiple devices?
Other solutions also welcome of course :)
About 1000 Shared iPads, Managed Apple IDs and managed by Intune.
Tried with a script via the Graph but logging off multiple cached users makes the iPad lose connection with Intune. Maybe I'm missing something...
Anyone found a reliable way to log off multiple cached users on multiple devices?
Other solutions also welcome of course :)
Hi all,
I’m planning an iPadOS update rollout using Microsoft Intune with DDM and would like to hear how others handle this at scale.
We have around 700 iPads spread across 4 locations. Each location has its own WiFi infrastructure and its own internet connection.
The devices are a mix of shared iPads and personal/user-assigned iPads.
The target iPadOS version has already been tested and works as expected. Downtime is acceptable, so the main concern is the impact of the rollout itself.
My questions:
What kind of impact did you see when pushing a large iPadOS update through Intune/DDM?
Did you deploy everything at once, or did you use phased rollout rings?
Did you experience any noticeable impact on WiFi, internet bandwidth, or overall network performance?
How did Apple CDN behaviour affect your rollout, if at all?
I’m mainly interested in real-world experiences from environments with hundreds or thousands of iPads.
Thanks!
Hi all,
I’m planning an iPadOS update rollout using Microsoft Intune with DDM and would like to hear how others handle this at scale.
We have around 700 iPads spread across 4 locations. Each location has its own WiFi infrastructure and its own internet connection.
The devices are a mix of shared iPads and personal/user-assigned iPads.
The target iPadOS version has already been tested and works as expected. Downtime is acceptable, so the main concern is the impact of the rollout itself.
My questions:
What kind of impact did you see when pushing a large iPadOS update through Intune/DDM?
Did you deploy everything at once, or did you use phased rollout rings?
Did you experience any noticeable impact on WiFi, internet bandwidth, or overall network performance?
How did Apple CDN behaviour affect your rollout, if at all?
I’m mainly interested in real-world experiences from environments with hundreds or thousands of iPads.
Thanks!
Hi everyone,
We’re running into an issue with Declarative Device Management (DDM) software updates on Shared iPads managed through Microsoft Intune and I’m wondering if anyone else has seen this.
Environment
What we’re seeing
The DDM software update declaration is successfully delivered to the device.
All declaration items report Succeeded, including:
The device also reports:
However, once the deadline passes, nothing happens. The update never starts installing.
Devices meet all known requirements
We’ve verified the following:
Since these are Shared iPads, powered on, idle, and no user is signed in, we expected the OS update to automatically install after the target date. Instead, the devices remain in Prepared indefinitely.
Has anyone experienced this with DDM software updates on Shared iPads?
Is this a known Apple limitation, an Intune issue, or is there another prerequisite we’re missing?
Hi everyone,
We’re running into an issue with Declarative Device Management (DDM) software updates on Shared iPads managed through Microsoft Intune and I’m wondering if anyone else has seen this.
Environment
What we’re seeing
The DDM software update declaration is successfully delivered to the device.
All declaration items report Succeeded, including:
The device also reports:
However, once the deadline passes, nothing happens. The update never starts installing.
Devices meet all known requirements
We’ve verified the following:
Since these are Shared iPads, powered on, idle, and no user is signed in, we expected the OS update to automatically install after the target date. Instead, the devices remain in Prepared indefinitely.
Has anyone experienced this with DDM software updates on Shared iPads?
Is this a known Apple limitation, an Intune issue, or is there another prerequisite we’re missing?