Apple released with iOS 17.4 and iOS 17.5 with two minor updates for users in the European Union to comply with the EU’s Digital Markets Act new features. In these releases users located in the EU have the possiblity to install 3rd party App Stores (aka Marketplaces in 17.4) and to download iOS apps directly from websites (aka Web Distribution in 17.5). If you wanna block users to install these on managed, corporate devices you can find here how.

What does this mean?

You can find a very detailed description what was changed in this Apple support document.

New for enterprise admins

In case you want to block one or both new distribution methods of apps you can do this quiet easy with two new device restrictions that are supported on supervised devices.

1. allowMarketplaceAppInstallation - iOS 17.4 includes a new Restriction key to prevent installing third-party app marketplaces on supervised iPhones in the EU.
2. allowWebDistributionAppInstallation - iOS 17.5 includes a new Restriction key allowWebDistributionAppInstallation to prevent installing apps through Web Distribution on supervised iPhones in the EU.

These already known restriction keys were updated to apply as well to the new distribution methods above:

• allowAppInstallation
• allowAppRemoval
• allowListedAppBundleIDs
• blockAppBundleIDs

The unexpected problem

What I mentioned during testing and deployment of the new settings as custom profiles via Microsoft Intune is that you have to be a little careful. This is because you can deploy this settings to all your devices and the profile reporting looks nice and clean. This is not working as you would expect on your devices. If you assign this configurations to iOS devices before 17.4 (allowMarketplaceAppInstallation) or before 17.5 (allowWebDistributionAppInstallation) is installed the report shows a successful deployment but the restriction does not apply (does not show in the management profile locally) and is not re-applied after the OS update is installed.

To overcome this (IMHO implementation flaw in iOS restrictions that is not taken in account by Intune) you can create to assignment filters that look like this.

Warning: You have to maintain them with upcoming iOS releases. I just added a few minor and patch versions in advance that may not be released ever to be prepared.

Go to Intune admin center -> Tenant administration -> Filters and create two new filters for the Platform ‘iOS/iPadOS’. I used in this example rule syntax a combination of the ‘device.enrollmentProfileName’ to target only supervised devices and a ‘device.osVersion’ list of ‘17.4 to 17.6.3’ and ‘17.5 to 17.6.3’ respectively. Edit: You can after the 2408 Intune release use -ge, -gt, -le and -lt operators in preview. This simplifies the filters. I added the simplified filters below

Filter name: iOS 17.4+

((device.enrollmentProfileName -eq "YourEnrollmentProfileName") and
(device.osVersion -in
["17.4","17.4.1","17.4.2","17.4.3","17.5","17.5.1","17.5.2","17.5.3","17.6","17.6.1","17.6.2","17.6.3"])

Filter name: Simplified iOS 17.4+

((device.enrollmentProfileName -eq "YourEnrollmentProfileName") and
(device.osVersion -ge "17.4")

Filter name: iOS 17.5+

((device.enrollmentProfileName -eq "YourEnrollmentProfileName")
and (device.osVersion -in
["17.5","17.5.1","17.5.2","17.5.3","17.6","17.6.1","17.6.2","17.6.3"])

Filter name: Simplified iOS 17.5+

((device.enrollmentProfileName -eq "YourEnrollmentProfileName")and (device.osVersion -ge "17.5")

Now you can simply add this filters to the respective custom profiles and you will not see this unintended behavior.

Edit: Martijn van Loenhout mentioned that allowMarketplaceAppInstallation is now (Service release 2403) already available as Setting Catalog configuration in Intune. You can use this for sure as well if you prefer this.

applefreakz-allowmarketplaceappinstallation-false.mobileconfig:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>PayloadDisplayName</key>
			<string>Restrictions</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.applicationaccess.24BB5BE8-DCB8-4876-9F16-7C6D25CABF78</string>
			<key>PayloadType</key>
			<string>com.apple.applicationaccess</string>
			<key>PayloadUUID</key>
			<string>24BB5BE8-DCB8-4876-9F16-7C6D25CABF78</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>allowMarketplaceAppInstallation</key>
			<false/>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Block third-party app marketplaces</string>
	<key>PayloadDisplayName</key>
	<string>applefreakz_allowMarketplaceAppInstallation-FALSE</string>
	<key>PayloadIdentifier</key>
	<string>de.applefreakz.987A43C8-F8E8-4636-8C82-9FDAD46AB686</string>
	<key>PayloadOrganization</key>
	<string>applefreakz</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>CDC18090-077D-48BF-9621-86ECFAA3C327</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

applefreakz-allowwebdistributionappinstallation-false.mobileconfig

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>PayloadDisplayName</key>
			<string>Restrictions</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.applicationaccess.BFB998BC-3E8B-4252-816E-A6795D302D34</string>
			<key>PayloadType</key>
			<string>com.apple.applicationaccess</string>
			<key>PayloadUUID</key>
			<string>BFB998BC-3E8B-4252-816E-A6795D302D34</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>allowWebDistributionAppInstallation</key>
			<false/>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Block app installation through Web Distribution</string>
	<key>PayloadDisplayName</key>
	<string>applefreakz_allowWebDistributionAppInstallation-FALSE</string>
	<key>PayloadIdentifier</key>
	<string>de.applefreakz.8AE1F450-602E-4156-B149-CE1E9CD0F469</string>
	<key>PayloadOrganization</key>
	<string>applefreakz</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>E5A4DE5C-E468-40A9-B4C4-D2D2D063E3DE</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

In the management profile you will see two new restrictions like this:

Understanding the problem

I mentioned that during enrollments of Macs with macOS 14.x the installation for applications is stopping without any obvious reason.

I started analysing what could be the problem and found an interesting workaround for this behavior. The apps in question include a variety of types supported by Intune:

• Volume Purchasing Program (VPP) apps: These are apps purchased in bulk from the App Store.
• DMG Installers: Standalone installations via diskimages for macOS.
• PKG Installers: Installation packages for distributing software on macOS.
• Shell scripts: Used for specific installations, like the Company Portal.

Intune, a Microsoft service used for device management, encounters a particular challenge with macOS: it does not prioritize or order app installations, nor does it handle dependencies. This lack of structured installation order can result in my experience to unpredictable and inconsistent app deployment.

Reproducing the issue

For example, I identified specific scenarios that halt the installation process:

1. Network switching: Changing from an ‘enrollment WiFi’ to a managed WiFi profile.
2. System Extension Installations: Installing a PKG that includes a network system extension, especially when combined with allowing explicit system extension policies.
3. VPN Connection: Initiating a VPN connection before the completion of all app installations.

Each of these scenarios can disrupt the installation process, often seen during the device enrollment phase.

User experience

When these interruptions occur, app installations simply stop, leaving users without a clear resolution. This issue can be particularly challenging as it can happen at multiple stages:

1. During a WiFi switch.
2. While installing any network system extensions (in my tests in total three).
3. At the initiation of a VPN connection.

Unfortunately, even if Microsoft’s Company Portal is installed, syncing the device doesn’t rectify this issue. A device reboot can temporarily restart the installations, but they may halt again upon encountering the same interruptions.

Developing a workaround

Analyzing the IntuneMDMDaemon.log file revealed key insights. For instance, an error in the log for Microsoft Edge showed an issue with downloading the app binary file. This suggests that the IntuneMDMDaemon struggles to download the necessary packages, leading to halted installations without any retry mechanism.

2024-01-25 07:10:01:920 | IntuneMDM-Daemon | I | 13242 | AppInstallManager+Logging | Error downloading app binary file. PolicyID: 37432470-3dcd-4835-ba9a-df66c4102601, AppName: Microsoft Edge, ExitCode: -2016214735, ErrorDetails: Cannot download app binary file.,ComplianceState: Error, EnforcementState: Error

The Script Solution

To circumvent this, I developed a shell script that:

• Checks the status of required apps.
• Restarts the IntuneMDMDaemon process if an app is found installed or
• if the initial VPN connection was successful.Currently, the script does not address WiFi changes, but this may be incorporated later if necessary.

Workaround Challenges

An interesting observation was that restarting the IntuneMDMDaemon inadvertently triggers the shell script again. To prevent repetitive executions, I incorporated a check to determine if the script had already been initiated but not all apps were installed.

Vendors involved

Currently I have an open ticket at the Microsoft Intune support as well as a sibling ticket at Apple Care Enterprise. Currently, the MS ticket is analysed and hopefully the root cause of this can be found. I will update the post with new information from both cases.

Update #1 - 2024-01-31 08:10 CET

Intune Product Group confirmed that the implementation of IntuneMDMDaemon/Sidecar in Company Portal for macOS is not handling the installation of systemextensions gracefully. They are now aware and working on a fix in an upcoming Company Portal for macOS release. I emphasised that it would be good to check the two other problems (WiFi change during downloads and connecting to a VPN during downloads) and address them as well in the upcoming update if possible.

Update #2 - 2024-02-05 07:20 CET

I published my workaround bash script on my GitHub account. Maybe you wanna check it out and I would be happy to get feedback if something can be done more elegant or if I did any major error in it.

Update #3 - 2024-04-09 22:10 CEST

Two days ago the IntuneMDMAgent version 2404.005 was released by Microsoft (more information how to check for the version here) This new version introduced a new mechanism of retrying app binary downloads. Currently, this has three attempts of downloading the binary. This significantly improved the enrollment flow and might work a lot better for some Intune macOS admins. This is a great achievment. Sadly, it does not fully solve my issue with the more than three interuption we face during our enrollents. I will create reproductions of my issue and report this to Microsoft.