Introductory Note: Evan Morris is filling in for Jerry Cochran on his weekly Exchange Administrator UPDATE column. Jerry handed over the keyboard so he could take off with a fishing pole instead. Meanwhile Evan is holding down the fort for their engineering team and the Exchange Server Site that they maintain. Evan will cover the next 2 weeks and then Kieran McCorry, who works in the same Applied Microsoft Technologies Group as Jerry, will take the following 2 weeks.
Our organization's Exchange Server system has failed—but perhaps not in the way you expect. Our Exchange Directory failed to deliver the useful information it holds. The Exchange system failed in the sense that the designed functionality didn't deliver practical functionality for all system users. Here's the story.
We recently hired a new administrative assistant who has a healthy enthusiasm for her job and sees problems as opportunities to help. Our physical location is a remote site of 20 people (in an organization of thousands), and we maintain a single mailbox server at this site (well, actually it's a clustered server, but you only need to know that because we're certainly capable of delivering the best possible Exchange system).
One day, the new assistant sent an email message with an Excel spreadsheet containing a mini-directory for our site. The spreadsheet contained the usual contact information (e.g., phone numbers, email addresses) for company employees in our office and a few external contacts. When I received the message, I realized our Exchange system had failed us. It failed to provide the level of functionality that we expect and need. After all, the personal contact information in the spreadsheet either already exists in our Exchange Directory or a field exists where you can store it.
So, I began to investigate where the failure occurred. Part of the failure lies in the lack of granularity in the administrative model for Exchange Server 5.5. It lacks the ability to give permission to update and publish certain mailbox information without granting access to all properties of the mailbox. Another part of the failure lies in the information view Exchange presents and whether it satisfies the end users' needs. And finally, part of the failure lies in our lack of communicating the capabilities of existing technology to a new employee.
A few weeks later, the assistant sent a revised list, which meant that those users who keep the file must replace it with a new one. I moved my copy of the message to our department’s Public Folder (which all internal employees in the contact list can access) and sent the assistant a shortcut to the new location. Being new to our company and email system, she was happy to learn of this ability to share information. Now she can update the file in one central location. The next step is to capture any information that she's entered into the spreadsheet and replace the spreadsheet's functionality with the features in Exchange. We already have the Address Book View created in Exchange for our site, so we can use the Custom Attributes fields to capture additional employee information. To enter the information, I can use my Administrator access to mailboxes—at least until we roll out Exchange 2000 Server, which relies on the security hierarchy of Active Directory (AD) so that we can give a user access to update only the fields within the mailboxes in our site. This approach will help solve some of the underlying reasons for our "system failure."
It's easy for an administrator of a specific information technology to forget the information view that nonadministrators see. Just because the information is being stored doesn't mean that end users of that information will see the need to come up with different methods of storing or sharing that information. Problem or opportunity, you decide!