“Imaging is dead!” Now what? — Part 1

For quite some time, there have been whispers that “imaging is dead.” Neat. That’s either all fine and dandy, or the scariest three words an IT admin ever wishes to hear. The questions remain…but what do I do instead? How much work is it going to take to transition into another workflow? Where am I going to find the time to test this all and build out so many more processes? Do you understand that I’m the only IT admin and I’m already busy doing everything else? I’ve been doing monolithic imaging for decades! Monolithic just works. All very valid points. Imaging as we know it has changed with the introduction of APFS (Apple “proprietary” File System). Fret not, for if you’re a Jamf Pro user, you have already worked with the necessary processes and workflows needed to create a new and more efficient provisioning process at your organization, both businesses and schools alike!

Monolithic imaging is indeed a thing of the past. Jamf has the ability to wipe a computer, enroll a computer and install all necessary software for your end user — without any IT admin having to physically touch the machine. How? This sounds like a unicorn methodology where only in extremely specific workplaces or environments would the necessary planets align for it to work that efficiently. Not the case. We have organizations of all shapes and sizes using the new methods, some of which I will highlight below. And yes, these are all Jamf-approved solutions to provisioning your machines. Everything you see below is supported by Jamf.

What does it mean to “image” a machine?

That’s where it all starts, right? To image a machine is to get the computer out of the box, plug it into a dongle with ethernet and NetBoot, or a dongle with an external hard drive and clone data from one big storage device to the target machine. Great. What is the outcome? A computer — ready to be deployed — with the proper operating system (OS), applications, customizations and settings/security. Now, since “imaging” is dead, let’s work backwards and create that same imaging result, but with provisioning.

The desired outcome

Your first task: sit down, grab a tall, tasty beverage, and open up your spreadsheet editor du jour. If you’d like a ready-to-deploy machine with all your apps and customizations on it for reference, bring that along too. In column A of the spreadsheet, list out every application, setting and customization — one item per row. Consider all of the things that need to be on the machine prior to your end users getting their hands all over it. For example, if you deploy Chrome and a homepage, those are two separate lines. If you deploy “Network settings,” one SSID per line, one VPN per line, one 802.1x configuration per line, etc. If you already have a checklist of items you deploy, that’s awesome! You can now go over and make sure the checklist is up-to-date and not from winter 2014! You may think to yourself, “I know what I deploy, I don’t need to write it down.” This list isn’t to test your knowledge, it is to be used as your source of truth when building out your new thin imaging/provisioning workflows in Jamf Pro. I’m certain you’ll find that once you have everything written down and you go to compare what you have configured in Jamf Pro, either ready to deploy or already deploying, the number of “new items” you need to add will already be less than previously thought. Column B will be for the category which the corresponding line item falls. Settings, Customizations, Applications or OS. You should label each of these line items and assign a category to them.

Organization is key

When creating a new workflow/deployment procedure, it is best to be as organized as possible. If you’re new to your organization and the previous admin had their way of doing things, now is the time to do it in a way that makes sense for you and to document what you have created and architected when it comes to training a new admin at your organization or for reporting purposes. One thing to keep in mind is the naming convention of your policies, applications, filenames and groupings. When it comes to naming conventions, every organization is different. Make a naming convention that works for your environment and what makes sense to you. Keep a scheme like: “APPNAME-VERSION.pkg” where it would look something like: “Google Chrome-67.0.3396.79.pkg” or: “CATEGORY-APPNAME-VERSION_DATECREATED.pkg” where it would look like: “Browser-Google Chrome-67.0.3396.79_20180513.pkg.” This way when you’re looking for an application you can find it via category, and if you want to ensure you’re not replacing the new version with an old one, the version is sitting in the filename. If it’s a setting: “SETTING_APPNAME-WHATSADJUSTED_DATECREATED.dmg” like: “Setting_Google Chrome-Homepage_20180513.dmg”. There are certainly many iterations of the above, but if you have a naming convention now, down the road you’ll certainly save yourself a lot of time and headache.

Settings/Security

If you have used Jamf Pro or are coming from another mobile device management (MDM) provider, deploying settings to devices that are already deployed in the environment is not a new thing. When deploying these settings via Jamf Pro you have configuration profiles, polices and restricted applications at your disposal. There are certainly times where you’d want to use one payload over another and there are times where one device should get different settings than others around it (i.e. desktop vs. laptop, teacher vs. student, graphic designer vs. CEO). The best methods to ensure proper deployment is to create one particular setting per deployment option. One example would be keeping one 802.1x configuration per configuration profile. When deploying Finder preferences and Sleep/Screen Saver policies, you should create two separate policies, one for Finder preferences and one for the Sleep/Screen Saver policy. If in one configuration profile you combine a local password payload, two SSIDs with passwords set to autojoin, and VPN settings all in one profile and down the road, you need to adjust either one of the SSID passwords or VPN settings, the settings will not delta update, and upon removal and replacement of the new profile, the device will have just lost internet. Not a desired workflow. Instead, having each setting or necessary grouped setting on its own, you can deploy the specific settings to whichever the desired target device is at time of provisioning.

Customizations

This would be the best time to streamline your provisioning workflows and weed out unnecessary deployments. Like all settings, both general and security, customizations to the OS itself or user environment are made to somehow modify the user’s space or the applications they use. In the past, when building a monolithic image, your customizations to the browsers homepages, the default apps you want to have open at login, and preferences inside of the mail/calendar utilities are adjusted once and then deployed to all desired machines via the block-copy. Jamf Composer has the ability to capture these exact settings and deploy them out to the client machines! (Programmatic scripting could certainly deploy these as well.) In Composer, you can capture just the customization you wish to deploy, bundle it up as a .pkg or .dmg and upload it to Jamf for deployment via policy. If you’re unfamiliar with Composer, have no fear, this video tutorial is here! More of a reader? Check out the Composer User Guide.

So now that you know how to package up that customization, think about each application and setting you’d normally need to adjust and see if the customization is absolutely necessary or if you just were doing it because its motor memory to do it from 10 years ago!

Applications

Head back to your list of line items that need to be deployed to a machine prior to handing that machine to the end user. Find your applications from the list and in one folder on your computer’s desktop, gather all of the installers and necessary items needed for installing the application as if you were to install the application on your machine for the first time. You’ll notice the majority of these are a single item deployment, meaning .dmg or .pkg, while the rest may be bundled in a folder with multiple items needing to be installed in succession. In the end, each of these installers/applications will be their own policy. Also, you’ll need to ensure each package you upload to Jamf works when deployed from Jamf. This is to ensure the same result happens if you installed it clean on the machine you’re sitting at. And, as always, test, test and test again. If the file you downloaded from the developer/manufacturer is a .dmg, 99.9 percent of the time this will need to be re-packaged in Composer. On the other hand, the majority of .pkgs that are in the wild need not be re-packaged at all and are ready to be deployed as is! 

Back to your list. For each app, in the next column, add whether the installer is a Mac App Store App, .pkg, .dmg or folder/multiple files needed to complete install. And in the final column, add if there are any OS restrictions as some apps are not compatible with later OSs and need updating. Create another folder on your desktop called “Ready to Upload”. This is where you’ll put your .pkgs and re-packaged installers ready to be uploaded to Jamf. Take a look at the folder containing all of the installers you’ve gathered, and cmd+select every .pkg you find, copy that group, and paste into the “Ready to Upload” folder. For all the others, use the snapshot method in Composer or “drag-and-drop” for app only .dmgs and those multiple installer buggers. How to do this? The same way as you used Composer to create those “Customizations.” Find a computer, or VM, that does not have the desired app already installed on it, open Composer, create that first snapshot when the app is not installed, complete the installation as if you were installing it on your computer, then the closing snapshot. Ensure no extra files fall into that bundle and package ‘er up! Once all your .dmg and folder/multiple installer files are re-packaged, add them into the “Ready to Upload” folder as well. If your item does not have an installer, it was probably from the Mac App Store so there is no packaging/uploaded needed. Check to ensure all applications in your list have a corresponding .pkg or .dmg, or can be found in the Mac App Store. If some are missing, ensure you reach out to the manufacturer to get the installer to be uploaded into Jamf.

An operating system

Since OS X Lion, Apple has allowed major OS releases to be installed using just an installer that has been plopped down onto a machine and ran with a command, and that holds true today. Machines that are compatible with macOS High Sierra can be updated using the “Install macOS ___.app” App Store app and installed via Jamf. There are many workflows for many scenarios on how to get your out-of-date computers up to date if they’re in the wild. But if you are on High Sierra in your environment, let’s get them to 10.13.4 and any new machine you get from the factory to also be on the minimum of 10.13.4. Why? APFS was the beginning of the mourning of imaging. Along with APFS, Apple introduced the “startosinstall” binary with the ability to “--eraseinstall” in 10.13.4. This is truly where the greatness of automation takes place. Using the command line, or any of the workflows highlighted below, you can erase and install a computer back to factory settings like you can with an iOS device. Whether the computer is in a lab and locked down, if your employee has moved on to another adventure, or if the students are done for the semester, by using Jamf you can have that computer wipe, enroll and provision itself wirelessly!

In part 2, we’ll cover building the policies needed to deploy packages and scripts.

Not already a Jamf customer? Take our best-of-breed Apple management solution for a free test drive and start putting these workflows in place.