Perhaps the most welcomed feature that will be included with the upcoming Exchange 2010 Service Pack 2 is without doubt the new Address Book Policies (ABPs) feature, which replaces the old ACL-based GAL segmentation method that was used with previous versions of Exchange Server and by the way never became supported in an Exchange 2010 environment.
The Address Book Policy (ABP) feature which can be managed both via the Exchange Management Shell and Console allows an organization to segment or provide custom GAL to different sets of users based on attributes such as custom attributes, company or department.
All necessary steps are done from within the Exchange Management tools and I must admit that the way this feature has been put together rocks. The way you control the visibility flow all the way from the ALs/OABs and the policy itself to applying it to users.
First, you create the Address Lists (ALs), offline address book (OAB) and then GAL (remember the GAL can only be created via the EMS). Then you create the Address Book Policy (ABP) and associate the ALs, OAB and the GAL with it.
When the ABP has been created, you can then associate it with a set of users via Mailbox Features on the property page of a User Mailbox or using the Set-Mailbox cmdlet.
In Outlook, you will then see a view like the following:
A few facts about ABPs:
ABP’s work for any client that goes through CAS for directory and;
- Opens the address list picker
- Tries to resolve a name or an alias
- Adds a room resource to a meeting request
- Searches the GAL
- Searches the directory from Outlook Voice Access
- Queries the directory from a mobile device
- Views someone’s DL memberships, or views the members of a DL
- Yes – if a user in a DL is outside the scope of your ABP, you won’t see them
- This prevents GAL mining by surfing up and down the member/memberof properties in some scenarios
- This does mean you might be sending to more people than you think you are… and that MailTips might not be telling the truth…
And some considerations:
- Deploying ABP’s successfully is all about PLANNING and understanding what they can, and cannot do
- Use standard, built-in and existing Custom Attributes to represent company/division/class or whatever you want to divide upon
- DL’s don’t have Company attributes so you can’t filter on those
- Custom Attributes are consistent on all mail enabled objects
- Build simple AL and GAL filters where possible and group them together into ABP’s
- Try not to span DL’s over ABP’s unless you really need to hide DL membership and prevent GAL mining
- Build OAB’s based on GAL’s, not AL’s (yes, we fixed this too)
- Make sure a user exists in their own GAL
And some final words:
- ABP’s cannot prevent anyone directly connecting to AD and bypassing ABP logic
- So any LDAP clients, for example Outlook Mac/Entourage using LDAP will not work with ABP’s
- So you can’t use ABP’s if Exchange is installed on a GC as NSPI is provided by AD, not Address Book Service
- If you span DL’s over ABP’s you need to disable Group Management in ECP as ECP uses Get-Group which ignores ABP’s
- Don’t try and mix and match ABP’s and ACL’s (unless migrating) or use QBDN’s
And lastly a few words for the hosters out there:
- MS will support hosting Exchange with SP2 and ABP’s but there are some caveats to this
- MS is not producing prescriptive guidance on hosting using this feature, but will document some support boundaries
- ABP’s don’t solve all the problems hosters usually face
- ABP’s are not providing legal separation
- ABP’s don’t stop ‘Default’ permissions meaning the entire platform
- ABP’s don’t stop Lync presence between organizations
- Internal OOF’s will still be sent between companies sharing the same platform
- Provisioning, billing, service plans, throttling etc
- Bottom line is – we still recommend you use /hosting mode
Thanks to Greg Taylor for sharing most of the above info with me.
Now with that, I’ll jump back to my Exchange 2010 SP2 Beta lab
Technology Architect/Writer/MS Vendor
MCM: Exchange 2007 | MVP: Exchange Architecture