With new Apple hardware now available on the market, I've found myself revisiting alternative methods for provisioning and re-provisioning Mac hardware. Interest in "non-imaging" provisioning methods has ebbs and flows in the MacAdmin community, and seems to be at the forefront yet again due to the reading of tea leaves and testing old workflows on new hardware that can (and might in the future) have unexpected and undesirable results. Last year I started toying with the idea of a customized QuickAdd package when it was looking like DEP wasn't a possibility at my old shop. New Macs (especially brand new hardware models) often come with forked OS builds that accommodate new features that the OS installer from the App Store has yet to include. If you buy a new machine, then wipe the shipped OS and install your own (or even delete the entire drive and all partitions), you may find yourself gambling when you don't need to.
Anyway. I'm not here to stern-parent-stare you, other people can do that. ಠ_ಠ
Back to the QuickAdd package.
So the build of the QuickAdd package changed slightly with JSS/Jamf Pro version 9.9, which included a new location of the jamf binary to behave well with recently-added SIP restrictions. Jamf also changed around the components of the QuickAdd package and binary installer. As of 9.96, it looks something like this:
Because of the binary moving to /usr/local/, the postinstall script in the QuickAdd package is slightly different as well.
Much like I discussed in my previous article, running custom policies that mimic imaging is fairly easy by including a command after the binary is installed that runs on a custom trigger. In this example I created policies in the JSS that ran on the custom trigger of qaenrollment (line 47).
I also added an additional recon after the qaenrollment policies run (line 52).
I remembered that I had to find a way to get the computer name updated to reflect our naming conventions, and in the past that involved installing cocoaDialog for a prompt with input. I decided this go-round that I didn't want to install any additional tools if I didn't have to (less is more), so with help from RossD I cobbled together a way to get input from Elliot Jordan's JSS FileVault 2 Key Reissue project that uses AppleScript to display a dialogue prompting the IT person provisioning the hardware to set a computer name.
The result will be something that looks like this:
I decided that getting the user was somewhat irrelevant as here we include the username in the computer name, so I didn't include that in my updated workflow.
I've been using LoginLog during our traditional imaging process for observation/monitoring, so I wanted to see if I could replicate that during this workflow as well. To keep it simple I just have a policy on the qaenrollment trigger that runs the Unix command open -a Console /var/log/jamf.log. This opens a Console window to the jamf.log where someone setting up a computer can monitor progress.
The window looks something like this:
As far as the rest of this goes, what's installed is up to you. I did my best to mirror our imaging process, so I put policies like the following into a Enrollment – QuickAdd category and on the qaenrollment trigger.
As always, test and evaluate before you start using this day-to-day. Not every environment is the same, and needs may very. We're pretty light touch here, so this works rather well for us.
If I'm lucky and can get DEP going here, we won't even need to bother with the above. But it's a nice middle-ground to move away from pave-and-image and provision machines rather than image them.
Did you find this post useful? Leave me a tip!
💖
Anyway. I'm not here to stern-parent-stare you, other people can do that. ಠ_ಠ
Back to the QuickAdd package.
So the build of the QuickAdd package changed slightly with JSS/Jamf Pro version 9.9, which included a new location of the jamf binary to behave well with recently-added SIP restrictions. Jamf also changed around the components of the QuickAdd package and binary installer. As of 9.96, it looks something like this:
Because of the binary moving to /usr/local/, the postinstall script in the QuickAdd package is slightly different as well.
Much like I discussed in my previous article, running custom policies that mimic imaging is fairly easy by including a command after the binary is installed that runs on a custom trigger. In this example I created policies in the JSS that ran on the custom trigger of qaenrollment (line 47).
I also added an additional recon after the qaenrollment policies run (line 52).
I remembered that I had to find a way to get the computer name updated to reflect our naming conventions, and in the past that involved installing cocoaDialog for a prompt with input. I decided this go-round that I didn't want to install any additional tools if I didn't have to (less is more), so with help from RossD I cobbled together a way to get input from Elliot Jordan's JSS FileVault 2 Key Reissue project that uses AppleScript to display a dialogue prompting the IT person provisioning the hardware to set a computer name.
The result will be something that looks like this:
I decided that getting the user was somewhat irrelevant as here we include the username in the computer name, so I didn't include that in my updated workflow.
I've been using LoginLog during our traditional imaging process for observation/monitoring, so I wanted to see if I could replicate that during this workflow as well. To keep it simple I just have a policy on the qaenrollment trigger that runs the Unix command open -a Console /var/log/jamf.log. This opens a Console window to the jamf.log where someone setting up a computer can monitor progress.
The window looks something like this:
 |
| Computer name changed to protect the innocent |
As far as the rest of this goes, what's installed is up to you. I did my best to mirror our imaging process, so I put policies like the following into a Enrollment – QuickAdd category and on the qaenrollment trigger.
- Open Console.app to jamf.log
- Prompt for computer name
- Run "first boot" script for settings configuration
- Bind to AD
- Create local admin account
- Install applications
- Install printer drivers
- Install preset Dock
- Install company desktop pattern and desktop pattern setting
- Restart
I make sure to name them in a way that keeps them in the order I want them in, and found this best accomplished by using numbering (you can see an example of that above).
A few parting thoughts:
- Getting the reboot to fire is a crapshoot sometimes, especially if the QuickAdd Installer is sitting on a Complete screen. I've found on the 16B2659 build of 10.12.1 that apps very easily stall the shutdown process (Spotify and Chrome, I'm looking at you). So ymmv here. You could throw in a jamfHelper pop up that says "Hey you, shut me down" or something.
- You can make your trigger whatever you want. I just wanted to make it something that I know I wouldn't use elsewhere.
- If you're concerned about getting user info during recon, just have something like this run on login or at regular intervals.
This works best when you have LDAP setup for LDAP lookups. - The AppleScript prompt above can be pretty easily adapter for other things you might want to get from a IT person setting up a computer.
- Speaking of… don't expect the jamf.log to start showing the updated computer name after you set it with the prompt. You'll see that reflected after you restart the machine.
- If you want to cling to pave-and-image workflows for your computers that's fine, just make sure you do your due diligence to know what the impact might be if you have machines with forked OS builds.
As always, test and evaluate before you start using this day-to-day. Not every environment is the same, and needs may very. We're pretty light touch here, so this works rather well for us.
What I've recommended to the folks here when they need to reprovision a machine that was previously deployed:
- Boot into Recovery and erase ONLY the Macintosh HD partition.
- Reinstall the OS.
- Log in with a local account.
- Open a browser and go to the URL with the QuickAdd package shared.
- Run QuickAdd package.
- When provisioning is complete, reboot and sign in as the user/have the user sign in (since we're AD bound)
- Profit.
If I'm lucky and can get DEP going here, we won't even need to bother with the above. But it's a nice middle-ground to move away from pave-and-image and provision machines rather than image them.
Did you find this post useful? Leave me a tip!
💖
Write a comment
Post a Comment