Managing customizations for Exchange

Tales of the disasters that result because of misconfigured email settings are pretty common, but perhaps don’t quite have the dramatic and strange effect of the snafu as related in “The 500 mile email”, an amusing story about how an upgrade to a newer version had the regrettable side-effect of causing email failures.

Of course, the story revolves around a Sendmail configuration file rather than having anything to do with Exchange. But that’s no reason for Exchange administrators to smirk or otherwise fell superior because there are many places within Exchange where an upgrade can wreak havoc because it overwrites a file that you had previously customized to meet the needs of your organization.

For instance, Paul Robichaux recently outlined the methods used to customize Outlook Web App (OWA) in Exchange 2010, including the common requirement to apply a company’s logo or color scheme to OWA pages. This kind of customization is very common and OWA customization is documented by Microsoft, yet making changes to OWA comes with a public health warning because it is all too easy to find that your work is overwritten by a change made by Microsoft in a service pack or roll-up update. Microsoft makes the change for the best possible reason (to fix a bug) and cannot guarantee that they can avoid overwriting important OWA components such as CSS files in this process. It’s therefore important to preserve any change that you make to OWA in a well-documented method to make it easy to reapply the customization to Exchange after upgrades, should that need arise.

But there’s more. Exchange includes a set of XML-formatted configuration files that are used for many purposes such as the transport system or Mailbox Replication Service (MRS). You can certainly edit these files to change the way that a component like MRS works as long as you remember that the change is only effective on the server where you make it and once again, Microsoft might have to overwrite the customization during an upgrade. In the case of MRS, if you make a change to its configuration file, you’d have to make the same change on every CAS server in the organization to ensure that MRS behaves in the same way throughout.

Casting my mind back to the dim and distant past, I can report that the preservation of customizations across upgrades has been a problem ever since vendors provided the ability to administrators to customize their servers. When I worked on DEC’s ALL-IN-1 server, Kevin Laahs, Ben Geerdes, and myself built a complete sub-system called System for Customization Management (which went by the charming code-name “SCuM”) that isolated all administrator-made changes into one set of directories and forced the server to use customizations before product files. This approach was introduced in 1987 and persists today in the few servers that still run HP OfficeServer for OpenVMS. It would be nice if such a facility was available for Exchange today, even if today’s politically correct times would mandate the use of a nicer code-name.

Whatever scheme Microsoft might come up with to manage customizations, it would be best if the mechanism wasn't limited to a single server. In other words, I'd like to see a method that allows an administrator to make changes on one server and then deploy those changes to other target servers within the organization. Perhaps it is possible to store elements like CSS, configuration files, or customized logos in the Active Directory? After all, isn't it the repository for all shared elements for an organization?

Follow Tony’s ramblings on Twitter

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.