Overview
This is part 3 in a multipart series on how macOS devices are managed by Intune. In part 1 we look at the history of macOS management. In part 2 we look at how macOS handles MDM with Intune. Finally, in part 3 we look at Company Portal and the Intune Management Extensions role in macOS management.
Intro
Company Portal is Microsoft’s cross platform application catalog for devices managed by Intune. It supports iOS, Android, Linux, macOS and Windows devices and empowers end users to self-service install software and preform basic task on their devices. Company Portal can be deployed via Automated Device Enrollment using Intune, or during user driven enrollment scenarios. For organizations evaluating moving from Jamf Pro to Intune, this is analogous to Self Service, and serves many of the same purposes.
Company Portal
Let’s take a look around Company Portal on macOS. Using our fictious friend Johnny Appleseed’s Intune managed device, we open Finder and navigate to /Applications to find Company Portal. Once inside Company Portal, we see a few different views. On the Devices tab we can see basic data about the Mac, along with the ability to force the client to do an MDM check-in, as well as IME Policy check-in when clicking on the “three dots”. More on this in a bit.
On the Apps tab we have some applications that can be installed. On this system we have MDE, Microsoft 365 Apps, and Edge as available for install for end users.
And finally on the Support tab, basic information Johnny can use to contact his IT department.
The Microsoft Intune Agent, or the IntuneMDMAgent, or the Intune Management Extension?
These are all the same thing. The Microsoft Intune Agent, the Intune Management Extension, or IME, also known as SideCar, is an executable that is installed on Intune managed Macs. Its purpose is to add support for scenarios like running scripts and software installation outside of the MDM stack. For orgs coming from Jamf Pro, the IME is the equivalent to the Jamf Binary.
IME in a bit more detail
The IME lives in /Library/Intune/Microsoft Intune Agent.app, and contains the IntuneMDMAgent, and the IntuneMDMDaemon. Each are controlled by Launchd (the process management system in macOS), and are run in user, and system context respectively. These serve a similar function to the mdmclient in macOS. For more information on the mdmclient check out part 2 of the series. The IME is installed silently on macOS devices upon script or app deployment from Intune.
One difference is that while the Jamf Binary has a number of arguments that can be passed in via the CLI, IME does not. Infact if you do interact with the binary itself you are presented a little “easter egg”.
Deploying Scripts
If you’re coming from Jamf Pro, Scripts in Intune can function a lot like Extension Attributes, or like script parameters on a Policy. They can execute on a timed trigger to reenforce settings, “echo” results back to the Intune Portal, or run once to change something on the device. Let’s create a script that generates a file on the filesystem and adds a unique value, each time it runs. We start by opening a browser and navigating to https://intune.microsoft.com/ > Devices > MacOS >Shell Scripts > Add.
Next, we add a name and a description and click thru to Script Settings. Here we will upload the Shell Script to Intune. One thing to note is while in Jamf Pro you are able to edit scripts directly in the console, in Intune these are currently read only.
Scrolling down thru the script window allows for further configuration, including the context to run the script, frequency and failure options. For our example, this script is set to run as root as it is touching the /Library/ directory which requires elevated privileges, so we set the “Run script a signed-in user” to No. Since we want this to add a value to this file each time it runs, we will set “Script frequency” to Every 15 minutes. Finally, the “Max number of times to retry if script fails” to 1 time. Navigating thru the script assignment we save the policy.
Back on the Overview Page lets grab the PolicyID in the browser address field. This will come in handy to track progress in IME logs.
Scripts – macOS
Over on Johnny’s Mac we navigate to /Library/Logs/Microsoft/Intune/ and open the latest IME log in Console. Searching for the PolicyID, we can see the following:
- SideCarService gets policy from Intune.
- RecurringScriptPolicyCoordinator schedules the policy.
- ScriptPolicyRunner kicks off the policy.
- ScriptExecutionObserver runs the script.
Deploying Apps
Apps work very similar to scripts. Let’s take a look at the device when the Mac is included into scope for deploying FireFox. Just for added fun, Johhny’s device already had FireFox installed. Let’s take a look at the process in a bit more detail.
- AppPolicyHandler gets a Policy from Intune. This includes the BundleID, and other install parameters.
- AppDetection looks for an existing install of FireFox by using the BundleID.
- AppDetection sees that there is an app that matches the BundleID of com.mozilla.firefox on the device.
- AppResultStateChangeManager determines that this policy needs to run on this device.
- AppInstallManager kicks off the policy.
- AppBinaryDownloader begins to download the bits to the device.
- AppBinaryDownloader completes the download, decrypts and validates the downloaded file.
- PackageInstaller installs Firefox, and completes the installation process.
Common Troubleshooting
- If you expect to see an app as available in Company Portal, and don’t, force the client to check into Intune.
- Make sure the Policy is in a ready state and not still uploading a package or dmg before troubleshooting install issues.
- IME can be forced to check in only in Company Portal or killing the IntuneMDMAgent process. Forcing a Sync from the device object in the Intune Admin Center only forces an MDM check in.
- Scripts run as System (root) context by default.
- Always test your scripts locally to ensure they perform the action you are expecting. Once they work then upload them to Intune.
- Adding logging and a -x to the Shebang (#!) help with debugging scripts.
- IME is self-updating; nothing needs to be done on your end to update the client.
- If a device is not scoped a policy or app, IME will remove itself. Readding the device into a scope of an app or script will redeploy IME.
- Intune has a few different metaphors for its app models (LOB, DMG, PKG). Each one is a bit different and has different functions. If you are coming from Jamf Pro you may find this a bit more complicated in Intune.
- If it’s been a while and you are taking a fresh look at Intune…App Wrapping with the Intune App Wrapper is no longer a thing and has not been for some time. 👏
- Logs are always your friend. Check out /Library/Logs/Microsoft/Intune for logging details.
- Remote Log Collection is supported thru the Intune Admin Center on macOS and will collect IME logs. This is something that Jamf Pro does not have, and it its extremely helpful.
- Check the docs for supported file sizes when uploading scripts and software. These have been increasing since IME introduction. For the most part large software like Adobe should not be a problem.
- Additional configuration via Pre and Post Install Scripts are available. This is analogous to Pre and Post flight scripts on a Policy in Jamf Pro.
- If you are seeing errors in the IME log regarding TLS, and this is the first time you are deploying software from Intune, ensure you are not inspecting the traffic or accessing it thru an authenticated proxy.
- Unlike Windows IME, IME on macOS does not support P2P downloads.
- Intune does not support a “distribution point”. If you have Connected Cache deployed in you ConfigMgr Hierarchy, macOS will not use. Delivery Optimization is a Windows only technology.
- If you are moving from Jamf Pro (hosted or cloud) and have Distribution Points in your environment, Intune does not have a similar capability. All traffic will egress your network to the internet to get packages. Make sure you adequately test this with your network team.
- Check out Microsoft’s End-to-end Guide for Mac management with Intune here.
Closing
That wraps up the 3-part series, Understanding macOS management with IntuneMDMAgent and Configuration Profiles. Hopefully this in-depth look at macOS management helps with your evaluation of Intune and, shows that Mac management with Intune is a “first class” citizen.