Custom Order During Imaging

@wallis.isaac while probably not the method you'd like, this can be accomplished with two policies. First policy takes care of steps 1 & 2 and second policy handles the install of the OS.

The second policy will not have any triggers selected, it will simply have whatever scope you want and the OS package. You could scope this to All Managed Clients if you would like, since you will be calling this manually.

At the end of the script to remove the firmware password, you would call the second policy. For example, if your second policy had an ID of 20 (the ID can be found in the URL of the policy when viewing the policy), then your script could look like this:

#!/bin/sh
/Applications/Utilities/Firmware Password Utility.app/Contents/Resources/setregproptool -d -o "CurrentPassword"

jamf policy -id 20

The only other way I can think to do this would be to use a script to do all of it, utilizing curl to download the packages from your distribution point (assuming an HTTP DP), and then doing the install inside of the script.

@stevewood

Thanks heaps, I'll give this a shot now and hopefully it's all good.

At the moment I'm pushing out the download + remove policy, to run at as many opportunities (power on/off, log in/out, check in, etc.).

For the imaging process, could I have a script that is just

#!/bin/sh
jamf policy -id ID_OF_DOWNLOAD_AND_REMOVE
jamf policy -id ID_OF_OS_ISTALL

just to catch any that have slipped through?

@wallis.isaac yes you can absolutely do that using Casper Imaging. Your imaging configuration would simply be a script pointing to both of those policies.

This is what I've got in the script (Year 10 Decomission Script)

#!/bin/sh
#Run the download and install FPU policy (Buyout Preparation - Imaging) and remove the firmware password
jamf policy -id 1503

And this is the message in the logs

Result of running Year 10 Decomission Script was: /Library/Application Support/JAMF/tmp/Year 10 Decomission Script: line 3: jamf: command not found

The machine was newly imaged with 10.8 (to test in the same environment as the year 10 students, most of them havent updated since year 7), so I ran

sudo jamf enroll -prompt

just to make sure it was connected to the JSS. The same problem happened upon reimaging then too

Any ideas?

@wallis.isaac so that actually makes sense, the results you are seeing. I wasn't thinking through the steps well enough when I posted that. I'm going to assume that you are running that via Casper Imaging, and if so, the reason you are receiving that error is because it is running against the system that is running Casper Imaging. So if you are booting the system via a NetBoot set, the script is trying to run the jamf commands against the NetBoot set and not the system. Make sense?

I think there are two ways you could try to do this. The first would be to package your script up with a LaunchDaemon and deploy via Casper Imaging. When Casper Imaging reboots the computer, your LaunchDaemon would kick off and run the script. The only problem I could see is that after the OS image applies, the machine would still be enrolled in Casper and you'd have to issue jamf removeFramework to un-enroll. And honestly, I think that will be true of any method you use.

The second way I would tackle this is as a Self Service policy with Autorun data. The Self Service policy downloads FPU, runs FPU to remove the password, sets the starutp disk to be a NetBoot set and then restarts the machine. On restart Casper Imaging would find the Autorun data, which would be set to your OS image. The configuration that Casper Imaging would need to run would need to include commands to erase the disk and then lay down the OS image. You would still end up with a machine that was enrolled in your Casper server, and you would need to unenroll the machine (which means logging into the machine, which means having a user on it).

There have been discussions around decomissioning machines in the past, one of which is right here:

Machine Decommissioning - Best Practice

@bentoms points out the use of his product, Imagr, as an option, a very good option if you ask me. By using Imagr you can lay down an OS image without the machine being enrolled in Casper.

Hope this all makes sense and helps you out.

@stevewood

Ah, yeah that makes sense. Is there a reason that the Casper netboot doesnt have the JAMF commands?

At the moment I think we're just going with the FPU policy getting pushed out by as many means possible, and manually removing the passwords for ones that are left. We've got about half the machines completed at the moment, and D-Day is the end of this week, so I'll leave it as is and play with it next year.

Thanks for the assistance, it's helped us heaps

@stevewood and anyone else that may be able to help

Is there a way for us to get the jamf commands onto the netboot environment?

We've got the Environment made from https://macmule.com/projects/autocaspernbi/, using a sierra image as the base. A few questions:
1. Does the jamf binary go in /usr/local/jamf?
2. If yes, does having it there automatically include the jamf commands into terminal, so they can be run from a script when imaging?
3. How can we add this to the Environment? Is there a package that will install it there?

Cheers

@wallis.isaac I believe you can probably drop the jamf binary on the NBI, but why would you want to? If you are simply trying to run through your workflow you laid out above, then I would just do it in a script without using policies.

Create a script that will use curl to download the FPU installer and install on the machine, and do whatever other cleanup you need. Could end with a nuke of the drive and then curl the OS file down and install it via script.

Again, however, the thing to remember is that if you use Casper Imaging for this, you end up with a machine that is vanilla AND enrolled in the JSS. If your goal is to remove the machine from the JSS AND have a vanilla OS on it, you need to look at my previous post where I reference Imagr by @bentoms .

I only decommission a handful (10 to 20) laptops each time I do a refresh, and I do this by hand. I boot the machines off of a Thunderbolt SSD drive, use diskutil partitionDisk to erase the drive, and then use ASR to push a vanilla OS DMG that I captured from an out of the box machine. Total time per machine is maybe 3 minutes.

@stevewood

Mainly because while this year there's only 10-20 machines with firmware passwords, next year we'll have more than 300. We've found that policies aren't fully reliable in pushing this out (2 weeks active, 218/380 have it applied), so if we can include it in the imaging process, then it'll save a lot of time.

Can you give an example of how we'd use curl in a script to download and install the package, to any location really, instead of relying on jamf commands?

As for the JSS issue, we're naming them all DCMB13-[SERIAL NUMBER], so we can bulk remove machines with names like DCMB13 when this is over. We start tomorrow, so we don't really have time to start working on a new approach, but we will probably look into it for next year, depending on how this year goes

Could you not set this up as a configuration with the priorities set so they run in order

Priorty 1. Add Firmware Password Utility (a package)
Priority 2. Remove Firmware Password (a script)
Priority 3. 10.12.1 Vanilla.dmg (a pkg in the JSS settings)

@wallis.isaac I use curl to pull down images or packages during our DEP process, and for other things. Here are the basics of what you could use:

#!/bin/bash

# grab the URL to the FPU pkg on your DP from the logs of the policy pushing it
curl -so /tmp/FPU.pkg https://yourDP.yourdomain.com/CasperShare/FPU.pkg

installer -pkg /tmp/FPU.pkg -target /

If you've pushed FPU via a policy, you can go into the logs of that policy to pull the appropriate URL to curl from. Here's an example of what I'm talking about:

If you are thinking of doing this while booted from NetBoot, you would want to throw in some logic to discover where the specific partition you want to install on is mounted. Obviously it will be /Volumes, but to be safe you want to pull the correct volume. That gets a little trickier, but I'm sure there are examples on the web or maybe even in Jamf Nation showing how to do this using diskutil. You'll need to use that path in the installer command replacing -target / with the appropriate path. For example -target /Volumes/Macintosh HD/

My comment about using CI to deploy this and the machines being enrolled refers to not just the entry in the JSS, but the fact that the jamf binary and associated items will be on that machine. You would, ideally, want to run jamf removeFramework on those machines to clear away any cruft before handing them over. That is why I mentioned Imagr or even just using an external hard drive(s) to wipe the machine and push an OS image via asr.