Thin Imaging in the MacBook world

[jwojda]

I was looking at possibly doing thin imaging, now that the MacBook USB C world is upon us. Most all of the information I could scrounge up was pretty outdated (2012 and earlier). I was wondering how or best practices for 10.10 (and 10.11?) and Casper 9.x. We aren't using DEP at this time, but if apple continues to move the direction of single USB C and no ethernet adapters.. then we may.

[davidacland]

We have a few sites doing thin imaging. The only thing I'd watch out for is having too many automated policies kicking off after enrollment. If too much happens at once, it seems to fall apart and you just end up with a big mess.

If you can get the policies running correctly, some effort needs to go into the user notification so they know what is going on, otherwise they might restart or shutdown the Mac while its installing something.

Self service certainly helps with this as you can leave it up to the user to take what they need.

[bentoms]

@jwojda some call it no imaging.

[jwojda]

@davidacland that seems to align with this video I found from Jamf

[bpavlov]

@davidacland Can you clarify what this means because my understanding is that policies run one at a time....so how can too much happen at once? Just looking for an example to avoid.

[davidacland]

@bentoms that reminds me, I got told off by someone for calling it thin imaging. Isn't "Thin Deployment" the PC term these days?

@jwojda Self Service certainly gets my vote for this method, although you need the users on board with it. I've worked in some places where the users don't really get it. They just want to log in and do their work. They don't want to install things and they don't want to update anything. In these cases, self service fell flat on its face.

[davidacland]

@bpavlov its normally been when there is no feedback displayed to the user (or tech if they are setting up the Mac). Really compounded if the network connection to the distribution point isn't too good and policies are trying to install a bunch of packages.

Policies should and will run one after another, but I've had too many cases where what should happen doesn't quite work out. Sometimes one policy has a dependency, but the policy before it fails, causing a domino effect.

Network performance or other issues have been the biggest cause of failures that I've seen, but Its just been my experience that if you setup a load of policies to run immediately after enrollment, you will be asking for trouble.

I would go for a very thin deployment initially, just enrollment and thats it. Then test adding one policy at a time. Making sure to test it in the real environment.

[stevewood]

@jwojda are you planning on having you or your techs do the imaging and then giving to the end user? Or are you planning on dropping the machine at your user's desk and letting them handle the software installations?

If you're just giving the machines to the end users and letting them handle it, Self Service is the way to go. You could batch different aspects of the install and name your policies something like "Step 1 - Install Apps", "Step 2 - Install Printers", etc.

If you and your team are going to handle the imaging, you could create all of your policies that install the different software packages, and then create a First Boot Script that calls the policies by their ID # (or by a trigger). That script could be part of a "Enrollment Complete" triggered policy that installs the script and a LaunchDaemon to fire it, and then restarts the computer. The script then handles the configuration of the machine and reboots.

I do something similar to that, except I still use Casper Imaging to put that script on the machine, that way I don't have to use a QuickAdd package or run through Setup Assistant.

[jwojda]

@stevewood techs to start, but possibly down to end users. I'm okay with the Step 1, step 2, etc for both sides. I guess the next question is machine names. we have a specific naming convention for them, how can I ensure they use that as the setup wizard doesn't give you an option to select it. Do I just need to put that into the doc on how to go in and change it and do all the terminal commands to make sure the name shows correctly and not xyz's macbook pro

[stevewood]

@jwojda if you can programmatically determine what the machine name is supposed to be, I would use a script to do that. Then you can enable a policy that ensures the machine name stays the same as what is in the JSS. However a written policy that explains what the name should be is a good addition.

[RobertHammen]

Depending on your naming convention, it may be possible to script the naming (lot of clients use the serial number of some subset of it as part of the computer name). If that isn't possible, I'd suggest possibly a script or an AppleScript app for your techs that prompts them for the name then does the right thing behind the scenes, so that they don't need to know...

[loceee]

Patchoo! Deploy

... Gives you a framework to deliver "thin deployment / provisioning".

Use you location information or even a custom extension attribute to scope the delivery of policies to build your macs.

Provides a UI to adjust location info, computer naming in the JSS on enrolment complete if enabled, Locks login window and provides feedback, launches your policies, and even does a patchoo update loop when deployment is done to ensure your apple software updates are sweet too!

Built to support a number of workflows, user enrolment, imaging, pre staging, tech enrolment, because the build is based on JSS computer data it's persisten between imaging, re-deployment and can support prestige imaging, or more importantly prestage DEP enrolment!... The next mac I buy will be DEP enabled as we've finally got access in Aus.

I will be roll another video demo once I have a DEP mac on my hands.

[jwojda]

@loceee i'd need to take a look, we have patchoo setup for updates currently.

@RobertHammen @stevewood i don't think it can be fully scripted w/o some form of user interaction. we have country location codes, regional codes, laptop or desktop, and then an asset tag.

Regardless, it's way over my skill set and timeframe to learn/understand how to make one up (need to get this done by Tuesday the 2nd)

[jwojda]

I found this link for changing computer names

Can someone help modify it for prompting for each section (Country, region, laptop or desktop, and asset tag)? and then have the inputs combine to be the machine name?

#!/bin/bash
#Freddie Cox for Knox County Schools
#Edited by Justin Ellis
#2012

ComputerName=`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set ComputerName to text returned of (display dialog "Please Input New Computer Name" default answer "" with icon 2)
end tell
EOT`

#Set New Computer Name
echo $ComputerName
scutil --set HostName $ComputerName
scutil --set LocalHostName $ComputerName
scutil --set ComputerName $ComputerName

echo Rename Successful

[loceee]

Vanilla to desired state takes a fair number of polices and scripts in our environment to make things happen. I suggest being as granular as possible though, as you bring on more sites there is less work, after initial setup. Clone, edit, save.

I try to keep away from hardcorded scripts and make it all driven via polices for increased visibility (and scopability) in the JSS.

This log from a Patchoo deploy build might give insight into what it does. I will post a screenshot of my policies from current JSS tomorrow

https://github.com/patchoo/patchoo/blob/master/docs/jamf_patchoo_deploy.log.txt

[techhelprhs]

If you are running this by hand in terminal you could use echo and read to return the variables. Something like this?

#!/bin/sh
echo "What Country? Enter the answer and press [ENTER]:"
read COUNTRY
echo "What Region? Enter the answer and press [ENTER]:"
read REGION
echo "Desktop or Laptop? Enter the answer and press [ENTER]:"
read MODEL
echo "What is the asset tag? Enter the answer and press [ENTER]:"
read TAG

COMPUTERNAME=`echo "$COUNTRY-$REGION-$MODEL-$TAG"`

scutil --set HostName $COMPUTERNAME
scutil --set LocalHostName $COMPUTERNAME
scutil --set ComputerName $COMPUTERNAME

echo Rename Successful

exit 0

The guys who have posted above are much smarter than I am and are great resources for automating the modular/no image approach.

Building on their work and thought process, I modify my quick add packages to set specific ARD fields with specific values. Examples: "Just_Imaged" "Teacher" "Laptop" "Building".

I have smart groups setup with the extension attributes for ARD fields. When a machine enrolls and recons, the Just_Imaged group calls to a single package of dependent files and post flight script to setup the machine defaults and pass it to "Phase_TWO" by changing the ARD field and running recon again. Phase two contains a script that calls to jamf policies one at a time and ends with a final ard rename, software update, etc.

Good luck in your project,

-Chris

[jwojda]

@loceee i looked over the docs. seems like a neat thing, is the code already setup in the patchoo script then or does it need to be manually added?

[Nix4Life]

@jwojda
just a quick thought.. If the various countries use different subnets, you could possibly automate this with an if-then-script.

Larry

[jwojda]

@LSinNY we have 200 subnets so far... that's a lot of work :)

@techhelprhs I took yours and added it to the Applescript one as I'd like to keep the popups for input...but it's still not fully right..

#!/bin/bash
#Freddie Cox for Knox County Schools
#Edited by Justin Ellis
#2012

COUNTRY=`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set COUNTRY to text returned of (display dialog "Please Input The Country" default answer "" with icon 2)
end tell
EOT`

REGION=`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set REGION to text returned of (display dialog "Please Input Region" default answer "" with icon 2)
end tell
EOT`
MODEL=`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set MODEL to text returned of (display dialog "Please Input Model - Desktop or Laptop? (ML = laptop, MD = desktop)" default answer "" with icon 2)
end tell
EOT`
TAG=`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set TAG to text returned of (display dialog "Please Input The Asset Tag (6 digit barcode sticker)?" default answer "" with icon 2)
end tell
EOT`

ComputerName=$Country$Region$Model$Tag

#Set New Computer Name
echo $ComputerName
scutil --set HostName $ComputerName
scutil --set LocalHostName $ComputerName
scutil --set ComputerName $ComputerName

echo Rename Successful

[jwojda]

Nevermind, I fixed it.
:)

[techhelprhs]

Nice. Glad to help.

You could automate it a bit, if your org's policies allow some leeway on the naming convention and how much interaction your techs have with the machines beforehand (i.e. setting the network time server):

#!/bin/sh
COUNTRY="`systemsetup -gettimezone | awk '{print $3}' | sed 's/[/].*//'`"
REGION="`systemsetup -gettimezone | awk '{print $3}' | sed 's/.*[/]//'`"
MODEL="`sysctl hw.model | awk '{print $2}' | sed 's/[0-9][,][0-9]//'`"
TAG="`/usr/bin/osascript <<EOT
tell application "System Events"
    activate
    set TAG to text returned of (display dialog "Please Input The Asset Tag (6 digit barcode sticker)?" default answer "" with icon 2)
end tell
EOT`"

ComputerName="$COUNTRY$REGION$MODEL$TAG"

echo "$ComputerName"

exit 0

Just a thought (I know you have a hard deadline). But, if the time zone has been set, it should return the country, "region","Model", and asset tag input from the gui.

Best,

-Chris

[jwojda]

got another weird problem, relating to the naming script. It seems like the policy runs, I see in the logs that it switches the name (the log line switches to the new name, but then it switches right back and ends up trying to bind the xyz's macbook.

[techhelprhs]

(the log line switches to the new name, but then it switches right back and ends up trying to bind the xyz's macbook.

Not exactly sure what you mean. Does the machine switch back to the old name in terminal? Can you try running the script offline (without network connectivity)?

[jwojda]

it starts out as admins's macbook pro due to the setup wizard
from there I launch the Self Service policy to kick off the corprification process
after a few steps you see the machine name change on the line checking for policies by "networkStateChange"
then back to the admin's macbook

Terminal shows the right machine name, but i checked Directory Binding, and it shows the admins Macbook.

so I guess I need to move the binding to later in the process (?)

[techhelprhs]

Yes, I believe so... If you run the script locally without any network connection, it should change the name. If that doesn't stick once the machine re-connects with your servers, then they are most-likely not setup to accept dynamic changes from apple clients.

[loceee]

The host name in the logs may not update immediately. But if it's binding with the incorrect name after you've set the 3x names prior with scutil something is a miss.

Ensure you don't do what I did recently. If you are using a config profile to manage loginwindow settings, check that you haven't inadvertently checked. "Set computer name to computer record name".

I spent hours troubleshooting why my naming script wasn't working, and that option prevents you from changing it! Derp!

[bentoms]

FWIW, I saw similar when no-imaging some Mini's a few months ago.

These Mini's were running 10.10.1 (I think).

I also, think that the resolution was to bind later in the process. As trying to bind to soon after setting the name picked up the old name.