The MacBU released a new update to Office 2008 this past Tuesday, to bring the suite to version 12.1.2. There are a number of important fixes in this update, including changes to Word’s boot sequence that can bring a dramatic improvement in boot speed (the exact speed gain will vary a lot depending on a number of factors), major speed improvements in floating point calculations in Excel, and a slew of other items.
Shortly after the update went live, I started seeing recurring reports of people being unable to apply the update. Typically, the updater starts to run, and then mysteriously (from the user’s perspective) says “You cannot install Office 2008 12.1.2 Update on this volume. A version of the software required to install this update was not found on this volume.”, even though the user has Office 2008 installed and has been using it.
We’ve seen these reports regularly, and they almost always happen because of one of four reasons:
- The user has renamed the Office 2008 folder or some application name inside it
- The user has deleted some part of the Office 2008 folder they didn’t think they needed
- The user has run a tool such as Monolingual to remove extra languages from Office
- The user has run a tool such as Xslimmer or Monolingual to remove extra code architectures from Office
In an ideal world, our installers could handle these cases and complete the install, but installers are complex beasts, and in the interest of reducing complexity, doing any of the above actions is unsupported. Let’s get into each of the issues:
Supporting the renaming of the folder or an app adds complexity because then we have to derive heuristics to guess what bits on your hard drive might be Office. A heuristic is by definition a guess, and for every time we guess right, we might guess wrong. As a very simplistic example, if we have a heuristic that says “look in the /Applications folder for any folder that contains the word Office, and assume that is the Microsoft Office 2008 folder”, then what happens if some other app uses a folder with that name? We’d have to add another rule that says “ok, then look for an app inside that folder named Microsoft Word.app”. That rule can fail too, if users rename the app to be just Word.app. So, we could add another rule, and another, and suddenly the updater complexity just to find Office becomes unmanageable. I don’t think Apple allows their apps to be renamed or moved, either (although I’ve been told by an Apple engineer that they do. I’ll have to check on that.)
Supporting the deletion of parts of Office adds complexity because updates are not necessarily full file or bundle replacements. Some updates are just patches of the executable, or of sub-resources in the app bundle. If you have deleted a particular component that a given update wants to modify, you can end up with only a partial version of that component updated and the rest missing. Office is designed to act together as a suite, and as such, dependencies between the various apps and libraries can change at any time under the hood. If you’ve deleted a library that version 12.1.1 of Word doesn’t need, but version 12.1.2 does, your install of Office would be completely broken if we updated Word after you deleted the now-needed library. So, we err on the side of caution and refuse to update the suite if it has been modified by deleting components.
Supporting the removal of ‘unnecessary’ languages with an app like Monolingual is basically the same scenario as above, although a bit less risky. Interestingly enough, since very few parts of Office actually ship with multiple languages (I think that only MERP, the Help Viewer, and one or two other items have more than one language), removing the ‘extra’ languages only saves you a few KB of disk space, which is pretty small compared to the overall size of Office. Again, however, if you’ve modified Office by removing parts of it, we can’t tell up front whether the bits you currently have on disk will work with the updated bits the updater wants to install, so we err on the side of caution and refuse to update the suite if it has been modified by deleting languages.
Supporting the removal of ‘unnecessary’ architectures with apps like Xslimmer or Monolingual adds complexity because we don’t know exactly what has been done to the software. Did the tool adjust the loader commands in the Mach-O binary? What if we’re patching the binary instead of replacing it? It’s always safer to do nothing to your current install than it is to blindly make changes based on an unknown current state, so we err on the side of caution and refuse to update the suite if it has been modified by deleting architectures.
Some web forums have posted a workaround that involves copying the updater to a write-able location and then modifying one of the scripts inside the installer, so that the installer always blindly goes ahead and applies the update. That may appear to work, but leaves your Office install in a possibly precarious and probably unsupported state. [Update: I did a little digging into this script in the updater, and it is checking a number of specific files to make sure they match their expected state. It is pretty obviously not validating every file in the Office suite (for performance reasons, maybe). If we’re not validating every file, then it is possible to update some modified file, which undermines my own discussion here. Hmph. I’ll have to talk to the folks at work to get the background on this script. My guess is that we check a representative sample of files to see if they’ve been modified, since the usual suspect processes modify almost every file in the suite. If one of this set of files has been modified, it’s likely that the rest of the suite has been changed too, and it’s safer to abort the update. Again, that’s just my guess.]
Now, having said all that, I think the current user experience is not ideal and could be improved. One change might be to tell you that we did in fact find what looked like Office, but that we detected some change that is unsupported (such as language or architecture deletion, etc), but even doing that adds some heuristics, and if we’re looking by name and don’t find the right name, then the current error message is technically correct. So, we’ve got some thinking to do about this.
Hopefully this post explains some of the reasons users are seeing the updater error message. If you are seeing it for reasons I haven’t listed above, please add a comment.