Mac IT Lessons From Microsoft's Botched Office 2011 Update | Cult of Mac

Mac IT Lessons From Microsoft’s Botched Office 2011 Update


The recent Office 2011 issues highlight the importance of testing all updates before deploying them
The recent Office 2011 issues highlight the importance of testing updates before deployment

Last week, Microsoft pulled its Service Pack 2 update for Office for Mac 2011. As we reported earlier in the week, the update could result in the corruption of the Office database and issues with Office identity files could make resolving the problem difficult. After initially posting advice about the update and its potential problems, Microsoft pulled it from the company’s update servers.

Microsoft has now re-released the update. In addition to not creating the problems that plagued the original update, the new version will also correct problems for users that had downloaded the initial.

The entire situation illustrates why most tech companies, including Apple, advise business customers to wait before rolling out any new updates.

The primary reason that businesses should download and thoroughly test updates before rolling them out is pretty obvious – to ensure that Macs and other systems in their environment won’t suffer from unanticipated problems.

A simple cooling off period of a week following a release alone has value because any major issues will likely have been discovered and reported within a week. That said, there’s a difference between active testing and a cooling off period. Active testing ensures that there aren’t problems specific to an organization’s system settings, other installed software (retail and custom), or an organization’s network and infrastructure.

Then there’s the fact that even the simplest of applications, which Office most certainly is not, can function different in mass deployment environments. Often mass deployments rely on network user accounts stored in a central directory system as opposed local accounts on each Mac. This can mean that a user’s home folder resides on a file server  instead of the iMac at his or her desk. It can also mean syncing all or some of the contents between a network home folder and a local home folder on a MacBook Air that routinely works off the network. Almost universally this means the average user doesn’t have admin rights on any machine.

All of these things can result in problems manifesting in business environments that Mac users have little, if any, chance of seeing at home.

Accurate system and environment documentation is also key.

To use that MacBook Air example, sync rules may restrict certain parts of the home folder from syncing in order to conserve bandwidth. If those subfolders are where an app stores important data, then that app might work fine for that MacBook Air’s user while he or she is using it but not work at all or work in unexpected ways when he or she uses an iMac at someone else’s desk. Troubleshooting that problem (in a test environment or in the field) will be far simpler with accurate information about the sync rules and why they were configured as they were.