I have seen a lot of topics where people talk about running their quick add packages to re-enroll a mac with the JSS. Maybe I am understanding what they mean incorrectly, but when I run a quick add package on a machine that has previously been enrolled with the JSS it fails unless I completely delete the device entry from the JSS and then run the quick add again. So I guess what I am asking is, is there a way to reenroll a device without having to delete all of the data that is stored in the device entry on the JSS, such as policies that have been run and application usage?
I usually have this command handy to run to re-enroll a machine. You can script it, or just copy and paste it into the terminal:
sudo /usr/local/jamf/bin/jamf createConf -url 'https://jss.yourcomany.com:8443/' -k;sudo /usr/local/jamf/bin/jamf startSSH;sudo /usr/local/jamf/bin/jamf enroll -invitation 166222421695850711274991501866187933345;sudo /usr/local/jamf/bin/jamf recon
If you use a script you can break it up nicely, I just keep it like this so I can copy and paste it into the terminal.
Using this method I have never had to delete the record form Casper.
You don't need to go through all of that with a Recon-created pkg. Just create a QuickAdd with the proper information and use it as many times as you need. It's the ones that come from the JSS, such as with the /enroll URL, that are one-offs.
Re-enrolling an existing device should only update the existing record, there shouldn't be any problem with that. Our support team regularly wipes & reinstalls machines that get re-deployed, but we don't delete the JSS entries.
@chris.kemp I have a pkg that I created with recon and whenever I run it on a machine that has a record in the JSS, the installer says the package failed. The only way it works is if I delete the record from the JSS and run the pkg again. Is there a special way that I have to create the package or am I just doing it completely wrong?
Interesting question - tbh I haven't done this recently because we use the URL, although I did this for +5 years at my last gig; I also checked the manual & it says that you can share the Recon-made QuickAdd with users, so that should still be the case that it isn't a single-use pkg.
Have you asked JAMF Support about it yet?
@jellingson I've had this on a few occasions but for the most part I can run a QuickAdd.pkg without issue.
I have also had cases where locally installed profiles generate an error during the install.
Worst case, you could modify the quickadd in composer to add a
profiles -D command (to clear out any local profiles from the previous enrolment, and curl to delete the computer record from the JSS before the enrolment starts.
This topic is quite old, but should it still work?
My issue is that when I have a client that needs to be re-enrolling I do a jamf removeMDMprofile
But if I then try to run the above it fails - connection timeout ?
Can anyone confirm if it still should work If I need to make a quick re-enrollment of a client
I created a jamf health check years ago and I ended up scrapping it, because people were YOLO'ing it in their production instances and not vetting the solution and I deleted it off my github.
Here are the things to consider when doing such a workflow:
EnrollmentCompletepolicies, unless you specifically call
-noPolicyin your enrollment command
jamfbinary is present you can pass an enrollment code to it, and tell it to enroll with the
-noPolicyflag. This still works as I did it the other day for a borked system transfer as a one off
curldown the binaries from Tomcat directly but ya know, MITM and security, and all of that jazz that might not really be a great solution
In the end, if this is a major issue for your Org I would strongly suggest at looking at mitigating it other ways. If you are going down the local tools/code route, there might be an opportunity to look at a tool that does those things great. Any CM tool will be good at this because it is designed to execute everything locally (mostly but not 100% always). Then you can have the whole double agent health checking each other, and you can have another tool that does local stuff well. Versus a bunch of spaghetti code scripts and launch daemons running you may not have any insight to, and if the jamf agent breaks you lose communication anyway with the device.
Just my opinions based off my experience so take it for what it is. I would just say the local auto enroll tools are more of a last ditch effort if you cannot do it any other way.
its not an dep computer
when I try to do like sudo Jamf enrolling -prompt -nopolicy and error occours that "unable to establish trust with the jss - connection failure"
and when trying Jamf checkjssconnection also there is timeout.
Is it something with certificate issue or ? - I can re-enroll the device through web without problems, but terminal it fails. But was hoping to get a quick way to re-enroll without policies and terminal would there be fast. BTW- I am on cloud
EDIT: If the mac is enrolled and i do the "jamf enroll -prmpt -nopolicy" it works. But I the best practise in case of client problems not to remove profiles first and then re-enroll ?
Just tried it again
jamf createConf -url 'https://jss.yourcomany.com:8443/' -verifySSLCert never
And then afterwards sudo Jamf enrolling -prompt -nopolicy
It still saying
Downloading required CA Certificates(s)... An error occurred while enrolling computer. Unable to establish trust with the JSS - connection failure: "the request timed out"
The main difference is how the full chain of trust is established. OTA enrollment, you download a cert (root CA) that is signed by your jamf pro instance (self signed) and you must install it first to establish trust. Once that is established, you then get the MDM profile, which uses that chain of trust to enroll the device. This is designed to do user approved MDM
If you are doing DEP to the cloud, jamf has public certs, which are pre-trusted by Amazon. DEP enrollments are automatically user approved MDM
they are technically different methods. If I am wrong, someone please correct me.