macOS App Deployment with Microsoft Intune: An In-Depth Guide

Last Updated on December 31, 2023 by Oktay Sari

In today’s modern workplace, where macOS is becoming more popular, the ability to deploy and manage applications is crucial. Microsoft Intune offers powerful and versatile solutions for managing macOS applications, enabling organizations to automate the deployment process, enforce security policies, and provide centralized management.

Introduction to macOS App Deployment with Microsoft Intune

This guide aims to demystify the process, providing a thorough understanding of the various macOS app deployment methods, considerations, and best practices involved.

By understanding the different app types, making informed decisions about deployment strategies, and employing advanced techniques, you can streamline the app deployment processes and achieve a more seamless user experience.

This (basic) knowledge will come in handy, when we will actually deploy and configure some apps in another blog post and dive into the nitty gritty details of macOS App deployment with Microsoft Intune.

If you want to try things out while reading this article, make sure you have a test devices at hand. This will help you a lot!

Understanding Application Types for macOS

When diving into the world of deploying apps on macOS with Intune, you need to be aware of the different flavors to pick from. You’ve got a variety of cool options: Microsoft 365 Apps, Microsoft Edge, Microsoft Defender for Endpoint, Apple VPP, web clips, and a few other tasty treats. So, when you’re scooping out apps to deploy, just remember you’ve got a whole menu of choices with Intune!

In this post we’re zooming in on three main characters in play – PKG, DMG, and LOB apps. While each has its own storyline in the world of app deployment, they share a common backstage area – the prerequisites. They are pretty similar for all three and here’s what you need to know:

Prerequisites:

• Devices are managed by Intune
• The PKG or DMG file is smaller than 2 GB in size.
• The Microsoft Intune management agent is installed.
• The PKG file successfully runs using the installer command in Terminal
• Full disk access permission is required to update or delete DMG apps
• macOS LOB apps
  • need to have a logo in order to be displayed in the Company portal App
  • LOB apps need to be signed
  • have some other prerequisites so check out the docs.

1. PKG Files: The Cornerstone of macOS app Deployment

PKG files are installer packages native to macOS, essential for applications that need a structured installation process.

Key Characteristics:

• Customizable Installation Scripts: PKG files allow for tailored installation experiences, accommodating complex setups. You can configure a preinstall or a post-install script for complex customization.
• Broad Compatibility: Ideal for a wide range of software, ensuring compatibility with different macOS versions.

Best Practices:

• Ensure Integrity: Verify the source and integrity of PKG files to maintain system security. Unmanaged PKG applications have no requirement to be signed.
• Test Deployments: Conduct thorough testing in controlled environments to iron out any installation issues.

Here’s a quote from the documentation: “Use the information in this article to help you add an unmanaged macOS PKG app to Microsoft Intune. To deploy a managed PKG app, see How to add macOS line-of-business (LOB) apps to Microsoft Intune.”

So there’s managed and unmanaged apps?? Hmm, what’s the difference you ask? More on this a little later.

2. DMG Files: The  Alternative

DMG files are disk images that provide a simpler, drag-and-drop installation experience when installed manually.

Key Characteristics:

• Ease of Use: Typically involve straightforward installations, making them user-friendly.
• Versatility: Suitable for a wide array of applications, particularly those not requiring complex setup scripts.

Best Practices:

• Verify Compatibility: Ensure the DMG file is compatible with your target macOS version.
• Simpler applications: Choose DMG for simpler applications that don’t require additional installation scripts .

3. LOB Apps: Tailored for the Enterprise

Line-of-Business (LOB) apps are mostly custom or internally developed applications specifically designed for organizational needs.

Key Characteristics:

• Customization: Highly tailored to meet specific business requirements.
• Integration: Often integrated with other enterprise systems for seamless operation.

Best Practices:

• Regular Updates: Keep LOB apps updated to align with evolving business needs.
• Security Compliance: Ensure they adhere to organizational security standards.
• Developer ID Installer: Check if pkg file is signed.

Understanding Signing requirements

LOB apps need to be signed using the “Developer ID Installer” certificate. The documentation is clear on that. But why is that important? Here’s a little more background information.

Notarization and Gatekeeper

Notarization and Gatekeeper in macOS ensures the security and integrity of apps. Apple’s process of scanning apps for malicious content and certifying them as safe is called Notarization . It provides an extra layer of security by verifying that an app isn’t tampered with or harmful.

Gatekeeper then uses this notarization status, along with the developer’s signature, to allow only trusted apps to run on macOS. This combination of notarization and Gatekeeper checks helps protect Mac users from malware and other security threats.

In short Notarization and Gatekeeper provide;

• Enhanced Security: Ensures that deployed apps meet Apple’s security standards, providing users with safe and reliable software.
• Compliance with macOS Protocols: Aligns with macOS security features for trusted application execution.

Verifying App Integrity

Checking if a PKG or DMG file is signed and approved by Apple involves a few steps, typically done using the macOS Terminal. Here’s how you can check for these using Terminal Commands; pkgutil and codesign.

Check if PKG file is signed

The first example shows how you can use pkgutil to check if a PKG file is signed;

1. Open Terminal
2. Use the pkgutil Command for PKG Files:
   • Type pkgutil –check-signature /path/to/your/file.pkg.
   • For example; pkgutil –check-signature GoogleChrome.pkg
   • This command will return information about the signature, including the developer or company name and the certificate used for signing.

Check if DMG is Signed and Notarized

The second example shows how to use the codesign and spctl command for DMG Files:

• First, mount the DMG file by double-clicking on it.
• Then in Terminal, type codesign –verify –verbose /Volumes/NameOfMountedVolume.
• This command checks the signature of the application contained within the DMG file.

Then continue to check Notarization using the spctl command:

• spctl –assess –type execute -vv /path/to/application.app.
• This command will return notarization status along with other assessment information.

Here’s a little more info on what is happening:

1. codesign –verify –verbose /Volumes/Google\ Chrome/Google\ Chrome.app:
   • Valid on Disk: This means the application’s signature is intact and valid. The app has not been tampered with since it was signed.
   • Satisfies its Designated Requirement: The app’s signature matches the one expected for it, confirming it’s from the legitimate source (in this case, Google).
2. spctl –assess –type execute -vv /Volumes/Google\ Chrome/Google\ Chrome.app:
   • Accepted: macOS’s security assessment tool (spctl) has accepted the application as safe to run.
   • Source=Notarized Developer ID: This indicates that the app is not only signed by a registered developer (Google LLC in this case), but it has also been notarized by Apple, providing an additional layer of security and assurance.
   • Origin=Developer ID Application: Google LLC (EQHXZ8M8AV): This part identifies the specific Developer ID used to sign the app, linking it to Google LLC.

In a nutshell, it’s like getting a thumbs up for your Google Chrome app. The results show it’s got all the right signatures and stamps of approval (notarized), which means it’s the real deal and up to the mark. Basically, your Chrome app is totally legit and safe. 👍🔒.

Managed vs. Unmanaged Apps: Here’s the deal…

When uploading a PKG file to Intune, you can choose from the flavors PKG or LOB. With both options, you’ll upload a PKG file to Intune. So what’s the difference between a managed and unmanaged app then? Well… to be totally honest I’m not really sure but here’s my 2 cents;

Managed Apps (LOB)

LOB apps can be deployed as either managed or unmanaged. When you configure the app settings in Intune, you can set the option “Install as managed” to YES. The default setting is NO. So when this setting is set to NO, the app is considered NOT managed.

The “Install as managed” option for LOB apps in Microsoft Intune, when set to “Yes”, ensures that the macOS LOB app is installed as a managed app on supported devices (macOS 11 and higher). Key requirements for this option include that the app distributable must contain a single app without any nested packages and must install to the /Applications directory.

Think of a managed LOB app as having a couple of neat superpowers in your toolkit.

• Firstly, you can wave goodbye to the app with the ‘uninstall assignment type’ on devices that support this feature.
• Secondly, when you decide to pull the plug on the MDM profile (remove it), it’s like a clean sweep – every managed app, along with its data, gets whisked away from the device. It’s all about keeping things tidy and under control! 🧹

Here’s a note from the documentation;

Deploying Vendor PKGs as LOB Apps

Yes, you can deploy vendor PKGs as LOB apps but remember the prerequisites for LOB apps. Then when you’re good to go, continue and download the file. Finally make sure you verify the vendor’s PKG file like explained above. If all is OK, deploy it via Intune as a LOB application.

Unmanaged Apps (PKG)

Apps deployed by both the PKG and DMG deployment methods are considered unmanaged. When it comes to assigning apps using the PKG deployment method, think of it as a one-way street. The only option you’ve got is the “Required” assignment type. The “Available for enrolled devices” and “uninstall” options? They’re like those elusive ice cream flavors that aren’t on the menu right now. So for now, it’s all about going with “Required” and rolling with it! 🚦

Unmanaged Apps (DMG)

When deploying DMG apps, you have both the “Required” assignment type and the “uninstall” options in your toolkit. The “Available for enrolled devices” is not available for DMG apps.

Why is it so difficult to have all assignment options available for all three deployment methods? Let me know in the comments if you have the answer but for now, we’ll have to settle with it.

Retiring devices and unmanaged apps

Heads-up: let’s make it a little more difficult than it already is… When you deploy an unmanaged macOS app (PKG or DMG), it’s kind of like a house guest who doesn’t take the hint to leave when the party’s over. When you retire the device, the app and all its data will just hang out there, chilling on your device. So, before you say goodbye to your device, don’t forget to give that app the boot first (uninstall) . It’s always better to clear the house before you lock up and move on! 🎉💻

Again, check out the documentation!

Summary on managed vs unmanaged apps

Managed Apps (LOB)

• Managed apps in Intune, particularly LOB (Line-of-Business) apps, can be deployed as either managed or unmanaged.
• When set to “Install as managed”, the app is installed with more control options in Intune.
• Key features include the ability to uninstall the app using the ‘uninstall assignment type’ on supported devices and the automatic removal of the app and its data when the MDM profile is removed.

Unmanaged Apps (PKG)

• Unmanaged apps, typically deployed via PKG or DMG methods, have fewer management controls in Intune.
• The primary deployment option available is “Required”, with “Available for enrolled devices” and “uninstall” assignment options not being available.
  • The “uninstall” assginment option is available for DMG
• Unmanaged apps remain on the device even when it is retired, necessitating manual uninstallation.

PKG vs DMG: The Inside Scoop

Is there more to this PKG vs DMG saga? Absolutely! Let’s dig into some of the juicy details

Unmanaged PKG: The Know-It-All

When you upload an unmanaged PKG file and tinker with the app settings, it’s like the file’s showing off – the App bundle ID (CFBundleIdentifier) and App version (CFBundleShortVersionString) are already filled in. It’s got all its ducks in a row, just like LOB apps.

Unmanaged DMG: The Mysterious Enigma

On the flip side, DMG files are the mysterious types. They leave the App bundle ID and App version fields empty, making you feel like Intune’s playing hide-and-seek with this info.

Finding the CFBundleIdentifier and CFBundleShortVersionString

Need to track down these elusive details? Time to don your detective hat and dive into Terminal with some good ol’ defaults commands:

• defaults read /Applications/Google\ Chrome.app/Contents/Info CFBundleIdentifier
• defaults read /Applications/Google\ Chrome.app/Contents/Info CFBundleShortVersionString

A Word of Caution: Case Sensitive Catastrophe

Beware, the CFBundleIdentifier is super picky about uppercase and lowercase! Slip up here, like typing “com.google.chrome” instead of “com.google.Chrome”, and Intune will throw a tantrum with an error message you won’t find in the manual; “The DMG file is a no-go because it’s missing an app that matches the bundle IDs you gave me. (0x87D3013D)” Translation: Fix that typo, or your app’s going nowhere fast!

App Updates: Understanding the Nuances

Ahh you may think…This one is easy enough right?? Well, like we’ve seen before. All deployment methods have their own update mechanism.

Updating LOB apps

Let’s call this an in-place app update. What do I mean by this? Basically, you edit the previous LOB app you deployed and upload a new PKG file. Check the documentation for the exact steps.

Considerations: to update your LOB app the app developer must increment the CFBundleShortVersionString of the PKG file and provide you with the updated PKG file.

Updating PKG apps

For apps that have an auto-update mechanism, set the option “Ignore App version” to Yes. That’s it as far as the documentation goes… I guess it all comes down to the same thing;

• Updating the PKG File: The developer should update the app, repackage it into a new PKG file, and increment the version number in the CFBundleShortVersionString.
• Download the PKG file: Proceed to download the PKG file
• Re-Distribution: You then need to manually upload the updated PKG file to Intune and re-deploy it to the relevant devices or user groups.

So, here’s the deal: I played the role of a tech detective and embarked on a little experiment. I deployed Firefox version 119.0 as an ‘unmanaged’ PKG file – kind of like sending a scout on a secret mission. After patiently waiting for it to cozy up on my test device, I decided to stir things up. I sneakily updated the app in Intune to version 121.0, just to see how the story unfolds. It’s like changing the plot in the middle of a movie and waiting to see how the characters react! Here’s what happened behind the scenes;

Updating Firefox PKG app with Intune

First I uploaded Firefox 119.0.pkg to Intune as an unmanaged app:

On my test device, I checked the app properties using the Finder. I did not open or start the Firefox app since this could have triggered an auto update:

Confirmed in Intune the app is actually installed:

Then downloaded Firefox 121.0.pkg and in Intune I edited the existing PKG. I’ve renamed the app and uploaded version 121.0.

When checking the Managed Apps tab for my device in Intune, I noticed that the application Name reflected the change already, but the version was as expected still 119.0 :

After a little while the application updated on my macOS test device:

A few minutes later, Intune also showed the updated information under the Managed App tab.;

Here’s an observation: We’ve read the documentation and know that the deployment method for PKG files is defined as “adding an unmanaged macOS PKG app to Microsoft Intune” right?

Now, here’s the kicker – when you go snooping around the device to see what apps are installed, this ‘unmanaged’ PKG app pops up in the ‘Managed apps’ section. Confusing? Absolutely. But hey, we’re still on this wild ride together, right? 🕶️🎢

Updating DMG apps

Ready to update DMG apps with Intune? Cool, but remember, you need full disk access permission to update or delete those DMG apps. It’s Intune’s way of saying, ‘No backstage access without a pass!’

The update dance is pretty similar to what you do with LOB or PKG apps. Just waltz into Intune and tweak the existing app. The playbook (a.k.a. documentation) advises you to upload the app’s latest version with the same ol’ bundle identifier (CFBundleIdentifier) as your original DMG app.

But wait, what about the CFBundleShortVersionString? The docs are silent on this one. However, let’s use some logic – if the new version’s CFBundleShortVersionString is a doppelganger of the old one, don’t expect any update fireworks. It’s like trying to impress with the same magic trick twice.

And oh, don’t forget the secret sauce – make sure your Microsoft Intune agent for macOS is version 2304.039 or newer. Think of it as the latest gadget needed to pull off this tech mission!

Summarizing Updates

Alright, let’s break down the app update magic in simple terms. Imagine your app in Intune is like a vintage car. To give it a fresh look, all you’ve got to do is roll in a shiny, newer PKG or DMG file, kind of like slapping on a new coat of paint. But here’s the key: You’ve gotta bump up the CFBundleShortVersionString to a new version number. It’s like updating the license plate from “Happy2023” to say “Happy2024”!

Ignore app version:

Alright, drumroll, please! This setting is the last one we wanna pay extra attention to.

When you’re setting up app installs in Intune, think of “Ignore app version” as your laid-back option. If you set it to “Yes,” it’s like saying, “Hey, as long as the app isn’t already hanging out on the device, come on in!” This option doesn’t sweat the details – it just checks if the app’s bundle ID is there. It’s super handy for apps that update themselves.

But if you flip it to “No,” it’s more particular. It’s like a bouncer checking IDs at the door. It’ll only let the app install if it’s totally new to the device, or if the version you’re deploying is different from what’s already installed.

So, “Yes” for easy-going installs, and “No” for when you need to be a bit more specific! Sometimes a table tells more with a lot less words;

Final thoughts

In conclusion, mastering the deployment of applications on macOS devices using Microsoft Intune requires a blend of technical knowledge, strategic planning, and adherence to best practices. Whether dealing with PKG, DMG, or LOB apps, each type demands a nuanced approach to ensure successful deployment, robust management, and seamless user experience. By understanding the distinct characteristics and requirements of each app type and integrating effectively with Apple’s ecosystem, organizations can achieve a secure, efficient, and compliant application deployment environment.

I’m left with some questions I don’t have a satisfactory answer for yet. Let me know in the comments if you have the answer!

1. Why don’t we have all assignment options (required, available for enrolled, uninstall) available for all three deployment methods?
2. Why would one want to install a LOB app as an unmanaged application? What’s the deal with manages vs unmanaged apps?
3. The documentation is not up to date and does not contain relevant information for all deployment scenarios. Specifically around the update mechanism.
4. CFBundleIdentifier and CFBundleShortVersionString are pre-populated for LOB and PKG but not for DMG. The documentation is not clear on why that is..
5. when you go snooping around the device to see what apps are installed, the ‘unmanaged’ PKG apps pops up in the ‘Managed apps’ section and this is adding to the confusing around managed vs unamaged apps.a