Jamf binary not installing after Enrolment of macOS 13.5 Macs

[arfan_ali]

I have an issue where Macs (ARM and Intel) on macOS 13.5 do not get the Jamf binary after enrolling (ADE or manual) and appear unmanaged in Jamf Pro (on-prem 10.48.2). Macs on 13.4.1 and below (inc latest Monterey 12.6.8 have no issues at all). MDM commands are fine, no issues.

The Macs effected do not have the ‘Allow Jamf Pro to perform management tasks’ checked. Enabling this and rebooting the Mac can, on a few instances get the binary installed (after about a 15 min wait ) and run my post DEPNotify policy (enrolment complete trigger), but not always.

Looking at older forum posts, I see in the past people have experienced similar issues.

Tried the following...

• Enable user-initiated enrolment - (already enabled) have tried with it disabled, still the same.
• Checked sysdiagnose logs – I do see this but confirmed we have no Restriction Config Profiles with ‘Require admin password to install or update apps’ checked.
  [com.apple.appstored:AppInstall] [MNFE60849E9/com.jamfsoftware.enrollment.dep.quickadd] Failing installation after receiving error: Error Domain=PKInstallErrorDomain Code=100 "Authorisation is required to install the packages." UserInfo={NSLocalizedDescription=Authorisation is required to install the packages.}
• Restored Mac using IPSW – no effect.
• Have not tried disabling Management account creation, I’ve been advised its required for our FV policies to work.
• No orphaned (ghost) Mac records related to effected Macs on jamf DB

Our current (not ideal) work around to enrol devices is downgrade Macs to 13.4.1 -> enrol -> install 13.5 update.

[sdagley]

@arfan_ali Do you have a Configuration Profile that enables the "require admins to install and update apps" restriction? User @sassywookie posted recently they were experiencing the jamf binary not get installed until they removed that restriction (they were getting some level of management though).

[arfan_ali]

Hi - I did double check if we had that enabled, we don't.

[K_K_]

@arfan_ali Have you found what the issue is?  I'm seeing the same issue, and manually trigger enrollment policy works ok.  Thanks. 

[arfan_ali]

Hi - issue still present. User-initiated enrolment (limited testing) seems to work with no issues, the Jamf binary installs fine.

Tried with macOS 13.5.1 - AED goes through with no issues, MDM communicating fine, but Jamf binary still not installing.

I have an open call with Jamf support currently. Hopefully its not long till I have a resolution, will post back then.

[K_K_]

I found my issue is the admin account created during the PreStage Enrollments doesn't have the proper secure token, it will still go through my DEPNotify just won't enable the FV.  My work around is to created another admin account and login, using the second admin account to grant the secure token to the local admin account.  

[user-MygFNHEclO]

Are your SMTP server settings up to date, does the test work?
If not update them, test and if successful try enrollment again.

[arfan_ali]

Hi - we don't have any SMTP settings configured.

[arfan_ali]

Looks like my issue is something to do with our Jamf Connect Enrolment Package. If I clone my working PreStage and just remove the Enrolment package, Jamf Binary installs with no issues on macOS 13.5 and the newly released 13.5.1

I have since created a newly signed, notarised and stapled Jamf Connect Enrolment package which uses a custom app manifest pointing to our on-prem DP. However, I now have a new issue where I am unable to upload the custom manifest, I get the error "Package manifest file extension must be .xml" - this is relating to PI112328 I am told, and expected to be fixed in Jamf 10.50.0. Looks like the error was introduced in 10.48.x

[Doof]

I ran into a similar issue today, although it wasn't always consistent. We're on Jamf Pro 10.50 and all devices were running MacOS 13.6. We push Jamf Connect and Jamf Connect notify packages out via PreStage enrollments and devices are configured to skip all setup assistant screens. Out of a total of 30 Mac Studios, about 2/3rds of the devices completed the enrollment without the Jamf binary ever installing. Some of the devices would eventually pick up the binary after multiple resets and re-enrollments, but more often than not they would fail again. What finally seemed to resolve the issue was purposefully slowing down the enrollment / re-enrollment process by interrupting the setup assistant manually, making selections on the initial select a country and language screens. It seems as if the extra couple of seconds added by clicking the next button a few times gave allowed enough time to install the binary successfully. I'm still not exactly sure why this is occurring. It seems as if it's a combination of ADE, skipping all setup assistant options, and pushing out a couple of enrollment packages via the PreStage for us. 

[arfan_ali]

Hi - I gave your method a go and left a full minute between screens before proceeding to the next screen (Language, Accessibility, Enrolment and Location screen) but still nothing.

I have a open call with Jamf Support, hoping they can shed some light, but nothing yet...

[Doof]

If you figure out the root cause let us know. I have a workaround at the moment, but still don't understand why I can't just walk away and allow the device to do it's thing without worrying that the binary won't get installed.

[arfan_ali]

Benn meaning to update this thread for past couple of weeks, but it looks like we have this working now. It was related to our Enrolment PKG, but we still don't know what in particular about the Enrolment PKG it no longer liked in macOS 13.5 and higher.

Our Enrolment package is a single PKG containing 3 PKGs and a Post Install Script to install the respective PKGs in the package and install Rosetta if it was a Apple Silicon Mac.

We thought we'd separate out the single PKG and have the 3 PKGs in the PreStage and just moved the Post install script to be part of our DEPNotify process.

This seems to have done the trick, and the jamf binary gets installed every time.

Test on macOS 13.5, 13.5.1, 13.6 and 13.6.1 

Hope this helps someone.