You might know that the United States Congress has been debating whether to change the number and kind of taxes assessed against the estates of people who die. There's a lot of arguing over whether inheritance taxes are fair, who should be subject to them, and so forth. I don't really have an opinion on the topic, but inheritance taxes have been on my mind this week because I've been working with a company whose current email system configuration was more or less inherited from previous systems administrators. The company is paying a healthy "inheritance tax" because of some of the decisions the previous administrators made—or didn't make.
The original Microsoft Exchange Server administrator didn't leave behind any documentation of how the email system was configured or modified. This kind of running record of configuration changes—what old-school mainframe guys would call a "run book"—makes all the difference when it comes time to transfer responsibility for messaging or infrastructure systems. One of the first things I had to do was assess which objects, connectors, and settings were set a particular way on purpose and which ones were merely inherited from the original setup. A written record would have greatly simplified that process. (The parallels here for estate planning are so obvious I won't even point them out.)
I found a number of what I can only describe as amputated components in the system: connectors that pointed to decommissioned servers, trust relationships to domains that no longer existed, and so on. The most common dangling items found in Exchange are the system public folders used for the Offline Address Book (OAB) and individual users' free/busy information. If you don't follow Microsoft's instructions when decommissioning the first server in a site (or in the organization), the site folder attributes will point to the wrong server and your users will have trouble using free/busy information for calendaring and using OABs with Microsoft Outlook. Many of these problems are easy to fix but can be a hassle to deal with, particularly if you don't know to expect them.
I also helped sort out some design and configuration decisions made by the previous administrator that were no longer applicable (or even right) for the organization's current needs. The Exchange Server Best Practices Analyzer (ExBPA) can help a lot with this process because it can flag configuration items that aren't in line with Microsoft's recommended practices. Fortunately, the company had already run ExBPA and applied its recommendations where applicable, but there were still a few areas that we had to discuss at the whiteboard to reach an agreement on which design or configuration alternatives were best.
One administrator I worked with said something that struck me: He felt that calling support or bringing in an outside consultant was an admission that he didn't know how to do his job. I wasn't quite sure how to respond to this at first, but then it hit me that his fear of being perceived as incompetent for seeking outside help was also an inheritance tax. As any long-time Exchange administrator knows, Exchange is such a sophisticated environment that even experienced administrators might need help to unravel complex problems. Don't be reluctant to call Customer Service and Support or an outside expert when you're having serious or intractable problems; the cost for their time is probably less than the extended cost of beating your head against a problem you haven't been able to solve on your own—especially if the problem involves downtime.
I'm happy to report that this particular company's inheritance tax is now paid in full; its Exchange system is humming along, with all the junk removed. But what about you? Are you still suffering the effects of decisions made (or not made) by whoever ran your Exchange system before you? Let me know what kinds of hassles you've faced, and I'll excerpt the best ones (anonymously, if you like) in a future column.
