If you’ve been watching the Intune Whats New page closely, you may have noticed you can now use Intune to push down applications to MacOS devices. This is a quick post on how to achieve that – We’ll use Skype for Business as the example app.

Select Managed Google Play as the app type, search for the app, and select the app in Intune. Microsoft 365 apps for Windows 10. Store app (Microsoft 365) Select Windows 10 under Microsoft 365 Apps as the app type, and then select the Microsoft 365 app that you want to install. Microsoft 365 apps for macOS. Select Apps All apps Add. Select macOS in the Microsoft 365 Apps section of the Select app type pane. The Add Microsoft 365 Apps steps are displayed. Step 1 - App suite information. In this step, you provide information about the app suite. This information helps you to identify the app suite in Intune, and it helps users to find the app suite in the company portal. Paste the URL into a web browser, this will convert the URL from the store into one you can use with the Intune app. Copy the URL from the browser into the Appstore URL field. Complete the app configuration as required. Click OK to complete. Next, we need to create a group to deploy the app to. At the root of the Intune blades, choose Groups. Hence, Intune company portal app is the place where you can go and check for changed Intune policies. This will help user to get the updated policies immediately applied to the device. Open the company portal app and go to my devices – click on the Android or iOS device which you are using, click on the check compliance link.

For this example, I’ll deploy TeamViewer, on the 3 platforms. On Intune Mobile Apps Apps. Choose the type of the application, Line-of-business app to deploy our MSI package: Select the package: Provide information and validate the deployment: When the upload of the file is finished, we need to assign this app to a user/group/device.

The IT admin process is pretty straight forward but I must admit I tripped on a couple of syntax issues the first time I did this so I’ll blog it here with some syntax to save you some time. Your welcome 😊

Step 1 – Get the app package (.pkg file)

First you need to acquire the app as a .pkg file.

(Conversion of other formats e.g. “.DMG” to “.PKG” is not supported.)

On a Mac, Logon to http://portal.office.com as a user licensed for Office 365 Pro Plus and download the Skype for Business .pkg file.

Step 2 – Convert it to a format that Intune understands (.intunemac)

On a Mac, download the Intune app wrapping tool from Github ( https://github.com/msintuneappsdk/intune-app-wrapping-tool-mac)

Once you have it downloaded, Open a Terminal session and navigate to the directory where the IntuneAppUtil tool was placed. Run this syntax to convert from .pkg to .intuneMac format

(-c is the input file and -o is the output directory)

You now have an .intunemac file you can distribute with Intune

Step 3 – Upload to intune

In the Intune console, go to Mobile Apps> Apps>Add> Line-of-business App

Choose the .intunemac file to upload.

In the App Information blade, you can configure some metadata and add an icon.

Click Ok, and Add and wait for the app to be uploaded.

Step 4 – Assign it

Select the Skype for Business app, Assignments, then assign it to a User and/or Device group as a Required install.

(Note: At the time of writing this post, Available install isnt an option)

Intune Macos Lob

Don’t forget to click save.

On Intune enrolled Mac’s, Skype for Business will be installed seamlessly and be ready for use.

Tip: If you want to watch the progress of the install, open the Console utility on the Mac and filter for the Bundle ID. (For Skype this is com.microsoft.package.Microsoft_autoUpdate.app)

• Use filter for App keywords: “Skype”

Filter on the Thread ID for app download and installation

Other handy filters for troubleshooting are mdmclient and Company Portal

** EDIT **

Due to constant requests, I’ve updated this solution to use newer authentication methods that allow MFA as well as native support in PowerShell 7.

Please note – the code below is provided as reference material only – authentication is NOT the point of the article and there are countless ways to acquire the correct authentication token.

***

Hi All and welcome.

As I am about to reach the pointy end of a project to implement an Intune MDM solution for a client, I’ve taken a moment to take stock of the lessons learned, problems faced and for the most part; the cool things I’ve run into and decided now is the time to start writing about them! Hopefully you find my posts interesting and I hope to keep the page updated fairly regularly.

Anyway, lets move onto the fun stuff!
As I mentioned, I’ve been working on an Intune MDM solution for a client who currently has no other management solutions in place (no SCCM, no mobile device management, nothing, nada, zilch. you get the idea) which was daunting to say the least, but it did give us a great opportunity to provide an entirely cloud-centric management solution (absolutely no on-premise requirements – devices are not domain-joined!).

Intune Macos Support

Because of these design decisions, we have had to be very creative with how we deploy applications & how we can replicate group policy configurations – what that essentially means is that we relied very heavily on the Intune Management Extension – previously known as sidecar.

Because Intune currently only allows single file line-of-business applications, for anything more complex than that (read: most legacy LOB applications), handling the installation using Powershell via the Intune Management Extension is the best solution.

Now, while I am ecstatic that there is a script deployment solution within Intune; there is definitely challenges with the current implementation – case in point, the client reached out to me and asked me a very good question the other day… “how can we re-run the script if the script returned a successful result, but the expected result of the script was not achieved??”

A quick explanation – The way that the Intune Management Extension handles execution of scripts is that it will attempt to run the script until it successfully completes. If it fails, it will attempt again in an hour (the Intune Management Extension synchronizes to Intune once every hour), however if for any reason you want a script to re-run, the only obvious solution is to delete the configuration item from within the Intune portal, recreate the configuration item and restart the IntuneManagementExtension service on the local device (as well as any other device or user that is in the assignment group).

If you are shaking your head and saying “there has to be a better way”, then read on for the solution!

The Intune Management Extension stores details of configuration scripts that have executed in a specific registry location: HKLM:SOFTWAREMicrosoftIntuneManagementExtensionPolicies
If you have a look there, you’ll see a list of executed items – all with unique GUIDs.

Inside each folder, you will see a breakdown of what is stored locally.

As you can see above, the script has downloaded once, there are no errors, and even cooler – the ResultDetails property has the full transcript of the script.

Now, the downside here is that aside from digging into the ResultDetails item property, there isn’t an easy way to decipher which configuration item you are looking at. If you can figure out how to identify the script from the ResultDetails item property, then all that is required to trigger a re-run is to delete that item from the registry and restart the IntuneManagementExtension service on the local device.

Now we are getting somewhere.

Because the configuration items are stored in keys named with GUIDs, this should give anyone with experience with Intune or Azure in general, that if we can get a GUID id, then we should be able to extract more data by using the Graph API.

Alright, lets break down the solution.

First up – lets connect to the API…

In the code below I am using a module written by Jason Thompson called MSAL.PS to allow easy authentication to the Graph API using the new MSAL authentication libraries.

Once we have our authentication token, lets capture some handy information to identify each script stored in the IntuneManagementExtension registry hive.

First up, lets get some info about the device.

Intune Macos App Deployment

Next, using the device id captured above, lets grab some info about the registered user of that device.

and finally, lets capture the script properties from Intune.

Here’s an example of the data returned from the above API call.

Now, using the user id GUID, we simply iterate through each script object stored in Intune, match it up with the policy objects stored locally and present the combined data to the end user.

Here’s the example result of the above snippet – an interactive out-gridview datatable that will pass back any selected objects to the powershell window.

Push Software With Intune

So, for this example, I want to re-run the “ConfigureScheduledTask.ps1” script, so we select that row, hit OK on the Out-GridView to send that object back to the script, and using that object, we simply force a removal of that registry key and restart the IntuneManagementExtension service to trigger the script to re-run.

You will find that the script / policy will re-run almost immediately once the registry key has been removed. This will save you countless hours over the course of setting up your sidecar scripts – something I wish I had worked out at the start of the project and not the end!!

Well that wraps up my first post – I will have the full solution available on my GitHub account, so please have a look, have a play, and if you use the example, or improve the solution, please feel free to let me know below in the comments or on my twitter @powers_hell.

Enjoy,
Ben