To make it easier to keep your Microsoft Exchange Server software up to date, Microsoft regularly issues rollup releases that combine all of the hotfixes that are currently available for your Exchange version, including those from previous rollups. Update Rollup 3 (UR3) for Exchange Server 2007 Service Pack 1 was released on July 8, 2008. (If you're running Exchange 2007 RTM, your latest update is Update Rollup 7 for Exchange Server 2007.) It's generally a good idea to follow the installation of a service pack by installing the latest rollup so that your server is running the most current software. But sometimes the best laid plans go a tad amiss, and that’s the situation with UR3 and its predecessor, UR2. Here’s why.
UR3 and UR2 contain some Microsoft .NET Framework 2.0 managed assemblies that Microsoft applied a digital signature to using Authenticode. During the installation of these rollups, Windows attempts to validate that the key used to apply the digital signature to the assemblies is valid to ensure that you don’t load code that someone might have compromised in any way onto a server. During the validation process, the installation procedure attempts to make a connection to a certificate revocation list (CRL) at crl.microsoft.com/pki/crl/products/CSPCA.crl. If the installation procedure can’t access this site, it experiences a timeout that eventually passes—or it might cause the installation to fail. During a recent upgrade of fifteen Exchange 2007 servers to SP1 UR2 that I witnessed, the delay ranged from 40 minutes to an hour and the installation failed completely on two of the fifteen servers. This failure is painful because the only indication that anything bad has occurred is the fact that the Microsoft Exchange Service Host service isn't running.
The root cause of the problem is that many companies don't allow Exchange servers, especially those running the Mailbox or Client Access roles, to have direct access to the Internet: Those servers will never be able to connect to crl.microsoft.com to perform the check that the rollup installation procedure wants to perform. The solution is to make sure that your firewall lets your servers make a connection to crl.microsoft.com.
If this solution isn’t possible or is undesirable in your environment, the fastest workaround is to create an entry that points crl.microsoft.com to 127.0.0.1 in the local hosts file of the server before commencing the upgrade. This method forces a local lookup that quickly fails and lets the installation complete. It’s reasonably safe to assume that the key used by Microsoft to sign the managed code assemblies is valid, so it should be safe to use this hack. Microsoft offers some other advice and explains the background to the problem in the articles "Exchange 2007 managed code services do not start after you install an update rollup for Exchange 2007" and "FIX: A .NET Framework 2.0 managed application that has an Authenticode signature takes longer than usual to start."
Apart from being a real pain to manually update a hosts file just so a server can install a set of patches, this problem highlights an issue that Microsoft needs to solve: Its scheme of validating the keys used to sign managed code assemblies can't work if it requires servers to check a particular Internet location that might be blocked or otherwise inaccessible. The word from the Exchange engineering group is that they're considering how best to disable the validation for future rollups, but for now the best idea is to make the change in your hosts file (through gritted teeth) before proceeding to install UR3.