Troubleshooting Common macOS App Deployment Issues in Intune
Struggling with macOS app deployment in Intune? This comprehensive guide covers common Intune error codes (0x87D13B67, 0x87D13BA2, etc.), troubleshooting installation failures, app detection errors, code signing issues, MDM profile problems, and configuration mistakes. Learn step-by-step how to fix Intune Mac app installation failures for apps like Google Chrome, Zoom, and Adobe, including log file locations and key commands for IT admins.
Microsoft Intune provides powerful tools to deploy applications to macOS devices, but deployments don't always go smoothly. IT administrators often encounter installation failures, detection issues, code signing errors, MDM profile problems, or other misconfigurations when managing Mac apps via Intune. In this guide, we'll explore the most common macOS app deployment issues in Intune and how to troubleshoot them. We include common Intune error codes and their meanings, real-world examples (Google Chrome, Zoom, Adobe apps), and step-by-step instructions to diagnose and fix problems. By the end, you'll have a clear, actionable approach to tackle Mac app deployment errors in Intune.
Understanding Intune's error codes is a great first step in diagnosing app deployment issues. Here are some common error codes you might see for macOS app installs, along with what they typically mean:
0x87D13B67 – The app state is unknown: Intune cannot determine the install status of the app. This often indicates the Intune agent didn't receive confirmation of success or failure. It can happen due to packaging issues or communication hiccups.
0x87D13BA2 – One or more apps contain invalid bundle IDs: Intune reports that included app identifiers in the package don't match what's on the device. This usually occurs when a macOS package contains multiple app bundles and Intune thinks some are missing or unrecognized (for example, Microsoft Teams with its updater component).
0x87D13B66 – The app is managed, but has been removed by the user: This error means Intune installed the app, but a user or process later uninstalled it. The app is marked as Failed in Intune because it's no longer present on the device.
0x87D13B64 – The app install has failed: A generic installation failure. This can appear for many reasons (signature issues, compatibility problems, etc.) when a Mac fails to install the pushed package.
0x87D13B65 – The device is redeeming the redemption code: Seen with App Store (VPP) apps, it indicates the device is attempting to redeem a VPP license or App Store redemption code. The install is pending that process.
0x87D13B63 / 0x87D13B62 – The user rejected the offer to update/install: These mean the user declined an update or install prompt for an app. (Note: On macOS, direct user prompts are rare for managed installs, but these codes might appear for VPP apps or if user interaction was needed.)
Knowing these codes and messages helps focus your troubleshooting. Next, we'll dive into specific categories of issues and how to resolve them.
When an app fails to install on macOS via Intune, follow these step-by-step troubleshooting methods:
Check Intune Status and Error Details: In the Intune admin center, navigate to Apps > macOS and check the Device install status for the app and device. Note the Status (e.g. Failed) and Status Details (error message/code) for clues. For example, a status detail might say "The app install has failed (0x87D13B64)" or another code from the list above. This gives you a starting point on what went wrong.
Verify Device Enrollment and Connectivity: Ensure the Mac is properly enrolled in Intune and connected:
On the Mac, open the Company Portal app and verify the device shows as managed/compliant. If the Company Portal or management profile isn't present, the device may not be fully enrolled.
Check System Settings > Profiles (or System Preferences > Profiles on older macOS) to see that the Intune MDM profile is installed and not showing errors. If the MDM profile is missing or not approved, the device will not receive app installation commands.
In Company Portal, use the Sync or Check status option to force an Intune check-in (the Company Portal's three-dot menu offers a sync). This can trigger any pending app installations and update status.
Ensure the Intune Management Agent is Installed: Intune uses the Intune Management Extension (IME) (also called IntuneMDMAgent or "Sidecar") to install apps on macOS. This agent should install automatically when an app or script is deployed. On the Mac:
Confirm the agent is present at /Library/Intune/Microsoft Intune Agent.app. You can also check Activity Monitor for IntuneMdmAgent and IntuneMdmDaemon processes.
If the agent is missing, try assigning a macOS Shell Script or another app to the device to force the IME to install, or re-enroll the device. Without the agent, LOB app deployments won't run.
Verify the Installer Package Format: Intune supports deploying .pkg installer files for macOS apps. If you have a .dmg or raw .app, it needs to be repackaged:
Use a PKG installer: Intune only accepts .pkg files for macOS LOB apps. If the software comes as a DMG or App bundle, convert it to a signed PKG (for example, using a packaging tool or the vendor's installer).
Ensure the .pkg is a component package or product archive (not just a bundle). The .pkg should actually install files to the system, not simply contain an app file.
The package should have the correct installation location (typically /Applications). If a .pkg's internal metadata doesn't specify a valid install location, Intune may silently fail to deploy it.
Check Code Signing of the Package: A very common issue for failed installations is an improperly signed package. macOS requires that Intune LOB app packages be signed with an Apple Developer ID Installer certificate. Troubleshoot as follows:
Is the PKG signed? On a Mac, run pkgutil --check-signature /path/to/YourApp.pkg. This will show if the package is signed and by which certificate. If it says "Status: signed by Developer ID" it's good. If not, or it's signed with an unknown cert (or says "no signature"), that's a problem.
Use a Developer ID Installer cert: Intune documentation and best practices state that the *.pkg file must be signed with a Developer ID Installer certificate from an Apple Developer account. If you built the package yourself (e.g., via a tool like Packages or productbuild), be sure to sign it with your Developer ID. Unsigned or adhoc-signed packages will be rejected by macOS during MDM install.
Re-sign if necessary: If you discover the package is not properly signed, you can sign it retrospectively using the productsign command with your Developer ID Installer certificate. For example: productsign --sign "Developer ID Installer: Your Name (TeamID)" Input.pkg OutputSigned.pkg.
Notarization: Apple's Gatekeeper requires apps (and installers) to be notarized for user downloads, but for MDM-delivered packages, notarization is not strictly required as long as they are Developer ID signed. However, it's still a good practice to notarize to avoid any future macOS restrictions. If your package isn't notarized, macOS might still install it via Intune silently, but if you see Gatekeeper/quarantine issues, notarization could help.
Check for macOS Compatibility (OS Version & Architecture): Intune lets you specify a minimum OS version for the app. If the Mac's OS is below that, Intune will not install the app. Verify the Requirements you set for the app in Intune (e.g., macOS 11+). Adjust or upgrade the OS as needed.
Also consider CPU architecture:
If deploying to Apple Silicon (M1/M2) Macs, ensure the app is a Universal or ARM build. Deploying an Intel-only app to an M1 without Rosetta 2 will fail or hang. If you only have an Intel version, install Rosetta 2 on the Mac to enable translation. You can deploy a script via Intune to install Rosetta (e.g. softwareupdate --install-rosetta --agree-to-license) before installing the app.
Conversely, if an app is very old and 32-bit (unlikely for modern macOS deployments), it won't install on Catalina or later at all. In such cases, find an updated version of the app compatible with current macOS.
Examine Installation Logs on the Mac: For deeper insight, review the local logs during the installation attempt:
Intune Agent Logs: Open the log files at /Library/Logs/Microsoft/Intune/. Key files include IntuneMDMDaemon[datetime].log and IntuneMDMAgent[datetime].log. These logs record the Intune agent's activities. Look for entries related to your app name or phrases like "InstallApplication" or "error" around the time of deployment.
System Logs: You can use the macOS Console app or Terminal's log show command to find MDM installation events. For example, run:
to attempt a manual install. This won't use Intune, but if it fails it may print a specific error (like an OS requirement or a script error inside the pkg).
Company Portal Logs: If the Company Portal app was involved (for user-available apps), its log is at ~/Library/Logs/CompanyPortal.log. This can show if the user triggered an install and if anything obvious went wrong.
Common Causes for Install Failure: From the above steps, you might identify specific causes:
Signature Errors: The install logs might show the package was rejected due to an invalid signature or "unidentified developer." In that case, fix the code signing as discussed.
Permission or Profile Errors: If the MDM profile wasn't approved or there are Keychain permission issues, the MDM agent might not have permission to install software. For example, a stale management certificate could cause trust failures. In such cases, re-enrolling the device or clearing the device's old management credentials (as per Intune docs) might be necessary.
No Payload: Intune will repeatedly try to install a pkg that has no payload (nothing actually installs). If you accidentally deployed a placeholder package, it will "succeed" with nothing and then attempt again endlessly. Repackage the app with actual content.
By systematically checking these factors – Intune status, device enrollment, package format and signing, OS compatibility, and logs – you can usually pinpoint why an installation failed. Next, we'll look at cases where the installation did succeed on the Mac, but Intune still reports an issue (detection problems).
Sometimes an app does install correctly on the Mac, but Intune shows a failure or unknown status. These app detection issues can lead to confusion and repeated deployment attempts. Here's how to diagnose and fix detection problems:
Understand Intune's Detection Logic: When deploying a macOS LOB app, Intune keeps track of what apps (bundle IDs and versions) the installer is supposed to put on the system. In the Intune app configuration, there is an Included apps list with app bundle IDs and versions that the PKG is expected to install. Intune uses this list to verify installation. If Intune doesn't find all of those app bundle IDs on the device post-install, it will not mark the deployment as successful. This can result in errors like "invalid bundleIDs (0x87D13BA2)" even if the main app is installed.
Error 0x87D13BA2 – Invalid Bundle IDs: This error is a prime example of detection issues. It often occurs with apps that have multiple components. Microsoft Teams is a real-world example: its installer deploys the Teams app and a couple of support apps (like an updater). If Intune's Included apps list contains both "Microsoft Teams" and the updater, but one of those isn't properly reported back, Intune throws 0x87D13BA2. How to fix: Edit the app in Intune to remove any extra bundle IDs that aren't essential. Intune only needs to track one app from the package to consider it installed. Keeping the list to a single primary app (e.g., the main .app bundle) avoids false failures. In the Teams case, removing the secondary app IDs from the Intune app configuration resolves the error.
Use the Mac to List Installed Apps: To figure out which bundle IDs and versions are actually present on the Mac, use the built-in MDM client command. On the affected Mac, open Terminal and run:
This command queries the device's managed app inventory and outputs it to a text file. Open the InstalledApps.txt file and find your application. You'll see the Identifier (bundle ID) and Version of each installed app that macOS reports. Compare this with Intune's expected list:
If Intune expects a bundle ID that you do not see in the file, that's the culprit – Intune thinks something should be there that isn't.
Remove or correct any such entries in Intune's Included apps list for that app, then re-sync the device and check if Intune now shows the app as installed.
Included Apps Best Practices: When adding a macOS app in Intune, carefully review the Included apps section:
Only list the actual app bundle(s) that will be installed by your PKG. Do not include helper tools, uninstallers, or other files that aren't application bundles – including those can confuse Intune.
If the installer has multiple app bundles but you only care about the main app, you can remove the others from the list. Intune will then just look for the main app's presence to mark success.
If multiple apps are truly needed, note that Intune can only report on one of them in the portal. Typically, the first app in the list is used for reporting. Make sure the primary app is listed first, or only that one is listed.
App Shows as Installed in Intune but Not Present on Device: The opposite scenario is less common but can happen. For example, if a user manually installed an app before Intune managed it, Intune might consider the requirement satisfied (0x87D13B61 – The user has installed the app before managed installation). In such cases:
The Intune portal might list the app as installed (because the bundle ID/version was detected), but the app might actually be a different version or not fully managed.
To fix this, you could have the user uninstall the app and then let Intune push it fresh, or enable "Ignore app version" in detection rules so Intune will attempt to install its version over the existing one if versions differ.
Configure "Ignore app version" if Needed: Many apps like Chrome or Zoom auto-update themselves. If Intune is looking for a specific version but the app updated on its own, Intune might think the installed version doesn't match and try to reinstall or report "Not installed" (because the version changed). To avoid this, Intune allows an "Ignore app version" setting. When set to Yes, Intune will only check for the presence of the app's bundle ID and not the exact version. For auto-updating apps, this is recommended so Intune doesn't fight the app's updater. If you see Intune repeatedly installing an app that's already present but newer, enabling this setting will help.
Handling "App state is unknown" (0x87D13B67): If Intune reports unknown state for an app, it implies the device didn't report back conclusively. This could be a transient issue or a sign the Intune agent didn't execute correctly. To troubleshoot:
Check the Intune logs on the Mac for any errors or crashes during the install cycle.
Try a device sync from Intune and even a reboot of the Mac. A fresh check-in might update the status.
If it persists, you might re-push the app by changing a detection rule (forcing Intune to attempt again) or remove & re-add the app deployment.
In summary, resolving detection issues often involves aligning Intune's expectations with reality: make sure Intune is checking for the right app identifiers and versions. Using the Mac's reported app list and adjusting Intune's detection rules will clear up most of these problems.
Intune portal showing a macOS app deployment failure with error "One or more apps contain invalid bundleIDs. (0x87D13BA2)" – in this case, Intune expected multiple app components from the Teams installer that weren't all present, triggering a false failure.
Code signing issues are a frequent culprit for macOS app deployment failures in Intune. macOS has strict security requirements for software installation, especially when delivered via MDM. Here's how to troubleshoot and fix signing problems:
Use a Developer ID Installer Certificate: As noted earlier, Intune LOB apps must be signed with an Apple Developer ID Installer certificate. This certificate is obtained through an Apple Developer account and is specifically meant for signing installation packages. Without this signature, a macOS device will refuse to install the package silently. Always sign your .pkg with this certificate before uploading to Intune.
Verify the Signature: If an Intune deployment fails with a generic error, double-check the package's signature:
On a Mac, run pkgutil --check-signature /path/to/file.pkg. Expect output that includes "Developer ID Installer" and "Status: signed by Developer ID". If you see "Status: no signature" or an error, you've found the issue.
You can also right-click the .pkg in Finder, click "Show Inspector" (or "Get Info"), and look under Certificates to see if it's signed and trusted. Any indication of "not signed" or "certificate not trusted" is a red flag.
Fixing an Unsigned Package: If you created a package that isn't signed:
Obtain a certificate: Get a Developer ID Installer cert from Apple (your organization might already have one). Install it in your Mac's Keychain.
Sign the package: Use Terminal:
productsign --sign "Developer ID Installer: [Your Name or Org]" Unsigned.pkg Signed.pkg
This wraps the package in a proper signature. Ensure the process reports success.
Use pkgutil --check-signature Signed.pkg to confirm the new signature.
Certificate Trust Issues: Even if signed, the certificate must be trusted by macOS:
The Developer ID certificate you sign with should be valid (not expired or revoked by Apple). If your company's Apple Developer membership lapsed or the cert was revoked, macOS will reject it.
Intune MDM might show a generic failure if the cert isn't trusted. On the Mac, you might see logs about "signature verification failed" or an error code from the installation subsystem.
The solution is to re-sign with a valid, current certificate. Always maintain your Apple Developer account and renew certificates as needed.
Notarization Consideration: Apple's notarization service scans and approves apps for distribution. While MDM installs can often bypass the need for user approval of unidentified apps, a non-notarized app might still encounter issues (especially if a user manually launches it later). If you suspect Gatekeeper blocking the app from running post-install (e.g., the app won't open because it "cannot be checked for malicious software"), you should notarize the app. Notarizing involves uploading the app to Apple and getting a ticket stapled or online verification. This process is outside Intune, but it ensures the deployed app will run without manual override on the client side.
Avoid Common Signing Mistakes:
Don't confuse a Developer ID Application certificate with a Developer ID Installer – you need the Installer type for signing PKGs. The Application cert is for signing apps/.app bundles; the Installer cert signs the installer packages.
If you use third-party packaging tools (e.g., Jamf Composer, Packages app, etc.), ensure you configure them to sign with the correct cert on build.
If you have to repackage a vendor's app (one that wasn't provided as a pkg), do all your packaging steps first, then sign the final .pkg as the last step.
Test Install Manually: A quick test for signing issues is to try to run the installer manually on a Mac:
If you double-click the .pkg on an enrolled Mac, does it open an installer and complete? If the OS immediately says it "can't be opened because it is from an unidentified developer," that means it wasn't signed with a recognized cert.
If it prompts that it "needs to be updated" or "can't be installed," check if this is due to an outdated certificate or missing notarization.
Running it manually can show GUI prompts that Intune's silent install might not reveal. Any such prompt indicates why Intune's silent push might have failed.
Addressing signing problems often simply means properly signing (and possibly notarizing) the app installer. Once corrected, redeploy the app via Intune – the installation should succeed on managed Macs that trust your Developer ID.
Some app deployment failures are not about the app or installer itself, but about the device's management state or Intune configuration. Here are other issues and misconfigurations to consider:
MDM Profile Not Enabled: If a Mac was enrolled via Company Portal, the user must allow the management profile in System Preferences/Settings. If they skipped the approval, Intune has no control to install apps. The device in Intune might show as "Enrolled User Enrolling" but not actually apply policies. The fix is to have the user approve the MDM profile (they might need to re-initiate enrollment). Always verify the MDM profile status when troubleshooting.
Device Not Syncing Policies: Sometimes the Intune management on the Mac might be out-of-sync (especially if the laptop has been offline). You can trigger a sync from Intune (Intune portal > Devices > select the Mac > Sync), or ask the user to open Company Portal and click Check status. If an app is stuck in "Waiting for install" state, a manual sync often kicks it off.
Wrong App Assignment or Scope: Double-check that the app is assigned correctly in Intune:
If you accidentally targeted a user group but the device is only enrolled without user affinity, the app may never install. macOS devices can be enrolled with or without user affinity. Ensure your assignment (Required/Available for users or devices) matches how the Mac is enrolled.
If using device groups vs user groups, verify the Mac is in that group. Also check if there are conflicting assignments (like an uninstall assignment somewhere).
Mis-scoping or using an incorrect targeting can make it appear the app isn't installing, when in fact Intune never attempted it on that device.
Multiple Versions or Duplicated App Entries: If you uploaded multiple versions of the same app in Intune (say an older and a newer version) and both are assigned, Intune might get confused or only install one. Clean up any duplicate app entries. Use Intune's Supersedence feature (if available for Mac apps in the future) or remove old app assignments when deploying an updated version.
Required Configuration Profiles: Some apps, especially security or hardware-related (VPN clients, AV software, printer drivers), might require additional configuration profiles (for kernel extensions, system extensions, or privacy permissions) to be in place. If an app installation succeeded but the app won't run properly until a profile is approved, Intune might mark it installed (since the files are there) but the app is non-functional for the user. Review the app's documentation:
For example, certain VPN or AV apps need a System Extension allowed via a config profile. If you deploy the app without that, the user sees a macOS prompt or the extension gets blocked. This isn't an Intune error per se, but it's a deployment consideration.
Always deploy needed profiles (via Intune Device Configuration profiles for macOS) alongside the app. This ensures a smooth activation. While this won't show as an "error" in Intune's app install status, it's a "misconfiguration" that can cause the app to be effectively not deployed correctly from the user's perspective.
Cleaning Up Stalled Installs: If an app deployment is stuck or repeatedly failing on a device, sometimes removing the app and re-pushing can help:
On the Mac, you can remove any partially installed app (drag the .app to Trash, or use a vendor uninstall script if available).
Then, in Intune, you might choose "Retire" the device or use the "Reinstall" option if the Intune portal shows one for that app (Intune UI sometimes provides a Reinstall action for failed app instances).
Once the slate is clean, reassign the app as required and force a sync.
Log Collection for Escalation: If all else fails and you need to escalate to Microsoft support, gather logs:
Use the Company Portal's Help > Save Diagnostic Report to collect a full log bundle. This captures Intune agent logs, Company Portal logs, etc., into a zip you can inspect or send to support.
The Intune portal also has a Collect Logs remote action for macOS (under Devices > select device > … > Collect Diagnostics). You can specify log file paths (like /Library/Logs/Microsoft/Intune/IntuneMDMAgent.log) and initiate collection. The logs will be uploaded and available in Intune for download.
Key log locations to remember (for general troubleshooting or support):
CompanyPortal.log – Company Portal app log (~/Library/Logs/CompanyPortal/ or sometimes in the same Microsoft/Intune folder).
macOS system logs – accessible via the log command or Console.
By addressing any enrollment or profile issues and verifying your Intune app assignments, you can eliminate environmental causes of deployment failures. Now, let's look at how these principles apply to specific popular applications.
To make the guidance more concrete, here are real-world examples of macOS app deployments in Intune and how to troubleshoot their common issues. We'll look at Google Chrome, Zoom, and Adobe apps, since these are widely deployed and illustrate different challenges.
Scenario: You want to deploy Google Chrome to macOS devices via Intune. Chrome is a popular browser and Google provides it as a PKG installer for enterprise.
Best Practice Deployment: Rather than packaging Chrome yourself, download the official GoogleChrome.pkg from Google's enterprise download page. This installer is already signed by Google's Developer ID and is Intune-ready. Add this PKG to Intune as a Line-of-Business app:
In Intune admin center, go to Apps > macOS and add a new app. Upload the GoogleChrome.pkg file.
Fill in app details (Name: "Google Chrome", etc.). Intune should automatically detect the bundle ID (com.google.Chrome) and version.
On Detection Rules, it's recommended to set Ignore app version to Yes. Chrome auto-updates frequently, and this setting ensures Intune just checks that Chrome is installed, not the exact version.
Assign the app to a group of users or devices (as Required for automatic install, or Available if you want users to install from Company Portal).
Potential Issues & Troubleshooting:
Installation Failure: Chrome's official PKG is properly signed, so it typically installs without issues. If you do encounter a failure (0x87D13B64 generic error), verify the PKG wasn't corrupted during upload. You can test by downloading the content from Intune (there's no straightforward way to do that, but re-download from Google to compare). Also ensure the device is online and Intune agent is functioning.
Detection Problems: If Intune reports Chrome as failed even though it's installed, check the detection settings:
Make sure only the Chrome app is listed in Included apps. The Chrome PKG should only install the Chrome.app into /Applications. If Intune accidentally had another bundle ID listed, remove it.
If a user already had Chrome installed before enrollment, Intune might show status "Install pending" indefinitely (since Chrome's already there, Intune might not install it if it's considered up-to-date). In such a case, Ignore app version = Yes helps, or you might script an uninstall of Chrome before pushing it as required (in most cases, not necessary).
Self-Updating Behavior: With Chrome, the app will update itself in the background. Intune won't track those updates. By ignoring version in detection, Intune won't retry installation unless Chrome is completely missing. Educate users that Intune's version display might lag behind Chrome's actual version due to auto-updates.
Key Takeaway: Use vendor-provided PKGs for apps like Chrome. They are correctly signed and have proper metadata, which sidesteps many packaging issues. Intune integration is smooth as long as detection is configured to accommodate auto-updates.
Scenario: Deploying Zoom (meeting client) to Macs through Intune. Zoom provides different installers for Intel, Apple Silicon, and a Universal package.
Recommended Approach: Use the Zoom Universal PKG if available, which supports both Intel and Apple Silicon in one installer. This avoids having to target different app versions to different device types. Like Chrome, Zoom's PKG from their Download Center is signed with a Developer ID and ready for MDM deployment.
Steps to Deploy:
Download the Zoom Client for Meetings installer for macOS from Zoom's site. Choose the universal installer (or if not available, download both Intel and ARM versions and create separate Intune apps with device-specific assignment).
Add the PKG to Intune (Apps > macOS > Add). Intune will pick up the bundle ID (us.zoom.xos) and version.
In Detection Rules, set Ignore app version = Yes, because Zoom also frequently auto-updates itself.
Assign to the appropriate groups (e.g., all users who need Zoom).
Common Issues:
Apple Silicon and Rosetta: If you accidentally deploy the Intel-only Zoom package to an M1/M2 Mac without Rosetta 2, the installation will fail (the Mac can't execute Intel installer code until Rosetta is present). Intune might show a generic failure in this case. To fix:
Ensure you either deploy the Universal package or, if using the Intel package, pre-install Rosetta 2 on M1 devices. You can deploy a one-time script via Intune to install Rosetta on all Apple Silicon Macs in your org.
A quick Intune script (shell script deployment) for Rosetta could be:
Permissions Pop-ups: The first time Zoom runs, macOS will ask for camera/microphone/screen recording permissions. These are user-level prompts and not something Intune can pre-set without a configuration profile (PPPC profile). While not a deployment "failure," admins sometimes interpret app not working (can't use mic/cam) as deployment issue. The solution is to deploy a Privacy Preferences Policy Control profile to pre-authorize Zoom if desired. This is an extra, but worth noting for user experience.
Auto-Update and Version Reporting: Zoom, by default, might prompt users to update or auto-update in the background. Intune's detected version might become outdated. With Ignore app version, Intune will not reinstall Zoom just because it updated. But if you ever push a Zoom version update via Intune (upload a new PKG), be aware that devices which auto-updated themselves may already be ahead. Generally, leave Zoom to manage its own updates or use Zoom's administrative auto-update settings. Intune can primarily ensure Zoom is present.
Uninstall/Re-install: If a user manually uninstalled Zoom, Intune should detect it's absent on next check-in and re-install it (if assigned as Required). If that doesn't happen, check the Intune detection – possibly the app was still showing as installed. In such cases, you might need to wipe the Zoom app entry (you can "Retire" the app from that device via Intune) so it redeploys.
Key Takeaway: Zoom deployment is straightforward with the right PKG. Always account for Apple Silicon compatibility (use universal binaries or install Rosetta). Manage auto-update vs Intune deployment strategy to avoid conflicts (many let Zoom update itself and only use Intune for initial install or major version enforcement).
Scenario: Deploying Adobe Acrobat Reader DC, or packaging multiple Adobe Creative Cloud apps for users.
Adobe apps present unique challenges because Adobe often supplies their own installers or packaging tools.
Adobe Acrobat Reader DC:
Adobe offers a .dmg that contains an Acrobat Reader .pkg installer. The .pkg inside is signed by Adobe. The best practice is to extract or download the AcrobatReader.pkg (enterprise distribution) and use that.
Add Acrobat Reader .pkg to Intune as usual. The bundle ID is com.adobe.Reader (or similar) and Intune will detect it. Acrobat Reader doesn't auto-update as aggressively (unless users trigger it), so you might leave Ignore app version as No if you plan to manage updates via Intune, or set it to Yes to be safe if users can update.
One common hiccup: Acrobat Reader installer might also install the "Adobe Acrobat Refresh Manager" or other helper. Intune's Included apps might list multiple Adobe components. If Intune throws the 0x87D13BA2 error for bundle IDs, consider removing any secondary helper from the detection list, keeping only the main Reader app.
Adobe Creative Cloud Apps:
If deploying Creative Cloud packages (like a package of multiple apps created from Adobe Admin Console), the installer will likely install several apps at once (e.g., Photoshop, Illustrator, plus the CC Desktop app). Intune can only track one app in the portal, and if the package includes multiple, you risk the "invalid bundleID" error if Intune expects all of them.
To handle this, you have a couple of options:
Split the Package: Instead of one big package for multiple Adobe apps, create separate Intune app deployments for each main Adobe application. Adobe's Packager can create individual installers, or you can use the Creative Cloud Desktop app deployment then have it install apps via script.
Modify Included Apps: If you must deploy one package with multiple apps, edit the Intune detection to include only one of the apps (preferably the main one like Creative Cloud or the primary app). This way, as long as that app is installed, Intune marks success. (The other apps will still install on the Mac, just Intune won't track each one.)
Code Signing: Adobe's packages from their official sources are properly signed, so you shouldn't hit signing issues. If you repackaged something manually (not common for Adobe CC, but say you made a custom wrap), ensure you sign it as discussed. It's usually better to use Adobe's official installer packages to avoid this.
Installation Time: Some Adobe installs are large and take time. If Intune has a timeout (Intune management agent might have an execution timeout), large apps could potentially time out. Monitor the IntuneMDMDaemon.log during a big app install to see if it's running into limits. You might need to deploy large apps one at a time or ensure a good network connection.
Post-Install Configuration: Adobe apps might require users to sign in with Adobe ID or your enterprise ID. This is beyond Intune's scope, but plan to inform users. The deployment could be perfect, yet the user might report "I can't use Photoshop" simply because they need licensing sign-in. Be prepared with documentation or an SSO integration for Adobe.
Key Takeaway: For Adobe deployments, keep Intune's detection logic simple (one app per Intune "app" when possible) to avoid multi-app reporting issues. Use Adobe's provided installers or packages to ensure signing and installation scripts are correct. Test on a pilot machine because Adobe installers can be heavy and occasionally finicky under MDM constraints.
Deploying macOS apps through Microsoft Intune can be challenging, but with the right approach you can overcome the common issues. Remember these key points:
Package Format & Signing: Always use properly formatted .pkg installers signed with an Apple Developer ID Installer certificate. Unsigned or wrong-format apps will fail silently.
Common Error Codes: Familiarize yourself with Intune's error codes (like 0x87D13B67 for unknown status or 0x87D13BA2 for bundle ID mismatches) to quickly identify the cause of failures.
Troubleshooting Process: Check Intune status details, verify the Mac's enrollment and agent, inspect logs, and attempt manual installs to diagnose issues. Use mdmclient QueryInstalledApps and Intune's detection rules to resolve reporting discrepancies.
Log Files are Your Friend: The Intune logs on macOS (IntuneMDMAgent.log and IntuneMDMDaemon.log) contain detailed information. They, along with macOS system logs, help pinpoint failures that Intune's portal error alone might not explain.
Test and Iterate: Before wide deployment, test app installs on a pilot Mac. This can reveal issues with signing or prerequisites (like Rosetta 2 for M1) in a controlled way. You can then adjust the Intune package or provide necessary dependencies.
By following the troubleshooting steps outlined above, IT administrators can systematically diagnose and fix macOS app deployment issues in Intune. With well-prepared packages, correct detection logic, and awareness of common pitfalls, you'll ensure a smooth deployment experience for end-users and keep those Mac endpoints running the apps they need.
IntuneBrew