The project

Deploy 1170 MacBook Pros (later amended to 1250), 60 iMacs, 214 Apple TVs, 106 (full sized) new iPads, and 30 iPad minis. Relocate 100 or so “newer” (one or two year old) machines into different locations, either in different classrooms in the same building or to a different building. Retrieve nearly 1700 old machines (iBooks, eMacs, iMacs, Mac Minis, MacBooks) back to the warehouse for disposal. And do all of this in roughly 3 weeks (once the computers started arriving.)

The “problems”

Under any normal circumstances, this would be a huge summer project that we’d start planning around this time of the year. But this project was on the fast track. For various reasons, we were going to do this during the school year. The vast majority of devices would be ordered in two waves, the first in mid-November and the second a week or two later (with the additional 80 MacBook Pros ordered in early December), and we’d start deploying machines ASAP because of limited warehouse space. And, we’d try to have everything deployed before winter break was over. Although I was involved with the later stages of deciding what computers we were buying and in what quantities, most of the rest of our team hadn’t been involved, and didn’t even know about the project until around the time that the first order went in. (We didn’t want too many people knowing about the project until it had official board approval.) Our team (our supervisor, 3 technicians, our administrative assistant and myself) had our work cut out for us.

Inventorying all of the new equipment, then physically removing the old computers and placing new 13” MacBook Pros would be a relatively easy process. The real challenge was getting our deployment tools updated and in place in order to get 1400+ computers ready to deploy (or redeploy.) We’d already bought into the “thin imaging” mindset (adding management tools to a new machine and using those tools to install applications, etc., versus building a whole new image with necessary applications included) via deploystudio. We had been using puppet to do our software installs, but we hadn’t been very diligent in keeping the software that was installed on existing machines updated (we had only recently pushed Firefox 15 out to machines that had been running 3.6.28, for example.)

I’ve been to several conferences and learned about munki, and wanted to start using it, but had never taken the time to get something set up beyond using puppet to install munki on a test machine. Now I had to get a fully functioning munki system set up, and I had to do it quickly. I had to change our puppet configuration to manage the state of the computers (things like ensuring remote login was enabled, certain users existed on the computers, etc.) and move software installation over to munki. I also had to change the scripts that I had written for puppet to look up information from our help desk to return valid data for munki (while still returning valid data for puppet.) Based on the responses on a recent staff survey, we wanted to give staff the ability to install and update software without needing help from someone in our department. We wanted to leverage munki’s optional software feature to make software available and let the end users decide if it was something they want to use. Because munki doesn’t require a password to do installations/updates, our end users will now be able to do their own installations and updates (at least as much as we make available to them.)

Since we hadn’t purchased very many computers recently, our deploystudio netboot set was woefully out of date (it was still built on Mac OS X 10.6.4, I believe), so it wouldn’t be able to boot any of these new machines. I’d have to get that updated, too. Fortunately, we had a few MacBook Pros from the same hardware family so I was able to get a jump start on that and not have to wait until the first order arrived and it’s not a big deal to get a base deploystudio netboot image built (or updated.) The real work is in the workflows anyway, and I’d have to update those to start installing munki and some other stuff.

We don’t want to fall behind on updates again, so in addition to using munki to handle application updates, I’m working to get reposado set up to handle Apple software updates. This is the one part that isn’t quite done, mainly because of how I want things to work.

There were some other situations that required that some custom code be written. One of these was that some of the computers (the 80 that were added at the end of the project) needed VPN connections to be configured. In an effort to be as hands off as possible in the configuration process, I needed to have a way to do that.

So that was the project. No big deal… ha. This was by far the biggest project our department had ever undertaken in the 12+ years I’ve been here. And we had to be successful, or we’d have everyone questioning why we were doing this during the school year.

Over the next few posts, I’ll describe how I configured deploystudio, puppet, and munki to work for us. I’ll throw in some luggage discussion since I’m using munki to deploy printers and needed to repackage some applications as well. Once it’s done, I’ll describe our reposado configuration as well. So stay tuned… this was a fun project (I can say it now that it’s essentially done and we’re starting to get our heads back above water) and I’m looking forward to sharing our experience.