Volume Number: 22 (2006)
Issue Number: 12
Column Tag: Patch Panel

Rolling out Microsoft Office Updates

Repackaging updates for fun and sanity

by John C. Welch

Well, it's been a while since my particular brand of loquaciousness has graced the pages of MacTech, but like boomerangs and bad pennies, here I am. In this month's installment of Patch Panel, I'm going to chat with you about a subject near and dear to all our hearts; Rolling out updates to Microsoft Office. By "near and dear" I mean, "met with much eye-rolling and groaning". This has nothing to do with Microsoft Office itself. Regardless of your opinion of the suite, the fact is, it's something that most Mac administrators have to support. One of the time honored tediums of the administrator's life is that of rolling out the update. This is something that can either be relatively easy, or a tedious process that makes you wish we could revert back to the good old days of stone tablets and chisels.

Waaaaay back in the dark ages, (okay, back before OS X), there was nothing as organized as the current Apple installer. Oh, Apple had an installer, but it was not nearly as easy to deal with as the current Mac OS X version. So, sensing an opportunity, several companies came out with their own products, one of the biggest being Installer VISE, from MindVision. (http://www.mindvision.com). VISE had a number of advantages over the others, including not just Windows support, but actual acceptance on that platform. This of course, made it rather attractive to a number of companies, including Adobe. Now, while Microsoft had, and indeed, still has their own Windows installer(s), the rest of VISE's feature set made it a good fit for the Mac BU.

So now you have a setup where if something can be installed via an Apple Installer, or direct copy, the administrator's job is simple. If you use Apple Remote Desktop, and it's an Apple Installer, you let Apple Remote Desktop handle it, or copy it over and run the installer command via SSH. If it's a direct copy, then you, well, copy it. Simple, easy, and even allowing for some of the issues with Apple's installer, elegant. With Apple Remote Desktop 3's AppleScript support, I don't even directly interact with Apple Remote Desktop to install these two kinds of items. I just drop them in specific folders and let folder actions handle them. It's pretty sweet, and lets me not waste a lot of time with installing files on clients.

However, when you hit a VISE installer, which is what the Mac BU still uses for Office updates, that system breaks, and hard. You have to either manually install it on each machine, or you have to repackage it. Since the former just is not happening unless you have a very small number of machines, we of course, will look at the latter. (Note: While I'm really only talking about Office 2004, this all should work just peachy with Office v.X)

As I said before, to most tools, VISE installers are opaque. You can see the file, but you can't crack it open and see what's in it, what's going to be installed where, etc. You also can't have a tool like Apple Remote Desktop just install it. Luckily, Microsoft, bless their little IT-centric hearts, gives you a couple of ways to figure this out. The first, best method is via their updater logs. If you look in the Microsoft Office 2004 folder after an update, you'll see a folder called "Updater Logs". Inside that folder, you'll find a text file for each of the updates you've applied to that system. The updater file lists every file that was installed on the system.

Now, before you just run off and blindly use this, by "each file" I mean just that. If it installed ten files inside a bundle, then you get ten entries. Now, you can directly follow the log line for line, but that's kind of the silly way to do it. Instead, read the file, and use it to get the minimum number of files and packages you actually have to care about. Some of the lines are obvious like the ones for the main apps, (this is on my own drive, so it follows my own... unique... filing system. Normally, the Office 2004 folder is in the root of your Applications folder):

Installed Aurora:Applications:Word Processing:Microsoft Office 2004:Microsoft Entourage

Installed Aurora:Applications:Word Processing:Microsoft Office 2004:Microsoft Excel

Installed Aurora:Applications:Word Processing:Microsoft Office 2004:Microsoft PowerPoint

Installed Aurora:Applications:Word Processing:Microsoft Office 2004:Microsoft Word

So, we can see it installed new copies of each of the four main applications. Okay, that's easy. But then we see a bunch of lines like the following:

Created the Folder: Aurora:Applications:Word

Processing:Microsoft Office 2004:Office:Microsoft Cert

Manager.app

Created the Folder: Aurora:Applications:Word

Processing:Microsoft Office 2004:Office:Microsoft Cert

Manager.app:Contents

Installed Aurora:Applications:Word Processing:Microsoft Office

2004:Office:Microsoft Cert Manager.app:Contents:Info.plist

And this goes on for about 30 lines. Does this mean you have to now deal with 30 separate files? Nope. It means you deal with one: The Microsoft Cert Manager.app, which lives in the "Office" folder inside of the main Microsoft Office folder. This can be kind of tedious to parse, although since Microsoft is thankfully consistent in how it does this, you can script this parsing out fairly easily. However, there is an easier way, one that all administrators will of course already know about, and that is the Read Me file.

With every update, the Mac BU has a Read Me file that lists out the files which are updated, and their new versions. (For those of you who are Britannica fans, this is the Macropaedia, whereas the installer log is the Micropaedia.) So rather than parsing through the Updater Log file to figure out what was installed, you can just use the Read Me to see what was installed. It's much simpler. Now, the Read Me won't tell you the specific locations of the files, so it's not a complete replacement for the Updater Log, but that's not a huge issue, depending on how you build your updater.

So, we now have two lists of files, one detailed, one not. Now, how do you build the updater? Well, the answer is, "Whatever works best for you". No, I'm not trying to be smarmy, it's just that there are a lot of ways to do this. If you use Apple Remote Desktop, as I do, then you can just do a drag of the files to a list of destination clients, and chose "Same Relative Location" as the destination, like in the screenshot below:

Copy Items Dialog from Apple Remote Desktop 3

Drag all the files you need to copy over, pick "Same relative location", click on copy, and watch the fun. (Yes, I realize none of my targets are currently running or running ARD). You can of course, with Apple Remote Desktop 3, AppleScript this, via Copy Items task. Just set the "location" property to "same relative location" in the properties for the task. You could even set up a Folder Action that would always copy whatever you dropped into it to the Same relative location, and be even lazier. That of course is my preferred method. Life's too short to watch file copies. If you aren't using Apple Remote Desktop, or you prefer using Apple Installer packages, you can use Apple's PackageMaker tool to bundle up the update into an install package, and then use that via Apple Remote Desktop or your tool of choice. (There's a PackageMaker article in this very issue, so I'll not get into using PackageMaker, as it would be redundant.)

If you like using Apple's Installer packages, but are not thrilled with PackageMaker, then a third party option is to use Iceberg, (http://s.sudre.free.fr/Software/Iceberg.html). Iceberg is billed as a better way to make Apple Installer packages, and in general I've found that to be true. The only issue with Iceberg is that it requires the use of a daemon that runs as root. If that's not an issue for you, Iceberg is worth checking out. I also find the documentation on Iceberg's site to be solid as well, always a welcome touch for an installer builder.

Please don't think that these are the only options out there. When you're talking about straight file copies, which is what updating Office is, once you install it on an initial system, there are as many ways to roll this out as there are ways to copy files. If you're thinking "that's a lot of ways", well, you're right. Once you know where to look for the correct information, then how you get the copies onto the end user system is totally up to you, and your normal workflow.

There are of course some things to keep in mind that could trip you up. (You knew there would be, nothing's ever that simple.) First, the main applications in Office, namely Word, PowerPoint, Excel, and Entourage are traditional dual fork applications. That is, they have a resource fork. That's probably not going to change until the next release of office, still known by its nom du code as "Office 12". So, when you're copying Office updates, you really want to make sure that whatever method you use doesn't do bad things to resource forks. Otherwise, the applications will break, and your users may do bad things to you.

The other thing to watch out for is the Microsoft Database Daemon. This is a daemon that runs whenever one of the main Office applications is running, or it runs at login if the user is an Entourage user and has set events or tasks with reminders. If you update the Microsoft Database Daemon while it's running, and there are changes made to it, then the end users, particularly Entourage users could get odd messages that might lead them to think their Entourage database died. That would make them flustered and stern, especially if they find out later that it was just an update doing this. Since the daemon only runs within a user login context, the obvious solution is to not run the update until the users have logged out. If this isn't possible, then I'd highly recommend adding a post install action that restarts the daemon.

If this all seems pretty simple, well, it is. While the Mac BU really, really, really needs to move to Apple Installer packages sooner than later, their laudable habit of providing detailed installer logs, and updated file lists in the update readmes makes what could be an onerous task into one that's just mildly tedious and annoying. As long as you keep my warnings about resource forks and the Database Daemon in mind, rolling out Microsoft Office updates shouldn't be hard at all.

Microsoft Macintosh Business Unit: various Read Me's and updater log files.

Apple Computer: Documentation for Apple Remote Desktop and PackageMaker

Stéphane Sudre: Documentation for Iceberg

John Welch (jwelch@bynkii.com) is Unix/Open Systems administrator for Kansas City Life Insurance, (http://www.kclife.com/) a columnist for Datamation, (http://itmanagement.earthweb.com/columns/appleent/) and the "GeekSpeak" segment producer for Your Mac Life, (http://www.yourmaclife.com/). He has over fifteen years of experience at making Macs work with other computer systems. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computery on occasion, or at least that's the rumor.