PreStage Enrollment - Enroll computers without using QuickAdd.pkg

Sure, you could just send the QuickAdd.pkg to a machine via ARD. I do this all the time if I encounter a machine that has dropped out of management. Saves the user a trip to us to manually run it. And it's done transparently to the user.

For years, we imaged our Macs and the QuickAdd package was part of that imaging process. Now that imaging is dead (almost), I'm using enrollment via DEP. Machines are put into PreStage enrollment groups and then during setup, they get the management enforced which does things like create the hidden admin user and enroll the machine into the JSS. This is the future of Mac enrollment; you should start to familiarize yourself with this process.

And then....later on, if I see a machine that's dropped out of enrollment, I can easily QuickAdd them using ARD.

Trouton has a CasperCheck tool he wrote that also watches for machines that have lost their management and automatically reinstalls the jamf binaries and remanages the machine. Google it and it'll come up easily. Well-documented and lots of orgs use it.

I have a smart group in my JSS that reports to me machines that have not checked-in in X number days, so it's an easy hit-list for me to stay on top of machines that are losing management (for whatever reason).

@damienbarrett, I know you can install QuickAdd.pkg via ARD. That's how I did the 950+ machines already. My issue is that there is about 30 where the QuickAdd.pkg won't install via ARD. Is there another silent method that I can use that would accomplish what the QuickAdd.pkg does? These computers have never had the jamf binary on them at all so as far as my Cloud JSS instance is concerned, these machines don't exist at all.

You could try recon

@hjcao, How would I do recon if the computers don't have the jamf binary? My goal is to silently get the Jamf binary on target computers that have never had it. My method of enrolling them by the use of ARD to install the QuickAdd.pkg silently is failing.

@joethedsa A QuickAdd.pkg pushed to clients over ARD should work ok to get them enrolled, but you need to make sure it's a QuickAdd package built in Recon.app. You can't use the QuickAdd.pkg's that get pulled down during a user initiated enrollment, since those are single use for that session only. Perhaps its failing because you're using one of the latter style packages?

If you are using a validly built package and it's still failing, you could do something like pushing just the Jamf binary over to the machine in ARD, then, if SSH is enabled on those Macs and you can use it to get in to the Mac and do a manual enrollment.

/path/to/jamf enroll -prompt

where you put in the path to the jamf binary above and use the enroll -prompt flag. If it works, it will prompt you to enter credentials for the enrollment, meaning an account in your Jamf server that can do enrollments, and also what account to use as the management account, which for the time being could be the one you're using for SSH. There are ways to switch it to another account later if needed.

I meant the recon App...remote enrollment

Like @hjcao was alluding to, with the recon.app, you can search by IP address and remote enroll if you have SSH and an admin account. Use your ARD creds.

Hmm, I've never used the Recon App so I will have to explore this. Any "gotcha" things I should know about or any quick tips as I pursue?

I think you need to do some more troubleshooting on why these 30 machines aren't able to install QuickAdd via ARD. What happens if you visit one of these machines and manually try to install the QuickAdd package? Does it fail? If it fails, can you look in the logs to find out why it fails? Is there some common denominator between these 30 machines that might be affecting the installation of QuickAdd via ARD? OS version? Security setting? Do other ARD command and controls work on these 30 machines? Can you remotely drive them? Observe them? Have you "reset" the ARD settings on one or more of these machines, using the kickstart command? Maybe it's something wonky about the ARD settings on these machines?

In my experience, the failed installer packages usually display the same error in install.log

./postinstall: ln: /usr/local/bin/jamf: Not a directory

@damienbarrett, The problematic machines have 10.6.8, 10.8.5 and one of them has 10.10.5. The majority of them are 10.6.8. What are the minimum requirements for the binary? As far as my testing, I'm able to copy items to the /tmp directory of all of them via ARD. I was able to successfully execute the ls -l command via ARD to all of them. I can remotely drive them. If use the kickstart command, won't that cause my currently "good" connection with those machines to break? I tested a 10.6.8 machine by installing it at the machine and it says it failed. Oddly enough, the binary is on the computer (/usr/local/jamf/bin). When I run "jamf enroll -prompt", I get an error that reads "Segmentation fault". I suspect this is because the Jamf binary isn't "fully" on the computer. System Preferences does not have a Profiles icon which tells me it is not on or at the very least not "fully" on the computer yet.

Ouch! 10.6.8 as in Mac OS X “Snow Leopard” 10.6.8?
If so, I feel reasonably sure in saying that that is the problem right there. I’m certain that the current version of Jamf Pro doesn’t support such an old OS. I don’t know what the minimum is, but it might be 10.8, and even that isn’t likely. Apple themselves support N-2, but Jamf might go back a version or two from there. Even assuming 2 older versions that still puts it at 10.10!

Out of curiosity, why are there Macs with a 10 year old OS still on them in your environment? I hope you know those are a significant security risk.

As for how to address this, I would reach out to your jamf support contact. I could be mistaken, but I think they maintain a legacy jamf binary that they can get you to deploy to those Macs to at least get them reporting in. From there you’ll need to get them upgraded sooner rather than later. Truthfully a wipe and reinstall of a more up to date macOS might be the easier way to go. Upgrading from 10.6.x to something current will be painful.

Finally, per the Profiles pane not showing up, yeah, that would be because 10.6 didn’t support config profiles. That didn’t come along until 10.7.

@mm2270, Yes I agree that they are a security risk. To answer your question about why they are still here is two-fold- they are seldom used so they are not online and our deployment team hasn't come around to cycle the systems with new ones. They came to the surface during the deployment of the Jamf binary in our environment (We've had Jamf for only 6 months). We used LANRev to install it but the reporting was very clunky and sometime inaccurate, hence the move to Jamf. The goal for those old systems at this stage is to get them in Jamf solely for reporting purposes. They will be retired in the next few months.

I didn't realize profiles were not present pre 10.7, so thanks for the info. Lastly, I will reach out to Jamf support to see if we can get a legacy installer for those machines.

I only see as low as macOS 10.7 in this doc:

Jamf Pro Compatibility Reference for macOS

@joethedsa Thanks for the follow up post on your findings. So it looks like Jamf supports N-3, one further back than what Apple supports. Makes sense.
When I posted my response above, I was on my phone and didn't have the chance to look up any of Jamf's official documentation, so I'm glad you got some clarification on that.
So it does look like you will need to work on getting some of those older systems manually upgraded, or just wait until they get replaced, before you can manage them effectively. I agree you were lucky to get some of those machines enrolled at all. Good luck!