MDM drop off?

tsylwest
Contributor

Hi All,

A couple of things...

Firstly... a few weeks ago I noticed that a bunch of our macs haven't reported in for *cough* *cough* about 6 months 😞 

I finally got hold of one of the users of these macs and found some interesting things... 

doing 'sudo jamf recon' yielded the typical error of:

% sudo jamf recon
Password:

There was an error.

     Device Signature Error - A valid device signature is required to perform the action.

After which trying 'sudo jamf trustjss' did not help either.

Upon further investigation, running 'profiles status -type enrollment' yields this:

Enrolled via DEP: Yes
MDM enrollment: Yes (User Approved)
MDM server: https://xxxxxxxxx.jamfcloud.com//computer/mdm

 When running this command on a working Mac, I see this:

Enrolled via DEP: Yes
MDM enrollment: Yes (User Approved)
MDM server: https://xxxxxxxxx.jamfcloud.com/mdm/ServerURL

 As you can see, there is a difference in the MDM Server URL ending...

Trying the good ol' 'sudo profiles renew -type enrollment' shows me this:

image.png

I haven't tried 'sudo jamf reenroll -nopolicy -prompt' just yet, as I consider that the penultimate sledgehammer move, and really trying to avoid the re-install MacOS move as much as possible as there's quite a few of these macs out there...

One of the questions I have here: where is that MDM Server URL held? is it possibly in NVRAM?

Which brings me to my "Secondly"... I ask that because we have 2 jamfcloud instances... a production one and a test one, and recently when I moved an old production Mac to the test Jamf Pro, I couldn't even enrol it due to an MD server URL error... I usually fixed that with an NVRAM reset, but have come across a test mac that even an NVRAM reset doesn't help 😞 

I've ignored asking that last question for a while, but it's been bugging me for a long time now...

Any insight, if not resolutions, on this would be greatly appreciated,

Cheers,
Tom

7 REPLIES 7

jtrant
Valued Contributor

I ran into similar issues when renewing our PKI Certificate last year and was pointed to PI-009050 by Jamf support. The error message was similar to what you're seeing, and our Jamf PRO URL never changed.

@jtrant thanks for that, any insight in to what that PI relates to? or how to view it? πŸ™‚ 

jtrant
Valued Contributor

Yes, you'll find a searchable list here: https://account.jamf.com/products/jamf-pro/known-issues

@jtrant thanks so much for that, really appreciate it. Not sure if it's the same thing, but I'll contact Support and see where it takes me, if it is the same thing, I'll come back and mark this and hit the good ol' "Accept as solution" button πŸ˜‰

JamfURLError
New Contributor

@tsylwest - Any Fix for this issue? We're seeing it in high numbers.

@JamfURLError unfortunately not 😞 when I find one of these, the users seem to be understanding enough for a wipe and re-install. Haven't had much time to dive in to this one more recently due to other more urgent projects like transitioning our anti-malware product of choice ( fun 😢 ).

@JamfURLError are you sitting comfortably?

There was a mac I found that came in to my possession that I was able to see if I could "fix". This isn't an easy happy story, but it did have a "happy ever after" that did NOT include a full wipe and re-install.

I cannot confirm or deny the timing of these actions as it all seems like a bit of a blur of trial and errors and I wasn't noting any of this down.

This MacBook wasn't checking in for some reason, I ran a sudo jamf recon which didn't help. I ran a sudo jamf policy and all of a sudden it said it was updating various components like JamfHelper and Self Service. Seemed like a step closer... I ran sudo jamf recon and it connected to jamf and threw everything back in to Jamf...

BUT... no new Config Profiles were getting pushed πŸ˜£ so I tried:

  • sudo profiles renew -type enrollment - this gave an error with something about a wrong URL
  • sudo jamf reenrol -prompt -nopolicy - this seemed to work, but CP's still didn't go through
  • manual web enroll - the CA cert installed but the MDM profile didn't due to permissions
  • sudo jamf removemdm profile - this didn't remove any of the old MDM or other CP's
  • sudo jamf removeframework - this uninstalled all things jamf but again, didn't remove the MDM or other CP's at all

This is where it gets messy...

It was at this point I decided to sledgehammer it. Booted in to recovery mode, opened up Terminal and ran csrutil disable to turn off SIP (really BAD and SOOO not recommended, this was only done for science πŸ˜‚ ). I then rebooted to make sure SIP was off, restarted again and went BACK in to recovery mode and proceeded to remove all the contents of the /var/db/ConfigurationProfiles folder. restarted again. Checked SIP and saw it was still off... went back into recovery mode, ran csrutil enable to turn SIP back on (please remember to stay secure).

OK... so no more profiles, great. Tried a sudo profiles -N and nothing seemed to happen. I then went for a manual web enrol again, downloaded the profiles, installed them and it got enrolled... hallelujah! 

However, me being the slight perfectionist, I didn't like the manually installed CA Cert User Profile in there, so ran sudo jamf removeframework and then a sudo profiles -N and it all enrolled as expected, all was good with the world and all the user's old installed software and Config Profiles were "happy ever after"!

(depnotify admins, beware, it might kick depnotify off again too. If you have an interactive setup and want to interrupt it before it goes ahead and runs all of your set up software again, just hit Ctrl+Cmd+X)

Please don't take this as a confirmed fix, it worked for me on one of the MacBooks I managed to get my hands on... your mileage may vary. Oh and if you have a lot of macs to "fix" the easiest might be to still take the user through a full wipe and MacOS re-install...