Error managing computer and installing MDM Profile

I am now encountering this as well. Seems to only happen on 10.10.3 machines with the latest build. It was just brought to my attention this morning by the help desk. I'm still investigating and planning on opening a support ticket with JAMF.

I had something similar happen but turns out my certificate on the JSS expired and I neglected to renew....

My Push Certificate isn't due to expire until November 2015. I did update my activation code last week, but that was it.

I am a noob to certificates, how do I go about checking the expiration date of my Tomcat certificate?

I checked inside the JSS at https://jss.example.com:8443/tomcat.html?id=0&o=r and see the SSL Certificate expires 11/13/2019, is that the same thing?

Edit: I just opened my tomcat keystore and took a screenshot of the it. It seems to expire in 2019/2020

Update: I was able to fix my issue. It was indeed my Tomcat keystore that was broken, so I simply backed up my current one, generated a new keystore within the JSS interface and re-installed my SSL certificate.

@brandonusher, after re-installing the SSL Cert. and restarting Tomcat, what did you do with the Unmanaged Macs? Did you need to re-enroll them again, or did they become Managed after their next check-in?

Thanks.

@ehendricks They slowly rolled themselves back to managed.

I am experiencing the same thing with JAMF Cloud environment... Also, I completed the installation of MDM profile on one of my computers but could not on the other... I am lost.

A finding in regard to DEP machines:
jamf mdm -verbose will only work when you check "Allow MDM Profile Removal":

PreStage Enrolments:
Allow MDM Profile Removal (Allow the user to remove the MDM profile)

I am/have been experiencing the same issue.. But only on El Capitan images, and enrollments... It brings down the policy, however it shows MDM Capable-No, and "Unable to contact SCEP" error in the jamf logs.. However, if I leave the machine in the JSS as MDM Capable-No, it eventually brings the profiles down after 24-48hours. It then becomes MDM Capable-Yes..

Can't be a cert issue, cause my Tomcat cert expires in 2018, and my Yosemite image, images just fine bringing down the profile.. Anyone have an idea what can I look at, for the El Capitan to image properly?

@JustDeWon Just to check, are you running JSS 9.8+?

Yes.. I am running JSS 9.8.1

I am seeing this exact same issue @JustDeWon but we are running 9.92. Cert on the JSS isn't expired, issue only started on 10.11, and the MDM capability will randomly turn to Yes after a few days.

Were you able to find out any fix?

@JustDeWon Hmm I have been seeing some of this as well, and I didn't think to see if there was consistency with the OS. We do not image, just install JSS and have been seeing several -915 errors or no management happening on new enrollments. Sometimes, yes, if we just wait long enough and try again it will manage.

I think I have found that it's something to do with our cert chain (3rd party, recently updated cert). Some times, and on some macs (not all... and some macs you can just refresh and the page shows up fine) the mac can't establish the cert chain to my jss. I've just ended up installing the intermediate certs. Once they're installed, they establish the chain to the root that's installed on the OS and I have no more management issues.

It's an InCommon cert, roots to AddTrust External CA.

I should add, we're seeing this with some other certs in our org with the same chain, and we're running 9.81

@tucker.hayden .. I haven't found a fix just yet.. I'm still working on some things.. I will let you know the results..

@koalatee Good info, I'll take a look at that as well, and see what I come up with..

Just adding to the mix:

For me, the issue was caused after I moved our JSS to a new host and the SSL CN of tomcat didn't match the JSS URL. Re-created the SSL cert and issue resolved.

Just in case it helps someone in the future.

Update

For my El Capitan image, it still doesn't enroll from the image properly. If I run a sudo jamf -manage after imaging, I get the (-915) error again, and it removes the MDM profile, also doesn't allow me to install from Self Service, but it does get alot of my "recurring check-in" policies..

I tried to re-enroll via Recon, it enrolls fine, but the Profiles aren't added...

So I ran a sudo jamf enroll -prompt, and after putting in both the account to enroll and the SSH account, it enrolls and also installs the MDM certificate which of course brings the MDM profile down.. The configuration profiles slowly starts to get added within the hour or so..

With that being stated, why can I only enroll El Capitan with sudo jamf enroll -prompt and not like my other images(Yosemite, Mavericks) that works just fine during image, and/or quickadd.pkg? Also I'm not that awesome at scripting, so is there a way I can put this command in a script during imaging, with the username and password already in the script so it won't prompt the techs during imaging? If i can figure that out through pushing that script during a policy at login, I would be fine with that..

@JustDeWon What JSS version?

@bentoms . I am running 9.81

final update

I created the El Capitan base image this time using AutoDMG, never logging into it. From that, I added it to the configuration....

And I am happy to say, it was a success.. It seems using AutoDMG for the base image, works great for El Capitan, in our environment, rather than logging into one and creating an admin account. So instead I will create a script that creates the local admin account during image.. Thanks for all the advice everyone

@tucker.hayden .. I think the issue was a combination between using AutoDMG to image plus SIP(System Integrity Protection) on the El Capitan Image.. Evidently SIP on El Capitan requires you to first set your Mac to trust the NetBoot Server.. You can see that info here

I was having the same -915 error from my VPN-connected Mac...after dropping VPN, I ran the sudo jamf mdm and it was able to connect to SCEP and pull the MDM profile just fine. In my case, I believe this was due to our QA environment not being excluded from our web proxy/filter, which doesn't play well with Mac (WebSense/ForcePoint; we're primarily a Windows shop, and probably need to get an authentication bypass put in for the QA JAMFCloud server, like we have for the prod server, so the proxy doesn't try to force authentication, which of course ROOT can't manage during the setup).

Had the same problem here:

Error installing the computer level mdm profile: profiles install for file:'/Library/Application Support/JAMF/tmp/mdm.mobileconfig' and user:'root' returned -915 (Unable to contact the SCEP server at “https://ppc-jamf.theppc.com//CA/SCEP”.) Problem installing MDM profile. Problem detecting MDM profile after installation.

Anyway, been battling with it for a few days and then it suddenly worked for me. The last thing I did was remove the machine from the jamf inventory, and on the client machine I ran:

jamf flushPolicyHistory
jamf flushCaches

Then:
jamf enroll -prompt (filling in my login and machines admin creds)

It didn't work the first time, but when I tried again 30minutes later it decided to enroll perfectly and became MDM=yes in the inventory.

"jamf flushPolicyHistory
jamf flushCaches

Then:
jamf enroll -prompt (filling in my login and machines admin creds)

It didn't work the first time, but when I tried again 30minutes later it decided to enroll perfectly and became MDM=yes in the inventory."

PictureProductionMan's workflow did the trick. Before reading this, I did a -prompt and still was encountering the error at jamf mdm flushing the cache and policies did the trick

Hardware 2010 iMac 10.10 now on 10.13.5 /var/ "path for jamf changed" old cache