{"id":2475,"date":"2016-03-07T12:45:26","date_gmt":"2016-03-07T12:45:26","guid":{"rendered":"http:\/\/blog.designed79.co.uk\/?p=2475"},"modified":"2016-03-07T22:45:58","modified_gmt":"2016-03-07T22:45:58","slug":"jss-and-mdm-problems","status":"publish","type":"post","link":"https:\/\/blog.designed79.co.uk\/?p=2475","title":{"rendered":"JSS and MDM Problems"},"content":{"rendered":"<p>Recert<\/p>\n<pre>\/usr\/sbin\/jamf removeMdmProfile -verbose\r\n\/usr\/sbin\/jamf manage -verbose\r\n\/usr\/sbin\/jamf recon<\/pre>\n<p>Or<\/p>\n<pre>jamf mdm -verbose\r\nJams recon<\/pre>\n<p>Check EA&#8217;s<br \/>\nMake sure you don&#8217;t have any extension attributes that are hanging up recon. For example, we had a script that set the hostname variable with a &#8220;scutil &#8211;get HostName&#8221;<\/p>\n<p>But even if hostname is present in Sharing Preference Pane, it may not be recognized by scutil &#8211; especially if hostname was created dynamically. So that command will just hang &#8211; causing recon to hang.<\/p>\n<p>When you enroll, a quick computer record is created in JSS, containing very little system info &#8211; MAC addresses, Serial Number, etc. And a UUID and JSS Computer ID is generated for the record. But the MDM enrollment does NOT occur until after the recon is done with enrollment.<\/p>\n<p>At any rate &#8211; the &#8220;No Name&#8221; record will appear in JSS until a full recon is done.<\/p>\n<p>For testing &#8211; it may be beneficial to create a quick add, but then modify the enroll command with a &#8220;-noRecon&#8221; option. For example &#8212;<\/p>\n<pre>\/usr\/sbin\/jamf enroll -invitation 123456789876543212345678976543 -noRecon -verbose<\/pre>\n<p>Then, run a<\/p>\n<pre>jamf recon -verbose<\/pre>\n<p>to try to determine where the hangup is<\/p>\n<p>Verify JAMF Keychain<br \/>\nAs part of your troubleshooting, make sure your system is actually receiving its device certificate. The device certificate is NOT in the System Keychain. It&#8217;s in the \/Library\/Application Support\/JAMF\/JAMF.keychain<\/p>\n<p>To verify<\/p>\n<pre>sudo security dump-keychain \/Library\/Application\\ Support\/JAMF\/JAMF.keychain<\/pre>\n<p>You should see a public key, a private key, and a certificate. This of course is assuming that you are using the built-in JSS CA.<\/p>\n<p>IF you get an error like <\/p>\n<pre>Error installing the computer level mdm profile: profiles install for file:'\/Library\/Application Support\/JAMF\/tmp\/mdm.mobileconfig' and user:'root' returned -1202 (The certificate for this server is invalid. You might be connecting to a server that is pretending to be \u201cblah.blah.com\u201d which could put your confidential information at risk.)<\/pre>\n<p>Remove the JAMF.keychain and then re-enroll<\/p>\n<pre>sudo rm -f Library\/Application\\ Support\/JAMF\/JAMF.keychain\r\nsudo jamf enroll -prompt<\/pre>\n<p>JSS CA Problems<br \/>\nIf you have attempted to enroll the computer several times, there is a chance that the internal JSS CA is just plain mucked up and confused, and when it issues a device certificate, it can&#8217;t verify it because there have been too many certs issued.<\/p>\n<p>JAMF is aware of this issue. I don&#8217;t think a defect is official yet.<\/p>\n<p>The solution below is NOT official by any means, but it worked for me (to an extent)<\/p>\n<p>In JSS &#8211; find the computer that is failing to enroll (should be a &#8220;No Name&#8221;).  Find by MAC address, or serial number.  Under Inventory \/ Hardware &#8211; find the UUID<br \/>\nThen navigate to Global Management &#8211; PKI &#8211; Issued Certificates<br \/>\nSearch the page for the UUID you found in step 1<br \/>\nAre there more than one for that UUID<br \/>\nIf yes &#8211; you may need to purge some of those via MySQL<br \/>\nCopy the DEVICE certificate name that corresponds to that UUID.  Should look like &#8220;CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate&#8221;<br \/>\nThen in MySQL &#8211; as root or user with write access &#8212;<\/p>\n<pre>use jamfsoftware;\r\nSELECT * FROM certificate_authority_issued where subject_name=\"CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate\";<\/pre>\n<p>That should simply list all the corresponding certificates that are found. Better to do this before running the delete command, just in case. Make sure that all those found are actually ones you want to delete. Then run<\/p>\n<pre>delete FROM certificate_authority_issued where subject_name=\"CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate\";<\/pre>\n<p>Obviously &#8211; replace the certificate from my example with the certificate you copied in step 6<\/p>\n<p>Conclusion<br \/>\nEven after saying all that &#8211; we are STILL having trouble with clients who were in one JSS enrolling into a new, clean JSS. The steps above helped me with a few scenarios, but we still have many lingering failed enrollments.<\/p>\n<p>Also &#8211; for anyone who &#8220;wishes&#8221; to recreate this issue, we have been able to recreate at will &#8211; even in a completely vanilla JSS or even in our JAMF Cloud test instance.<\/p>\n<p>I strongly recommend you only do this on a dev JSS, but by simply enrolling over and over again (sometimes a dozen or so enrolls) &#8211; we can produce the same device certificate errors &#8211; at least in 9.72 (haven&#8217;t tried other versions)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recert \/usr\/sbin\/jamf removeMdmProfile -verbose \/usr\/sbin\/jamf manage -verbose \/usr\/sbin\/jamf recon Or jamf mdm -verbose Jams recon Check EA&#8217;s Make sure you don&#8217;t have [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2475","post","type-post","status-publish","format-standard","hentry","category-info-on-tech"],"_links":{"self":[{"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/2475","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2475"}],"version-history":[{"count":0,"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/2475\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.designed79.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}