Automatic Updates and Exchange Server

Don’t get me wrong: Microsoft Update and its predecessor, Windows Update, perform a valuable function by collecting all the updates for a given combination of Microsoft products in one easy place. For example, when I use Microsoft Update on my Microsoft Office Communications Server (OCS) 2007 server, it shows me updates for OCS 2007 as well as Windows Server 2003 and SQL Server 2005, which I have on the same system, all in a single update system. I can review and choose updates to install for all the Microsoft server products at one time instead of going to different places for each server. Windows Software Update Services (WSUS), an optional component you can install on your Windows servers, lets you pull new updates automatically from Microsoft Update, stage them, and distribute them to servers and clients in your organization. All of this is made possible by the Background Internet Transfer Service, an efficient HTTP-based transfer tool that uses idle time, and idle bandwidth, to transfer updates.

You might think that given this arsenal of tools, update and patch management is a simple set-and-forget operation. For small, single-server operations, this might be true, but larger organizations typically have more complex policies that require them to download patches, apply them to a set of test machines, and verify that the updates don’t break anything before distributing them more broadly. The overhead required for doing this kind of testing is a key reason why Microsoft now issues security updates on a predictable schedule; that predictability lets the rest of us plan for the orderly distribution of security updates.

As I write this, Microsoft has just released Update Rollup 4 (RU4) for Exchange Server 2007 SP1. Like other Exchange rollups, RU4 combines the contents of the previous rollup, RU3, with the hotfixes that have been released since RU3 became available. However, RU4 is a little unusual because this is actually its second release. An earlier version was accidentally released on September 9 through Microsoft Update, so Exchange administrators who had automatic updates enabled got the broken rollup—which in turn led to broken Exchange servers.

The moral of this story is pretty clear: You probably shouldn’t enable completely automatic updates on your critical servers. Based on the traffic I saw on mailing lists and newsgroups after the broken RU4 release (and the fact that the Exchange team felt it necessary to blog about the incident), my guess is that a surprisingly large number of us had automatic updates in MU turned on.

The ability to automatically apply security and performance fixes to computers is a fundamentally useful one; I use it on my home clients and recommend (OK, actually, enforce is a better word) it for family members whose computers I support. However, in the enterprise it doesn’t make sense to let updates roll directly to production server systems without any vetting or checking. Before we hit the end of daylight saving time (DST) in North America, you might want to check your automatic update settings, just in case.

End of Article