I've seen a fair amount of resourcing for iOS notifications, but on macOS there is little if any documentation on what we're supposed to experience when using time-sensitive notifications. We are intending to send time-sensitive notifications about IDP credentials from our agent to the end user, with the intention of breaking through Do Not Disturb or Focus modes. What should we expect the experience to be? We've implemented the notifications, but on macOS, they do not break through focus or DND the way that we'd expect them to.

While it's clear that SSO Extensions can be limited to managed applications, it's not necessarily clear how to handle the scenario where a managed application is generating a SafariViewService web view to handle authentication of an account within that managed application. The SSO Extension sees SafariViewService as an unmanaged destination in User Enrolled devices, which means we can't warrant that it's coming from a managed app in the work APFS container. Is it possible to, in User Enrolled MDM Scenarios, understand where a Safari process came from (i.e., a Managed App) or a SafariViewService process came from, for the purposes of ascribing management status to the authorization request?

I have a valid package that is failing when I deliver it via MDM. The package meets all of the criteria necessary for delivery via MDM (available freely, signed, distribution-style) but when it's delivered, the device fails to install: default 12:09:23.398734-0500 mdmclient Processing install phase 99 for E7A2748E-E38F-4976-A440-FFA7F4E6002B ==> { "Error" = { code = 660; domain = ASDErrorDomain; userInfo = { NSLocalizedDescription = "Could not create PKProduct"; NSLocalizedFailureReason = "Could not create PKProduct"; }; }; "Success" = 0; } default 12:09:23.399787-0500 mdmclient Processing install phase 97 for E7A2748E-E38F-4976-A440-FFA7F4E6002B ==> { "Error" = { code = 660; domain = ASDErrorDomain; userInfo = { NSLocalizedDescription = "Could not create PKProduct"; NSLocalizedFailureReason = "Could not create PKProduct"; }; }; "Success" = 0; } error 12:09:23.400711-0500 mdmclient [ERROR] Aborting app install: Error Domain=ASDErrorDomain Code=660 "Could not create PKProduct" UserInfo={NSLocalizedDescription=Could not create PKProduct, NSLocalizedFailureReason=Could not create PKProduct} default 12:09:23.400752-0500 mdmclient Install phase 97 (E7A2748E-E38F-4976-A440-FFA7F4E6002B) completed. Result: ==> Error Domain=ASDErrorDomain Code=660 "Could not create PKProduct" UserInfo={NSLocalizedDescription=Could not create PKProduct, NSLocalizedFailureReason=Could not create PKProduct} default 12:09:23.402070-0500 mdmclient Processing install phase 98 for E7A2748E-E38F-4976-A440-FFA7F4E6002B ==> (null) default 12:09:23.403122-0500 mdmclient Install 'E7A2748E-E38F-4976-A440-FFA7F4E6002B' finished. Sucess: no Error: { code = 660; domain = ASDErrorDomain; userInfo = { NSLocalizedDescription = "Could not create PKProduct"; NSLocalizedFailureReason = "Could not create PKProduct"; }; } What causes these 660 errors? Error.txt

There is a change in the behavior for upgrading from a current version of Monterey to the Ventura beta, where devices enrolled in the DeveloperSeed are offered the macOS Ventura update as a standard software update, which any user can accept as long as they're a disk owner for the volume. This change allows for smaller updates (nice!) and shorter restarts (nicer!) but also grants standard users the ability to upgrade (uh oh), and there's no way outside of the 90-day Restrictions key for Major Upgrade Delay to block updates (uh oh uh oh). **What should Mac Admins expect in terms of behavior for the macOS Ventura upgrade this fall? ** Will users after a certain version (12.3? 12.4? 12.5.1?) get a delta upgrade to Ventura offered? Will that upgrade require admin rights to install, as previous versions of macOS have required?

Summary: Occasionally when running dscl from the command line, we are seeing "Authentication for node /Local/Default failed (-14487, eDSServiceUnavailable)" and we cannot trace why that occurs. The most recent incident is running on an Apple M1, with Big Sur 11.6. However, we have also seen it on Intel systems, too. DESCRIPTION OF PROBLEM In our (JumpCloud) device agent (which runs on macOS computers), we use dscl to verify passwords. We have a customer who's computer is reporting Directory Service Unavailable. It looks like the specific error is: "Authentication for node /Local/Default failed. (-14487, eDSServiceUnavailable)". It looks like at the same time, we're also seeing 'account temporarily locked for user '. What condition(s) would cause the Directory Service to be unavailable, and what steps can we take when this happens? Perhaps related, what would cause an account to be temporarily locked? STEPS TO REPRODUCE Exact steps are unknown. This occurs very infrequently. However, the command we're running is: /usr/bin/dscl . -authonly (the code then waits for the password prompt, and provides the password when prompted)

Apple provides ABM Administrators the ability to change the address associated with a Managed Apple ID (MAID henceforth for simplicity). When this address changes, do we need to do anything as an MDM manufacturer to account for this? As the MAID is part of the enrollment profile, is there a set of checks that handles this gracefully? When the device needs to re-enroll after a year, do we include the new address in the response? How should that be accounted for?

I know how to spot a "universal" app in the App Store metadata (devicefamily array includes mac, app kind is iosSoftware), but how can I spot an iOS app that will allow M1 Mac install in the metadata currently? I know that developers have the ability to exempt macOS on Apple silicon from running some iOS apps, and I want to make sure that's respected when we're doing MDM assignment of applications.

Currently Apple federates only with Azure AD for Managed Apple IDs, and that is very limiting for our customers who use us as an IdP. In addition, Apple Business Manager requires manual creation of Managed AppleIDs one at a time. This combination is very limiting, and I was wondering what we should be doing to help our customers create Managed AppleIDs at school for use of the new User Enrollment?

Hello, While working with the InstallEnterpriseApplication command, we ran into an interesting situation that we wanted to understand what the expected behavior would be. On a machine bound to our MDM, we had previously installed Firefox 88.0.1. We uploaded a properly formatted and signed installation package for Firefox 78.10.1 and instructed our MDM to push InstallEnterpriseApplication to the client machine that had 88.0.1 installed. What happened next was interesting! We still had 88.0.1 listed on the machine as current, both the Info.plist and the application on disk think it is 88.0.1. However, pkgutil pkg-info org.mozilla.firefox reports back the older version: package-id: org.mozilla.firefox version: 78.10.1 volume: / location: Applications install-time: 1622056611 What I was expecting was either a wholesale replacement of Firefox.app, and a committed receipt to match, OR a refusal to replace Firefox.app (version on disk was higher than the installer package), and either no receipt (if a drag-from-a-DMG install was done), or the previous receipt. What should have happened here? The fugue station of a receipt for 78.10.1 and the application for 88.0.1 was confusing.