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.

I believe that invitation code is unique as well. How to find it quickly escapes me at the moment though.

You would need to create a quickadd package. What I did was create a quickadd package then drag it to composer and look at the script and found the invitation code and copied it. The invitation code in the quick add package can be used multiple times.

Speaking of invite codes, unless that is a dummy one @roiegat I wouldn't leave that posted here. Assuming your JSS is externally available anyone could enroll and while that's not malicious they could get install software you might be offering in Self Service. :)

@cwaldrip

You can do this:

Computers > Enrollment Invitations > Add New...

Or, if like me, nothing shows up in Enrollment Invitations:

1. Creat QuickAdd.pkg with Recon


2. Open Composer


3. Drag QuickAdd.pkg into Composer


4. Convert QuickAdd.pkg to source


5. The invitation ID is in there somewhere.

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.

@roiegat

get rid of that invitation ID.

If using @roiegat 's script, it is very important to note that using -k will SKIP checking the SSL cert of the JSS.

If you want the SSL cert to be checked, use -verifySSLCert instead, such as:

/usr/local/jamf/bin/jamf createConf -url 'https://jss.yourcomany.com:8443/' -verifySSLCert

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

@jameson Is this a DEP enrolled Mac, or no?

@jameson Process worked for me. Note, removeMDMprofile has the potential of dropping the current network connection. Perhaps the script is running before the machine re-connects, or can't connect.

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:

• Is there an actual need for this? If so, are there other ways to fix it?


• Is your JSS (jamf pro lol) accessible publicly, or do you have a guest network users can easily connect to? If not, you are going to work with great things like chicken and egg scenarios and race conditions


• Also, a re-enroll will trigger all EnrollmentComplete policies, unless you specifically call -noPolicy in your enrollment command


• The above means all apps reinstalled, all scripts ran again, and so forth. This might cause more problems than they are worth


• if the jamf binary is present you can pass an enrollment code to it, and tell it to enroll with the -noPolicy flag. This still works as I did it the other day for a borked system transfer as a one off


• You can curl down the binaries from Tomcat directly but ya know, MITM and security, and all of that jazz that might not really be a great solution


• You will probably need local code/tools and a launchd to do this, and jamf is not great at managing any of those things

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 ?

@jameson if your JSS cert is self signed you must sudo jamf createconf -k first (check syntax on that) because your SSL cert is signed by a CA that is not publicly trusted.

Look at the help output in the jamf binary

Jameson - you should try looking up in the thread for seeing the commands

@jellingson @chris.kemp ,

1. I hope they are using old quick add package to enrol macs again.Try to delete old quick add pkg then download agin with URL , enroll it.


2. Did you double checked your mac date & time is correct, if date & time is not current then quick add pkg will fail.

I have followed the script

jamf createConf -url 'https://jss.yourcomany.com:8443/' -k

But it then just write

Creating configuration file for https://xx.jamfcloud.com:8443/...

The SSL certificate for https://xxx.jamfcloud.com:8443/ does not need to be trusted.

That's expected. The -k switch (deprecated), which is now -verifySSLCert never, tells the client it doesn't need to trust the certificate used for the webapp on the Jamf server during enrollment. To enroll try:
sudo jamf enroll -prompt

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"

@jameson

Try createConf -k which is the insecure way that will not verify SSL on self signed certs. Be weary of this as it is not ideal, but if your jamf pro server CA is self signed, you will have to use the insecure method.

Just need to understand.

If enrolling a device through web and doing it through terminal what is the difference regads the self signed certs ? I am using Cloud and not om prem if there should be any differene

You mentioned jamfcloud, make sure you're using the correct port when doing the createConf. Most cloud instances use 443 (in which case you don't have to specify the port).