Remove Jamf agent after imaging

[conor]

Hi,

Is there a script that can be ran as a policy that removes all traces of Jamf from a machine that we can run after imaging,

We run Jamf as an opt-in system but would like to use the imaging process for all machines in the business.

Is it as simple as having a policy that runs sudo jamf -removeFramework or would that run into issues?

Thanks

[dfarnworth_b]

That will work, but it will leave a record in the JSS for the device. You may want to run an API script alongside that to remove the record from JSS.

[conor]

@dfarnworth_barc Thanks for that, leaving a record in the JSS isnt too much of an issue, just so long as the machine cant talk to the JSS and doesnt have the CA certs on the machine anywhere

[mm2270]

Just to throw another option out there, have you considered using a 3rd party imaging tool, like DeployStudio? It won't do enrollment to your JSS unless you tell it to by dropping in a QuickAdd.pkg to get installed on the boot volume.

[conor]

@mm2270 we did look at that but it seemed pointless to employ another system to do certain mac imaging when we paid for Jamf to do this for us.

[StoneMagnet]

@conor Just because you're paying for Jamf Pro doesn't mean you have to use every service it provides. Like @mm2270, I'd recommend DeployStudio as an imaging tool that allows you to enroll Macs being imaged with your JSS but doesn't require it.

[conor]

@StoneMagnet I guess what we wanted to avoid by not using DeployStudio was having different imaging processes for different machines in order to cut down on complexity.

But I will definitely have a look at it. I guess I was checking first if there was a way to do this via Jamf as it seems like it would be a fairly useful thing.

[StoneMagnet]

@conor DeployStudio is pretty versatile. If your standard practice is to have the same image on your JSS enrolled Macs as the non-enrolled ones you could create a base Workflow that lays down your standard image, then create a 2nd Workflow that embeds the 1st Workflow and adds a QuickAdd for your environment as the final step. That way any changes you make to your base workflow will automatically be incorporated into your JSS workflow.

[mm2270]

Yep. You can essentially have 2 image configs. One that just images the Mac and does not enroll into Casper, and the other, identical to the first, but adds a QuickAdd.pkg built from Recon.app to install on the boot volume, so it enrolls on first boot. Name them something pretty easy to identify, like "Image-10.12.6-NoJamf" and "Image-10.12.6-WithJamf" or something more descriptive if needed and pick the one you want when DS Runtime comes up.
I totally get why you just want to use what you bought, but the truth is, for as awesome as Jamf Pro is, it doesn't, nor can it possibly fit every need out there for admins. So for those special circumstances there are other tools that tie in quite nicely to the rest of the suite.

If you decide you still want to go the route of using CI and unenrolling later, be sure to not have any 'on enrollment' triggered policies or those Macs will get whatever those policies do after enrollment, and likely before you get to run your removeFramework command. Just something else to consider.

[conor]

Ok, thanks all for the input, will have a play around with DeployStudio next week

[spalmer]

@conor Just an FYI, when creating an imaging Configuration via the JSS web interface (Settings>Computer Management>Configurations) you can actually create it without a management account. However, it does still lay down the jamf binary on the target drive. Without the management account it will not enroll in the JSS after applying the imaging configuration. For some reason the JSS web interface allows this while Casper Admin does not.

By doing this I have created a workflow that is very similar to what I have seen others use Deploy Studio for. It lays down a base unbooted OS dmg, then layers on all of my applications and some base settings that I want baked into the image. I then boot and verify everything looks good, run jamf removeFramework, run a script to delete network settings, bluetooth settings, tmp files, etc. then use Composer to build a monolithic image. And since it never enrolls I don't have to worry about deleting the Mac out of the JSS.

And before anybody preaches about moving away from monolithic builds, I am well aware of the idea of Thin Imaging. This is my intermediate phase of componentizing all of my packages, settings, etc. As I find time, I am slowly moving those from my imaging configuration to policies so I can utilize DEP.

[conor]

Hey @spalmer thanks for that. However we dont want even the Binary on there. We essentially just want to use the imaging for the imaging alone then remove all traces of Jamf off of it, including the binaries and the CA certs.

But thanks for the workflow, might help us in the future

[davidacland]

Imagr is another nice simple system for imaging / re-imaging a Mac back to it's defaults state: https://github.com/grahamgilbert/imagr.

An even simpler alternative would be to erase and install the Mac using the standard recovery partition. That way, no additional infrastructure would be needed.

[spalmer · Accepted solution]

@conor Sorry I should have explained that the jamf removeFramework command removes everything related to jamf. It removes the binary, jamf folders (like /Library/Application Support/JAMF), the JAMF.keychain, and all jamf plist settings. So once you run that you will have a clean image.

See https://www.jamf.com/jamf-nation/articles/153/removing-jamf-components-from-computers and for more info.