Keep base images clean of JAMF/Casper configuration

[HelpDeskWarrior]

We have a Mac computer that we use as an image master that has not been registered in the JSS console. We would like to keep it free of any configuration and installation of Casper services. The issue with this is that once we use the current image master for something else, we will need to deploy the image master to a different machine to work on it, effectively making that machine register in JSS.

My Question is 3 fold:
1. Do we need to be concerned about keeping this image master absolutely quarantined from JSS/Casper.
2. If we should, is there acceptable ways of 'cleaning' it like 'sudo jamf removemdmprofile'?
3. Or is there some trickery that casper imaging has that I am not aware of that can achieve this (I'm mostly a newbie, can you tell?)

Thanks

[calumhunter]

You should probably look into create never booted images.
Monolithic images made from one machine and deployed to other machines are troublesome

AutoDMG is your friend
Thin imaging methodologies are the way to go

[Simmo]

I'm gonna +1 for steering away from monolithic imaging, it just causes trouble and complicates things.

However the 'cleaning' you mentioned can be done with the command

sudo jamf removeFramework

[Look]

What is on the master that needs to be transferred across?
As the others have said, regardless of whether you wipe what the machine ships with or install over the existing OS it's definitely better to just build the image up package by package as a configuration in Casper Admin, it's a lot of work at the start, but the flexibility it gives you later is awesome!
You kind of have two options for the base OS, use the InstallESD file (hidden deep inside the OS X install app) or use AutoDMG to make a never booted version of OS X that can be included when imaging.
Tell us what you are trying to achieve and we will endeavour to point you in the right direction.

[HelpDeskWarrior]

Yes I am aware that monolithic images are the preferred method, but that is out of my control. Also, our main issue is we use a large array of software as we work in a school and some of it either doesn't like being created in Composer or has flaky behavior with capturing activation processes in terms of the software licensing.

@Simmo I did mean the sudo jamf removeframework command.

[mpermann · Accepted solution]

@HelpDeskWarrior if you have a master monolithic DMG file why don't you just use Disk Utility to restore that DMG file onto another computer then do whatever you need to do to it and recapture the master monolithic DMG again. Don't use Casper Imaging to deploy your master monolithic DMG to another computer if you need to make additional changes to it. If I'm not understanding what you are asking, I apologize in advance.

[HelpDeskWarrior]

@mpermann Thanks, you're on the money!

[calumhunter]

Also, our main issue is we use a large array of software as we work in a school and some of it either doesn't like being created in Composer or has flaky behavior with capturing activation processes in terms of the software licensing.

These things can be over come.

Is there a specific software title that you have issues with? I have worked in edu environments for a very long time and have been packaging and deploying software for schools for just as long. I haven't come across anything that has required me to bake it into a monolithic image yet.

If you need help with packaging/scripting/deploying software modularly feel free to create a post and we can see if we can help you.

[Look]

I am also in an education environment and we package every single application we use, one way or another.
Some are admittedly much more dificult than others, but pretty much anything can be usually be done.
It can of course be a lot of work to get there, so I can see why you might want to start with a working image and work backwards.
To give you an idea our deployment for 2016 currently looks to involve 148 items in Casper (These are the directly used items in any active configuration mostly pkg, dmg, script items). It's a little expanded over the number of actual applications though as I often use multiple items for one application (i.e. The vendors installer, a license file, a captured user settings file)

[HelpDeskWarrior]

@calumhunter Ok thanks ... at this stage we are ok, we haven't baked in much yet so hopefully we can stay the course and package everything in the next stage rollout...and perhaps package the few things we were having trouble with later to get back to bare imaging + workflow packaging in imaging configurations.

@Look Wow, thats a lot and it's nice to know that you have managed in the same sort of environment, certainly we should be able to as well. Unfortunately we are all new to Mac / Casper administration so we have been tempted and pushed for time to rely on our current Windows based methods for imaging. Also, we are getting some quite flaky and inconsistent results when packaging in Composer and due to our inexperience we are floundering a bit there.

Also, I didn't really expect JAMFnation to be such a responsive forum for technical help....very impressed so far so thanks heaps to all contributors. I feel inspired to lean on the forum more now.

[Look]

@HelpDeskWarrior To be honest we went pretty much down the same road starting two years ago, we had monolithic images out of Deploy Studio, the first year we used Casper Admin to simply create these again adding what we needed.
The next year we still used this, but created the images completely from packages in Casper Admin in a heirachial manner greatly reducing the amount of work required as most of the images were very very similar.
This year we have moved to being able to choose between thin imaging directly out of the box for Staff or laying down a new copy of OS X and then thin imaging over that for Student labs, all using Casper Admin and Casper Imaging.