Exchange 2010 Service Pack 1 and Required Hotfixes
As you are probably aware, Exchange 2010 service pack 1 was released last week, on the Internet (a so-called RTW [release to web] by Microsoft) at the Microsoft Exchange Team Blog. The release posting was The Future of Exchange Starts Here: Exchange Server 2010 SP 1 Is Now Available.
In my opinion, SP1 represents Exchange 2010 as it "should have been" at its original release. You can finally control RBAC (Role Based Access Control) in the GUI, Retention Policies now work properly and can be controlled in the GUI, common DAG options are now available in GUI, themes are available in OWA; plus a large number of bug fixes and other improved feature content. You can read the article about What's New in Exchange 2010 SP1.
However, along with this has come some controversy. You cannot install Exchange 2010 SP1 without first installing a handful of hotfixes. This is a hard-block in the Exchange setup program, which means that if the hotfixes are not detected, the setup program will abort. The list of hotfixes are available in the article Exchange 2010 SP1 Prerequisites and if you don't have them installed, the Exchange setup program also informs you of this and tells you where to get them.
Now, this is a first for Exchange setup. In the past, Exchange may have required a particular service pack and/or OS version, but not specific hotfixes. The issue with hotfixes are, as I see it, three:
[1] They must be individually requested,
[2] There is confusion about which specific hotfix to get (you will always need the x64 version, and if you are running on Windows Server 2008 SP2 then you get the Vista version; if you are running on Windows Server 2008 R2, then you get the Windows 7 version), and
[3] Hotfixes are not fully regression tested and should "only be installed on computers experiencing this particular problem".
It is this last one that makes people stop and say "whoa!" But it shouldn't.
Microsoft has required this configuration. Microsoft supports this configuration. Don't make it an issue, because it isn't.
Hotfixes are not fully regression tested because they are designed to fix a specific issue in a specific module of a specific piece of software. It does not make sense to go through a full service-pack set of testing for a single fix. Also, Microsoft has been running millions of mailboxes on this codebase (in their Live@Edu environment) for quite some time, as well as over half-million TAP customer mailboxes. These fixes have been tested in production environments and Microsoft does support them.
In my opinion, Microsoft should require these hotfixes. If Microsoft is aware of a particular problem and a fix is available for that problem - then I believe they should require that fix. I don't want an Exchange service pack released with known issues that are going to affect the end-user customer stability of the service pack.
There is some question about why these fixes aren't available on WSUS or Microsoft Update; and the answer is simple: these are not security related fixes, they are not Exchange fixes, and they will not affect every single Microsoft server installation. However, they are known to affect Exchange and thus need to be installed on Exchange servers.
My only complaint about the process is the naming of the hotfixes. Installing a "Windows 7" hotfix on a "Server 2008 R2" computer makes sense to me - but it doesn't to the average system administrator. The same is true for installing a "Vista" hotfix on a "Server 2008 Service Pack 2" computer.
So...feel safe. You have the warm-and-fuzzy you want. Microsoft fully supports the deployment of these hotfixes on an Exchange server.
Until next time...
If there are things you would like to see written about, please let me know.