Casper Imaging (no erase) initial deployment .. vs. Policy deployment

[loceee]

I'd like to start a discussion around thoughts, pros and cons of approaches. I am re-evalating my preferred method for initial deployment and would love to get some thoughts about both approaches.

Approach 1. Casper Imaging machine configuration. Pkgs, configuration scripts are deployed by Casper Imaging machine configuration... with an erase or no erase.

Approach 2. Casper Imaging OS only or Mac from the box is enrolled, machine configuration done entirely post enrolment via policies.

Both have swings and round-a-bouts.

I lean towards utilising Casper Imaging... as it's the more supported approach for initial deployment. Workflow for a new Mac being, run setup assistant, hit an internal portal to download Casper Imaging, run and choose a "no-erase" machine configuration. Software is installed, Mac is enrolled, bound, booted, patchoo bootstrap patches to latest (in case of version drift or OSX patches).

Casper Imaging:

Pros
- It's the supported workflow around intial deployment, even though a lot of people don't actually image anymore.
- Machine configurations within the Casper Imaging/Admin GUI are very visual, you can see exactly what's being deployed to a computer.
- There is a GUI whilst it's running, (although the firstboot screen is a little rough)
- You can leverage JAMF's firstboot, and Adobe install workarounds (why build this yourself?).
- You can also leverage pre-staging for large deployments.
- Completely refreshing (with an erase) is the same workflow and a vanilla unbooted OSX.dmg, and you can just make an erase / no erase a smart config under your base.
- Computers are named easily, and configurations can be stored / linked back to the JSS easily.

Cons
- It feels like it's become a little unloved. https://jamfnation.jamfsoftware.com/featureRequest.html?id=1155
- We need "application groups" and some more abilities around grouping common pkgs / etc. one level of "smart configs just isn't enough).
- Machine configurations aren't available post deployment. For me it makes sense to utilise the outside of Casper Imaging. https://jamfnation.jamfsoftware.com/featureRequest.html?id=2261
- It's called imaging, even though you don't have to image with it. - Is it even going to hang around? It doesn't make sense to build your workflows around it, when Imaging is an old methodology and it feels like it's stagnating and might not even be around come v10.0.

JSS Policy Based

Pros
- Supports a more modern even BYOD workflow. User enrols computer, computer is configured to good state.
- You don't have to get the Casper Imaging app on to the Mac, nor Netboot (unless of course you are baremetal or in a very broken state).
- Build via smart group and all that delicious data within the JSS.

Cons
- No visual way to determine every thing in your builds (potentially having linked and chained polices could get very complicated and more difficult to debug).
- No GUI (build it yourself)
- No way to assign computer configuration / identifier (build this yourself)
- Much more admin heavy lifting, policies and scripts (again policy, smart groups...)
- No drag and drop to change computer configurations
- No computer naming during deployment (build this yourself)
- No "best practice", it feels like everyone is doing their own thing around pkg deployment and Mac identification.
- You'll still need Casper Imaging (or something) for bare metal unless you are internet recovering and manually pulling OSX from Apple.

Why do I ask all this?

I am considering working something into Patchoo to handle some of the stuff for JSS policy based deployment, but would love to know how people are taking Macs from the box and getting them into their desired state.

On the other hand, I still think we should use the tools that JAMF supply as much as possible, which is why Patchoo was built to augment the existing, group-->policy--->deploy workflow for POST deployment patching.

Thoughts?

[timdambrosio]

Doing everything policy based here. Base image done with Autodmg with no additions. We can net boot/Image a machine, enroll a new machine out of the box that won't net boot in the case that it's newer that the NBI or we can restore a machine from Recovery HD then enroll and get the same results. The second 2 options can also be done off site for us as we have our JSS hosted in AWS with cloud DP.

More work to setup initially but much better to manage ongoing.

[calumhunter]

For me the casper imaging GUI's problems of showing EVERYTHING is the biggest problem.
We can't trust the end users(techs) who are deploying machines to not mess things up. So instead Im a huge fan of deploy studio because it has the functionality that allows you to set permissions on which workflows are allowed to run.
Then I just use a first boot policy that sets up the machine and installs the base software.

[Kumarasinghe]

Casper Imaging needs immediate attention. They way of controlling all the settings for Casper Imaging should be through JSS. When someone selects a configuration it should automatically fill the details according to the settings stored in JSS.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2186.

Some of the features we need now;

1)Update Casper Imaging - Give it some LOVE
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1155

2) Casper Imaging settings to be preconfigured in JSS
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2186

3) Hide or scope configurations to specific groups
https://jamfnation.jamfsoftware.com/featureRequest.html?id=170

3) Ability to look for the first available disk instead of the target drive name(we had to run some scripts to achieve this)
https://jamfnation.jamfsoftware.com/featureRequest.html?id=61

4) Imaging logs to contain who imaged the machine.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=145

5) Imaging logs to contain the configuration used for imaging and record in the inventory or able to read from an EA.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=841

[loceee]

All good feedback. Probably my biggest issue with policy based deployment is the lack of GUI, prompting for computer rename, client identification (fake receipt methods) and lack of CS6 / adobeuser workarounds.

Good know know what people prefer for this. Are deploying policies based on "once per computer" or utilising other fake receipt "deployDone" or ext attribute to populate once deployment is complete.

[timdambrosio]

We have about 300 policies and almost all are scoped to smart groups and most of them are set to ongoing.

We are also making use of static groups as application groups like you mentioned. Our help desk staff add a machine to a static group via a custom API page and the software gets installed, if they remove the computer from the group the software gets removed. If they re image the machine it always gets the correct software.

[calumhunter]

I've used once per computer, but I really like the method @timjd4 has suggested, when I have a new site to setup if jamf hasn't drastically improved the way things are done now I think that is how I'm going to go about it, i really like the web app using the api to assign machines to a group for software deployment

[emily]

For new machines we do something similar to a "policy deployment" but rather than having something totally automated on the enrollment trigger we use custom policy triggers. So when we enroll a machine some basic software is installed that is included for all users, then in the terminal we run

sudo jamf policy -trigger oob_enroll

…and it runs some other policies built specifically for what we call Out of Box (OOB) enrollment. It also places a dummy receipt (http://www.kitzy.org/blog/2013/10/5/making-smarter-dummy-receipts-with-plists)
on the machine that specifies that it was an OOB enrollment so we can then customize policies for machines configured by an OOB enrollment. It's a tad less automated but we find it gives us more control over the process. It also ensures that when we run imaging using Casper Imaging that the policies aren't redundant.

[dpertschi]

I've been tinkering with deployment strategies recently also and sliding slowly towards policy based. It seems to me that JAMF is encouraging this also and I have a feeling the Imaging app. won't be significantly developed much further. But, it's still my personal preferred method due to the flexibility it offers.

I've got two 'Imaging' configurations. They're nearly identical except one contains an AutoDMG base image (for re-imaging, erase drive) and the other does not (for new machines, don't erase drive.)

I have several nit picks with the Imaging app as others have mentioned, but most of my problems with it are operational and come down to user issues. My tier 2 support staff that are deploying machines are not always using the current version and/or can't seem to understand how to use it properly no matter how simple I try to make it. "It was a brand new machine? Yes. And your using the no-OS config. Yes. So why did you erase the drive?…"

So to solve that 'problem' I created a custom triggered, deployment policy for new machines. Again, including most everything that's in my Imaging Configurations.
1. unbox, boot, run QuickAdd package.
2. run custom trigger package.

This solves several problems, but is a bit more difficult to engineer the order of operations.

Here, with a large global tier 2 staff deploying machines I have to develop to drop-dead-simple. Policy based deployment also eliminates the need to boot from an external drive, which seems to be a challenge for some folks. And Netboot is a ridiculous hassle to maintain at more than one or two locations. I give up on that mess.

I expect I'll end up fine tuning the policy based method and then turning it over to end-user self provisioning.

Lessons learned to date on this topic, simplify. In 12-18 months you'll probably need to change it.

[acdesigntech]

We're doing policy-based setup here, triggered by a LaunchDaemon that runs on first boot.

Workflow is Netboot to a custom script, answer a few deployment questions (deployment type, location, etc), a name is auto-generated, LaunchDaemon and custom gui is installed to Macintosh HD and the computer is rebooted. Then LaunchDaemon throws up the GUI and runs a quickadd in the background. After that a setup policy is called which makes one or more decisions based on where a computer is on the network.

Reimaging is essentially the same process: Netboot -> custom script -> LD and reboot. Only difference is it restores a factory dmg of that model to get a clean, base, Apple-ified, never booted image again. From the techs point of view there is no difference except what NBI to use.

The biggest challenges here are keeping up with the OS and any Apple "Fork U's" with netbooting, keeping a stable of dmgs to restore from (really not that big a deal at the end of the day), and the fact that every once in a while a policy will be called while post-setup is running that will mount another copy of the CasperShare, then unmount it, screwing up the setup. To that end I have an EA that gets populated to block all other policies except the post-setup policy, then removes that EA once finished.

I'd love to be able to use a truly GUI-based deployment tool again like CI, but with all the bugs that CI experienced with v8.x I abandoned it quickly. Plus I think that JAMF is going to kill it since it hasn't gotten ANY love since sometime back in the v7 days I think...

[loceee]

I'm again thinking out loud about how patchoo can implement deployment.

Patchoo actually already has a bootstrap mode that does the loginwindow feedback, so attached a few more modes to augment a policy based workflow should be possible.

The approach of tagging a machine with fake receipts to identify it to the JSS appeals to me. (eg. deploy-accountsdept). They are easily scopable and also easily read and created by a script. It could be accomplished by ext attributes, but not really necessary.

In the same vein and Patchoo's software deployment tracks are tied to group membership, using custom update triggers, you could your mac to a deploy configuration identifier that is appended to a trigger.. eg.

trigger: deploy - would fire your stand configuration policy
trigger: deploy-accountsdept - would fire your accounts depart policy

Or you can just tie it all to smart groups... eg.

Smart Group:
deployAccountsDept
Installed by Casper is deploy-accountsdept
Installed by Casper is NOT deploy-accountsdept.done

It moves some of the smarts to the client and requires somewhat less work within the JSS.

I'd like to build something that's usable in as many environments as possible. This method requires interaction during deployment, building something to simply touch the filesystem is easy... but...

but I do like the approach @timjd4 is using with static groups. That build data also being persistent if the mac is reimaged by adding the Mac to static groups.

I am battling with how I can both provide these two workflows:

- New computer, unbox, enrol - Tech Selects necessary builds (that's fine, can build UI and group/fake receipt script)
- New computer, unbox, enrol - Mac is "PreStaged" and allocated build based on static group membership to deploy build (not easy / possible?)

Since Casper doesn't have a placeholder concept like some other MDMs, you can only leverage this kind of workflow via PreStage imaging, or basing your deployment rules on network segment or other metadata ... which brings me back to Casper Imaging again and we are butting against some fundamental designs of Casper.

I can see there are lot of places where people might want to dropship a Mac to remote office, send a URL or they have a USB stick with quickadd... and then get an end user to enroll. In this case you might not want a bunch of choices around the configuration being delivered.

Does your workflow handle this situtation @timjd4 ? I can't figure out how I can manage that.

[timdambrosio]

We use the JSS Departments to some degree. We support multiple lines of business as our IT is run by a holding company. So a department is a line of business. If a new machine gets imaged/enrolled with no dept then it will miss a few items until the dept is set. This only needs to be done once so not a big deal. We also move computers between businesses so help desk can just change the dept and the machine will update with the correct software login window icon etc.. Anything outside of dept software is static group managed.

For patching we're just using 'Patch - SoftwareName' policies and smart groups. For software that can update while still being open, like Firefox, we just let it run in the background. For others we prompt the user with the policy notification explaining they can defer for a certain period of time then it will be forced.

[chriscollins]

We wrote a deployment app in AppleScriptObjC. So we have offices all over the world so new machine comes in for end user. Non-Apple tech IN that office takes machine out of box, creates the initial admin account, then runs our app.

They see a few text fields for computer name, drop downs for what domain the user is a part of and what software load they need, their user account, their office location. They enter that info and hit configure.

A script runs that renames the computer, configures the built in Cisco VPN and then installs a quick add package and enrolled in Casper. The script then runs "jamf policy <what policy we chose in the interface>" and runs the policy installing all our software and runs all of our scripts, binds to AD, etc, and shows all the progress to the tech using Cocoa Dialog.

So ultimately it's nice since the tech only has to know a few pieces of info which is mostly the info they would use to configure a windows box.

[gachowski]

The question is really what are the dependancies in your environment. AD, FDE, backup…. and how do you configure/install them without you onsite team or users having to do anything ( zero touch)

We do a combination ….

We use the factory image then have Casper Imaging install .pkgs, not erasing the drive. The imagining is trigger by a prestage. (the onsite team option boots the machine and only has to choose the correct netboot image) One of the .pkgs is a launchd that is trigger by changes to the /Users folder acting as 1st log in script. This script triggers FDE and AD and adds the “admin” account.

I don’t have zero touch yet as, the onsite team or users have to run two scripts that are on the desktop after they log in…one to reboot for FDE and for customize safari and deleting the two Scripts : )

If onsite team has to do a re-image, on the same netboot server as the Casper Imaging netboot image I have a netinstall netboot image..

I think both options are really out of date… Hopefully we will be moving to “enrollment” based deployment for X.10… just like an iPhone using Casper MDM : ) log in to a factory image, go to this url, install this profile, wait X mins and you now have all the supported software and security setting that are required.

C

[loceee]

Really cool to share all of this. Thanks everyone. Patchoo might get some function around a policy based deploy featureset soon with a bunch of this in mind.

[loceee]

I am quite interested in using a combination of a dropdown extension attribute as a "build" identifier and fake pkg receipts to provide a policy and enrollement based workflow.

Using methods like this to read and modify a computer's ext attributes... https://jamfnation.jamfsoftware.com/discussion.html?id=5476 .. and perhaps injecting into the QuickAdd's postinstall script to have hardcoded builds --- eg. QuickAdd-departmentname.pkg.

Hmmm... stay tuned.

[makander]

I dont know if this is still relevant, but I've been tinkering with the enrollment complete trigger within Casper 9.

Just enroll the machine and it'll trigger the policies and everything I need to have on the machines was laid down. Was pretty neat but I went back to Casper Imaging in the end anyway. I prefer the good ol' nuke and pave method.

[loceee]

Here's my take on it, for those playing at home. https://jamfnation.jamfsoftware.com/discussion.html?id=11849