With the release of macOS Sonoma 14.x (I think it was 14.1) a new alert notification was introduced which indicated the user that a new/updated payload of a password restriction was received by the Mac.

After the policy is received the local account password is no longer accepted and the user has to change it in System Settings or, as mentioned in the notification, log out and log in again.

This is in my opinion a great improvement for the user experience. The challenge in my experience here is, that with the macOS default behavior for notifications is the alert type ' Banner'. Banners appear in the upper-right corner and go away automatically. The user might not see the notification and is confused that the local account password does not work anymore in the current session.

But luckily with the help of Apple Care Enterprise engineers (hat tip) I have now the App Bundle Identifier to create a notification settings profile. In the example below you find a profile for com.apple.ManagedClient.PasscodeUserNotification2 which changes the Alert Type to ‘Alerts’. Alerts stay on screen until dismissed.

<?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>NotificationSettings</key>
			<array>
				<dict>
					<key>AlertType</key>
					<integer>2</integer>
					<key>BadgesEnabled</key>
					<true/>
					<key>BundleIdentifier</key>
					<string>com.apple.ManagedClient.PasscodeUserNotification2</string>
					<key>CriticalAlertEnabled</key>
					<true/>
					<key>GroupingType</key>
					<integer>0</integer>
					<key>NotificationsEnabled</key>
					<true/>
					<key>PreviewType</key>
					<integer>1</integer>
					<key>ShowInCarPlay</key>
					<true/>
					<key>ShowInLockScreen</key>
					<true/>
					<key>ShowInNotificationCenter</key>
					<true/>
					<key>SoundsEnabled</key>
					<true/>
				</dict>
			</array>
			<key>PayloadDisplayName</key>
			<string>Notifications</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.notificationsettings.99163D44-2ADB-4669-AAC2-84F41DF4377E</string>
			<key>PayloadType</key>
			<string>com.apple.notificationsettings</string>
			<key>PayloadUUID</key>
			<string>99163D44-2ADB-4669-AAC2-84F41DF4377E</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Notification settings for com.apple.ManagedClient.PasscodeUserNotification2</string>
	<key>PayloadDisplayName</key>
	<string>Notification Settings </string>
	<key>PayloadIdentifier</key>
	<string>applefreakz.3797D291-714A-466F-A248-B5D3EF325FA2</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>3797D291-714A-466F-A248-B5D3EF325FA2</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

Hope some of you find this tidbit helpful for your environment.

Fixed 😎

This issue was fixed with the release of IntuneMDMAgent version 2404.005. Please check here for more information.

Understanding the problem

During extensive testing of Intune enrollments with macOS Sonoma beginning of January (find here why), a colleague of mine mentioned an unexpected behaviour of machines installing applications on reboots. This seams interesting to investigate further.

So I analysed this behaviour in some virtual machines and on the Macs of my colleagues.

1. I figured out that the apps (PKG and DMG) in question where installed before the reboot with the Intune installation intent ‘required’.
2. This could be just a few hours ago on the speciific machine or can happen weeks after the inintial install.
3. Before the reboot I was able to confirm that the applications are installed and should be detected by IntuneMDMAgent.
4. Currently I can not reproduce this on every reboot in our setup but it happens a lot.

State of analysis

I was able to check if apps are successfully installed by querying installed apps with the following command and output the result to a file before a reboot.

Just use the following command via Terminal:

sudo /usr/libexec/mdmclient QueryInstalledApps > installedApps.txt

This will give you a verbose output of the detected app on the specific machine.

On the affected machines I perfomed a shutdown and booted the machine some minutes later. Now, I checked the /Applications folder for required apps and ‘Date modified’ changed to the current time before analysing the IntuneMDMDaemon.log file for suspicious activities.

It looks like that the apps are installed, but the detection of already installed apps fails for no obvious reason.

2024-01-19 11:39:54:236 | IntuneMDM-Daemon | E | 5244 | AppDetection | Error in getting requirement for apps. Error: AppDetectionError.errorGettingBundleIDAsString, PolicyID: 3bc5b6c6-33dc-4ce2-80fa-9f8830b5d6c7, AppName: Microsoft OneDrive, BundleID: com.microsoft.OneDrive

Ticket at Microsoft I opened a ticket at Microsoft. End of last week Intune Product group confirmed this is reproducable and other customers also reported this behaviour. I will update the post if I get more information what is the root cause and a potential fix.

Update #1 - 2024-03-25 20:20 CET There is some good news regarding this issue. I am currently testing an updated version of Sidecar Agent (IntuneMDMAgent) which fixed the detection. The detection is now very stable. Once the update is available I will share how you can verify that the new Agent is on your machines.

Update #2 - 2024-03-30 10:30 CET Microsoft now released the Company Portal version (20240301). The Sidecar Agent version included in this release verified by checking the IntuneMDMAgent in ‘/Library/Intune/IntuneMDMAgent.app’.

Update #3 - 2024-04-09 20:45 CEST

ISSUE FIXED!

Yesterday I received the most current version of IntuneMDMAgent (2404.005) that fixed this issue in all my tests. I tried reproducing with multiple VMs and Macs the issue in the last two days. I was not able to get these machines with over 100 reboots or shutdowns to show the reported behavior. I closed the ticket now at Microsoft.

You can easily check the version of the Sidecar Agent in Terminal with the defaults read command. To get an overview of all Agent versions in a fleet, I will create a ‘Custom Attribute’ in Intune. I created a little bash script:

#!/bin/bash
#Check Intune Agent (sidecar agent) version
defaults read /Library/Intune/Microsoft\ Intune\ Agent.app/Contents/Info.plist CFBundleShortVersionString

Now you can create a ‘Custom Attribute’ in the Intune Admin center. Go to ‘Devices -> macOS -> Custom attributes’ and click on the ‘Add’ bottom.

In the first screen ‘Basic’ choose a name and add a description for your custom attribute and click ‘Next’.

On the next page ‘Attribute settings’ choose ‘Data type of attribute’ = String and upload the script I showed you above. Afterwards, you can finish the creation of the new custom attribute by adding scope tags in step 3, assign the attribute to all your machines or users as you like and lastly add it.

Now you will always have a nice overview of all the machine’s currently reported IntuneMDMAgent version in case you want to dig deeper.

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.