Posted on 02-07-2018 03:18 PM
We have an odd behavior effecting DEP enrollment on Jamf Pro 10.1.1. These Macs complete the Setup Assistant as expected based on our PreStage Enrollment settings, however the Jamf agent fails to install. We get the following in jamf.log
Enrolling computer... Wed Feb 07 13:54:01 MacBook Pro jamf[619]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "searchForItems:conversionBlock:error: : The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=searchForItems:conversionBlock:error: : The specified item could not be found in the keychain.} Wed Feb 07 13:54:01 MacBook Pro jamf[619]: Error submitting enrollment status to the JSS: Security Error - A security error has occurred. Wed Feb 07 13:54:01 MacBook Pro jamf[619]: There was an error. Error enrolling computer: Invalid Message - The message could not be parsed.
The Mac has the MDM Profile installed but nothing else. Running "sudo jamf enroll -prompt" or downloading the quickadd.pkg from the JSS URL results in successful enrollment, as seen below.
Wed Feb 07 14:02:29 MacBook Pro jamf[1033]: Downloading the agent... Wed Feb 07 14:02:30 MacBook Pro jamf[1033]: Downloading the Jamf Bundle... Wed Feb 07 14:02:31 MacBook Pro jamf[1033]: Enforcing management framework... Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Enforcing scheduled tasks... Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Adding launchd task com.jamfsoftware.task.1... Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.jamf.daemon.plist... Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Error Domain=com.jamfsoftware.task.errors Code=3 "(null)" Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Creating launch daemon... Wed Feb 07 14:02:32 MacBook Pro jamf[1033]: Creating launch agent... Wed Feb 07 14:02:32 MacBook Pro jamf[1495]: Informing the JSS about login for user localadmin Wed Feb 07 14:02:34 MacBook Pro jamf[1495]: Daemon starting Wed Feb 07 14:02:35 MacBook Pro jamf[1510]: Upgrading jamfHelper.app... Wed Feb 07 14:02:35 MacBook Pro jamf[1510]: Upgrading JAMF notification service... Wed Feb 07 14:02:35 MacBook Pro jamf[1495]: Informing the JSS about login for user localadmin Wed Feb 07 14:02:35 MacBook Pro jamf[1510]: Upgrading Self Service.app... Wed Feb 07 14:02:37 MacBook Pro jamf[1510]: Checking for policies triggered by "enrollmentComplete" for user "localadmin"... Wed Feb 07 14:02:38 MacBook Pro jamf[1033]: Enroll return code: 0
We have a public SSL cert for Tomcat and the QuickAdd is signed with our Developer ID Installer cert, so I'm not sure what could be causing this. I've also restarted Tomcat to be safe. Any thoughts?
Solved! Go to Solution.
Posted on 02-19-2018 07:37 AM
We’ve conquered this problem, albeit through a very roundabout way. The day after posting this article, my Macs began exhibiting an entirely different behavior. Instead of partially enrolling, the JSS refused enrollment with this event in the server log.
"2018-02-08 13:09:16,731 [WARN ] [Tomcat-15 ] [onfiguratorEnrollmentStep] - Processing device rejection: CONFIGURATOR_ENROLLMENT_DISABLED 2018-02-08 13:09:16,731 [ERROR] [Tomcat-15 ] [onfiguratorEnrollmentStep] - Configurator OTA enrollment is not enabled"
Our jamf engineer and I were able to solve this by making sure the device was assigned to the right DEP server (It was assigned to our PoC test JSS on accident) and deleting a erroneous device record.
Apparently there’s a rare bug where a Mac somehow creates a mobile device record in the JSS titled no_name. With the Mac serial number seemingly associated with an iOS device, the JSS doesn’t know what to do! We don’t use our JSS for iOS so it was easy to notice. Never would have thought to look there!
Might seem odd, but take a look at both your computer and mobile device inventories and search for a device titled no_name. If it’s got your serial number then that’s it!
Surprisingly, once we fixed DEP and deleted the no_name iOS record our Macs enrolled fine. I entirely thought I’d get the same error from this post. Perhaps the no_name record was the original cause? Anyway, I hope this helps some of you!
Posted on 02-08-2018 07:09 AM
Were these Macs previously enrolled in your Jamf environment? If so, you may need to clear out the username in the computer record before a successful re-enrollment.
Posted on 02-08-2018 07:16 AM
We get this on brand new Macs as well as ones that were previously enrolled. We always delete the computer record before reenrolling via DEP.
Posted on 02-09-2018 12:11 PM
I'm having this exact same problem with our DEP enrollments as well. Clearing out records didn't resolve the issue. We're using JamfCloud hosted Jamf Pro.
Posted on 02-19-2018 02:05 AM
Hello there,
We are having the EXACT SAME issue. I have spent the last two weeks working on this with a JAMF engineer and no one can tell me what is wrong, or admit that there really is an issue. I'm having less than 50% success with brand new Macs, and there seems to be no pattern, rhyme or reason as to why this is happening.
Its VERY VERY frustrating.
I hope we get a breakthrough soon.
Posted on 02-19-2018 07:37 AM
We’ve conquered this problem, albeit through a very roundabout way. The day after posting this article, my Macs began exhibiting an entirely different behavior. Instead of partially enrolling, the JSS refused enrollment with this event in the server log.
"2018-02-08 13:09:16,731 [WARN ] [Tomcat-15 ] [onfiguratorEnrollmentStep] - Processing device rejection: CONFIGURATOR_ENROLLMENT_DISABLED 2018-02-08 13:09:16,731 [ERROR] [Tomcat-15 ] [onfiguratorEnrollmentStep] - Configurator OTA enrollment is not enabled"
Our jamf engineer and I were able to solve this by making sure the device was assigned to the right DEP server (It was assigned to our PoC test JSS on accident) and deleting a erroneous device record.
Apparently there’s a rare bug where a Mac somehow creates a mobile device record in the JSS titled no_name. With the Mac serial number seemingly associated with an iOS device, the JSS doesn’t know what to do! We don’t use our JSS for iOS so it was easy to notice. Never would have thought to look there!
Might seem odd, but take a look at both your computer and mobile device inventories and search for a device titled no_name. If it’s got your serial number then that’s it!
Surprisingly, once we fixed DEP and deleted the no_name iOS record our Macs enrolled fine. I entirely thought I’d get the same error from this post. Perhaps the no_name record was the original cause? Anyway, I hope this helps some of you!