Understanding Address Book Policies

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Global address list (GAL) segmentation (also known as GAL segregation) is the process whereby administrators can segment users into specific groups to provide customized views of their organization’s GAL. In Microsoft Exchange Server 2007 and earlier versions, segmenting the GAL was complicated and required that you use either a Query Base DN (which acted as a root for directory searches) or access control lists (ACLs) to allow or deny access to each address list. To learn more about how to configure GAL segmentation in Exchange 2007, see Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

To simplify the process, Microsoft Exchange Server 2010 Service Pack 2 (SP2) introduces address book policies (ABPs). When creating an ABP, you assign a GAL, an offline address book (OAB), a room list, and one or more address lists to the policy. You can then assign the ABP to mailbox users, providing them with access to a customized GAL in Outlook and Outlook Web App. The goal is to provide a simpler mechanism to accomplish GAL segmentation for on-premises organizations that require multiple GALs.

How ABPs Work

ABPs contain the following lists:

• One GAL

• One OAB

• One room list (for booking purposes)

• One or more address lists

In the following figure, Address Book Policy A consists of a subset of the various address objects that exist in the organization (shown in the bottom half of the figure). The resulting scope of an ABP is equal to that of the GAL contained in the policy, in this case GAL1. When the ABP is created and assigned to a user, the address objects in the ABP become the scope of the objects the user is able to view.

You can use the following methods to assign ABPs to individual mailbox users:

ABPs take effect when a user's client application connects to the Microsoft Exchange Address Book service on the Client Access server. If you change the ABP, the updated ABP doesn't take effect until the user restarts Outlook Outlook Web Access, or until you restart the Microsoft Exchange Address Book service. To learn more, see Understanding the Address Book Service.

Entourage, Outlook for Mac, and ABPs

ABPs won’t function for Entourage users or Outlook for Mac users who are connected to their corporate network. When inside the corporate network, Entourage and Outlook for Mac clients connect directly to the global catalog server and query Active Directory directly instead of using the Microsoft Exchange Address Book service. However, Outlook for Mac 2011 clients that connect from the Internet can use an OAB or Exchange Web Services (EWS). As a result, these clients can view the GAL based on the assigned ABP. To learn more about administering Outlook for Mac 2011, see Planning for Outlook for Mac 2011

Deploying ABPs

This section provides information about deploying ABPs in your organization, including best practices, scenarios, and general steps. To review all ABP management tasks, see Managing Address Book Policies.

Considerations and Best Practices

Consider the following when setting up ABPs in your organization:

• For ABPs to work correctly, the user mailbox to which you apply the ABP must be on a Microsoft Exchange Server 2010 SP2 server.

• Don’t run the Client Access server role on the global catalog server. Doing so results in Active Directory being used for Name Service Provider Interface (NSPI) instead of the Microsoft Exchange Address Book service.

• You can't use hierarchical address books (HABs) and ABPs at the same time. To learn more about HABs, see Understanding Hierarchical Address Books.

• Any user assigned an ABP should exist in their own GAL.

• If you allow client applications to access Active Directory directly through LDAP, they will bypass the logic built into ABPs. Because Outlook 2011 and Entourage 2008 use direct LDAP queries to access, Active Directory those client applications won’t function properly with ABPs if a domain controller or global catalog server is specified or provided to them by the Autodiscover service. Outlook 2011 can use EWS or a local OAB to access directory information. However, if Outlook 2011 can directly access an LDAP service, it will try to do so.

• The GAL used in an ABP must, at a minimum, contain all of the address lists, including the room address list, defined and specified in an ABP. Don’t create a GAL that contains fewer objects than any of the address lists in the same ABP.

• We recommend creating distribution groups that don't cross virtual organization boundaries. Creating distribution groups that contain members of multiple virtual organizations results in the following issues:

  • If group members request delivery or read receipts when sending mail to the distribution group, they’ll be able to see the e-mail addresses of the group members in other virtual organizations

  • If an encrypted message is sent to the distribution group and some group members don’t have valid digital IDs, the sender will receive a warning message that includes the total number of members who don’t have valid IDs and a list of their e-mail addresses. However, if some of those members without valid digital IDs are in a different organization than the sender, the warning message will include the correct count but won’t include the e-mail addresses of the members in the other organization. As a result, the total count won’t match the list of member addresses.

    For example, let’s say a distribution group contains five members total from two organizations, Agency A and Agency B. Three group members are from Agency A, and one of those members has as invalid digital ID. The other two members are from Agency B, and both of them have invalid digital IDs. If a member from Agency A sends an encrypted message to the distribution group, that member will receive a warning message stating that there are a total of three recipients without valid digital IDs. However, only the e-mail address for the recipient from Agency A will be listed in the warning message.

  • ABP's don’t apply to the Get-Group cmdlets. Therefore, any user or process that is able to run Get-Group will see all members of any group they have access to.

    We recommend that you modify the group management settings of the Exchange Control Panel (ECP) so users can’t use ECP to manage groups. To prevent users from using ECP to manage groups, exclude the users from the MyDistributionGroupMembership RBAC role. For details see MyDistributionGroupMembership Role and Turn Off User's Ability to Create Distribution Groups.

  • If you allow users to use Outlook or Outlook Web App to manage groups, the group owners must have full visibility to the group membership list.

• All ABPs must contain a room address list. However, if your organization doesn't use room address lists, you can create a default empty room address list.

• Deploying ABPs doesn't prevent users in one virtual organization from sending e-mail to users in another virtual organization. If you want to prevent users from sending e-mail across organizations, we recommend that you create a transport rule. For example, to create a transport rule that prevents Contoso users from receiving messages from Fabrikam users, but still allows Fabrikam’s senior leadership team to send messages to Contoso users, run the following Shell command:

  New-TransportRule -Name "StopFabrikamtoContosoMail" -FromMemberOf "AllFabrikamEmployees" -SentToMemberOf "AllContosoEmployees" -DeleteMessage -ExceptIfFrom seniorleadership@fabrikam.com
  

  To learn more, see Create a Transport Rule.

• If you want to enforce the ABP in the Lync client, you can set the msRTCSIP-GroupingID attribute on specific user objects. For details, see PartitionByOU Replaced with msRTCSIP-GroupingID topic.

Deployment Scenarios

The following three scenarios describe possible deployment solutions for three different organization types. Although there are many more scenarios, the most common ones are covered here. The address lists and GALs in these scenarios were created based on filters, such as Custom Attributes, that grouped the objects logically.

Scenario 1: Two Separate Companies - One Exchange Organization

This scenario is applicable to companies that have separate agencies, divisions, or departments that are:

• Within the same Exchange organization.

• Don’t share employees.

• Don’t share a common reporting chain.

In addition, the agencies, divisions, or departments don't have any special security or privacy concerns.

In this scenario, two ABPs are created with the following settings:

• Employees who view the GAL or distribution group membership can see only recipients within their company.

• There are no distribution groups that span across both companies.

The following table lists the address lists, GALs, room lists, and OABs that are included in the ABPs for Contoso and Humongous Insurance. The ABP components were created by using the CustomAttribute15 parameter to group the objects. Because the two companies are separate without any interaction between them, they don’t share any address lists.

Scenario 2: Two Companies Sharing a CEO

This scenario is applicable to companies that are:

• Within the same Exchange organization.

• Share the same CEO.

• Don’t share employees.

In this scenario, three ABPs are created with the following settings:

• Employees who view the GAL or distribution group membership can see only recipients within their company.

• In each company, there is a distribution group named SeniorLeaders, which includes the senior leaders of that company and the shared CEO.

• Employees who view the CEO's group membership can see only groups within their company.

• Three ABPs are created: Fabrikam, Tailspin Toys, and CEO.

When the CEO is added to the distribution groups in each company and falls within the scope of each company's ABP, the CEO becomes visible to each company. The CEO is visible in both the Fabrikam and Tailspin Toys GALs and can create distribution groups that span both companies. However members of the distribution group can view only members that are within their own company.

Scenario 3: Education

This scenario is applicable to schools or universities where a division of classrooms is necessary to ensure the privacy of the students.

In this scenario, ABPs are created with the following settings:

• Students can view only other students in their classroom, their teacher, and the principal.

• Teachers can view only students in their classroom, all teachers, and the principal.

• Distribution groups are created for each classroom’s parents and the faculty.

General Deployment Steps

This section provides the general steps for deploying ABPs in your organization, including how to migrate from Exchange 2007 address list segmentation.

Migrating from Address List Segmentation to ABPs

If you’re currently using Exchange 2007 address list segmentation (per the instructions in the white paper Configuring Virtual Organizations and Address List Segregation in Exchange 2007) and you want to migrate to ABPs, follow the steps outlined in Migrate to Exchange 2010 Address Book Policies from Exchange 2007 Address List Segregation. This procedure requires some downtime for your organization so be sure plan accordingly.

New Deployment of ABPs

If you aren’t using Exchange 2007 address list segmentation, follow the steps listed in this section to deploy ABPs in your organization.

The following steps apply to Scenario 2: Two Companies Sharing a CEO. In this scenario, Fabrikam and Tailspin Toys are separate companies that share a CEO and senior leadership team. This scenario requires three ABPs:

• ABP_FAB

• ABP_TAIL

• ABP_CEO

Step 1: Divide your virtual organizations

You'll need to develop a way to divide your organization into virtual organizations. When making this division, we recommend using the Custom Attribute properties on the mailboxes, contacts, and groups instead of the precanned conditional attributes (such as Company, Department, or State/Province). Using Custom Attributes instead of precanned attributes includes the following benefits:

• Not all recipient types have precanned conditional attributes in Active Directory. For example, the Active Directory objects Distribution Group and Dynamic Distribution Group don’t support the Company, Department, or State/Province attributes.

• Not all precanned conditional attributes are exposed in cmdlets for some recipients. For example, the Company, Department, and StateOrProvince parameters aren’t available in the cmdlets for mail users, contacts, distribution groups, and mail-enabled public folders.

• Multiple cmdlets are required to segment recipients when you use precanned conditional attributes. For example, to set the Company, Department, or StateOrProvince parameters for a user mailbox, you must run the Set-User cmdlet after you run the New-Mailbox or Set-Mailbox cmdlets.

  However, the CustomAttribute parameters are exposed in the Set-* cmdlets for each recipient type, so there’s no need to also run the Set-User cmdlet.

• Custom Attribute properties are explicitly reserved to customize an organization and are controlled entirely by organization administrators.

To learn more about custom attributes, see Understanding Custom Attributes.

Another best practice to consider when dividing your organization is to use company identifiers in the names of distribution groups and dynamic distribution groups. One method for doing this is to use group naming policies. These policies allow you to specify that a prefix, a suffix, or both be applied to distribution group names. This is helpful when dividing your organization because you can use these policies to specify a suffix or prefix based on user attributes such as the creator of the distribution group's Company, State/Province, Department, and Custom Attribute properties. This is especially important if you allow users to create their own distribution groups. For more information, see Create a Distribution Group Naming Policy.

Step 2: Create the address lists, room list, GALs, and OABs

When you create the address lists and GALs, don’t use the IncludedRecipient and ConditionalX parameters, such as ConditionalCompany and ConditionalCustomAttribute5. Instead, we recommend that you use recipient filters. To learn more about recipient filters, see Creating Filters in Recipient Commands.

Create the address lists

When you create the ABP, you include multiple address lists based on how you want your users to view the lists in Outlook or Outlook Web App. This scenario requires four address lists:

• AL_FAB_Users_DGs

• AL_FAB_Contacts

• AL_TAIL_Users_DGs

• AL_TAIL_Contacts

This example creates the address list AL_TAIL_Users_DGs. The address list contains all users and distribution groups where CustomAttribute15 equals TAIL.

New-AddressList -Name "AL_TAIL_Users_DGs" -RecipientFilter {((RecipientType -eq 'UserMailbox') -or (RecipientType -eq "MailUniversalDistributionGroup") -or (RecipientType -eq "DynamicDistributionGroup") -and (CustomAttribute15 -eq "TAIL"))}

The above command would then be run to create the remaining address lists: AL_FAB_Users_DGs, AL_FAB_Contacts, and AL_TAIL_Contacts.

For detailed syntax and parameter information, see New-AddressList.

To learn more about creating address lists by using recipient filters, see Create an Address List By Using Recipient Filters.

Create the room lists

This scenario requires three room lists:

• AL_FAB_Rooms

• AL_TAIL_Rooms

• Default All Rooms (created by default)

ABPs must contain a room list. If your organization doesn't have resource mailboxes (such as room or equipment mailboxes), we recommend that you create a blank room list. The following example creates the blank room list AL_BlankRoom.

New-AddressList -Name AL_BlankRoom -RecipientFilter ((Alias -ne $null) -and ((RecipientDisplayType -eq 'ConferenceRoomMailbox') -or (RecipientDisplayType -eq 'SyncedConferenceRoomMailbox')))

However, in this scenario, Fabrikam and Tailspin Toys both have room mailboxes. This example creates the room list for Tailspin Toys by using a recipient filter where CustomAttribute15 equals TAIL.

New-AddressList -Name AL_TAIL_Rooms -RecipientFilter {(Alias -ne $null) -and (CustomAttribute15 -eq "TAIL")-and (RecipientDisplayType -eq 'ConferenceRoomMailbox') -or (RecipientDisplayType -eq 'SyncedConferenceRoomMailbox')}

The above command would then be run to create the room list for Fabrikam (AL_FAB_Rooms).

For detailed syntax and parameter information, see New-AddressList.

Create the GALs

This scenario requires three GALs:

• GAL_FAB

• GAL_TAIL

• Default GAL (created by default)

The GAL used in an ABP must be a superset of the address lists. Don’t create a GAL with fewer objects than exists in any or all of the address lists in the ABP.

This example creates the GAL for Tailspin Toys. It includes all the recipients that exist in the address lists and room list.

New-GlobalAddressList -Name "GAL_TAIL" -RecipientFilter {(CustomAttribute15 -eq "TAIL")}

The above command would then be run to create the GAL for Fabrikam (GAL_FAB).

For detailed syntax and parameter information, see New-GlobalAddressList.

Create the OABs

This scenario requires three GALs:

• OAB_FAB

• OAB_TAIL

• Default OAB (created by default)

When using the New-OfflineAddressBook or Set-OfflineAddressBook to create the OAB, include the appropriate address lists or GAL in the AddressLists parameter to make sure no entry is unexpectedly missed. For example, if you want to customize the set of lists a user will see when viewing the OAB, or if you simply want to reduce the OAB’s download size, you can use the AddressLists parameter to specify the address lists available to the OAB. However, if you want users to see the full set of GAL entries in OAB, make sure you include the GAL in the AddressLists parameter.

This example creates the OAB for Tailspin Toys. The entire GAL (GAL_TAIL) is included in the OAB..

New-OfflineAddressBook -Name "OAB_TAIL" -AddressLists "GAL_TAIL"

The above command would then be run to create the OAB for Fabrikam (OAB_FAB).

For detailed syntax and parameter information, see New-OfflineAddressBook.

Step 3: Create the ABPs

After all the required lists are created, you can create the ABPs.

This example creates the ABP for Tailspin Toys.

New-AddressBookPolicy -Name "ABP_TAIL" -AddressLists "AL_TAIL_Users_DGs","AL_TAIL_Contacts" -OfflineAddressBook "\OAB_TAIL" -GlobalAddressList "\GAL_TAIL" -RoomList "\AL_TAIL_Rooms"

The above command would then be run to create the ABPs for Fabrikam (ABP_FAB) and the organization’s CEO (ABP_CEO).

For detailed syntax and parameter information, see New-AddressBookPolicy.

Step 4: Assign the ABPs to mailboxes

Assigning the ABPs to users is the last step in the process. ABPs take effect when a user's application connects to the Microsoft Exchange Address Book service on the Client Access server. Users who are already connected to Outlook or Outlook Web App when the ABP is applied to their account will have to close and then restart the client application before they can see their new address lists and GAL.

This example assigns the address book policy ABP_TAIL to all mailboxes where CustomAttribute15 equals TAIL.

Get-Mailbox -resultsize unlimited | where {$_.CustomAttribute15 -eq "TAIL"}| Set-Mailbox -AddressBookPolicy "ABP_TAIL"

For more details, see Assign an Address Book Policy to a Mail User.

 © 2010 Microsoft Corporation. All rights reserved.