I’ll preface this with one thing - I’m not a Casper Suite expert. I don’t use it regularly, and at what it costs, I probably won’t! It’s this price that gave me high expectations for this last install. Unfortunately they were unfounded. I’m hoping to write a series of articles comparing the various aspects of Casper against the free tools I use every day. First up is DeployStudio. Workflow creation Both Casper Imaging and DeployStudio have a nice GUI for creating the workflow. It’s just a drag and drop to place the tasks you need. The DeployStudio interface feels a bit more polished, but that’s probably just my bias showing though. The only real differentiator here are the package groups that DeployStudio offers. If you had a standard group of packages that you deploy over several different workflows, DeployStudio makes it easy to maintain - yes, this should probably be done elsewhere, but it can be handy to install a certain set of applications at imaging time. I couldn’t see a direct replacement for this in Casper Imaging. ...

A few months ago, we decided to move away from DeployStudio for imaging our Macs to reduce the OS X footprint in the server room (a plain old NetRestore can be run from NetSUS). This left us with a problem - how are we going to name our Macs now (a task previously performed by DeployStudio)? Enter MacNamer. It’s usage and installation is detailed in the Readme file, please fork, try to break, file pull requests. This has been in production for several months at work, but I’m sure someone will manage to make it break!

Maintaining visibility over your fleet of machines is always difficult. It’s even more difficult when you’ve got Macs. It gets nearly impossible when you decide you’d like something hosted in the cloud. We’ve been looking for a good solution for ages now - we even resorted to using OCS Inventory for a while. We then discovered Meraki’s Systems Manager. This isn’t going to be one of those fancy review type things - you can go and look at it’s features yourself. This is more an overview of the factors that came into our decision: ...

This post could also be called “Things we could learn from our developer brethren, but I digress, to the list! (Lists are awesome, aren’t they?) I’m not going to try and tell you how to get started with Git (go here instead for that), I’m merely going to get on my soapbox. Branches - need to test something? No need to spend all day making a test setup, just make a branch and clone it to the test server. If it turns out that I wasn’t mad and my changes were a good idea, they can be merged back into the main branch just as easily. Accountability - who made that strange config change? A quick look at the commit history is all you need. Diff - what actually changed? It’s easy to see the exact changes Change history - why was that random change even made? Hopefully it’s in the commit message! (Your commit messages are useful, aren’t they?!) You can be a nice sysadmin - if you use GitHub it’s simple to take your repo public and share your awesomeness. So there you go - I hope this goes some way to answering the question “why should I be using Git?”

This will probably be obvious to most seasoned Puppet inclined OS X admins, but this is a relatively recent revelation for me. Up until very recently, I wasn’t really making full use of Facter, merely pointing my clients to the appropriate classes and leaving it at that. When tasked with giving end users the option to install their own printers when they went to a different site than the one they usually work at, my initial thought was to go for a Payload-free package and pop it into their optional installs in Munki. But then I was asked if it could happen without the user doing anything - they go to the other site, and they automatically get the right printers set up - so after a little thought, came up with this. I’ve made use of the excellent mosen-puppet-cups module on GitHub to get the printers set up, and the drivers are already deployed with Munki (I did consider moving them to Puppet, but why reinvent the wheel for the sake of it?). ...

Update: There’s a better method over at afp548 that does this better. Use that! A few months ago I made a package to create a Recovery HD on a freshly deployed Lion Mac. It’s time to do the same for Mountain Goat. In true Blue Peter style, you will need: The Luggage (If you’re having problems getting The Luggage working with the latest version of Xcode, please see this post on macenterprise The GitHub Repo A read only DMG of a never booted 10.8 Recovery HD The Lion Recovovery HD Update ...

Last week at work we were discussing where we were headed. Our email is now firmly in the cloud with Google providing a better infrastructure than we ever could. They’ve also got word processing and spreadsheets solved for most people with the hard to beat price of free. So, what else could we do better with the cloud? ...

Munki is great. It keeps your macs up to date - well it does most of the time. Sometimes you get a user that just refuses to click on “Update” now matter how many times it pops up. Now you have a tool to defeat them - install this package over ARD and munki will install everything that’s available, including Apple software updates (it will reboot the mac if needed and carry on where it left off). ...

I recently had a requirement to run an Ununtu machine, but the client had only mac servers, and no budget for additional hardware. The solution turned out to be VirtualBox - we could run it headless and have it start when the mac booted. First, get your VM set up how you like it and shut it down. I like to move my VMs out of the boot drive, so move the entire ~/VirtualBox VMs directory onto your storage device. ...

Over the past week or so, we had a need to enroll macs automagically with a Lion Profile Manager server. My first plan was to do what Charles Edge did in his recent blog post and use DeployStudio. Then I remembered another post by Charles on /usr/bin/profiles and wondered if I could make a workflow that can be used throughout our deployment and system maintenance process - yup, the humble pkg, that can be popped into Munki for existing macs, installed with DeployStudio for imaging and pushed out with ARD if need be. ...