Skip to main content

(Warning - this is a long one!)



Hello all,



I've been trying to figure out an easier method for deploying Mountain Lion to end users without a full re-image, especially to Lion users who have been re-imaged in the last year. Having to backup and reconfigure end users is a real pain and inconvenience, and with Apple now releasing yearly OS updated, I really felt a need to come up with a method of just upgrading, rather than re-imaging, computers that were in healthy condition. This post is a kind of "thinking on paper" to see if my ideas are in agreement with what other Casper customers are doing, and perhaps help other Casper users that are trying to accomplish the same thing I am, but are stuck.



I initially referenced the Knowledge Base Article that is located here for deploying Lion and Mountain Lion:



https://jamfnation.jamfsoftware.com/article.html?id=173



What was the most intriguing in that article was scenario 2, but I didn't want to deal with a NetInstall, especially since I have network locations where the NetBoot service is unavailable. In addition, I've heard the NetInstall upgrade process sometimes causes some issues with the jamf client and the service accounts that are installed on the computers, leaving some clients in a semi-manageable state.



After doing some additional research, I found the Greg Neagle's "createOSXinstallPkg" would fit my needs for this project. The tool is located here: http://managingosx.wordpress.com/2012/07/25/son-of-installlion-pkg/. Kudos to Greg for developing and releasing this tool for the rest of us to use. If you're not familiar with it, this tool takes the OS X installer from the Mac App Store and turns it into a package that at next reboot will kick off the installation of Lion or Mountain Lion, similar to the process that occurs when using the Mac App Store installer. In addition, you can use the tool to add small simple packages that are installed along with OS X.



The drawback of the OS X Installer is that many packages, including the Casper Quick Add package generated from Recon, cannot be installed as part of the process, due to the limited amount of command line tools available in the installer environment. To get around this, rather than try to have the generated OS X Installer from the createOSXinstallPKG tool try to install the Quick Add package directly, I just had copy it to a directory so that it's on the upgraded computer, and wrote a shell script and a launchd daemon that will run at boot time that installs the Quick Add package. The script that is executed by the launchd job then deletes the launchd task at completion, effectively making it a "first boot" only task.



I uploaded the package generated from the createOSXinstallPkg tool into Casper Admin. I then created a self-service policy that Installs this package. At the end of the self-service policy, a simple script runs that executes the command 'shutdown -r now' to reboot the computer to whichever partition the OS X installer has 'blessed' for the installation process to complete. Once the OS X installation is completed, the system reboots, runs the quickadd.sh script that I've set to run with launchd, and installs the QuickAdd.pkg. The quickadd script also runs some jamf commands after the QuickAdd package finishes before it deletes the launchd task, and then itself. These commands include:




  1. Re-enroll the computer

  2. Flush policy history

  3. Run any 'new' policies

  4. Install all cached software packages, and Apple software updates

  5. Refresh MCX

  6. Execute a policy, via a policy trigger, that installs some specific customization packages specifically for Mountain Lion computers, that would normally be installed during imaging.

  7. Repair permissions, flush caches.

  8. Update inventory.

  9. Reboot immediately.



So far, the results have been pretty good. After about 45 minutes, I get a fully upgraded and patched Mountain Lion system, with no re-image required. I'm not sure if this ever would be something that I would allow end-users to do on their own from Self Service, but it is very helpful for our Help Desk to just have the end users drop off their laptops, and come back an hour later with it fully upgraded, with no other hassles. I imagine I'll duplicate this policy with one that just executes with a policy trigger so that it can be executed outside of Self Service from the command line.



I'd be glad to share more details if anyone is interested in this type of workflow. My question to the nation, is, am I going in the right direction with this, and, are there others out there with similar workflows for upgrading Macs in place without a re-image? Is there too much risk in reducing computer reliability by not doing a full re-image for an operating system upgrade? The IT part of me that has been deploying Macs and Windows computers for almost 15 years says "always re-image", but the prospect of re-imaging every year to keep people current makes me want to have this type of solution available.



Your thoughts?



Thanks,



~Ted

Definitely other people are using this workflow, some even as Self-Service:



http://www.youtube.com/watch?v=7eMgh41KgOk



https://jamfnation.jamfsoftware.com/discussion.html?id=3297



(Both of those are for Lion upgrades, but the concepts are the same).



Outside of Casper, we've been successfully using these tools to do self-service upgrades to Mountain Lion from Snow Leopard and Lion.



-Greg

Ted,



Greg already chimed in, (he can detect any post about him in the ether...) but I will as well. Sounds like you're already on the right track.



Only, if you're going to use Casper for managing the upgrades to Lion, you don't NEED to also install a recon quickadd pkg: these assets will ALREADY be managed.



We're using kinstallOSX.pkg and it works brilliantly for us. And, because the packages that you can add into your deployment with his tool must be very small and simple (due to the nature of the OSX Install environment), we take a very bare bones approach -- we include only one additional package. This package installs a launchD item that:



+ fixes our hidden >400 administrative account
+ patches with a version of Java
+ points the newly minted 10.8 system to reposado (another great greg tool) and then updates with whatever patches we've approved
+ disables both the welcome screen and the iCloud set-up wizards for all current and future user accounts
+ sets the time server
+ ensures the correct SSH and ARD preferences
+ calls a custom jamf trigger which installs a few other packages that we want installed (older version of Java and Flash)



Works like a charm. And, if the Mac in question is already managed, there's no need to re-add it into the JSS. It will simply recon on it's normal schedule for us.

Here is the thread associated with the related JNUC session: https://jamfnation.jamfsoftware.com/discussion.html?id=5655



The JNUC process just uses the original AppStore installer instead of one created using "createOSXinstallPkg". I havent done much research but what are the advantages of using createOSXinstallPkg?



If you call the orig AppStore installer via script using a Self Service policy, that policy reports in as being 'complete' even if the end user doesn't actually go through the full install wizard. That also makes it difficult to kick off any additional tasks that you want to run AFTER you know it is at 10.8. Does the createOSXinstallPkg resolve that?

@frozennarse There is no wizard with the createOSXinstallPkg. It downloads, installs the payload, then reboots the computer. Installation begins after the reboot. If an end-user were to select this via SelfService, there would be no place to opt-out via the GUI once the policy begins.

@gregneagle @themacdweeb Thanks for the feedback and suggestions. This discussion already uncovered a few areas in the upgrade process that need to be tweaked. I'm a novice at shell scripting, so including the quickadd package as part of the upgrade process just saves me from writing a script to repair the service accounts until I have a little more time to focus on it. I'm really excited about the process of not having to re-image every single computer, especially those in our lab environment.

I really need to take a look at that createOSXinstallPkg thing....



Right now i'm testing a Self Service policy that 'unhides' our management acct and then kicks off the original Mtn Lion installer. The end user walks through the upgrade wizard and it reboots as part of that process.



I have another policy that runs once per computer at startup on 10.8 machines that 're-hides' the management acct.



The clunky part about what i'm doing is that the JSS thinks a newly upgraded 10.8 machine is still 10.7 until a recon is ran... So I have certain 10.8 Config Profiles etc that won't be in place upon first bootup of the newly upgraded machine.

Haven't played with createOSXinstallpkg yet, but I can see the utility for areas where netboot is non-existant or not easily accomplished. Right now I am using a pretty simple workflow with a netinstall image created from the InstallESD media downloaded from the apple store:




  1. a policy runs to rename the drive to a generic name and reboots the Mac to the netinstall image (currently all sites have a netboot server)

  2. netinstall is automated to upgrade the generic drive name. It also throws down a quick add package and launchd item to run the quick add on next reboot

  3. Computer reboots when it is done, executes the launchd which actually does a jamf removeframework, then installs the quick add and immediately looks for policies, then removes itself



SO far in testing it's taken me about 30 -40 minutes from start to finish to upgrade a 10.6 client to 10.8.2 over a gigabit network.

@frozenarse We looked at this a while back, but got bogged down with other stuff. Here's the link I have from a while back:



http://code.google.com/p/munki/downloads/list



Greg, assuming you're lurking...<g>...is this where we can get the latest version for testing?



Thanks,
Don

Ted, Can you share that script?

Terms & ConditionsCookie settings