Many Exchange deployments will be quite happy with the default GAL, by which every mail-enabled object in the organization is visible to every user. However, situations do arise when companies want to compartmentalize the GAL so that different users see different sets of objects, even though everyone is part of a single organization. In effect, each set of objects represents a virtual organization.
Classically, the reason such segmentation arises is to allow a single Exchange organization to support multiple businesses or even complete companies, possibly managed by a hosting company that wanted to extract maximum advantage from a single infrastructure. Office 365 is an example of a massive shared infrastructure in which all the tenant companies are deployed across common servers, storage, and network. Each of the tenants is logically separated from the next by software boundaries, one of which is the view of the GAL created through address book policies (ABPs). The Office 365 deployment is unique, but it illustrates the problem ABPs seek to solve.
ABPs create a policy framework in which users are associated with a certain set of address lists that define the view they should have of the overall directory. Normally, users have access to a GAL and OAB and are unaware that the available objects have been restricted by policy. Historically, this setup is known as GAL segmentation because administrators segment the overall user population into sets that are identified by the queries that underpin ABPs. Each ABP consists of a GAL, an OAB, room lists, and one or more address lists. If you don’t use room lists, you can include an empty list to satisfy the requirement. After an ABP is created, it can be assigned to mailboxes. When assigned, the owners of those mailboxes are restricted to the views included in the ABP by the Client Access Server (CAS) to which they connect.
It’s important to realize that ABPs create a virtual view of the world that is easily circumscribed if users in the virtual organizations wish to communicate with one another. Just like when she wants to send mail to anyone else, all a user in one virtual organization needs to communicate with a user in a different virtual organization is that user’s SMTP email address. The presence of ABPs within the overarching organization does not prevent the different sets of users from communicating with one another. If it is a business requirement to prevent the different sets of users from sending email to one another, you must introduce a transport rule to look for messages sent from one virtual organization to another. This is not a perfect solution because users can still communicate with one another by sending email from something like a consumer email system.
ABPs were first introduced in Exchange 2010 SP2. For this reason, they only work for users who connect to Exchange 2010 SP3 or Exchange 2013 servers. In addition, you should not run CAS servers on global catalogs because this forces the CAS to access Active Directory directly rather than going through the address book service. Active Directory knows nothing about ABPs, so valid but undesired results are returned for any address book lookups. Outlook for Mac 2011 uses Lightweight Directory Access Protocol (LDAP) queries to access Active Directory and encounters the same problem of inconsistent results if these clients connect to a CAS collocated on a domain controller or global catalog, all of which underscores the best practice that Exchange 2013 should never be installed on an Active Directory server. Another factor to consider is that hierarchical address books (HABs) do not coexist alongside ABPs; you can have one or the other feature but not both.
Finally, although you can create and manage the underlying address lists that form an ABP by using EAC, you cannot manage ABPs with EAC. ABPs have to be created and managed using EMS.
ABPs and groups
Groups are Active Directory objects, and as you already know, Active Directory knows nothing about ABPs. Therefore, if Active Directory is queried to discover the membership of a group, it will return the full membership without regard to any logical boundaries that an administrator seeks to establish through an ABP. For this reason, if you deploy ABPs, you should positively avoid creating distribution groups that contain members from different virtual organizations. If you do, you are likely to run into several problems, including the following:
- If a group member who belongs to a virtual organization sends a message to a group that contains members from multiple virtual organizations and requests a delivery or read receipt, he will receive notifications from Exchange that reveal the existence of the other virtual organizations.
- Exchange flags warnings when a user sends an encrypted message to groups that contain members who do not have valid digital IDs. The user will be told the number of group members who will have a problem seeing the encrypted message and the list of their addresses. However, the notification data is incorrect when a group spans organizational boundaries because not all recipient addresses will be shown. This might cause some confusion to users.
- The Get-Group cmdlet knows nothing about ABPs because it accesses Active Directory directly. Anyone who can run this cmdlet can therefore use it to expose the full membership of any cross-organization group.
- Outlook Web App enables users to maintain the groups they own and the membership of those groups. However, Outlook Web App does not include the filters that ABPs use to restrict access to Active Directory to create the virtual organizations. It is therefore best to modify the default RBAC management role for users to exclude access to the MyDistributionGroupMembership role because Outlook Web App requires group owners to have full visibility of the complete membership of a group.
None of these issues is particularly important, and all can be managed with a little forethought and planning. However, they do illustrate that the deployment of ABPs is not simple because both the underlying technology (Active Directory) and some parts of Exchange remain unaware of object segmentation. With this in mind, explore how to create a new ABP and what this means to users.
Creating and implementing an ABP
Before creating an ABP, understand the business requirement that is forcing the establishment of a new policy. Sometimes, as in the case of a hosted scenario, the requirement is obvious because you would not want to allow users belonging to one virtual organization to be aware of anyone else sharing the same Exchange infrastructure. In other situations, the business requirement is not so obvious and perhaps arises only in unusual circumstances. For example, assume that a company is preparing to sell off part of its business and wants to begin the process of separating the IT infrastructure during the period when it seeks regulatory approval for the sale. In this situation, it might be a good idea to move the users who belong to the soon-to-be-sold business into a virtual Exchange organization so that when the break happens, users won’t see any difference in the view they have of the GAL.
To illustrate what needs to be done, assume that Contoso seeks to sell its Irish subsidiary to another company. Accepting that many other things need to be done to isolate and break off the IT components that might serve the users in the affected subsidiary, here’s what you could do to create an ABP that provides the Irish users with a GAL that contains only Irish users and the rest of Contoso with a GAL that includes everyone but the Irish users.
First, create some address lists. These can be done through EAC or with EMS. Three address lists are required for the Contoso Ireland subsidiary:
- Contoso-Ireland-Users: Contains all the users and distribution groups belonging to Contoso Ireland
- Contoso-Ireland-Rooms: Contains all the resource mailboxes belonging to Contoso Ireland
- Contoso-Ireland-Contacts: Contains all the mail-enabled contacts belonging to Contoso Ireland
Now you must decide how to isolate the Contoso Ireland objects from the general directory. Many companies include country or office codes in the data held in Active Directory for users and other objects. If this data is consistent and accurate, it can certainly be used to identify the objects that belong to the Irish subsidiary. You will need to review and probably update records to ensure a high degree of accuracy.
Depending on the size of your organization and the split in responsibilities that exists between Exchange and Active Directory, you might also have to decide whether to rely on basic Active Directory attributes or those that are specific to Exchange. For example, the Office or StateOrProvince attributes seem to be good candidates by which to isolate Irish users, but these are basic Active Directory attributes that are manipulated with the Set-User cmdlet rather than with the Set-Mailbox cmdlet. If Active Directory management is not the responsibility of the Exchange administrators, it might be better to rely on attributes that can be changed with Set-Mailbox, just in case an update performed with Set-User might affect some other process such as account provisioning and maintenance.
For the purposes of this example, you select CustomAttribute8, one of the 15 custom attributes Exchange supports, but you will perform an initial population of the attribute by scanning Active Directory to identify likely Irish users. For example, this code scans for a certain code in the Office attribute of user accounts and updates their mailboxes with ‘Ireland’ in the chosen attribute:
Get-Mailbox –Filter {'Office' –eq 'DBO'} | Set-Mailbox –CustomAttribute8 'Ireland'
You probably won’t pick up every record that should be included in the set the first time around, but this will certainly be sufficient to begin the process. It is a simple matter to generate a report of the mailboxes that are marked with the custom attribute at any time to validate against other sources of information such as human resource lists. It’s also important to remember that the accuracy of address lists depends on the underlying data. If you fail to ensure that the properties for new mailboxes are not set correctly, it’s likely that users will start to see people who should not appear in the GAL.
Your first address list required by the ABP is created in EMS as follows:
New-AddressList -Name "Contoso-Ireland-Users" -RecipientFilter {((RecipientType -eq 'UserMailbox') -or (RecipientType -eq "MailUniversalDistributionGroup") -or (RecipientType -eq "DynamicDistributionGroup")) -and (CustomAttribute8 -eq "Ireland")} –DisplayName 'Contoso Ireland Users'
This command is far too much bother to type for the other address lists, so you can revert to EAC to create the other address lists. Open the Organization section of EAC, select address lists, and then choose New (+). Figure 1 shows the information you need to enter to create the new rooms address list. You can see that a rule has been added to restrict the selected resource mailboxes to those that have the required value in CustomAttribute8. The same steps can be taken to create the Contoso-Ireland-Contacts address list, except that in this case, the chosen recipient type will be mail contacts with external email addresses.
Figure 1. Creating a new address list
If you are in any doubt about the effectiveness of the filter used for an address list, you can use the same technique as explained earlier for dynamic groups to test the results Exchange generates when the filter is put into use. For example:
$Filter = (Get-AddressList –Identity "Contoso-Ireland-Users").RecipientFilter Get-Recipient –RecipientPreviewFilter $Filter
Alternatively, as explained in the section covering address lists, you can just open the address list with EAC and use its preview facility. Perhaps this is another example of when real administrators use EMS and those who couldn’t be bothered with complex commands use EAC!
After you are satisfied with the results generated by the address lists, you can proceed to the next step, which is to create a GAL for use by Contoso Ireland. This has to be a superset of the address lists that effectively combine to form the GAL, so you can create a suitable list by stating a filter that looks for any object with Ireland in CustomAttribute8. You cannot create a new GAL with EAC, so here’s the EMS command:
New-GlobalAddressList 'Contoso Ireland GAL' –RecipientFilter {(CustomAttribute8 –eq 'Ireland')}
The general rule is that after you create a GAL, you should also create an OAB to enable offline clients to access the address lists, so you now create an OAB for Contoso Ireland:
New-OfflineAddressBook 'Contoso Ireland OAB' –AddressLists 'Contoso Ireland GAL'
You can then generate the new OAB files so that clients can download the OAB with:
Update-OfflineAddressBook –Identity 'Contoso Ireland OAB'
All the necessary address list components are now available, but you have not yet made them available to users. To do this, create a new ABP that combines the address lists you have created in a form that can then be assigned to mailboxes. Again, this has to be done with EMS. You should see EMS respond as shown in Figure 2.
Figure 2. Creating a new address book policy
New-AddressBookPolicy -Name "Contoso Ireland ABP" -AddressLists "Contoso-Ireland-Users","Contoso-Ireland-Contacts" -OfflineAddressBook "\Contoso Ireland OAB" -GlobalAddressList "\Contoso Ireland GAL" -RoomList "\Contoso-Ireland-Rooms"
To assign the new ABP to the users in Contoso Ireland, use Get-Mailbox to fetch the full collection of mailboxes in the organization (you cannot perform a server-side filter using the custom attributes), check for any that are marked as belonging to Ireland, and then assign the new ABP:
Get-Mailbox -ResultSize Unlimited | Where-Object {$_.CustomAttribute8 -eq 'Ireland'} | Set-Mailbox -AddressBookPolicy 'Contoso Ireland ABP'
Mailboxes that are not assigned the new ABP will continue to use the default ABP (shown as blank), default OAB, and so on. Those users will continue to see the Contoso Ireland users listed in the GAL. In fact, they can also see the new address lists you have created for the Contoso Ireland ABP because they appear under Other Address Lists (Figure 3), which then reveals that these entities exist. The Exchange logic is impeccable. The other users are not under the control of any ABP, so by definition, they enjoy access to any address list within the organization.
Figure 3. The Contoso Ireland address lists available to other users
If this is not the situation you want to exist, you have to create a set of address lists, GAL, and OAB that exclude the Contoso Ireland objects to form another ABP and then assign that ABP to the other users. In effect, every user in the organization should be assigned an ABP that specifically limits her to a certain set of address lists that does not include the default address lists (such as All Users).
If you need to remove a user from a virtual organization, you should update his mailbox to point to a different ABP (or null to use the default) and remove whatever value is driving his membership in the virtual organization. You should also update the GAL and OAB for the virtual organization so that the user disappears from sight. For example:
Set-Mailbox –Identity 'Tony Redmond' –AddressBookPolicy $Null –CustomAttribute8 $Null –OfflineAddressBook $Null Update-GlobalAddressList 'Contoso Ireland GAL' Update-OfflineAddressBook –Identity 'Contoso Ireland OAB'
To check that the ABP has been assigned correctly, you can run another Get-Mailbox command, using the original filter based on the value of the users’ Office attribute and see whether the correct values exist for ABP and CustomAttribute8. Sort the output so that it appears in the same order as the GAL. You should see something like the output shown in Figure 4 after running the following command:
Figure 4. Checking mailboxes to ensure that the new ABP has been assigned
Get-Mailbox –Filter {Office –eq "DBO"} | Sort-Object DisplayName | Format-Table DisplayName, AddressBookPolicy, CustomAttribute8
The newly assigned ABP becomes effective the next time the user connects to the address book service running on a CAS. Outlook Web App sees the most immediate effect because this client usually works in online mode and is forced to connect to the address book service whenever the user browses the GAL. It is then easy to compare the results of the Get-Mailbox command previously described with the GAL shown to the user by Outlook Web App (Figure 5). Hopefully, the two sets match up to tell you that the ABP is in place and effective. The user should not be aware that an ABP now controls her ability to see directory information unless she notices that some people who had shown up in the GAL prior to the application of the policy are now missing. Outlook users who work in online mode will also see the new GAL immediately. Those who work in cached Exchange mode must download the new OAB before they can see the effect of the ABP.
Figure 5. Viewing the GAL with Outlook Web App after the ABP is applied
As with most things in IT, it is easier to apply an ABP to a new deployment than to attempt to retrofit a policy on an organization that has been operational for a while. ABPs are not perfect and do not stop users from seeing people in the other virtual organizations if, for instance, they never download an updated OAB or if those people are in their contacts, including the nicknames cache Outlook maintains. ABPs can also cause confusion if users are not educated (or informed by the help desk) about their consequences. For example, after an ABP is assigned to a mailbox, that mailbox loses the ability to send messages on behalf of another user if that user is not included in the address lists the ABP uses. This is logical but can be confusing for a user who doesn’t expect it to happen. (How can you send mail on behalf of someone else if she doesn’t belong to your virtual organization?)
