Support tip: Troubleshoot device cap reached when enrolling devices into Microsoft Intune
By: Premkumar N – Security Customer Experience Engineer | Microsoft Intune When Microsoft Entra or Intune device limits are reached, users will encounter an error when enrolling their device into Intune. While it can be difficult to understand the reason for the failure from the error message, this blog will explain the differences between Microsoft Entra device registration limit and the Intune device enrollment limit, along with the steps to resolve these issues. For an overview of Microsoft Entra and Intune device limit scenarios refer to: Understand Intune and Microsoft Entra device limit restrictions. Let’s look at the experiences on different platforms, followed by the resolution steps. Android Intune device limit reached When the Intune device limit is reached, an Android device enrollment will fail with the following error: To diagnose the issue, review the Intune Company Portal logs for the affected device. Capturing Company Portal logs: Users can select "Email Support" from the error screen to send the logs via email or Send logs from Company Portal. If the Company Portal logs display the “Device Cap Reached” error as shown in the example logs below, this indicates that the Intune device limit has been reached. 2025-07-16T15:07:39.8410000 VERB o.zzafi 13923 6035 sending event: EnrollmentFailureEvent( networkState=CONNECTED, enrollmentFlowType=Enrollment, enrollmentType=AfwProfileOwner, failureName=DeviceEnrollmentFailure, errorException=com.microsoft.windowsintune.companyportal.exceptions.EnrollmentException: Server error = <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Body> <s:Fault> <s:Code> <s:Value>s:Receiver</s:Value> <s:Subcode> <s:Value>s:Authorization</s:Value> </s:Subcode> </s:Code> <s:Reason> <s:Text xml:lang="en-US">Device Cap Reached</s:Text> </s:Reason> <s:Detail> <DeviceEnrollmentServiceError xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"> <ErrorType>DeviceCapReached</ErrorType> <Message>Device Cap Reached</Message> <TraceId>xxx</TraceId> </DeviceEnrollmentServiceError> </s:Detail> </s:Fault> </s:Body> </s:Envelope>, errorMessage=, sessionGuid=xxx ) By default, Intune allows a maximum of 15 devices per user; exceeding this limit logs an error in the Company Portal. To address this issue, either remove inactive devices that have not checked in to Intune within a specified timeframe, or increase the device limit (up to 15) in the Intune settings. To remove stale devices: Navigate to the Microsoft Intune admin center > Devices > All Devices. Search using the affected user's UPN to view all enrolled devices. Remove any devices no longer in use. To increase the device limit: Navigate to the Microsoft Intune admin center > Devices > Enrollment > Device Limit Restrictions. Select the policy, go to Properties, then edit Device Limit, and adjust the limit (maximum 15). Note: If the Intune device limit is reached, errors are logged in the Microsoft Intune admin center under Devices > Monitor > Enrollment failures. Microsoft Entra device limit reached For Android, users will see the same error message when Microsoft Entra device limit has been reached. You can confirm the Microsoft Entra device limit has been reached by checking the Company Portal logs for the following error: com.microsoft.identity.broker4j.workplacejoin.exception.DrsErrorResponseException: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User 'xxx' is not eligible to enroll a device of type 'Android'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "xxx", "time": "xxx" } Similar to the Intune device limit reached, to resolve this issue either increase the device limit in Microsoft Entra for Microsoft Entra registration or remove any stale devices associated with the user in the Microsoft Entra admin center. Stale devices are those that are no longer active and can be removed when they haven’t checked in for a specified period. One cause of stale devices is deleting or retiring an Intune device, which may leave behind a record in Microsoft Entra and contribute to reaching the Microsoft Entra device registration limit. To remove stale devices: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Users. Search for the user using their UPN. Select Devices. This displays a list of registered devices for the user. Devices that are no longer in use can be removed. To increase the device limit for Microsoft Entra registration: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Devices. Select Device Settings. Locate Maximum number of Devices Per User. Adjust the device limit as needed. iOS Intune device limit reached For iOS, device enrollment may fail with the following error if the device limit has been reached. To check the issue, select 'Report and Email logs' to collect Company Portal logs. If the logs show the below error, it confirms the Intune device limit has been reached. 2025-07-18 12:38:33.427 | utility | 31673 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager The resolution is the same as Android, refer to the earlier steps for Intune device limit reached on Android. Microsoft Entra device limit reached On iOS devices, Intune enrollment may successfully complete; however, device registration may still result in an error as shown below in the Company Portal app. To collect Intune Company Portal logs, select More > Send logs > Email Logs. When you see the following error message in the Company Portal logs: iOSunderlyingErrorMessage: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Ios'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-07-16 14:07:23Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. macOS Intune device limit reached For macOS, device enrollment will fail with the following error when the Intune device limit has been reached. To identify the issue, collect the Company Portal logs by selecting 'Report' and then email the logs. In the logs, when you see the following error, this confirms the Intune device limit has been reached. 2025-07-25 07:39:23.731 | utility | 14262 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For macOS when enrolling into Intune, if the Microsoft Entra device limit has been reached, you’ll notice the following error: In the Company Portal logs, when you see the following error, this confirms the Microsoft Entra device limit has been reached. Description: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Mac'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-05-27 05:24:52Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Windows Intune device limit reached For Windows devices, enrollment will fail with the following error when Intune device limit has been reached: When you see this error, you can check the logs in the event viewer in this path: Source: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin Event ID: 71 MDM Enroll: Failed to receive or parse certificate enroll response. Result: The account has too many devices enrolled to Mobile Device Management (MDM). Delete or unenroll old devices to fix this error. To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For Windows, when the Microsoft Entra device limit has been reached, you’ll notice the following error during Intune enrollment: When you see this error, you can check the logs in the event viewer in this path: Windows Device Source: Microsoft-Windows-User Device Registration/Admin Event ID: 304 The get join response operation callback failed with: exit code: Unknown HResult Error code: 0x801c000e Activity Id: a0a15e15-631a-46ab-b0a4-2f540778df7d The server returned: HTTP status: 400 Server response: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User '8b000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Windows'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "a0000000-0000-0000-0000-000000000000", "time": "2025-05-30 15:33:09Z" } This is the result of the Microsoft Entra device limit reached for the user for Windows platform. To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Device limit reached – Windows Autopilot hybrid join scenario The Microsoft Entra device limit reached error will also occur when changing the primary user in Intune for Windows Autopilot Microsoft Entra hybrid joined devices). In the Autopilot hybrid join scenario there will be two device records in Azure. The Microsoft Entra hybrid join record, and the standard Microsoft Entra join record. Changing the primary user only updates the hybrid joined record in Microsoft Entra, leaving the original user as the owner of the Microsoft Entra join record. The owner entries on the Microsoft Entra join record will impact the device registration limit. Rather than removing the Microsoft Entra join device, which deletes its join state and is not a recommended approach, remove the registered owner on that record. Note: Deploying new devices as Microsoft Entra hybrid join devices isn’t recommended, for more details refer to Microsoft Entra joined vs. Microsoft Entra hybrid joined in cloud-native endpoints: Which option is right for your organization. The following image shows the device state after the Microsoft Entra hybrid joined deployment is completed. User1 enrolled a Microsoft Entra hybrid join device with Intune and Windows Autopilot and the registered user for both the records is ‘user1’. After changing the primary user in Intune to user2, only the Microsoft Entra hybrid joined record is updated for user2. The Microsoft Entra device registration usage for user1 remains unchanged for the Microsoft Entra joined record, both before and after modifying the primary user of the Intune device. This counts toward the Microsoft Entra registration limit for user1. Resolution Before proceeding with the resolution steps for this scenario, it’s important to note the difference between a registered owner and a registered user: Registered owner: A registered owner is the user that cloud joined the device or registered their personal device. The registered owner is set at the time of registration. Registered user: For cloud joined devices and registered personal devices, registered users are set to the same value as registered owners at the time of registration. Remove the registered owner This action can be done using PowerShell and Graph Explorer. Step 1. Check the user's device count in Microsoft Entra ID using Graph Explorer or PowerShell. PowerShell: This query lists the registered devices for the user. Install-Module Microsoft.graph Connect-MGgraph Get-MgUserRegisteredDevice -UserId <userID> Get-MgUserRegisteredOwner -UserId <userId> Sample from PowerShell: Graph Explorer queries: Owned devices for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/OwnedDevices Registered device for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/registeredDevices Sample Graph Explorer output: Only the "ID" in the output is needed to remove the device in next step. { "@odata.context": "******", "@microsoft.graph.tips": "******", "id": "00000000-0000-0000-0000-00000000", "deletedDateTime": null, "accountEnabled": true, "approximateLastSignInDateTime": "******", "complianceExpirationDateTime": null, "createdDateTime": "******", "deviceCategory": null, "deviceId": "******", "deviceMetadata": null, "deviceOwnership": "Company", "deviceVersion": 2, "displayName": "******", "domainName": null, "enrollmentProfileName": null, "enrollmentType": "AzureDomainJoined", "externalSourceName": null, "isCompliant": false, "isManaged": true, "isRooted": false, "managementType": "MDM", "manufacturer": "******", "mdmAppId": "******", "model": "******", "onPremisesLastSyncDateTime": null, "onPremisesSyncEnabled": null, "operatingSystem": "******", "operatingSystemVersion": "******", "physicalIds": [ "******", "******", "******", "******" ], "profileType": "RegisteredDevice" } Step 2. After confirming the user association for the device, remove both the registered owner and user for the Microsoft Entra joined device record to clear the user count toward the pre-defined limit. Graph API query: Replace the 'deviceid' in the following query with the 'id' from the Graph Explorer output from the previous step. Delete Registered Owner DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredowners/{user-id}/$ref Delete Registered User DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredusers/{user-id}/$ref This can also be done with PowerShell as below. PowerShell commands In the below commands DeviceID = Microsoft Entra Device ID/ObjectID. It’s important to remove both the registered owner and registered user for the device. Remove registered owner: Remove-mgdeviceregisteredownerDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: Remove registered user: Remove-mgdeviceregistereduserDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: PowerShell or Graph Explorer can also be used to delete the device in other scenarios such as Intune device deletion and Microsoft Entra device ID deletion. Summary Device enrollment can fail when either Intune or Microsoft Entra device limits are reached. These errors can be confusing, however, understanding the difference between Microsoft Entra device registration limits and Intune device enrollment limits makes it easier to sort out and resolve the issue. These issues commonly stem from stale device records, or changing the primary user of a Microsoft Entra hybrid joined device. Resolving them involves removing inactive devices or adjusting device limit policies in the appropriate service. As a best practice, avoid changing the primary user of the Microsoft Entra hybrid joined device and deploy the Windows Autopilot device to new users with a fresh start. Additional information on this topic can be found in the Microsoft Learn docs below: Device limit - Understand Intune and Microsoft Entra device limit restrictions List RegisteredDevices for user - List registeredDevices - Microsoft Graph v1.0 ListOwnedDevices for user - List ownedDevices - Microsoft Graph v1.0 Remove the registered owners for the device - Delete registeredOwners - Microsoft Graph v1.0 Remove the registered user for the device - List registeredUsers - Microsoft Graph v1.0 If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.Intune my Macs: Accelerating macOS proof of concepts with Microsoft Intune
By: Neil Johnson and Chris Kunze - Principal Product Managers | Microsoft Intune Intune provides a broad and mature set of capabilities for managing macOS devices across security, compliance, applications, and user onboarding. Many customers, however, aren’t always aware of just how much functionality is available or how to bring it all together. We've developed a starter kit to make it easy to explore and set up macOS configurations in Intune: Intune my Macs. Intune my Macs helps bridge that gap by making it easy to explore some recommended macOS configurations and quickly set up a successful proof of concept using Intune. What is Intune my Macs? Intune my Macs is an open-source project from the Microsoft Intune Customer Experience Engineering team that allows you to deploy a complete macOS proof of concept in minutes. This starter kit brings together over 31 enterprise-grade configurations—identified by Apple’s Mac Evaluation Utility—along with policies, scripts, and applications, all of which can be deployed using a single PowerShell script. The project operates in dry-run mode by default, letting you preview exactly what will be created before committing any changes to your Intune tenant. When you're ready, simply add the --apply flag to the command-line to commit changes. Important: From a support perspective, Microsoft fully supports Intune and its ability to deploy PowerShell scripts. However, Microsoft does not support the scripts themselves, even if they are on our GitHub repository. They’re provided for example only. You are responsible for anything that they may do within your environment. Always test! Why would you use it? 1. Jumpstart your macOS management Instead of building macOS configurations from scratch, Intune my Macs provides a ready-to-use baseline of production quality Intune artifacts. These configurations are designed to help you quickly evaluate Microsoft Intune for macOS management while also serving as reference implementations you can adapt to your environment. Below is an overview of what Intune my Macs deploys into your tenant, organized by category. Category Example configurations Security FileVault configuration, firewall enablement, Gatekeeper policies, Microsoft Edge policies Compliance Minimum macOS version (15.0), SIP enforcement, encryption requirements Identity Platform SSO via Secure Enclave with Microsoft Entra ID Applications Intune Company Portal, Microsoft 365, Remote Help, Intune Log Watch, Microsoft 365 Copilot, Windows App, and Edge Scripts Dock customization, FileVault key escrow (Escrow Buddy), onboarding automation Custom Attributes Hardware compatibility checks, Intune agent version reporting 2. Learn by example Each configuration in the repository serves as a practical reference implementation. The naming conventions follow a consistent pattern (for example, pol-sec-001-filevault, scr-app-100-install-company-portal), and detailed documentation explains what each setting does and why it's configured that way. 3. Reduce time to value Tasks that typically require extensive research, configuration, and testing can now be completed in just about 5 minutes, thanks to this streamlined approach. The script handles: Microsoft Graph SDK authentication Policy creation via Intune settings catalog and custom configuration profiles Script deployment with proper execution settings PKG application uploads Optional group assignments Optional Microsoft Defender for Endpointintegration If you're evaluating Microsoft Defender for Endpoint on macOS, the project includes an optional --mde command-line flag that deploys the full Defender for Endpoint configuration, including system extensions, privacy preferences, network filter settings, and a script that can be used to install the client . How it works This starter kit is driven by XML manifest files that define each configuration artifact. The main PowerShell script reads these manifests, resolves the associated JSON/mobileconfig/script files, and creates the corresponding objects in Intune via the Microsoft Graph API. You can scope this starter kit to specific artifact types using command-line flags like --apps, --config, --compliance, --scripts, or --custom-attributes. A custom naming prefix defined using the –prefix command-line flag) keeps your deployed objects easily identifiable, and the --remove-all command-line flag provides a clean way, based on the custom naming prefix, to delete everything created by an earlier run. For more information on how to use this project, be sure to review the prerequisites and instruction in the readme file. Bonus: Utility tools The project also includes several analysis and documentation tools: Export-MacOSConfigPolicies.ps1 - Back up existing Intune macOS policies to JSON Find-DuplicatePayloadSettings.ps1 - Detect conflicting settings across all your Mac configuration files Generate-ConfigurationDocumentation.py - Create Markdown or Word documentation from the manifests Get-IntuneAgentProcessingOrder.ps1 - Understand script and app processing sequence Get-MacOSGlobalAssignments.ps1 - List Mac policies assigned to All Devices or All Users Summary Intune my Macs isn't meant to be a one-size-fits-all production starter kit, but it’s a great way to get started. Use it to quickly implement a proof of concept, learn from the configuration patterns, and adapt the policies to your organization's specific requirements. Whether you're evaluating Intune for macOS management, setting up a new tenant, or just looking for reference implementations of common security configurations, this project can save you significant time and effort. Resources GitHub Repository Full Configuration Documentation Microsoft Defender for Endpoint Setup If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Support tip: Move to declarative device management for Apple software updates
By: Benjamin Flamm – Product Manager | Microsoft Intune Apple recently announced at the Worldwide Developer Conference (WWDC) in June 2025 that mobile device management (MDM) software updates are deprecated in the upcoming Apple OS 26 versions. Instead, software updates will need to use declarative device management (DDM). In this blog, we want to provide you with everything you need to know to navigate this transition and easily manage software updates in DDM. What is DDM? DDM is an enhancement to Apple’s device management protocol that makes devices more proactive and autonomous, and this is perfectly highlighted by the major improvements that DDM brings to managing software updates. Previously, Intune had to send update commands and repeatedly check for the update status. With DDM, Intune simply tells the device the required OS version and the installation deadline, while the device proactively updates Intune on its progress from download to installation. Move to DDM for software updates The MDM software update features in Intune will initially be marked as ‘deprecated’ in the Intune admin center and support will end shortly after Apple OS 26 releases. Devices will ignore MDM update settings when DDM update settings are being enforced, so the only steps you need to do are to create your DDM update policies using the settings catalog. The following table lists the MDM software update features that’ll be unsupported later this year, along with the matching DDM feature that is currently available or coming soon. Legacy MDM feature New DDM feature iOS/iPadOS update policies Software Update or Software Update Enforce Latest settings, located in the settings catalog under Declarative Device Management (DDM): macOS update policies iOS update installation failures report Apple software update failures (Devices > Monitor) which is expected to release with Intune’s August (2508) service release. macOS update installation failures report Software updates report (macOS per-device) macOS software updates (Devices > All devices, select a macOS device > macOS software updates) which is expected to release with Intune’s August (2508) service release. macOS Settings catalog > Software Update payload and settings Software Update Settings located in the settings catalog under Declarative Device Management (DDM): Settings in the iOS or macOS ‘Device restrictions’ template Settings catalog > Restrictions, software update delay settings How do I manage software updates using Intune? With Apple deprecating MDM software updates, DDM is the recommended method to manage software updates in your organization. For a thorough guide that highlights the differences between MDM and DDM, along with how to configure DDM software updates review: Managed software updates with the settings catalog. Useful resources Apple announcements: Announcement of DDM software updates at WWDC 2023 Introduction of Software Update Settings at WWDC 2024 Announcement of MDM update deprecation at WWDC 2025 Intune Apple settings catalog configuration list | Microsoft Learn Apple Platform Deployment guide for managing updates | Apple Support Stay tuned to this post for updates! If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. Updates: 7/25/2025: Updated the expected release timeline of the new per-device software update report for macOS.Apple making device migration to Microsoft Intune easy with upcoming OS 26 release
By: Iris Yuning Ye – Product Manager | Microsoft Intune Apple recently announced a major update at their Worldwide Developers Conference 2025 that solves one of the biggest headaches for admins: migrating macOS and iOS/iPadOS devices from one mobile device management (MDM) solution to another without factory resets, manual re-enrollment, or missing configurations. With the new MDM Migration capability in macOS 26 and iOS/iPadOS 26, built directly into Apple Business Manager, IT admins are able to transition devices from third-party MDMs to Microsoft Intune seamlessly, and without user disruption. Migrating devices to Intune helps IT admins consolidate device management across platforms, enforce consistent security policies, and reduce operational complexity. In this blog, learn how to start using Apple’s MDM migration feature to easily move your macOS and iOS/iPadOS fleet to Intune. Prerequisite: macOS/iOS/iPadOS 26 and enrollment into a device management service is required to use the Apple MDM migration feature. 1. Pre-migration – preparation and set up Before starting the migration process, there are five major steps to follow for preparation. 1.1 Keep a record of your devices Start by creating a detailed inventory of all devices in your organization. This should include each device model, the version of OS it’s running, and whether it’s corporate-owned or user-owned. This step is critical because Apple’s new migration feature has specific OS version requirements. Knowing which devices are eligible helps you scope the migration accurately and avoid surprises later. 1.2 Document configurations in current MDM Before making any changes, document all existing configurations in your current MDM platform. This includes: Configuration profiles: Capture all profiles related to Wi-Fi, VPN, email, and certificates. These are essential for maintaining connectivity and access post-migration. Compliance policies: Note any rules that enforce password complexity, encryption, or device health checks. Security baselines: Record settings such as FileVault encryption, Gatekeeper, and the macOS firewall to ensure security standards are preserved. Custom scripts: List any scripts used for automation, monitoring, or maintenance tasks. Deployed applications: Document all apps currently deployed, including how they’re delivered (Volume Purchase Program, App Store, or custom packages). This documentation will serve as your blueprint for rebuilding these configurations in Intune. 1.3 Configure the Apple MDM push certificate Navigate to the Intune admin center, create and upload an Apple MDM push certificate. This certificate allows Intune to securely communicate with Apple devices. Without it, device management and policy enforcement can’t function. 1.4 Add Microsoft Intune to Apple Business Manager (ABM) or Apple School Manager (ASM) Next, integrate Microsoft Intune with ABM or ASM, by following these steps: Download the public key from Intune. Upload that key to ABM or ASM when creating a new MDM server. Then, download the server token from ABM or ASM and upload it back into Intune. This allows ABM to recognize Intune as a valid MDM server and enables device assignment. 1.5 Set up MDM Configurations in Intune Since migration is treated as a new device enrollment, you'll need to follow standard Intune ADE (Automated Device Enrollment) guidance to setup device enrollment profile. Some key steps include: Once the device is in ABM/ASM, token that must be created to link Intune with ABM. Then, the device needs to sync from ABM to Intune. There is an automatic sync every 12 hours, or admin can manually sync once every 15 min. After successfully synced device from ABM to Intune, you need to create the enrollment profile, and then manually assign it to the devices via device serial number, and then the device can power on and enroll through that assigned enrollment profile Using the configurations documented in step 1.2, begin replicating existing configurations in Intune. This includes but is not limited to: Rebuilding configuration profiles for network access and security. Reapplying compliance and security policies. Re-deploying applications. Rewriting or importing scripts as needed. Identify the other controls to implement that improves Zero Trust. Call to action: Please make sure testing the MDM configurations on a test device before assigning them to the devices you plan on migrating. And before initiating any migration, communicate with your endpoint users first, keeping them informed to avoid any confusion. 2. Migration – Admin step-by-step flow The admin experience starts from ABM or ASM. After logging into ABM or ASM, navigate to the Devices section. Select the device or group of devices targeted for migration to Intune. Selecting the ellipsis on the top right of device overview interface unveils the “Assign Device Management” button. Select the server you want to migrate the device to. In our case, it’s Intune. Confirm device assignment. 3. Migration – Endpoint step-by-step flow After completing the device management assignment, the device user receives a notification informing them that a management change is required. macOS iOS/iPadOS When the user selects the notification, they are guided through a simple approval process. If the user doesn’t initiate enrollment before the admin set enrollment deadline, an enforced migration occurs, which results in a non-dismissible and full-screen prompt that must be completed by the user before using the device. Regular migration Enforced migration (past deadline) Once the user approves the migration, the device communicates with Apple’s servers to get its new device management assignment. It then downloads and installs the new MDM profile. This migration process happens without rebooting the device. 4. Post-migration – Verification Lastly, verify the migration and enrollment successfully completed by navigating to the Intune admin center and confirming the new devices are listed. evice. Please note, it's important to have test device verifying required configurations running smoothly before migrating large number of devices and test your devices after migration to ensure everything is working smoothly. If you run into any issues, further adjustments may be needed. Special thanks to our Intune MVP, Somesh Pathak, whose content we leveraged in this blog! For more details and a video demo, check out Somesh’s blog at: https://intuneirl.com/mac-admins-your-migration-glow-up-just-dropped Summary In short, Apple’s new MDM migration in macOS and iOS/iPadOS 26 makes moving Mac, iPhone or iPad devices to Intune now easier than ever. With careful planning and a few simple steps, you can make the switch smoothly to manage your Apple devices all in one place. For Mac devices that aren’t running OS 26, you can check out our Intune Github for migration scripts and review the blog Managing and migrating Macs with Microsoft Intune. Let us know how your Mac journey is going by leaving a comment below, reaching out to us on X @IntuneSuppTeam, or join our Mac Admins Community on LinkedIn! Post updates: 12/04/25: Updated section "1.5 Set up MDM Configurations in Intune". 12/11/25: Updated MDM Migration URL.
macOS enrollment - prompt to change the Mac login password
Cheers everyone! We are in the pilot phase of our macOS Intune enrollment and I've created the compliance policy which blocks simple passwords and applied this to a few test machines. After the 1st reboot I got a prompt to change the Admin password to meet the requirements. All worked fine until I've changed the "Maximum minutes of inactivity before password is required". After the first reboot, both local admin accounts (one, the IT admin, the 2nd of the actual user) get again a prompt that in order to login the password needs to be changed. Did the changes again and the story repeats itself after changing some other parameter (not something related to the actual password complexity) and ended up in the same loop. It looks like everytime I edit something in the Compliance profile, the user will be prompted to change his password, which doesn't make sense to me. Does anyone know why this is happening and how this behaviour can be changed? I don't want to enable "simple passwords" as just a workaround. Thank you in advance! 🙂Deploying macOS FileVault with Microsoft Intune
By: Marc Nahum – Senior Product Manager | Microsoft Intune FileVault is Apple's built-in disk encryption technology for macOS. To deploy FileVault securely and effectively in an enterprise setting, it requires a deeper understanding. Originally launched in 2005 with Mac OS X 10.3 Panther, FileVault has evolved significantly. The release of FileVault 2 in 2011 with Mac OS X Lion marked a major upgrade. Since then, Apple has continued to improve its capabilities. For example, macOS Sequoia now supports unlocking FileVault using Microsoft Entra ID credentials through Platform SSO. In this blog, you'll learn how to: Enable FileVault for macOS using Microsoft Intune Use and manage recovery keys Manually import FileVault recovery keys into Intune Troubleshoot FileVault issues during device migration to Intune Although FileVault has been around for nearly 20 years, much of the guidance available online is outdated or based on older versions of macOS. This blog focuses on current best practices for enterprise deployment, specifically for: Devices running macOS Sonoma (version 14) or later Apple silicon hardware Microsoft Intune as the mobile device management (MDM) solution for policy enforcement and recovery key escrow Legacy methods, such as Institutional Recovery Keys, are now considered obsolete and won’t be covered. Instead, we focus on building a modern, secure, and maintainable FileVault deployment strategy. Are recent Mac devices encrypted by default? Yes. Apple silicon Macs,and Intel-based Macs with a T2 Security Chip, are encrypted by default at the hardware level. This encryption uses a unique identifier stored in the Secure Enclave. However, the encryption becomes user-aware and policy-enforceable only when FileVault is enabled. Once activated, FileVault enhances security by linking the encryption to the user’s login password in addition to the hardware-based key. This ensures that access to the data requires proper user authentication. Apple provides detailed information on this process in their Apple Platform Security Guide. Enabling FileVault with Intune FileVault is a key component of macOS security and should be considered a mandatory requirement for organizations except where local laws explicitly prevent it. Intune offers several ways to configure FileVault, but the settings catalog is the recommended approach. It helps avoid policy conflicts and ensures consistent, reliable behavior across devices. It’s also the most future-proof method, as it aligns with ongoing platform and Intune updates. 📋 Steps to configure FileVault via settings catalog Login tothe Microsoft Intune admin center Navigate to Devices > macOS Create a new configuration profile: Profile type: Settings Catalog Name the profile and provide a clear description In the Settings Picker, locate Full Disk Encryption and configure the following in the subsections FileVault Defer → Enabled Enable → On (default) Force Enable In Setup Assistant → True Recovery Key Rotation in Months → (e.g., 6 months) FileVault Options Prevent FileVault From Being Disabled → True FileVault Recovery Key Escrow Location → Your Enterprise Name Note: The Defer setting was mandatory in certain versions of macOS. While this might not be required in the latest releases, it’s still recommended to enable it for added security and a more predictable user experience. Proceed through Scope tags and Assignments. It’s recommended to assign the profile to All devices (interpreted here as “all Macs”), use filters if needed. The usage of static groups of devices is also an option but dynamic device groups are not compatible with the “Force Enable In Setup Assistant” option, which is needed for enforcing encryption during the setup assistant without user intervention. If you’re using Platform SSO with Password synchronization you can use the FileVault Policy setting to force the device, connected to the network, to check Microsoft Entra ID password when a device is turned back on (macOS 15 and later). This setting can be found in the setting catalog under Authentication / Extensible Single Sign On (SSO) / Platform SSO And must be set to: AttemptAuthentication Refer to this article to properly configure Platform SSO and select the method to use it: Configure Platform SSO for macOS devices in Microsoft Intune. Once the profile is deployed and the device receives the configuration, FileVault will be activated and the recovery key securely escrowed in Intune. The key is stored in the device properties, Recovery Keys section and is accessible only to admins with proper role-based access. All access is audited. If the device is set as “Personal” in Intune, the recovery key will not be visible in the admin center. Enrolled with Automated Device Enrollment with the device in Apple Business Manager Enrolled from Intune Company Portal as a bring-your-own device In cases where FileVault isn’t enabled during Setup Assistant, such as in bring-your-own-device (BYOD) scenarios using the Intune Company Portal, the same policy will trigger FileVault activation after the next reboot, prompting the user to take the necessary actions. Using the FileVault recovery key The FileVault recovery key serves as a secure fallback for users who forget their login password. When used properly, it allows access to the Mac without requiring a password reset or device re-enrollment. While Apple documents the recovery key process on their support site, one useful detail is often overlooked: If the ”?” icon doesn’t appear on the Mac login screen, users can select Shift + Option + Return to manually bring up the recovery key prompt. This can be particularly helpful during support scenarios where the user is locked out, but the device is still enrolled and reachable via Intune. At this stage, the Mac has completed booting and can still receive remote commands such as running scripts or executing device actions. Manually escrowing an existing recovery key If FileVault is already enabled on a Mac before it’s enrolled in Intune, users can manually escrow their personal recovery key using the Intune Company Portal. This is especially useful in bring-your-own-device (BYOD) scenarios or in loosely managed enrollment flows, where FileVault may have been activated outside of the IT admins control. Steps to import the recovery key: Verify FileVault status Launch Terminal and run: fdesetup status This confirms whether FileVault is currently enabled. Rotate and display the recovery key Run the following command to generate a new personal recovery key: sudo fdesetup changerecovery -personal The user must have administrator privileges to execute this command. Upload the recovery key to Intune using the Company Portal website. Open a browser and navigate to: https://portal.manage.microsoft.com Select the corresponding Mac device (if prompted) Choose “Store Recovery Key” and paste the new key from the Terminal output On the same page, users can also retrieve an existing recovery key if it has already been escrowed. This manual method ensures that devices encrypted outside the MDM provisioning flow can still benefit from secure recovery key escrow and retrieval through Intune. Migrating to Intune A common challenge when migrating to Intune from another MDM is that FileVault may already be enabled. Aside from the manual steps, organization’s might consider another approach which is to automate the escrow of existing recovery keys using tools like Escrow Buddy, an open-source tool developed by Netflix. For all considerations of migrating to Intune we wrote another blog on it: aka.ms/Intune/mac-migration. Reach out for help If you’re interested in learning more about FileVault and other Mac scenarios, there are a couple more things you can do. Join our Microsoft Mac Admins community on LinkedIn. Our product teams are there, plus thousands of others who’re using Intune to manage their Apple devices in a Microsoft Enterprise environment. If you have a question about Microsoft and Mac, someone in this community will likely have the answer. If you have 150 Microsoft 365 licenses or more, you can also Request FastTrack assistance. Our FastTrack team are experts at helping our customers make the most of their investment in Microsoft technologies. Lastly, if you’re looking for a deeper engagement, consider finding a Microsoft partner to support your migration needs. If you have any questions or want to share how you’re managing and migrating your Apple macOS devices in Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn: aka.ms/IntuneLinked.
Is it possible to restrict/allow specific Bluetooth services on macOS via Intune MDM?
I’m exploring whether it's possible to allow only certain Bluetooth services — for example, allow HID (keyboard/mouse) and A2DP (audio), but block OBEX (file transfer), PAN (Personal Area Networking), BPP (Basic Printing Profile), BIP (Basic Imaging Profile), etc. On Windows, we can achieve this via Intune using Bluetooth service GUID filtering, but I couldn’t find an equivalent method for macOS. Does Intune support the following on macOS: Restricting or filtering Bluetooth services or profiles individually? Controlling OBEX, SPP, A2DP, HSP, or HID over Bluetooth? Any workaround using scripts, configuration profiles, or TCC/PPPC settings? If anyone has experience with this or knows if it's not supported, I’d really appreciate your input — along with any relevant documentation from Apple or Microsoft as reference. Thanks in advance!Support tip: Troubleshooting Microsoft Intune management agent on macOS
By: Chris Kunze – Principal Product Manager | Microsoft Intune The Microsoft Intune management agent for macOS is a crucial part of deploying and managing applications and scripts through Intune. It manages running scripts and installing apps of types macOS app (DMG) and macOS app (PKG). The following questions will help you verify if your Intune management gent is installed, operational, and functioning properly. Is the agent installed? The Intune management agent, displayed as Microsoft Intune Agent on a device, is installed when scripts or apps requiring the agent are assigned. This is usually at device enrollment since the agent installs immediately after the device receives the Intune management profile. Once installed, you can find the agent at /Library/Intune/Microsoft Intune Agent.app. You can also check the version of the client installed by right clicking the file and selecting 'Get Info'. A screenshot of the Microsoft Intune agent information. Are the agent processes running? There are two processes that should run once the agent installs: IntuneMdmDaemon: Responsible for PKG, DMG, and running scripts as root. IntuneMdmAgent: Responsible for running scripts as user. You can use the following command in Terminal to determine if the processes are running: pgrep -il "^IntuneMdm" If it’s determined that the processes aren’t running, they can be restarted by launching the Microsoft Intune Agent.app. Are logs being generated? The transaction logs for the Microsoft Intune Agent start with IntuneMDMDaemon and are found at /Library/Logs/Microsoft/Intune. If the transaction logs aren’t being generated, and the Microsoft Intune Agent is installed, ensure that scripts or PKG or DMG apps are assigned to the device. If the transaction logs aren’t being generated, and the Microsoft Intune Agent is installed, ensure that scripts or PKG or DMG apps are assigned to the device. What is shown in the logs? The IntuneMDMDaemon logs are broken up into 6 columns of data delimited by a pipe character (|). Each log line provides the following information: Date and time of the log Process (IntuneMDM-Daemon) Log level (Information, Warning, and Error) Process ID Task that wrote the log Task information Note: The logs in this blog were collected on different days and times and may not align perfectly between sections. A screenshot of the agents logs for the IntuneMDMDaemon process. Did the app install? If you're troubleshooting a specific app that isn't installing correctly, start by searching or filtering the log using the app ID or app name. The app ID is typically the most reliable identifier, as it consistently marks log entries related to that app. You can discover an app’s ID in the logs or in the URL of the app in the Microsoft Intune admin center. For example, in the screenshot below, the highlighted section of the URL in the address bar represents the app ID of the sample app shown. A screenshot of the Microsoft Intune admin center, highlighting the app ID displayed in the URL. You can also retrieve the app ID (displayed as the PolicyID) from the logs themselves by searching for the app name as in the following example log line: 2025-06-13 10:04:02:924 | IntuneMDM-Daemon | I | 10429 | AppDetector | Detecting app with specific bundle ID. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true The Microsoft Intune Agent detects if an app is installed on the device two ways: Is the bundle ID returned from a Spotlight Search? Is there a package receipt? To manually check for bundle ID and package receipt, use the following Terminal commands. Spotlight Search test Note: This command is case sensitive so pay special attention to the case of the bundle ID. mdfind "kMDItemCFBundleIdentifier == '{bundleid}'" A screenshot of the output of the mdfind command run in Terminal. Package receipt test Use pkgutil in Terminal to check if the package is installed. pkgutil --pkg-info {bundleid} A screenshot of the output of the pkgutil command run in Terminal. If your app or script isn't in the logs, check its assignment in the Intune admin center. Log entries will show reasons for any installation failures. When did the agent start? Each time the agent starts, a full sync will be kicked off and you’ll see the following line in the logs: 2025-06-13 10:03:59:892 | IntuneMDM-Daemon | I | 10426 | SidecarDaemonLifecycleManager | Initializing service. This line is added to the current log whenever the agent starts or restarts—whether due to a system reboot, the agent process being terminated, or an update being applied. Missing device ID and tenant ID? After enrollment, the first time the Microsoft Intune Agent runs, the logs will return these two lines: 2025-06-13 10:03:59:893 | IntuneMDM-Daemon | W | 10432 | TreatmentProvider | Missing device ID 2025-06-13 10:03:59:893 | IntuneMDM-Daemon | W | 10432 | TreatmentProvider | Missing tenant ID This occurs because the agent doesn’t have the device or tenant ID yet, so it requests these details from the gateway. After the information has been collected, your logs will have something similar to these lines: 2025-06-13 10:04:01:415 | IntuneMDM-Daemon | I | 10434 | VerifyEnrollmentStatus | Successfully verified MDM server info. URL: https://i.manage.microsoft.com/DeviceGatewayProxy/ioshandler.ashx?Platform=MacMDM 2025-06-13 10:04:01:415 | IntuneMDM-Daemon | I | 10434 | VerifyEnrollmentStatus | Successfully verified device status. DeviceId: 04674b8c-69b5-4450-b4dc-82a8c0025d18, OSVersionActual: 15.5.0, Version: 2506.002, VersionInstalled: 2506.002 2025-06-13 10:04:01:415 | IntuneMDM-Daemon | I | 10434 | VerifyEnrollmentStatus | Successfully verified enrollment status. Environment: PROD, Region: NA, ASU: AMSUA0602, MSU: MSUA06, AccountID: 691617c5-0000-0000-0000-000000000000, AADTenantID: c53fda5f-0000-0000-0000-000000000000 What is the HealthCheckWorkflow? The Microsoft Intune agent has a heartbeat that runs about every minute to verify the status of the agent and connection to Intune. If the agent is running properly, the following two log lines will represent this heartbeat: 2025-06-13 10:03:59:893 | IntuneMDM-Daemon | I | 10432 | HealthCheckWorkflow | Starting health check Domain: pulse 2025-06-13 10:03:59:901 | IntuneMDM-Daemon | I | 10426 | HealthCheckWorkflow | Completed health check Domain: pulse What policies are installed? You can see what policies are installed by the Microsoft Intune Agent in the logs. A line similar to the one below lists the policy IDs for the policies: 2025-06-13 10:04:02:923 | IntuneMDM-Daemon | I | 10435 | SyncActivityTracer | Validating data Context: apply mac app policies, Count: 4, PolicyID: ["14f79200-7c53-48ed-8d8e-287ae52a9c82", "c76df059-7bc6-468c-956d-56cf63a59888", "cc2af15f-9ed6-4c65-89bd-bc203031803f", "f6b5b5bd-9e87-42fc-94f8-31a2bc4bc255"] This list includes all Microsoft Intune Agent policies, including PKGs, DMGs, and shell scripts. If the policy ID isn’t listed for the app you want installed or script you want to run, it’s likely that itisn’t assigned properly. What will I see when a required app installs? When a device is notified of an app to install, the logs show the following. Determine intent for Required app: 2025-06-13 10:04:02:924 | IntuneMDM-Daemon | I | 10429 | AppPolicyHandler | Handling app policy. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, Primary BundleID: com.intune.AddScripts, IgnoreVersion: true, Count: 1, AppType: PKG, App Policy Intent: RequiredInstall Detecting app: 2025-06-13 10:04:02:924 | IntuneMDM-Daemon | I | 10429 | AppDetector | Detecting app with specific bundle ID. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true Detecting app by path: 2025-06-13 10:04:02:978 | IntuneMDM-Daemon | W | 10431 | AppDetector | Error detecting install path for app. Error: BundleInfoProviderError.bundleNotFound, PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, AppType: PKG, BundleID: com.intune.AddScripts, IgnoreVersion: true App not found by path: 2025-06-13 10:04:02:978 | IntuneMDM-Daemon | I | 10431 | AppDetector | App not found on disk, trying to detect app receipt PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true Detecting app by receipt (bundle ID): 2025-06-13 10:04:02:978 | IntuneMDM-Daemon | I | 10431 | AppDetector | App not found on disk, trying to detect app receipt PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true App receipt not found: 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | AppDetector | Receipt not detected in receipt library, install app PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | AppDetector | App with specific bundle ID is NOT installed on the device. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts, AppType: PKG, IgnoreVersion: true Need to install app: 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | AppInstallManager | App policy execution plan: Install PKG app [CK] Add Scripts PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, AppType: PKG, BundleID: com.intune.AddScripts Starting app install: 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | AppInstallManager | Starting app installation for mac app policy. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, AppType: PKG, BundleID: com.intune.AddScripts Download app: 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | AppBinaryDownloader | Start app content info metadata download PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts 2025-06-13 10:04:03:064 | IntuneMDM-Daemon | I | 10429 | SidecarService | Getting mac app content info from GW PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts 2025-06-13 10:04:03:788 | IntuneMDM-Daemon | I | 10432 | AppBinaryDownloader | Starting app binary download for mac app policy. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, Size: 2948.0 2025-06-13 10:04:03:812 | IntuneMDM-Daemon | I | 10432 | AppBinaryDownloader | Attempt 1 of 3 to download app binary. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts 2025-06-13 10:04:03:817 | IntuneMDM-Daemon | I | *10417 | HttpClientLogger | Network request succeeded. Method: PUT, StatusCode: 200, Description: ok, URL: https://agents.amsua0602.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService/SideCarGatewaySessions('7EFAA5B2-ADA9-4422-A55C-A2A08FBB6655')?api-version=1.1, ClientRequestId: 7665A5F1-3E11-406E-910B-715EE3231BD1 2025-06-13 10:04:03:943 | IntuneMDM-Daemon | I | 10427 | AppBinaryDownloader | Successfully downloaded app binary content. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, BundleID: com.intune.AddScripts Decrypt content: 2025-06-13 10:04:03:943 | IntuneMDM-Daemon | I | 10427 | AppInstallManager | Starting app binary decryption for mac app policy. PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, AppType: PKG, BundleID: com.intune.AddScripts Install Required app: 2025-06-13 10:04:03:945 | IntuneMDM-Daemon | I | 10427 | AppInstallManager | Install required for app PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, AppType: PKG, BundleID: com.intune.AddScripts 2025-06-13 10:04:03:945 | IntuneMDM-Daemon | I | 10427 | PkgInstaller | Starting PKG app installation PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, BundleID: com.intune.AddScripts, AppName: [CK] Add Scripts 2025-06-13 10:04:03:945 | IntuneMDM-Daemon | I | 10427 | ScriptOrchestrationLogger | Running system script. Domain: apps, User: root, PolicyID: c76df059-7bc6-468c-956d-56cf63a59888 Successful app install: 2025-06-13 10:04:05:362 | IntuneMDM-Daemon | I | 10551 | PkgInstaller | Successful PKG installation - installer completed with success status PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, BundleID: com.intune.AddScripts, AppName: [CK] Add Scripts 2025-06-13 10:04:05:363 | IntuneMDM-Daemon | I | 10551 | AppInstallManager | Successfully installed all apps PolicyID: c76df059-7bc6-468c-956d-56cf63a59888, AppName: [CK] Add Scripts, ComplianceState: Installed, EnforcementState: Success, Product Version (BundleID of primary app): 1.0, Primary BundleID: com.intune.AddScripts 2025-06-13 10:04:05:363 | IntuneMDM-Daemon | I | 10551 | ExecutionClock | Policy measurement. ID: c76df059-7bc6-468c-956d-56cf63a59888, Context: macAppInstall, Duration: 2.4395320415496826, Status: success If your logs diverge from the above, be sure that the app is assigned properly and all the correct endpoints are reachable by the client system. What do I see when an available app installs? Available app installs are very similar to required app installs. The main difference is that no detection is run prior to installing the app. In addition, the log lines that show the determined intent and installation are slightly different. Determine intent for Available app: 2025-06-18 12:52:38:693 | IntuneMDM-Daemon | I | 27013 | AppPolicyHandler | Handling app policy. PolicyID: 69045d7b-4e79-464b-bff6-3d4908f303f3, Primary BundleID: com.intune.TestScript, IgnoreVersion: true, Count: 1, AppType: PKG, App Policy Intent: Available Install Available app: 2025-06-18 12:52:38:693 | IntuneMDM-Daemon | I | 27013 | AppInstallManager | Available app install, skipping detection PolicyID: 69045d7b-4e79-464b-bff6-3d4908f303f3, AppName: [CK] Test Script, AppType: PKG, BundleID: com.intune.TestScript 2025-06-18 12:52:38:693 | IntuneMDM-Daemon | I | 27013 | AppInstallManager | Install required for app PolicyID: 69045d7b-4e79-464b-bff6-3d4908f303f3, AppName: [CK] Test Script, AppType: PKG, BundleID: com.intune.TestScript What do I see when a script runs? Scripts and their execution are also captured in the logs. Since you can only assign scripts as required, no intent is determined. Unless you schedule a script to run on a recurring basis, scripts will only run once on a Mac. Script to run 2025-06-18 13:12:38:188 | IntuneMDM-Daemon | I | 8303 | ScriptPolicyRunner | Running ad-hoc script policy PolicyID: b9b4b299-9a36-40bf-b43a-db295ee49dd6, ExecutionContext: root, ExecutionFrequency: 0, RetryCount: 3, BlockExecutionNotifications: true Starting script 2025-06-18 13:12:38:235 | IntuneMDM-Daemon | I | 5355 | ScriptOrchestrationLogger | Running management script. Domain: policy, User: root, PolicyID: b9b4b299-9a36-40bf-b43a-db295ee49dd6 Completing script 2025-06-18 13:12:43:949 | IntuneMDM-Daemon | I | 5355 | ScriptOrchestrationLogger | Finished management script. Domain: policy, User: root, PolicyID: b9b4b299-9a36-40bf-b43a-db295ee49dd6 Script run status 2025-06-18 13:12:43:950 | IntuneMDM-Daemon | I | 5355 | ScriptPolicyRunner | Ad-hoc script policy ran PolicyID: b9b4b299-9a36-40bf-b43a-db295ee49dd6, TotalRetries: 0, Status: Success, ExitCode: 0 How long did it take to run? 2025-06-18 13:12:43:950 | IntuneMDM-Daemon | I | 5355 | ExecutionClock | Policy measurement. ID: b9b4b299-9a36-40bf-b43a-db295ee49dd6, Context: shellScript, Duration: 5.769531011581421, Status: success Already run script 2025-06-18 13:13:28:232 | IntuneMDM-Daemon | I | 11413 | AdHocScriptProcessor | Not running script policy because this policy has already been run. PolicyID: b9b4b299-9a36-40bf-b43a-db295ee49dd6 When you assign a script to a device, the install configuration is also sent to the device. The configuration for this is also listed in the log and an example is included above in the “Script to run” bullet. The following table shows the mapping of settings from the Intune admin center for a script to the values shown in the log for this type of log line. Value in Intune Representation in logs Run script as signed-in user ExecutionContext Hide script notifications on devices ExecutionFrequency Script frequency RetryCount Max number of times to retry if script fails BlockExecutionNotifications Conclusion The Microsoft Intune Agent for macOS is a critical part of Mac management in Intune as it’s responsible for running shell scripts and installing both PKG and DMG types of macOS apps. This blog discussed how to access the logs for the macOS Microsoft Intune management agent, what is collected, how to read, and understand the logs to determine what apps were installed and what scripts were ran. Resources Here are some additional resources to help with your macOS management journey with Intune. Understanding Microsoft Intune management agent for macOS Add an unmanaged macOS PKG app to Microsoft Intune Add a macOS DMG app to Microsoft Intune Use shell scripts on macOS devices in Microsoft Intune Network endpoints for Microsoft Intune If you have any questions or want to share how you’re managing your macOS devices with Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn.
