Patching technologies have come a long way since Windows NT 3.5. (Yes, I’ve been around that long. No, I don’t want to talk about it!) Way back then, practically every change to a server required you to reinstall the current service pack plus any additional patches you might have been using. Similarly, Exchange 5.x often required you to reinstall the Exchange service pack after making changes to the Exchange application. And, of course, you ALWAYS rebooted after applying any patch. And do you remember “DLL hell” when differing applications required different versions of the same DLL making it impossible to run certain applications at the same time?

These issues are pretty much long gone (and good riddance!).

Some of the things that have happened over the last couple of Windows releases include the consolidation of Microsoft’s patching methodologies down to a single one. From this came WSUS (Windows Software Update Services). Continual improvements to the patching technology require fewer and fewer reboots when patches are applied. SFP (for System File Protection) makes it almost impossible for key system files to be overwritten and WinSxS (for Windows Side By Side) effectively eliminates DLL hell. You can find large amounts of information about those technologies on MSDN and Technet.

A related technology called Authenticode makes it possible to ensure that a program you receive was actually created by Microsoft. Authenticode is best known within Internet Explorer – it provides you assurance as to who created (for example) an ActiveX Control. However, Authenticode can also be used to “sign” programs that use the .NET framework.

Microsoft runs an enterprise certificate authority (CA). This CA produces keys for most .NET assemblies that come out of Microsoft. A key is used to generate a certificate – like the SSL certificate you are used to – but in this case it is an X.509 certificate. An assembly is just a special name for a program which may be any of a library [DLL], a service, or a regular application.

With the key from the CA, .NET “signs and seals” the assemblies. Once an assembly has been signed and sealed, you can be certain that the assembly came from Microsoft, that the assembly has not been modified, and when the assembly was generated. This is of great value, in this day and age, when worms and viruses get smarter and smarter and you need a way to verify that the programs you are running are “known good”.

Exchange Server 2007 uses .NET assemblies very heavily and many of the binaries that are shipped with Exchange 2007 are signed.

Now for the downside: the first time a signed assembly is executed, Windows must check and verify that the signature (the certificate with which the assembly is signed) is valid. In order to do that, Windows has to access the Microsoft Certificate Authority to get a list of all revoked or known invalid certificates. It does this at a specific URL: http://crl.microsoft.com/pki/crl/products/CSPCA.crl. This means that any server using signed assemblies – including your Exchange Servers – must have outgoing access through your firewall via TCP port 80. If not, then Windows can’t verify that a signature is valid. If your application is a service (think of all of those Exchange services!) the service won’t start. Keep this in mind!

Thankfully, for those folks who want for at least some of their Exchange servers to be fully isolated from the Internet, there is a workaround. See KB 936707. However, an easier (and apparently undocumented) workaround is to put crl.microsoft.com in your local hosts file – and point it to localhost (127.0.0.1)!

This issue is documented, but poorly explained, in the following KB article:
Exchange 2007 managed code services do not start after you install an update rollup for Exchange 2007

Articles that may interest you:

How to Prevent Lync from Locking Outlook's .O...

Is 'Make a new profile' the new 'Format C:'?

Searching Outlook's Calendar

Sharing Exchange 2010 Calendars with Outside ...

Last reviewed on Aug 23, 2011