Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Device Enrollment installation failed. The MDM server for your organization returned an unexpected status (403)

On some occasions when I’ve tried to use sudo profile renew -type enrollment I get the following error when i try to install the MDM profile:

"Device Enrollment" installation failed. The MDM server for your organization returned an unexpected status (403).

This happens even if I delete the device from Jamf Pro, unscope it, save, re-scope and save it in the Prestage Enrollment in Jamf. Anyone know why that might be coming up?

Like Comment
Order by:
SOLVED Posted: by nicholasmcdonald

I've seen that exact error several times recently. It appears to only happen on machines that have been setup for a while. (have these devices been setup for some time?) Currently working with Jamf Support on this issue. A wipe and reinstall of macOS seems to clear the issue.

Also just a side note

sudo profile -N

works as well for this function on macOS High Sierra and higher.

Like
SOLVED Posted: by craig.hopkins

Hello, did you manage to find any solution to this? Other than re-install.

Like
SOLVED Posted: by bpavlov

I have not. I still have a case opened with Jamf Support. This is quite an annoying issue. They originally stated that I should erase and install the OS which is just not a solution when this is a supported command to enroll a device into DEP via the command line. In fact, even if I didn't use the command, the DEP notification would still come up which is meant to let the end-user know to join this device to the MDM. Clearly Apple intends for enrollment to take place when that DEP notification shows up.

Like
SOLVED Posted: by Bos

No solution yet? I also have the same problem.

Like
SOLVED Posted: by UESCDurandal

This is a macOS limitation. If you delete the /Library/keychains/apsd.keychain file and reboot the Mac then it it should enroll successfully.

I opened an AppleCare Enterprise ticket on this problem and added ourselves to the feature request to solve this problem. If you have the ability I suggest doing the same.

Like
SOLVED Posted: by ary.zarrin

Thank you @UESCDurandal this just resolved the issue with a user!

Like
SOLVED Posted: by chadswarthout

@UESCDurandal Do you have a Radar # for this issue?

Like
SOLVED Posted: by UESCDurandal

@chadswarthout Our AppleCare agent informed me that this behavior is working as designed and therefore is not considered a Radar bug. Rather, he offered to submit a feature request for "Allow macOS systems to enroll into their DEP assigned MDM, post setup assistant."

Like
SOLVED Posted: by kevinmwhite

Confirmed, I just saw this on another customer's device.

Ugh Apple... This is not a new feature, it is a bug for an existing feature! There is no way this isn't a fully designed and engineered feature by Apple. The profiles command is literally designed to test and initiate the enrollment. They even took the time to design a custom notification method for this and a special privilege exception so you don't have to authenticate as an admin to complete the enrollment.

Like
SOLVED Posted: by bartreardon

regarding why deleting /Library/keychains/apsd.keychain works, it appears that the certificate in that keychain has expired and so the jss doesn't trust it. you can run

/usr/bin/security find-certificate -a -p -Z /Library/Keychains/apsd.keychain | /usr/bin/openssl x509 -noout -enddate| cut -f2 -d=

to find out what date it expires.

delete and re-boot is easy to do for one off's but if anyone knows how to get the OS to renew the certificate without triggering a DEP notification, or perhaps trigger a DEP notification in a way that renews the cert first, that would be a huge help in trying to trigger enrolment on > a couple dozen devices.

Like
SOLVED Posted: by aporlebeke

Had this happen for an old 10.11.6 machine that we'd upgraded to 10.13.6. Removing the keychain and rebooting resolved.

Like