Intune Stuff | The Community place for Microsoft Intune, Intune Suite, Autopilot, macOS Management, Copilot for Security.

Manage MacOS with Intune, including Apple Business Manager, Defender Enrollment, Platform SSO, and much more – The Complete Guide Part 2

by | Jun 4, 2024 | Apple, Application Management, Blog, Device Management, Featured Post, Intune, Manuals, Most Popular, Tools, Top Stories | 8 comments

Hi,

As promised, in my previous post Manage MacOS with Intune, including Apple Business Manager, Defender Enrollment, Platform SSO, and much more – The Complete Guide Part 1 here is part 2. In this part i will show you some tips and tricks to look out for. I will be showing you some things about Declarative Device Management, Rapid Security Response, App Deployment and some tools i use to make life easier to manage MacOS. I’ve also written a guide for a base set of intune policies, you can find this here.

Let’s start with Declarative Device Management.

 

 

Declarative Device Management (DDM)

What is Declarative Device Management (DDM)?

This is what apple says about DDM:

Declarative device management is an update to the existing protocol for device management that can be used in combination with the existing MDM protocol capabilities. It allows the device to asynchronously apply settings and report status back to the MDM solution without constant polling. This is ideal for performance and scalability.

Declarative device management gives organizations more confidence that devices are in the desired state and that essential data is kept secure, even without internet connectivity. And from a user perspective, it provides a much more responsive experience.

Status reporting allows a device to share information about its current state, and if there are any changes, these can be reported to the server proactively without having to poll the device for updates. Extensibility is built into the protocol to ensure that declarative management is designed for the present and the future.

I would rather explain it as this, a quote from Oktay Sari (Check out his blog site)

Declarative Device Management is like having a
smart assistant for your devices. You tell it what the
end state should look like, and voilà! It figures out
the ‘ hows ‘ faster than you can say ‘automate my
tasks, please…

 

 

Prerequisites

Before implementing Declarative Device Management (DDM), it is crucial to ensure that the devices being managed have the required hardware and software capabilities. Compatibility with the operating system, firmware, and management tools is essential for a successful implementation.

DDM necessitates devices running at least iOS/iPadOS 15 and macOS 13. These operating systems introduce the necessary features and frameworks to enable autonomous decision-making based on predefined rules and configurations. Therefore, it is important to verify that the devices in your organization meet these requirements before adopting DDM.

 

 

Software Updates

Declarative Device Management (DDM) facilitates the automated scheduling of software updates, ensuring that devices remain current with the latest patches and enhancements. By defining update policies and schedules, you can ensure timely and efficient software updates across your managed device fleet.

With DDM, you can set rules within the declarative data model that dictate how software updates should be managed on devices. These rules can include criteria such as update availability and scheduling preferences. Devices autonomously check for available updates based on these predefined rules and apply them accordingly.

 

 

How does it Work

DDM employs three key principles to enhance the software update process, surpassing traditional MDM setups:

  • Firstly, for configurations, your MDM instructs the device on how to handle updates. The device then executes these guidelines while also notifying and empowering the user to initiate updates at their convenience.
  • Secondly, predicates serve as the foundation for logical operations that dictate the sequence of software updates. This includes managing both seed builds and critical security patches that become available on the device.
  • Lastly, real-time status reporting ensures that administrators are promptly informed of any issues, allowing for immediate action.

 select all these settings

 

Setup the Intune Policy

Go to Intune Portal – Devices – MacOS – Configuration Profiles – Create – New Policy – Platform MacOS – Profile type Settings Catalog – Create

Name your policy e.g MacOS – Declarative Device Management and give a description if you want.

Click Add settings and browse to Declarative Device Management

Click on Software update and click select all these settings

Configure the settings:

  • Details URL: Enter a web page URL that has more information on the update. This site has all the info regarding the MacOS versions: https://developer.apple.com/documentation/macos-release-notes
  • Target Build Version: Enter the target build version to update the device to, like 20A242.
  • Target Local Date Time: Enter the local date time value that specifies when to force the installation of the software update. This setting uses the yyyy-mm-ddThh:mm:sss format.
  • Target OS Version: Enter the target OS version to update the device to. Here you can get the version numbers: https://support.apple.com/en-us/109033

These settings will update your MacOS device to the latest Sonoma update by 07/06/2024

Click next, fill in scope tags if you have them, assign the policy to your desired group and click create

Your policy will look like this:

As the policy arrives on your device you will get a pop-up like this:

This is not a notification from my machines as they are already on 14.5, this is a screenshot i took from the internet

Delay visibility of updates

When configuring managed software updates, you might want to hide updates from users for a specific time period. To do this, use a settings catalog policy that sets an update restriction.

A restriction period allows you to test an update before it becomes available to users. Once the restriction period ends, users will be able to see the update. If your update policies haven’t already installed it, users can then choose to install the update themselves.

To create a restrictions policy, navigate to the Settings catalog > Restrictions. Some settings you can use to defer an update include:

  • Enforced Software Update Delay
  • Enforced Software Update Major OS Deferred Install Delay (macOS)
  • Enforced Software Update Minor OS Deferred Install Delay (macOS)
  • Enforced Software Update Non OS Deferred Install Delay (macOS)

 

Settings explained:

  • Enforced Software Update Delay:
    Sets how many days to delay a software update on the device. With this restriction in place, the user doesn’t see a software update until the specified number of days after the software update release date. This value is used by Force Delayed App Software Updates and Force Delayed Software Updates. Requires a supervised device in iOS. Available in iOS 11.3 and later, and macOS 10.13.4 and later.
  • Enforced Software Update Major OS Deferred Install Delay:
    This restriction allows the admin to set how many days to delay a major software update on the device. When this restriction is in place the user sees a software update only after the specified delay after the release of the software update. This value controls the delay for Force Delayed Major Software Updates. Available in macOS 11.3 and later.
  • Enforced Software Update Minor OS Deferred Install Delay:
    This restriction allows the admin to set how many days to delay a minor OS software update on the device. When this restriction is in place the user see a software update only after the specified delay after the release of the software update. This value controls the delay for Force Delayed Software Updates. Available in macOS 11.3 and later.
  • Enforced Software Update Non OS Deferred Install Delay:
    This restriction allows the admin to set how many days to delay an app software update on the device. When this restriction is in place the user sees a non-OS software update only after the specified delay after the release of the software. This value controls the delay for Force Delayed App Software Updates. Available in macOS 11.3 and later.

 

With these settings in place you can configure multiple policies to create different update rings.

 

A policy that reports Success only means that the configuration successfully installed on the device. Monitor the OS version of targeted devices to ensure that they update. After devices have updated to a later OS version than configured in the policy, the policy will report error as the device sees this as an attempt to downgrade. It’s recommended to remove the older OS version policy from devices in this state.

 

Wrap Up

Declarative Device Management (DDM) is a groundbreaking approach that enables mobile devices to operate autonomously and proactively. By allowing devices to make decisions based on predefined rules, DDM enhances performance, scalability, and security.

With DDM, organizations can enjoy several advantages. Improved performance and scalability are achieved as devices function independently and efficiently, minimizing the need for constant supervision. This results in faster response times in large-scale deployments and frees up valuable resources for other strategic initiatives.

Enhanced security and compliance are also significant benefits of DDM. By enforcing predefined rules and configurations, organizations can ensure that devices adhere to established guidelines. Policies related to password complexity, encryption requirements, app installation permissions, network access controls, and more are automatically enforced by the devices themselves.

In conclusion, Declarative Device Management revolutionizes mobile device management practices by empowering devices to operate autonomously based on predefined rules.

 

Moving on……

 

 

Rapid Security Response

What is Rapid Security Response?

Rapid Security Responses deliver important security improvements between software updates.

Rapid Security Responses are a new type of software release for iPhone, iPad and Mac. They deliver important security improvements between software updates – for example, improvements to the Safari web browser, the WebKit framework stack or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that may have been exploited or reported to exist.

New Rapid Security Responses will only be delivered for the latest versions of iOS, iPadOS and macOS, starting with iOS 16.4.1, iPadOS 16.4.1 and macOS 13.3.1.

By default, your device will apply Rapid Security Responses automatically. If necessary, you’ll be prompted to restart your device. To check your device settings:

  • iPhone or iPad: go to Settings – General –  Software Update – Automatic Updates, then make sure “Security Responses & System Files” is turned on.
  • Mac: choose Apple menu  – System Settings. Click General in the sidebar, then click Software Update on the right. Click the Show Detail button next to Automatic Updates, then make sure “Install Security Responses and system files” is turned on.

The latest versions of iOS/iPadOS 16.4.1 (a) and macOS 13.3.1 (a) represent a significant shift in how Apple releases OS updates. These updates introduce Rapid Security Response (RSR) for the first time on iPhones, iPads, and Macs. This new feature enables faster delivery of security updates, allowing for more frequent and timely fixes to security vulnerabilities. RSRs are included in subsequent minor updates, not major upgrades, and on a Mac, the updated content appears on the Preboot volume.

There was considerable excitement surrounding the launch of RSR from Apple following its initial announcement. However, the actual release encountered numerous difficulties and unforeseen challenges, resulting in a tumultuous experience. Some of these challenges included:

  • A completely new naming convention for the OS.
  • Compliance policies in Microsoft Intune not being ready to adapt to the new naming convention.
  • Issues with rules and policies configured in Microsoft Defender for Endpoint.
  • Conditional Access Policies causing issues due to new iOS/iPadOS or macOS build numbers.

To navigate these changes effectively, it is essential to understand the new updates and how they can be managed on supervised devices. Knowing the installation behavior and how to control it is crucial for achieving the best results.

To fully understand the rapid security updates, I’ve broken down the information into several key points:

  • Restart Requirement: Rapid Security Responses (RSRs) intended for the operating system require the device to restart.
  • Automatic Updates: If enabled, these responses can occur automatically without user permission, provided the response is not for the OS.
  • User Interaction: Once the device requests the RSR update, it will be downloaded, giving users only a 10-second window to click “Not Now.”
  • Update Duration: The update process takes approximately 5-10 minutes from start to finish, depending on your internet connection.
  • Update Size: The download size is around 85MB. While the installation takes a bit longer, the restart process is relatively quick.
  • macOS Specifics: On macOS, updated operating system content can be made available to Safari and associated processes with a simple relaunch. However, a restart is required to make this content broadly available across the operating system.
  • iOS & iPadOS Specifics: On iOS and iPadOS, enterprise applications in the foreground may need to be restarted, potentially leading to data loss if not managed properly.
  • Uninstallation Option: By default, users have the option to uninstall or remove the responses.
  • Software Update Delay: RSRs do not adhere to managed software update delays.
  • Intune Software Deferral: If a software deferral policy is enforced from Microsoft Intune, the response is effectively delayed because they apply only to the latest minor operating system version.

 

 

Setup the Intune policy

Go to Intune Portal – Devices – MacOS – Configuration Profiles – Create – New Policy – Platform MacOS – Profile type Settings Catalog – Create

Name your policy e.g MacOS – Rapid Security Response and give a description if you want.

Click Add settings and search for Rapid Security Response and Click Select all these settings

 

If your organization is not ready to install Rapid Security Response (RSR), you can disable it by toggling the “Installation” option to “False.” This will prevent RSR from being visible on end users’ devices, effectively disabling it for users. !This is not recommended, as it will leave the device vunerable to threats!

 

Click next, fill in scope tags if you have them, assign the policy to your desired group and click create

Your policy will look like this:

 

To block users from removing the security response, toggle the “Removal” option to “False”. When enforced, the users will not see any option to remove the installed update.  Push the policy to your test devices first. Review the effects and, when ready, go for a production rollout.

 

 

Device experience

If you go to the System settings – Software Update and your screen looks like this, your RSR is not yet enabled

If you see an a behind the OS Version that means that RSR is active on your device (As my device is fully up to date, this is a random screenshot from the internet)

 

 

Wrap Up

Allowing major build upgrades on managed devices without thorough testing and user approval can lead to severe disruptions in business applications, unsatisfactory user experiences, and significant financial losses.

Therefore, it is imperative to exercise utmost caution and diligence when upgrading operating systems. To avoid these issues, responses are tailored to the minor version of the OS and provided between major updates, ensuring a smooth and seamless experience for users. However, it appears that the release of these Rapid Security Response updates was premature. MDM systems still need to adjust a few configurations on the back end before these responses can be effectively rolled out at the enterprise level.

 

 

Application Deployment

As Application Deployment for MacOS also has the options as for Windows, regarding Office apps and Egde,  there are some differences and considerations to keep in mind.  We do have the same types of apps however there is some difference in the behavior. In this post we will zoom in on the Line-of-business (LOB), DMG and PKG apps.

 

Prerequisites

  • Devices enrolled in Intune
  • The PKG or DMG file is smaller than 8 GB in size
  • 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 (Available assignment)
    • LOB apps need to be signed
    • For LOB PKG apps the file limit is 2GB
    • have some other prerequisites so check out the docs.

 

PKG LOB Apps Managed vs Unmanaged

App Requirements

The .pkg file must satisfy the following requirements to successfully be deployed using Microsoft Intune.

  • The .pkg file is a component package or a package containing multiple packages.
  • The .pkg file does not contain a bundle or disk image or .app file.
  • The .pkg file is signed using a “Developer ID Installer” certificate, obtained from an Apple Developer account.
  • The .pkg file contains a payload. Packages without a payload will attempt to re-install as long as the app remains assigned to the group.

 

The .pkg file must be signed using “Developer ID Installer” certificate, obtained from an Apple Developer account. Only .pkg files may be used to upload macOS LOB apps to Microsoft Intune.

 

Managed vs Unmanaged Apps

You might have noticed if you are deploying an app with intune you have to choice to set it as managed or unmanaged

There is a big difference here, according to Microsoft this is their explanation:

Install as managed: Select Yes to install the Mac LOB app as a managed app on supported devices (macOS 11 and higher). A macOS LOB app can only be installed as managed when the app distributable contains a single app without any nested packages and installs to the /Applications directory. Managed line-of-business apps will be able to be removed using the uninstall assignment type on supported devices (macOS 11 and higher). In addition, removing the MDM profile removes all managed apps from the device. The default value is No.

Also very important is the 1st requirement, stated above: The .pkg file is a component package or a package containing multiple packages.

If we grab for instance the Company Portal app you will see this app consists out of many other packages. I have set the install as managed to no

If i set the installed as managed to Yes we get this:

This is because the Company Portal app also installs other packages.

Now let see the behavior on another PKG file, let’s try Chrome. As you can see we now can install the package as a managed app, this will give us the advantage that we will be able to remove the app and also use the uninstall assignment option

First lets check the Install as managed set to no:

At the Assignment section we do not have the uninstall option

Now we set Install as managed to yes, the category selection also appears and the Show this as a featured app in the company portal

And now we do have the uninstall option at the Assignments selection

So this is the BIG difference between managed vs unmanaged apps. To conclude, if you use 3th party software it depends on that software if you can uninstall the package or not.

 

DMG apps

Prerequisites & Requirements

The following prerequisites must be met before a MacOS DMG app is installed on macOS devices.

  • Devices are managed by Intune.
  • DMG app is smaller than 8 GB in size.
  • The Microsoft Intune management agent for MacOS is installed.

 

The full disk access permission is required to update or delete DMG apps. Intune automatically requests the permission when a DMG app policy is assigned on macOS 13 and higher.

A single DMG should only contain a single application file or multiple application files that are dependent on one another. The containing application files can be listed under the Included apps section in the Detection rules tab in order starting with the parent app to be used in reports.

It is not recommended that multiple apps that are not dependent on each other are installed using the same DMG file. If multiple independent apps are deployed using the same DMG app, failure to install one app will cause other apps to be re-installed. In this case, monitoring reports consider the DMG installation a failure as well.

You can update apps of type macOS apps (DMG) deployed using Intune. Edit a DMG app that is already created in Intune by uploading the update for the app with the same bundle identifier as the original DMG app. In addition, you must use the Microsoft Intune agent for macOS version 2304.039 or greater.

 

Bundle ID & App version

During the deployment of the app intune at the detection rules section you will see a line called Ignore app version, i will explain this further in the next section of this guide. Now i want to talk about the Bundle ID and App version

 

You will need this to let intune detect a successful installation. Now where can you find these?

Let’s say we want to install Firefox DMG with intune. On your Mac download the Firefox DMG file and install it. To get the bundle identifier (also known as the bundle ID), Control-click the application, then select Show Package Contents. Open the Contents folder, then open the Info.plist file. If you aren’t sure which app to use, open the file in TextEdit. Use the app’s Find feature to find CFBundleIdentifier and CFBundleShortVersionString in the file, then copy the strings below that line.

Now you can add this info into intune and you are ready to deploy this app

 

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

 

Now let’s move on to Ignore app version

 

Ignore App version

This is what Microsoft says:

Ignore app version: Select Yes to install the app if the app is not already installed on the device. Select No to only install the app when it is not already installed on the device, or if the deploying app’s version number does not match the version that’s already installed on the device.

So we only select Yes is the app is installed on a fresh device period.

Select no if the app is installed on a fresh device or when you need to update the app to another version when a previous version is already on the device.

Intune Config & Device Experience

So lets say you want to update Firefox. I have Firefox 123.0.1 ready for deployment in intune with ignore app version set to no.

You can see that version 123.0.1 is installed on my device

To update the app replace the current file with the new version and change the name

And in the detection rule edit the app version

Now when checking in intune the app is updated but the version is still the same

However on my device it says 126.0.1

After a few minutes also intune reflects the new version

 

Wrap Up

Oktay Sari showed us a nice table during his presentation about the ignore app version.

Consider the “Ignore app version” setting in Intune as the relaxed choice when configuring app installations. If you select “Yes,” you’re essentially inviting the app to access the device as long as it’s not already installed. This choice doesn’t worry about the specifics – it simply verifies the presence of the app’s bundle ID. It is extremely useful for apps that automatically update.
However, changing it to “No” makes it more specific. The app will only be allowed to install if it is completely new to the device or if the version being deployed is not the same as the one already installed.
Therefore, say “Yes” for simple installations, and “No” for situations requiring more detailed instructions!

 

Imazing Profile Editor

With Imazing Profile Editor you can Create, Edit, and Sign Apple Configuration Profiles
It is a free app to easily define settings that are ready to be deployed locally or via MDM to fleets of iPhones, iPads, Macs, and other Apple devices. It is available for MacOS and also for Windows. Start by downloading and installing it onto your device. I will show you how to get a custom configuration profile in minutes. The app consists of a lot of settings you can alter, including app settings, in this example we will be doing some custom config for Chrome. Make sure you check the other settings, i’m sure you will find this a super handy tool!

In the app scroll down to Google Chrome and click Add Configuration Payload

 

 

Let’s say we want to add some managed bookmarks. Click Misc on the top toolbar

Now scroll down to the Managed Bookmarks section and fill in some details

Now click on File – Save As – Name the file and save it somewhere

Now you can upload this file in intune. I have Chrome installed on my device but no config is here

Go to the intune portal – Devices – MacOS – Configuration profiles – Create – New policy – Platform MacOS – Profile type Templates – Template Name Custom. Name you policy e.g. MacOS – Chrome Bookmarks. Enter a profile name e.g. Chrome Bookmarks and set the deployment channel to device as we are going to assign this policy to a device group.

Browse for the saved file you have created with Imazing and click next

Assign the policy to your desired group and create it. Now you can do a sync on your device to get the new policy.

After a few seconds open Chrome and you can see that our profile has been added.

This is just 1 of the cool features you can do with this app. Just play around with it and you it will make your life a lot easier!

 

This completes part 2 and final part of this guide. I hope you have enjoyed it and has cleared some stuff up for you!

 

8 Comments

  1. Khang Nguyen

    Thanks for your awesome two part guides. It helped me a lot. Can you create one for how to monitor USB file write activity with Microsoft Defender, Microsoft Purview?

    Reply
    • Joery

      Hi, purview is not my focus at this point in time.

      Reply
  2. James

    Hi joey great blogs, do you have any guide how to setup lab env for macos with vmware? or vm

    Reply
    • joery

      Hi james,

      I use parralels on my mac to create macos vm’s

      Reply
      • Marc

        How can you create a VM in Parallels which you can add to ABM?

        Reply
        • joery

          VM in ABM is a hassle, basically not possible but possible 😉

          Reply
          • Marc

            I would love some kind of help if possible 😉

  3. Greg

    do you have any information/ experience with implementing authorization groups within the PSSO profile?… specifically, I’d love to know what they are or see a list…I haven’t found any good documentation online about it. For PSSO, my goal would be to have users created as “Standard” but then authorize them to perform some common tasks (like install a printer, for example).

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from IntuneStuff

Subscribe now to keep reading and get access to the full archive.

Continue reading