{ "version": "https://jsonfeed.org/version/1", "title": "csh's toolbox", "icon": "https://avatars.micro.blog/avatars/2024/40/7414.jpg", "home_page_url": "https://applefreakz.de/", "feed_url": "https://applefreakz.de/feed.json", "items": [ { "id": "http://csh.micro.blog/2025/08/09/prevent-a-mac-laptop-from.html", "title": "Prevent a Mac laptop from turning on when opening its lid or connecting to power", "content_html": "

Just found this interesting article in my drafts. Apple released some time ago a support article that explains in detail how you can configure your Mac’s power on behavior.

\n

I personally do not like the current default behavior and modified it.

\n

Which team you are in?

\n

Prevent a Mac laptop from turning on when opening its lid or connecting to power

\n", "date_published": "2025-08-09T23:21:01+02:00", "url": "https://applefreakz.de/2025/08/09/prevent-a-mac-laptop-from.html" }, { "id": "http://csh.micro.blog/2025/01/29/configure-notification-settings-for-password.html", "title": "Configure notification settings for Password Policy Updated notification on macOS 14.x and above", "content_html": "

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.

\n\"macOS\n

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.

\n

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.

\n

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.

\n
<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n\t<key>PayloadContent</key>\n\t<array>\n\t\t<dict>\n\t\t\t<key>NotificationSettings</key>\n\t\t\t<array>\n\t\t\t\t<dict>\n\t\t\t\t\t<key>AlertType</key>\n\t\t\t\t\t<integer>2</integer>\n\t\t\t\t\t<key>BadgesEnabled</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>BundleIdentifier</key>\n\t\t\t\t\t<string>com.apple.ManagedClient.PasscodeUserNotification2</string>\n\t\t\t\t\t<key>CriticalAlertEnabled</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>GroupingType</key>\n\t\t\t\t\t<integer>0</integer>\n\t\t\t\t\t<key>NotificationsEnabled</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>PreviewType</key>\n\t\t\t\t\t<integer>1</integer>\n\t\t\t\t\t<key>ShowInCarPlay</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>ShowInLockScreen</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>ShowInNotificationCenter</key>\n\t\t\t\t\t<true/>\n\t\t\t\t\t<key>SoundsEnabled</key>\n\t\t\t\t\t<true/>\n\t\t\t\t</dict>\n\t\t\t</array>\n\t\t\t<key>PayloadDisplayName</key>\n\t\t\t<string>Notifications</string>\n\t\t\t<key>PayloadIdentifier</key>\n\t\t\t<string>com.apple.notificationsettings.99163D44-2ADB-4669-AAC2-84F41DF4377E</string>\n\t\t\t<key>PayloadType</key>\n\t\t\t<string>com.apple.notificationsettings</string>\n\t\t\t<key>PayloadUUID</key>\n\t\t\t<string>99163D44-2ADB-4669-AAC2-84F41DF4377E</string>\n\t\t\t<key>PayloadVersion</key>\n\t\t\t<integer>1</integer>\n\t\t</dict>\n\t</array>\n\t<key>PayloadDescription</key>\n\t<string>Notification settings for com.apple.ManagedClient.PasscodeUserNotification2</string>\n\t<key>PayloadDisplayName</key>\n\t<string>Notification Settings </string>\n\t<key>PayloadIdentifier</key>\n\t<string>applefreakz.3797D291-714A-466F-A248-B5D3EF325FA2</string>\n\t<key>PayloadType</key>\n\t<string>Configuration</string>\n\t<key>PayloadUUID</key>\n\t<string>3797D291-714A-466F-A248-B5D3EF325FA2</string>\n\t<key>PayloadVersion</key>\n\t<integer>1</integer>\n</dict>\n</plist>\n

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

\n", "date_published": "2025-01-29T12:37:52+02:00", "url": "https://applefreakz.de/2025/01/29/configure-notification-settings-for-password.html", "tags": ["macOS"] }, { "id": "http://csh.micro.blog/2024/12/08/change-siris-volume.html", "title": "Change Siri's volume on your HomePod", "content_html": "

I just stumbled over this support article.

\n

Change Siri’s volume on your HomePod

\n

Never thought about telling Siri to talk quieter. The output was always to loud for my taste. In the article you find a section for HomePod:

\n
\n

You can ask Siri to speak louder, quieter, or at a specific volume. Say “Hey Siri,” then say something like:

\n\n

HomePod automatically adjusts Siri’s response volume based on the level of noise in the room, your distance from HomePod, and how loudly you’re speaking to Siri. You can turn automatic volume on or off by saying, “Hey Siri, turn on automatic Siri volume,” or “Hey Siri, turn off automatic Siri volume.”

\n
\n", "date_published": "2024-12-08T01:16:44+02:00", "url": "https://applefreakz.de/2024/12/08/change-siris-volume.html" }, { "id": "http://csh.micro.blog/2024/10/08/vision-pro-reset.html", "title": "Vision Pro 2.0 - Reset after ACE configuration profile stuck downloading", "content_html": "

I recently learned that playing with ADE enrollments of AVPs on an unsupported (not yet) MDM could lead to a device stuck in ‘waiting for configuration’ screen. Restarting device will end in the same screen even after you unassigned the device in ABM.

\n

There was no obvious way to reset the device running visionOS 2.0. I have ask ACE support and there is a way to reset the device if you do the following.

\n
    \n
  1. Press both top buttons. A windows will appear: Apple Vision Pro is not configured.
    2. \n
  2. Go to Accessibility options -> Eye input -> Switch eye input (you need to reconfigure your eye input settings).
    3. \n
\n

Once you did this, an Apple logo with a progress bar will appear and AVP will be reset to factory settings before starting the new calibration progress.

\n

Hopefully that helps if you are playing around like myself.

\n", "date_published": "2024-10-08T14:51:46+02:00", "url": "https://applefreakz.de/2024/10/08/vision-pro-reset.html", "tags": ["VisionOS"] }, { "id": "http://csh.micro.blog/2024/04/16/blocking-ios-thirdparty.html", "title": "Blocking iOS third-party marketplaces and web distribution in the EU", "content_html": "

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.

\n

What does this mean?

\n

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

\n

New for enterprise admins

\n

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.

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

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

\n\n

The unexpected problem

\n

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.

\n

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.

\n

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.

\n

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

\n

Filter name: iOS 17.4+

\n
((device.enrollmentProfileName -eq "YourEnrollmentProfileName") and\n(device.osVersion -in\n["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"])\n

Filter name: Simplified iOS 17.4+

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

Filter name: iOS 17.5+

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

Filter name: Simplified iOS 17.5+

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

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

\n

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.

\n

applefreakz-allowmarketplaceappinstallation-false.mobileconfig:

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

applefreakz-allowwebdistributionappinstallation-false.mobileconfig

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

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

\n\"\"\n", "date_published": "2024-04-16T08:10:00+02:00", "url": "https://applefreakz.de/2024/04/16/blocking-ios-thirdparty.html", "tags": ["iOS"] }, { "id": "http://csh.micro.blog/2024/02/21/issue-with-app.html", "title": "Issue with app re-installation on macOS devices managed by Intune", "content_html": "

Fixed 😎

\n

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

\n

Understanding the problem

\n

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.

\n

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

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

State of analysis

\n

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.

\n

Just use the following command via Terminal:

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

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

\n

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.

\n

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

\n
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\n

Ticket at Microsoft\nI 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.

\n

Update #1 - 2024-03-25 20:20 CET\nThere 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.

\n

Update #2 - 2024-03-30 10:30 CET\nMicrosoft 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’.

\n

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

\n

ISSUE FIXED!

\n

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.

\n\"\"\n

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:

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

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

\n\"\"\n

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

\n\"\"\n

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.

\n\"\"\n

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

\n", "date_published": "2024-02-21T13:13:00+02:00", "url": "https://applefreakz.de/2024/02/21/issue-with-app.html", "tags": ["macOS"] }, { "id": "http://csh.micro.blog/2024/02/13/palo-alto-global.html", "title": "Palo Alto Global Protect (macOS) unable to connect via Personal Hotspot on T-Mobile Germany", "content_html": "

My colleagues recently discovered that users can not connect to Palo Alto Global Protect when using their Mac via Personal Hotspot. After some tests, we could nail it down that this only affects users that are using a Personal Hotspot via an iPhone on mobile carrier T-Mobile Germany. Other SIMs by other carriers in the same iPhone worked just fine.

\n

We had some challenges before with T-Mobile Germany using IPv6-only as default in their cellular network with other software vendors.

\n

Today I found in the MacAdmin Slack a thread by others reporting the same issue. I was reminded by colorenz in this thread that you still can use the old APN internet.telekom as a temporary workaround. Matthew G also provided some insides which point to DS-Lite/IPv4-over-IPv6 as root cause and that a fix is on its way. Thanks again macadmins Slack community!

\n

I will try getting a confirmation and ETA from Palo Alto for that.

\n

If you wanna change APN settings this manually go to Settings - Cellular - Select the SIM you wanna modify - Cellular Data Network and change the second APN under Personal Hotspot to internet.telekom.

\n\"Screenshot\n", "date_published": "2024-02-13T23:33:00+02:00", "url": "https://applefreakz.de/2024/02/13/palo-alto-global.html", "tags": ["macOS"] }, { "id": "http://csh.micro.blog/2024/01/29/troubleshooting-intune-macos.html", "title": "Troubleshooting Intune macOS app installation issues during enrollments", "content_html": "

Understanding the problem

\n

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

\n

\"Confused\"

\n

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:

\n\n

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.

\n

Reproducing the issue

\n

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

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

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

\n

User experience

\n

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:

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

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.

\n

\"Wait?

\n

Developing a workaround

\n

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.

\n
\n

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

\n
\n

The Script Solution

\n

To circumvent this, I developed a shell script that:

\n\n

Workaround Challenges

\n

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.

\n

Vendors involved

\n

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.

\n

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

\n

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.

\n

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

\n

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.

\n

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

\n

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.

\n", "date_published": "2024-01-29T15:27:00+02:00", "url": "https://applefreakz.de/2024/01/29/troubleshooting-intune-macos.html", "tags": ["macOS","iOS"] } ] }