I do not leverage Casper Imaging. Problems/bugs in previous versions made me think of alternative solutions.

My workflow for provisioning a new Mac is: 1. Tech unboxes mac
2. Tech netboots Mac to "NewMacSetup" nbi
3. A script auto runs, names the Mac based on IP location and installs a LaunchDaemon to run QuickAdd on first boot
4. Script reboots Mac
5. LaunchDaemon runs at startup, installs and runs QuickAdd
6. QuickAdd calls a setup policy and reboots when finished

For (re)provisioning an existing mac: 1. Tech netboots Mac to "Reimage-Troubleshoot" nbi
2. Script auto-runs to name the Mac based on network IP
2a. Note that there are several decisions the script prompts the tech to make (it asks between 4 and 6 questions, depending on the techs responses)
Repeat steps 3 - 6 above (it uses the same setup policy as provisioning a new Mac)

Provisioning a new Mac requires the tech to literally only boot the Mac up, hold the option key, and double click a netboot disk. Re-provisioning an existing Mac takes only slightly longer and a few simple decisions to be made.

@stevewood - Hey Steve, I wanted to eradicate any unnecessary Netboot from the build equation. There is always that grey time of a couple of months, where new Macs ship with machine specific builds, and the retail may or may not boot them. Creating mac specific netboots images is annoying, and I'd rather not have to sync them out to remote CDPs as well (some are on twichy WAN connections).

So my thoughts around it was only utilise Netboot if Macs are being re-purposed, or are in a unbootable state. Without having to worry about maintaining Netboot for new deployments, nbis can be just updated for major .x releases, and for CasperImaging updates. We don't buy labs of computers at a time, and quite often there are one or two being purchased as needed for new hires.

Assuming my techs are capable of setting up the same standard shortname for the first admin account when configuring with the setup assistant, the rest of the configuration is brought inline anyway. I guess it all depends on your environment.

and thanks for sharing your firstboot script too @stevewood ! It's always helpful to see how others are skinning the cat!

Nice fb script @stevewood interested in your enroll.sh and your com.jamfsoftware.firstrun.enroll.plist

@hcodfrie the enroll.sh and com.jamfsoftware.firstrun.enroll.plist are files that are placed by Casper during imaging to get the computer enrolled. I do not touch those files. The reference to them in my script was to help me check on a problem I was having where machines were not enrolling. I believe it was a defect in the 9.1 series of Casper that was ultimately resolved. I need to remove that from the script.

How are you all dealing with the issue of users needing to claim included apps for updates. I had started developing a process for a new mac deployment from self service. Our users sometimes just buy stuff for their departments and I wanted an easy way to get them setup as new systems where they could just self enroll and run from self service. Plus it's easier than having to periodically update USB keys for techs (who may be at remote locations). But I ran into an issue with users needing to claim the included Apps (Pages, Numbers, iMovie, etc...) to an Apple ID for updates. Ideally I would just make these available with institutional managed distributions via the VPP but we are unwilling to purchase VL keys for those applications. I disable the ability to claim the applications on any enrolled app per guidance from our organizations legal department.

As part of your thin imaging policy in Self Service are you removing the Apple applications or are you purchasing VL of the applications and installing/making them available for redemption.

I've got this more or less setup for trial. The last thing I'm running into is the " ? " on the dock for apple's apps that aren't installed. I rarely see them if I do the nuke and pave scenario, and for my testing thus far, I've been just wiping the the partitions and reloading off USB stick (they were never on there), so I'm not sure how the icon's are showing up.

@jwojda I had the same thing happening, though the ? for the apps was only happening on the local admin account. Once I logged into a network account the dock was fine. I think this may tie into the Dock policy bug that JAMF is trying to iron out with Mavericks.

I removed any Dock policy I had set in imaging and tested that, and the ? disappeared.

the other thing I notice is the firstrun.enroll check - in teh logs looks like it's pending for for multiple 30sec timeouts (last check was @ 180 and then does another 30sec before continuing - so I don't think it's expiring), before it just goes. is that normal?

@jwojda that may be due to imaging trying to run enrollment before the network connection kicks on. I've found it sometimes takes a few moments for the enrollment to finish after imaging, and I think it's because enrollment tries to start before the Mac has an IP assigned from the network.

@emilykausalik - the dock items still seemed to be there when I sign in with my domain account. weird.

@ jwojda I have seen this very rarely in our environment, and only with domain users. Logging out, rebooting, and logging back in usually authenticates as expected then.

It has been very inconsistent, such that I only get a report of it once or twice a month, difficult to reproduce. It's confusing as heck because apps like Numbers and Pages aren't on the machine in our imaging processes. When the issue occurs the user is prompted with an error about library permissions.

@Kprice how are you dealing with users either claiming the preinstalled Apple Apps or the app store grumbling it can't update the apps when the ability to claim the apps is disabled via Configuration profile?

I have created a FR to get the erase disk and option preconfigured in an Imaging Configuration.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=2186

Thanks @stevewood for the firstboot script.

We're starting to experiment with enrollment-based "imaging" (more like installing/configuring) with new machines that are coming right out of the box. We just run the QuickAdd package off of a USB (or out of a mounted software/fileshare) and on enrollment all the basic software is installed on the machine and its bound to AD. We then have some software assigned to specific LDAP users groups that get pushed to the machine once the user profile is loaded.

We've only done very basic testing with this method but we're already loving it.

I have started a super-thin imaging process of late, and I've been thinking about how to reduce the initial setup from a newly delivered machine. I've sort of gone off netboot with all the recent shenanigans (and am thinking of starting up a thread on this to canvas opinion), so got it down to

1) run through first set up with a standard admin user (the jss management account)
2) set name of machine and check time is OK
3) to to jss/enroll, download and run quickadd
[4) until I can get the quickadd signed, confirm quickadd install in 'Security' pref pane ]

I'm basically trying to adopt the 'let apple and jamf do as much as possible' reducing the customised scripts as much as possible. So I've got JSS MCX settings (yet to fully migrate to profiles) doing a lot of configuration.

It is still very tempting to do 1-3 via 'Casper imaging' at netboot. But I don't trust my scripts to emulate apple's first set up. My localisation script seems to lose UK keyboard setting for a lot of users, for one. Am I over-thinking this, or is anyone else dithering over this?

In the past, we've used a hybrid image.

We had a base OS X deployed and configured (UI settings and default user account). We then deployed packages on top of that including a recovery partition package that ran a post-install script to create said recovery partition. This method has worked well for us from OS X 10.7 - 10.9.

We are now in process of transitioning to a 100% thin imaging model with the following workflow:

NEW SYSTEMS
New systems get unboxed and we use Casper Imaging to deploy packages only. We configure our default local admin account using the CreateUserPkg app. All packages with few exceptions are pkg/mpkg files ass provided by the vendor. Other apps that don't play nice with Casper Imaging (i.e. Microsoft Office 2011, etc.) are dropped into a temp folder on the target system and are called from a post-install script.

Package deployment takes roughly 3-5 minutes tops. Post-install takes about 3-5 minutes tops.

When post-install completes and the JAMF client wraps up its gyrations (policies, etc.) the system goes through a single reboot. The tech is hands on and authenticates for FileVault2 encryption.

The tech logs in via FileVault2 then logs out - it's not the user's turn to log in.

The tech adds the user to the FileVault2 group, local admin group and configured Outlook then steps away.

Total deployment time, about 15-20 minutes per box. Total technician touch time is about 5-10 minutes give or take (sans any special configuration requests).

EXISTING/REPURPOSED HARDWARE:
We leverage Apples NetInstall feature to restore a system to factory settings using the latest OS. We can nuke and pave a Mac with the latest OS in 20 minutes give or take without calling out to the Internet, without using Thunderbolt/Firewire, without using USB drives, etc.

We then run through the same thin imaging process as we use for new systems. This adds about another 3-5 minutes of total touch time.

We can also nuke and pave several Macs simultaneously in this fashion and put them on a shelf without fear of an image going stale. We can also slip stream combo updates into the image if necessary if our NetInstall image is a revision or two behind.

Our biggest forward thinking challenge is how do we get from the technician launching casper install and stepping away and when they return, the laptop is fully ready for user delivery - filevault encrypted, admin rights, etc. - That's the holy grail for us - we're getting closer to that goal every day.

@stevewood Hi Steve,

your firstboot is great. Do you have anything similar for 10.10? anything that needs to change for it? I am in the middle of upgrading some MACs.

@wmateo for the most part the script is the same in 10.10. There really isn't much that needs to change. Now I took some of the items out of the script and started moving them to Configuration Profiles instead. I was just looking through my 10.10 version of the script, and found some more things I can clean up.

@stevewood Any chance you have examples of your config profiles posted on a GitHub or somewhere?

@pblake no, I do not, but I can. Give me a day or three and I'll see what I can do.

@pblake sorry it took a little longer to get to this than I expected. I've posted them up on my GitHub:

GitHub

Nothing special, just a few small profiles. Hope that helps.

@stevewood Thanks so much for the script - it is cranking away on 40 laptops as we speak! (two stations doing 3 at a time btw).

Is there any way to see the script on the login screen as it's doing it's work? I'm simply waiting for it to restart after shutting down the netboot, watching it sit at the login screen, and then waiting for it to restart again. I've missed the restart a couple times as well as jumped the gun a couple times. Wondering if there's a way to see the log running in real-time. If not, no worries and thanks again.

@rcastorani Glad it's working out for you. It's been my go to method for a couple years now.

There is no way that I know of to display the output of the log file as the script is running. Of course, there may be and I'm just not aware of it.

I took a different route and simply lock the screen while the second part is happening. I grabbed a script that Mike (@mm2270 ) had posted and used that. The script was discussed in this post and is on his GitHub [here].(https://github.com/mm2270/CasperSuiteScripts/blob/master/selectable_SoftwareUpdate.sh)

If you find the section in the script for placing a lock screen up, that's what I do. This is the way it looks in my script now:

################################################################################
##
##  The below section of code was "borrowed" from Mike Morales' software update
##  script.  This script can be found in the following JAMF Nation posting:
##
##  https://jamfnation.jamfsoftware.com/discussion.html?id=5404#respond
##
##  And on his GitHub page here:  https://github.com/mm2270/CasperSuiteScripts/blob/master/selectable_SoftwareUpdate.sh
##
##  Thanks Mike for some great code.
##
################################################################################

## Block the user from being able to see our trickery
## Define the name and path to the LaunchAgent plist
PLIST="/Library/LaunchAgents/com.LockLoginScreen.plist"

## set the icon
swuIcon="/private/var/inte/helperimages/UnderConstruction.png"

## Define the text for the xml plist file
LAgentCore="<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.LockLoginScreen</string>
    <key>RunAtLoad</key>
    <true/>
    <key>LimitLoadToSessionType</key>
    <string>LoginWindow</string>
    <key>ProgramArguments</key>
    <array>
        <string>/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/MacOS/LockScreen</string>
        <string>-session</string>
        <string>256</string>
    </array>
</dict>
</plist>"

## Create the LaunchAgent file
echo "Creating the LockLoginScreen LaunchAgent..."
echo "$LAgentCore" > "$PLIST"

## Set the owner, group and permissions on the LaunchAgent plist
echo "Setting proper ownership and permissions on the LaunchAgent..."
chown root:wheel "$PLIST"
chmod 644 "$PLIST"

## Use SIPS to copy and convert the SWU icon to use as the LockScreen icon

## First, back up the original Lock.jpg image
echo "Backing up Lock.jpg image..."
mv /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg 
/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg.bak

## Now, copy and convert the SWU icns file into a new Lock.jpg file
## Note: We are converting it to a png to preserve transparency, but saving it with the .jpg extension so LockScreen.app will recognize it.
## Also resize the image to 400 x 400 pixels so its not so honkin' huge!
##echo "Creating SoftwareUpdate icon as png and converting to Lock.jpg..."
##sips -s format png "$swuIcon" --out /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg 
##--resampleWidth 400 --resampleHeight 400

cp $swuIcon /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/Resources/Lock.jpg

## Now, kill/restart the loginwindow process to load the LaunchAgent
echo "Ready to lock screen. Restarting loginwindow process..."
kill -9 $(ps axc | awk '/loginwindow/{print $1}')

For the image, I created a funny cartoon image with text indicating that the machine was being imaged and to come back later. Using this method, once the computer is back at a login window you know it is done.