Exchange Address Lists For Federations

One of the issues that came up recently with a federated customer of mine was how they were going to manage the address list needs of 30 different departments. To centralize it would prove futile, as that group would undoubtedly become unresponsive, yet Exchange treats address lists at the global level, so it would be necessary to give 30 different administrators full control of the organization, which most people find even worse than waiting.

There is a third way to tackle this problem, but it is not exposed in the default Exchange System Manager interface. To make it work, you first need to expose the security tab in System Manager, by following the simple procedures outlined at https://support.microsoft.com/kb/259221/EN-US/. 

Once you can view the security properties of any object in Exchange, you can create the equivalent of top-level folders under the All Address Lists container. I would recommend that each top-level list be a valid address list, since it will be exposed and probably selected by end users. By default, all Exchange administrators that have been granted any of the standard roles in Exchange 2003 have read permissions on all Address Lists. If your departments have been organized with security groups, however, you can grant full control on each top-level address list to the respective security group. This allows departmental administrators with control over their own administrative group to also create their own address lists for their agency, without the wait of a centralized procurement system or the risk of doing damage to other departments' lists. 

It is very important, however, that you only add additional permissions. You should not change the existing default permissions, as that would render the Exchange organization possibly unsupported. Further, you should take inheritance into account to ensure than rights are not greater than what is required for proper delegation.

All that said, let's talk a little about address lists. Why do my federated customers want so many of these customized lists? I asked one and the response I got was strange (to me). "People like to browse the GAL and determine who they should send the mail to." Let me get this straight, people like to browse 50,000 objects just to send an email?

It seems to me that anyone falling into the category described above has some issues with change. We live in a search-based technological society. Does anyone just browse the web looking for what they want? No, they start with a search engine. Why can't we do the same with mail? First of all, I should know who I want to send most of my mail to, and all I need do is type that name in Outlook and allow ambiguous name resolution to help me out.

But let's say that I don't know the name of the person I want to send to. Maybe I want to find the manager of procurement. Wouldn't it be nice if I could just search for everyone with a manager title in the procurement department? Of course it would, but that would require that our directories actually contain useful, valid and somewhat realtime data. 

The advice I have for my federated customers is this. Build taxonomies within your federation. Force all administrations to follow simple, standard rules for entering personnel information into the directory. Every organization likely has a personnel database; it's a good place to start. When building taxonomies, however, it is just as important that the data is complete as it is consistent. You don't want a title to be manager in one department and supervisor in the other if the position is essentially the same level of responsibility. This is no minor undertaking, but chances are, it's already been done by HR. Work with your HR departments to get this data out of limited use systems and into Active Directory (not everything - keep the senstive stuff out of AD). Most importantly, show your end users that searching can be far more efficient and accurate than hunting and pecking for the right email recipient.