Posted on 03-22-2016 04:42 AM
Can anyone help, I have just setup a test JSS for demo purposes but every time I try and enroll a machine I get an error when installing the MDM profile , the error is saying that it can't contact the SCEP server?
i have setup the correct url in the "JSS URL" section and imported a fresh MDM Push certificate but with no success, also tried taking all machines out of JSS and re-adding but with the same result, it is building an inventory but in the"General" listing it tells me that MDM Capability is "NO
" ...Any Ideas?
Error below:
Posted on 03-22-2016 06:36 AM
@appleguru did you setup a Push Certificate?
Posted on 03-22-2016 06:39 AM
Yes I setup a push Certificate I even took out the URL for Enrollment to see if this helped, but No luck :(
Posted on 03-22-2016 06:48 AM
The main thing that stands out to me is that your JSS URL is an IP address; generally for MDM to work as expected, we need to have an FQDN (not a .local, as anything with iOS 8 or higher will have difficulties communicating with that) there, not an IP address.
If there is a URL Global Management >> JSS URL >> JSS URL for Enrollment Using Built-in SCEP and iPCU we’ll want to remove that, specify a proper FQDN for the JSS URL in the JSS URL field, then regenerate your Tomcat certificate (if using the built in) through System Settings >> Apache Tomcat Settings, then restart Tomcat to get that URL cleared out.
If it's still giving you trouble after getting those things changed/fixed, it may be fastest to get in contact with your Technical Account Manager and set up a call or a WebEx session so they can help you dig into it a bit deeper.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 03-22-2016 09:01 AM
@appleguru I had this issue in my test environment once. I ended up just reinstalling the JSS software and that was the only way to get it resolved.
Posted on 03-22-2016 09:37 AM
All sorted now, I setup a FQDN as instructed and requested a new Push Certificate, restarted tomcat and just enrolled a machine with no issues and MDM now saying "YES" :)
Many Thanks !
Posted on 03-22-2016 11:24 AM
Posted on 02-02-2017 07:23 AM
Sorry to bring up an old thread. We are having the same issue as the OP.
We don't have access to the external firewall but the team has stated nothing is happening with outgoing traffic. The other thing is our traffic is routed through a load balancer. The question I am wondering, is the jss.domain address is not the actual FQDN of the server. That resolves to the IP address on the load balancer. SSL terminates there as well and all traffic back to the server is routed via 8080. Anyway, since the FQDN that it is trying to connect to is at the load balancer could that be causing an issue here? This is not my strong suit so any help would be appreciated.
If that is the issue, what would be recommended to resolve it. We need to keep that shorter name as our server naming convention here is way long.
Thanks
Posted on 02-02-2017 05:02 PM
My situation is very similar w/ the load balancer, though we don't terminate SSL. We let the server do that. We have no troubles at all. Might try re-doing the cert, checking permissions on the directory. Also, I would check nat translation or other settings with the firewall. Can you test or connect to a webpage on the same server? Can you ping it?
Posted on 02-16-2017 07:18 PM
Installed a third party cert to try to fix this. Now DEP and prestage enrollment is broken.
Posted on 02-17-2017 07:06 AM
We're also having this issue with our jss that also has a FQDN. We're using a third-party wildcard cert and we're also having the same issue that @csm0004 is having with DEP and prestage enrollment not working.
I currently have a ticket open with jamf regarding this and I'll TRY to update here if I find a solution.
Posted on 08-31-2017 08:01 PM
I just had the same issue as some of the above users. To fix the issue I followed the advice from @appleguru (THANKS!!!).
FYI, The JSS I'm using is a Beta version and uses a .local for the fqdn. Renewing the certificate and MDM certificate fixed it. (Don't forget to restart Tomcat).
Posted on 09-12-2017 08:21 AM
Hi @rmcdonald,
Does the requesting of a new certificate leads to problems with the productive JSS?
I'm afraid to have problems with the prod JSS in the company.
Thank you
BR
Daniel
Posted on 01-17-2018 08:32 AM
@hunter990 @EdTechChris - when you were running into this, was it all computers producing the issue? We use a load balancer and when enrolling machines via DEP some are producing this SCEP issue, but not all. How'd you get past it?
Posted on 05-25-2018 07:32 AM
Our issue was resolved by 1: Not using a wild card cert (jamf still cannot give me a reason why wile card certs don't work) and 2: renewing tomcat cert and restarting tomcat.
We have since moved to a third-party cert for the server and no issues since.
Posted on 07-11-2018 02:04 PM
Very late response but just in case someone runs into it and reads this thread. My issue was at my last job and we abandoned using a load balancer. We ended up setting a more traditional setup with a server in the DMZ (our case it was a firewall context).
Out issue ended up being the SSL cert. Testing again later before I left letting the SSL cert go through as Chris Miller recommended resolved the issue. This was with a new cert as well.
Posted on 09-06-2019 09:21 AM
Just to chime in here and clarify for others. Here was my scenario and resolution:
1. Setup a Jamf pro server URL originally with IP address (this was for a PoC) as well as a Push Cert with Apple and User-Initiated Enrollment feature 2. Needed to change the URL so it wasn't using an IP, so I changed it in the JSS and restarted Tomcat 3. Tried to enroll a device; got the "Unable to Contact SCEP Server" error 4. Renewed both the Push Cert (not sure that was needed) and Apache Tomcat cert (using the "Generate a certificate from the Jamf Pro's built-in CA" option) 5. Restarted Tomcat again 6. Was able to successfully enroll a device using User-initiated enrollment feature!
Hope this makes it more clear for some. :)
Posted on 12-06-2019 11:46 AM
thanks @benducklow , this is clear. Worked for us! ;]