I'm running into an issue with a Yosemite client that is successfully enrolling with the JSS via a PreStage DEP enrollment. The client successfully enrolls and the MDM profile gets installed, but I am receiving the following error - "DEP QuickAdd failed to download. Use the Purchases page to try again."
I have tried including the QuickAdd package from Composer in the Policy, but that doesn't seem to address the issue.
Has anyone else seen this?
I saw this for the first time today. No idea what's causing it, but it is preventing me from enrolling a Yosemite client. The strange thing is I'm not using DEP, so I'm really confused as to what the issue is. The QuickAdd package installs the management framework, but it appears as if the client cannot submit inventory to the JSS, so the client never appears in our JSS. Has anyone been able to work around this?
I ran into this as well earlier this week. Using all my tricks, I still couldn't get enrollment to work. Below is an entry in the log file. I did a removeFramework and tried again. Additionally, the pkg wasn't not in use as I had just downloaded it. When I opened the App Store, I saw the DEP message as @skline mentioned.
The desktop tech did a time machine migration to a new box, then was trying to enroll. Once he wiped the machine, enrolled it, then did the time machine, all was good. He didn't look at the App Store for that DEP error message before deploying it, however. Are you guys migrating data with TM before enrollment?
some information changed below
Dec 3 14:05:11 donaldwbookpro2.domain.com installd: postinstall: /tmp/PKInstallSandbox.qNHfF6/Scripts/com.jamfsoftware.osxenrollment.P3ujAE/postinstall: line 10: 854 Segmentation fault: 11 /usr/sbin/jamf enroll -invitation 331436483647999937153463312757780661688 -endUsername "hidden" -realname "hidden, really" -email "user@domain" -position "Political Scapegoat" -department "Information Systems" -phone "555-555-5555" -room "L-6-12" -ldapServerID 1 -userID "5589255" Dec 3 14:05:11 donaldwbookpro2.domain.com installd: postinstall: Enrollment Failed. This PKG may be used already.
This is actually an issue that we do know about; we’ve got it filed under D-007893.
If you have not already, please get in touch with your Technical Account Manager either by giving them a call, sending an e-mail to firstname.lastname@example.org, or using the My Support section of JAMF Nation to get a case started.
The more information we can get gathered and attached, the more helpful it is for our testing and for our QA & Dev teams, and some of the log files we may want to look at are not files we’d want to have posted publicly as they may contain sensitive information.
If you have any questions on the above please feel free to ask.
JAMF Software Support
I'm running into this while testing PreStage Enrollments, and I noticed that it usually happens when the computer is already in my Casper inventory. Deleting the computer record from Casper's inventory before running through the PreStage Enrollment / Apple Setup Assistant seems to do the trick for me. I'm on JSS 9.62 and testing this with OS X 10.10.1.
I was doing some testing with this today, and this is what I see in my jamf.log when the "DEP QuickAdd failed to download" error pops up on my screen:
Mon Jan 12 12:38:19 TestMac jamf: Error installing the computer level mdm profile: profiles install for file:'/Library/Application Support/JAMF/tmp/mdm.mobileconfig' and user:'root' returned 102 (The operation couldn’t be completed. (CPFAccess error 102.))
I'm having a similar problem. I have a computer that is showing MDM Capability: No all of a sudden. No errors preceding this... nothing unusual at all. When I remove it from inventory and then try to re-enroll it, I get the same CPFAccess 102 error. Nothing I do is allowing me to re-enroll with MDM capability. Very frustrating.
Forgot to mention... I am unable to remove the MDM profile from Sys Prefs. Minus button is greyed out.
We've reported this as well (D-007893). Hoping to see resolution soon. The move toward using DEP with OS X clients will need to wait a bit (joins the queue of other projects requiring "fixes").
Pretty cool, but can we trust much of it to actually work as advertised? Will a QA team test before release? Reply hazy try again ...
I'm working on a DEP enrollment today and this error is coming up. It appears to be the same error that everyone else is getting.
The JSS is a JAMFCloud hosted JSS v9.73.x. The odd thing is that this error is presented, but the computer completes the full enrollment process. The computer creates a management account, it installs the JAMF binary, it installs Self Service, it creates items in /Library/LaunchAgents and /Library/LaunchDaemons and it checks in with the JSS and submits a full inventory record.
The QuickAdd Package installation is being handled by the App Store and until the error is cleared, it's a download in LaunchPad without an icon.
Having the same results on a hosted JSS 9.73 instance. I was told that the issue can be fixed (from JAMF staff) by going to the PreStage enrollment and checking "Allow MDM Profile Removal". Tried this, but still getting the popup error. Anyone else heard anything?
We asked whether there was a way to make the MDM profile non-removable later via script, policy, etc., but were told there was not. In that case, I think it's preferable to ignore the error which does not appear to mean anything rather than forego one of the best benefits of DEP.
It's disappointing that we saw this a month ago at our Jumpstart, and it's been discussed for nine months in this thread without resolution.
After looking at the log files, there is an error being thrown that the downloaded quick add package is trying to replace the mdm profile but it isn't allowed to. By allowing the profile to be removed it seems to work fine.
Adding my info here - its slightly different:
Running JSS 9.81 clustered (one inside instance, one DMZ instance) and Java 7 (just downgraded as AWS won't play w/Java 8).
DEP devices that are reimaged w/o Casper should be pulling down the MDM profile and the JAMF binaries (quickadd). The MDM profile comes down fine, however the binaries never flow through. Have tried this repeatedly on a 10.10.5 and a 10.11.1 machine, both with clean AppStore-based OS builds. I'm not even seeing the AppStore error like I used to, its just fails completely. I know this was working prior to the 9.81 release, so not sure if 9.81 broke this or not.
Additionally, I also use Meraki Systems Manager only for lost devices (free MDM with DEP for < 100 devices). When reassigning the same machine in DEP from the JSS to Meraki and then linking an MDM profile to the device in Meraki, I have no problems whatsoever. The MDM profile and all comes down 100% and the machine is visible/manageable in their interface.
Just right now we are experiencing the same Problem as described in the first Post.
Those macs just came from Apple, are assigned properly within the JSS to the PreStage Enrollment.
We added all Certificates/Intermediate Certificates we have around our JSS to the PreStage.
The MDM Profile installs properly, it is set as Mandatory and removing is allowed (as described in other posts)
Now the client complains about "DEP QuickAdd failed, please repurchase".
Looking into the log (/var/log/jamf.log)
The SSL Certificate for https://our.jss.de:8443/ must be trusted for the jamf binary to connect to it.
There was an error.
Error enrolling computer: Invald Message - The Message could not be parsed."
Did anyone see this issue and has a fix for it?
Removing the Enforcement of the Certificate Trust doesnt help out.
The Webpage loads fine in Safari without complaining about the cert.
jamf policy works completely, even says it is upgrading the jamf binary etc.
jamf manage fails because the computer is not enrolled
Additionally i just opened a case, i'll let you know if there is/was a fix for my problem.
Hm, I'm seeing exactly this while trying out DEP. I really thought I was doing something wrong, but it's obviously something less entertaining. :(
Is DEP of OS X computer really this disappointing?
Aha, well, that could be a reason to upgrade then. We had a nasty experience with 9.8 and are reluctant to upgrade nowadays ;)
I'll look into that, because I can't really get it to work properly at all, it doesn't enroll whatever I do, it looks strange and half done so it might be some 10.11-bug they've ironed out in 9.82.