In my last post, Building a Base OS X Image, I wanted to cover AutoDMG but felt it was to much for one post. Building and Deploying OS X with AutoDMG can be easy depending on what you are hoping to have done before handing the computer off to your end user. Below I will cover how to build your OS X image as well as some deployment options!
For those who haven’t played with AutoDMG, it was created by Per Olofsson for streamlined base image creation. The tool’s purpose is to take an OS X installer and build a base image without having to install OS X on a computer. This process will generate a never-booted base image. The discussion of booted vs never-booted generates a lot of comments about what is better. Instead of diving deep into the discussion, I have posted a few considerations to weigh when looking at never-booted base images.
- Quicker to build a base image
- Ability to be more agile when updates come out
- Recovery partition is included
- AutoDMG is a free tool
- Requires updates from Per and his contributors when Apple publishes a new OS or update
- Might require scripting to meet same requirements as booted base image
- Initially takes a lot of trial and error to get the workflow the way you want
Building an Image with AutoDMG
Once you drag and drop your OS X installer into AutoDMG, it will check the OS version and look for any updates that are not currently within the installer. With my Mavericks version, I did not have some iBooks and iTunes updates. You can also drag additional packages into the Additional Software area below. However, I would recommend keeping this to a bare minimum if you are using a management tool. In my opinion, it is best to have these software titles separate and use a modular imaging approach.Important note: if you create the image as seen below, you might not be able to login. If using a management tool, you could automate an account being created during imaging. If you are not using a management tool, you might want to check out another one of Per’s tools: CreateUserPKG. You can also insure that the .AppleSetupDone file is removed so that the computer will launch the setup assistant on boot.
AutoDMG stores updates and files it downloads for patching in ~/Library/Application Support/AutoDMG/Updates. If your computer is feeling full, you might want to check and make sure you don’t have a ton of files saved from previous base image creations. When you click build, AutoDMG will ask you to save the file, download updates, and ask for administrator authentication. Once that is al done, AutoDMG will start to build your image. Now go grab coffee!
While you are away, AutoDMG will install OS X, install additional updates and software, convert the disk image, and scan for restore. This process can take about 20-30 minutes on a SSD drive. Once you are finished, you will be alerted that your base image is compete!
Deploying an Image from AutoDMG
In my opinion, there are three main ways we can look to deploy the image we created above! Each have their place but not all might apply to your needs. Please read them below and see what one might work the best for you.
Disk Utility Restore
Using our never-booted image, we could restore and setup one computer at a time. This could be a good workflow for a few devices but will quickly cause a lot of IT admin overhead. If you do decide to do this workflow. Make sure that the .AppleSetupDone file does not exist in /var/db. If it does, you will not have the ability to go though the Setup Assistant and might not be able to login.
- No management software required
- Time consuming
- Not scalable
Fully Scripted Imaging
Using a tool like Casper Imaging, I have seen folks image a computer but then add several scripts to run after to configure settings like time zone, location services, and language. While this method would give us a setup the same as we had in my previous post, I believe this defeats the entire reason why we chose a never-booted image- we want to save time and energy. Building these scripts takes lots of time to build and test.
- Same outcome as booted image after scripting
- Great for shared or lab computers
- Takes lots of time and energy to create and maintain scripts
User Provisioned Imaging – My Preferred Method
Again, using a tool like Casper Imaging, image a computer with software and the base image. The change here is to allow the Setup Assistant to run after reboot. This will allow our end user to setup their computer with the settings that make sense to them. The one hiccup we have in this workflow is that a user created by Setup Assistant is an administrator. The cool part though is that I have a fix for that problem!
- Very little configuration and setup for IT
- Easy to update because of simplicity
- Setup Assistant creates an admin*
- Only works well if the computer is used by a specific person
LaunchDaemon to Demote Administrators
If you don’t need to see how the this works, feel free to skip to the end of the page for my scripts and info about permissions. However, I feel like most people really get how cool this workflow is by seeing it! So I made this quick video show the process. The whole imaging process took about 5 minutes but I cut a few pieces down to keep from boring you.
To make the workflow in the video above, all you need is three things: never-booted base image, a LaunchDaemon, and a script to demote user(s). Please make sure that you remove the .AppleSetupDone file if it was added (again because we need the user to setup the computer). If you notice in the video, I force Casper Imaging to run the Setup Assistant. This is because Casper Imaging assumes that you do not want to run it. Also, the reason why we have a script and a LaunchDaemon is because I am letting the LaunchDaemon do the heavy lifting for us. It will be watching for the .AppleSetupDone file (see why it is important) and will run the script after it is generated (which is only when the user gets created).
Below are my copies of the LaunchDaemon, demote script, and my notes on required permissions. Please test before using and enjoy!
- Needs to be placed in: /Library/LaunchDaemons
- Name in reverse DNS order. Ex: me.bareis.demote.plist
- Owner: Root
- Group: Wheel
- Permissions: 744
- Script assumes it is in: /Library/Applcation Support/dsclDemote
- Script assumes it is called dsclDemoteUsers.sh
- Owner: Root
- Group: admin
- Permissions: 755
Visual Folder Hierarchy
Below is a screenshot of the folder hierarchy that I used with the items above. As long as permissions are correct. Following this exact setup will work for you!