by Michael B. Smith, MCSE/Exchange MVP

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
http://support.microsoft.com/kb/944752

You can restrict OWA to offering only OWA Light for a specific Virtual Directory or for a specific user.

To set the restriction on the Virtual Directory for all users, you need to enter the following PowerShell:
Set-owavirtualdirectory –id:<virtual directory ID> -PremiumClientEnabled:$false

To set it for a particular user, use:
Set-CasMailbox –id:<mailbox ID -OWAPremiumClientEnabled:$false

The user will see both the "Premium" and "Light" logon option but they will always get the Light version, regardless of which option is chosen. This happens because Exchange renders before it knows who the user is or which logon page they are supposed to get.

Do you need to configure an Exchange server Public folder so that everyone can send messages to the folder but only a few select users can read the messages?

After mail-enabling the folder, give Contributor permissions to Anonymous to allow everyone internally and externally to send to the folder's address. If you only want to allow internal users to send mail to the folder, set Default to Contributor and Anonymous to None.

Then set the permissions for the other users or groups to a permission level that includes Folder visible and with read and Delete all permissions. The predefined permission levels of Editor and above will work or use custom settings.

When you try to delete non-Task items that are flagged completed from the To-do folder this warning dialog pops up:

Deleting this item will also delete the contact.

Do you want to continue?

This warns you that clicking Yes (to continue) will delete the item from its folder as well as remove it from the To-Do list. This happens because the To-do list folder is just a search folder for your tasks, flagged messages and contacts and deleting the item for this folder deletes it from Outlook. If you want to keep the item but remove it from the To-do folder, right click on the completed check and choose Clear Flag instead. If it needs to remain marked completed, create a custom view that hides completed items. You won't get this warning for completed tasks since users know (or should know) that they are deleting the actual task.

If you accidently click Yes, the items can be recovered from the Deleted items folder. To easily find the item, add the modified folder to the view in Deleted items then sort by it. The last deleted items will be on top.

If you attempt to use spell check and receive an error message that says "The spelling operation could not be completed. The word is too long for the dictionary", you either have a entry in the custom dictionary that is too long or your custom.dic file is corrupt.

Don't waste your time reinstalling or repairing Office. Locate the custom.dic and either rename it or open it in Notepad and look for the corrupt entry. It should be easy to spot as normally the entries are one word per line and a corrupt entry may be several words run together (forming a really long word) or contain HTML code or other strange text.

The custom dictionary is located at %USERPROFILE%\Application Data\Microsoft\Proof\Custom.dic in Windows XP and by default its at %USERPROFILE%\AppData\Roaming\Microsoft\Uproof\Custom.dic in Vista.