#JNUC : Deployment Strategies for OS X Mountain Lion

kyle_appel
New Contributor II

Matt Schalk and I are excited to discuss multiple deployment strategies for OS X Mountain Lion! The session will be held Wednesday, October 24 at 1:00 PM at the Wurtele Thrust Stage.

Throughout the session we will reference a couple of different resources, all of which are available below:

KB Article walking through deployment options: https://jamfnation.jamfsoftware.com/article.html?id=173

Extension attribute to check on readiness of Mountain Lion Installer:

#!/bin/sh
if [ -e /Library/Application Support/JAMF/Install OS X Mountain Lion.app ]
    then
        size=`du -sm /Library/Application Support/JAMF/Install OS X Mountain Lion.app | awk '{print $1}'`
    else
        echo "<result>Not Available</result>"
        exit 0
fi

if [ $size -lt 4165 ]
    then
        echo "<result>Incomplete</result>"
        exit 0
fi

if [ $size -eq 4165 ]
    then
        echo "<result>Available</result>"
        exit 0
fi

if [ $size -gt 4165 ]
    then
        echo "<result>Oversized</result>"
        exit 0
fi

Command to show recovery partition: ```
sudo diskutil mount disk0s3

Script to adjust partition type:

!/bin/sh

/usr/sbin/diskutil unmount /dev/disk0s3
/usr/sbin/asr adjust -target /dev/disk0s3 -settype Apple_Boot

Script to call Mountain Lion Installer:

!/bin/sh

/Users/Shared/Install OS X Mountain Lion.app/Contents/MacOS/Install OS X Mountain Lion&
```

*REMINDER* Be sure to test any scripts, extension attributes, and workflows before moving them into production!

Please use this thread as a resource for any further information that may be posted, as well as a place to hold any discussions about the session.

Matt and I will also be available in person to answer any questions at the overtime session on Wednesday from 2:15 - 3:15 PM in the Nelson Classroom.

Looking forward to see everyone there!

12 REPLIES 12

andyinindy
Contributor II

Here us a good script for creating the recovery partition automatically:

http://www.brunerd.com/blog/2012/03/21/update-create-lion-recoveryhd-partition-quickly-without-reins...

It should be easy to package this and use the command file as a postflight to create the partition.

stevewood
Honored Contributor II
Honored Contributor II

I've found the method Greg Neagle explains on his blog is even easier. His method creates a .pkg file that you can simply deploy to the system. Create one for 10.7, upload to Casper Admin and you're ready to rock. Need one for 10.8, just update the the files in the package:

http://managingosx.wordpress.com/2012/08/15/creating-recovery-partitions/

rtrouton
Release Candidate Programs Tester

I've got a similar method to Greg's posted here:

http://derflounder.wordpress.com/2012/06/26/creating-an-updated-recovery-hd/

kyle_appel
New Contributor II

Hey All,

If you couldn't make it to the session, some highlights are available in JAMF Software's newsroom!

http://www.jamfsoftware.com/news/2012/10/24/session-deployment-strategies-for-os-x-mountain-lion/

zmbarker
Contributor

Having a little challenge getting the entire process nailed down.

I know there were a few presenters in other sessions that quickly showed their JSS Policy summary for their examples. I was wondering if someone could post a JSS policy summary for "Upgrading systems from 10.6.8 to 10.7 or 10.8 via SelfService."

Cranappras
Release Candidate Programs Tester

I sat in on this session last week, which was great, and have begun testing the "in place" scenario for self service 10.8 upgrades, and I've noticed that everything works fine except it is breaking the management account. So post-upgrade, I am no longer able to communicate with the system via Casper Remote...it just falls on "Authentication".

When I check the local machine, it appears that our management account, "casper" is no longer there. Even if I run "dscl . list /Users" from terminal, it lists all users on the system and our management account is not listed. As a side note, I also checked this prior to the upgrade and the account was there.

Any thoughts?

nessts
Valued Contributor II

apple's upgrade process removes local only accounts, so you need to add a package to recreate your user on the first boot, its not convenient to say the least.

Cranappras
Release Candidate Programs Tester

Thanks for the info. I just ended up creating an extension attribute to check if the management account exists and then a policy that installs quickadd.pkg to any computers that report it as missing. Seems to be working fine so far.

#!/bin/sh

MgmtAcct=`dscl . list /Users 2>&1 | grep "casper"`

if [ "$MgmtAcct" = "casper" ]; then
    echo "<result>Verified</result>"
else
    echo "<result>Missing</result>"
fi

mm2270
Legendary Contributor III

To be more accurate, the in place upgrade process doesn't remove local accounts, but rather local hidden accounts. That is to say any account with a UID under 501 that isn't part of the OS. Your Casper Suite management account was likely hidden as many of ours are. I don't really understand why Apple's OS installer does this, but it is indeed a pain.

frozenarse
Contributor II

Wouldn't running a QuickAdd package be overkill since the device is already associated with a JSS? **Edit: I just realized that after the upgrade wipes out your management acct you probably won't be able to use any policies etc.... That's why a QuickAdd would be needed i'm assuming.

I'm starting to think that 'unhiding' the management account before upgrading might be a better option.

j_s_
New Contributor II

I created a policy using the JSS create account template that re-creates the management account for all 10.8.x systems. This seems to have resolved the issues I was seeing such as Self Service prompts for admin credentials when executing policies and authentication errors when using casper remote.

Re-executing QuickAdd seemed to have been an overkill since it wipes the machines policy history which may cause some confusion with self service items, etc.

jguz
New Contributor III

To those that are planning to use the extension attribute script. Make sure to change the script so that the size reflects the actual size of the lion.app. You can do this by running du -sm /path/to/lion.app we've found that this size changes, even though it's the same mountain lion.app, based on the OS.

Also has anyone figured out a way for the OS X installer window to pop up in front of self service automatically?

UPDATE: to those trying to figure out how to get the OS X installer window to pop up in front of Self Service, this tweak on the launch script ended up working for me:

#!/bin/sh
open /Library/Application Support/JAMF/OS UPGRADE/Install OS X Mountain Lion.app

exit 0