Microsoft has released their own white paper containing guidance on configuring Exchange 2007 for Address List separation. This is something that was pretty easy in Exchange 2003, but suddenly made a lot more complicated and less obvious in Exchange 2007. A bunch of home brew solutions came about some time after Exchange 2007 was released and now Microsoft’s white paper has the prescriptive guidance (which is basically the same as some of the better home brews out there).
Why segregate Address Lists?
Some larger organisations look for segregated Address Lists as a means of improving the relevancy of the Address List objects that users are seeing in their Outlook address book. Why see all 20,000 global employees when really you only need to see the 1000 employees and distribution lists in your country (especially since smart admins lock down distribution lists so people can’t send rubbish emails to “All Staff – Global” for example). Here is Microsoft’s word on the matter:
Address list segregation is a process whereby administrators can segment their users into separate groups and implement security policies so that groups of users can see only their specific address list. The ability to restrict access to address lists in this manner may be used as part of the toolset for helping companies meet their internal security requirements and as part of a regulatory compliance strategy for meeting the requirements dictated by the Health Insurance Portability and Accountability Act (HIPPA), and the Sarbanes-Oxley Act.
It is useful to illustrate how address list segregation can be implemented by way of examples. Suppose your company, Contoso, purchases the company Fabrikam. The management team determines that they want to manage Fabrikam’s entire IT infrastructure, but they want the employees of Contoso and Fabrikam to be completely segregated so that they are only able to see other users and resources from their respective companies. By implementing address list segregation, Contoso administrators can meet this requirement for all Exchange Server 2007 functionality.
Another scenario is the “Virtual Organisations” mentioned in the White Paper title, which I think is code for hosted Exchange providers. Last year I worked on deploying a hosted environment that included Exchange Server 2007 and that is how I encountered all of the difficulties with configuring Exchange 2007 in this fashion (and came across the home brew solutions). Microsoft calls it “Virtual Organisations” but I think that is because they are not recommending you use this solution for hosted Exchange services.
It is also important to understand that attempting to configure Exchange 2007 as a commercial “hosting” solution is not recommended.
The configuration described in this document is complex in nature, and while it can be effective in smaller environments or in limited scope, it can become very challenging to manage such a configuration as the scope of the deployment increases if automation steps are not implemented.
It is conceivable that an organisation that has developed suitable account management scripts in their hosted environment could solve this scalability issue.
