Save script variables in imaging workflow

[adroitboy]

Hello.

I'm not sure if this is possible, but I am trying to see if it's possible to "save" the arguments passed to a generic script in a casper imaging workflow. Why?

I'm considering trying to use a generic script to add some jamf "receipts" to a machine at imaging time. The receipts that it will write out would be arguments in the script's arguments fields and passed in when calling the script (the $4 to $11 arguments) "after" casper but before it restarts. I can certainly do this manually, by choosing "Custom", going to the script and typing things in. I'd rather avoid the typing and instead have a few different workflows with different sets of saved arguments passed to the script being the only changes.

Is this possible? If not, does anyone have a nice way of mixing/matching several different policy combinations without creating a script for each combination?

[dwandro92]

What are these dummy receipts being used for? I'm assuming that they are used to scope policies to newly built machines? If you can provide a detailed explanation and a few example scenarios, I would be able to provide more help.

[adroitboy]

Yes, we were thinking of using dummy receipts to scope some policies based on Smart groups and "Packages installed by casper". I'd love to set the arguments per Casper imaging workflow, but I don't see a way to create a workflow that saves the arguments (as I could in a policy).

It could happen in the workflow for a lot of the apps, but we try to keep the imaging workflows to an OS, a management account, and as little else as possible. I could have techs type things in, but that leaves a lot of room for errors. I could use self service, but that requires post-boot work. I could polices to the nth power, but that's a lot of policies.

Something like this...

#!/bin/sh

bootTarget="$1"
jamfPath=${bootTarget}"/Library/Application Support/JAMF/Receipts"

# SANITY CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 1
if [ "$1" == "" ];then
    echo "Boot Target is not specified: Quitting now"
    exit -1
fi

if [ "$4" != "" ];then
    touch "${jamfPath}"/"${4}"".pkg"
fi

# and so on...

[dwandro92]

Do all of these workflows rely on a common factor such as building, department, role, etc?

If so, this is how I would approach the situation.

Scenario 1: Building or Department based workflows
Workflow type:

Examples:
All machines in building/department "ABC" will be receiving MS Office, Photoshop, and Illustrator, and also need the App Store disabled.
All machines in building/department "DEF" will be receiving MS Office, Photoshop, and Premiere Pro, and also need the App Store enabled.

Solution:
1. Create a script which prompts for building/department info via a GUI app (such as CocoaDialog) and uploads data to the JSS via the API during imaging.
2. Create smart groups for machines in buildings/departments that don't have the software/settings enabled.
3. Deploy software/settings to smart groups during imaging by using enrollment/check-in policies, or a first boot script + "custom trigger" policies

Scenario 2: Role based workflows
Examples:
All machines used by graphic designers/for graphic design will be receiving MS Office, Photoshop, and Illustrator, and need to have the App Store disabled
All machines used by IT/for supporting end users will receive MS Office and Casper Suite, and need to have the App Store enabled

Solution: 1. Create a drop-down or text extension attribute which holds a machine's role info.
2. Create a script which prompts for role info via a GUI app (such as CocoaDialog) and uploads data to the JSS via the API during imaging.
3. Create smart groups for machines in certain roles that don't have software/settings installed.
4. Deploy software/settings to smart groups during imaging by using enrollment/check-in policies, or a first boot script + "custom trigger" policies

If this is something that would work for you, I can probably provide you with a prototype to help you get started.

[adroitboy]

Hi @dwandro92

Unfortunately no, they aren't all going to rely on a common factor. It used to, which is why it could be hardcoded in an initial imaging script.

It is like your "role based workflow", but there's not a simple combo of 2 or 3 roles. There is a basic set of apps (browsers and things) plus ~5 or so sets of apps (roles) such as Creative, 3D, Productivity, iWork, Production.

As far as your solutions go, I'm wanting to have something that works in the netboot environment. Then it's just one step. It looks like #2 and #4 could probably work. I haven't used cocoa dialog, but assuming I could get it working in the autocasperNBI generated net boot image, that could work. Check boxes or multi-selection list would work great in that sort of a scenario to pick and choose optional roles to install. I wonder if it would even need to upload it via api...perhaps the script and cocoadialig could just write out the dummy receipts?

4, with the custom trigger policies could work, but wouldn't the first boot script need input as to which roles to use?

Ultimately, I just want to make it easy for a non-technical person to image a machine by selecting a combination of roles and hitting "go". I'd prefer to set those at imaging time rather than in groups in the JSS or using self service.

[alexjdale]

You could certainly write out dummy receipts, but the script would have to know which drive to write them to, and the tech would have to wait for the OS DMG to be block-copied before that script could run, so there is a wait for that.

I would personally move this function to post-imaging. Are your systems not touched by technicians at all after Casper Imaging is kicked off? No validation steps or anything like that post-imaging? We do AD binding and wifi setup after imaging which is where I would put this (CocoaDialog checkbox to select roles, write to a plist which is read into an extension attribute for scoping policies).

[dwandro92]

@adroitboy

My apologies, it looks like I forgot a return after the "Solution:" header in the role-based example. Those were all supposed to separate steps for achieving a single solution, rather than separate solutions.

Now that I have a better understanding of what you are looking for, I think I have come up with the best solution. I also think I am going to include this solution in my own imaging workflow, which gives me more of an incentive to get it done.

Here is what I am thinking:

Step 1. Create extension attributes which run scripts to determine if settings are applied.

Step 2. Create static computer groups for each individual "role".

Step 3. Create "Not Installed" and "Not Configured" smart groups for each individual setting/software title that you are trying to deploy during imaging. In the group's criteria, include the static computer groups (roles) which should receive the software/settings if they are not installed/configured using "Computer Group > Member Of".

Step 4. Create policies to deploy the software/settings and scope them to the associated smart groups. Have all of the policies use the same custom trigger (e.g. "Post-Imaging"), as the smart groups will ensure that systems only run the policies which are applicable to them.

Step 5. Create a script which prompts for role info via a GUI app that supports checkboxes (such as Pashua, or Python + Tkinter) and adds computers to the associated static groups using the JSS API.

Step 6. Update your FirstBoot script so that it kicks off the installations using your custom trigger (e.g. "jamf policy -trigger Post-Imaging")

[adroitboy]

@dwandro92,

That makes more sense now. It could certainly work. I'll play with your method. I'm not sure that we'd have computers in static groups - perhaps the only part that doesn't fit with my desired workflow. But, I could just change the workflow as well.

I might go less elegant and just create dummy packages to pick and choose using pre-defined workgroups or "custom" installs at imaging time. The first recon would pick up the receipts and assign the machines to the right smart groups to trigger post install imaging.

So many ways...so little time to play.