Why Separate Users in the First Place?

Microsoft 365 has many controls built-in to manage how users communicate externally, however, these controls do not generally extend to internal communication. While this is fine in most environments, situations exist where a degree of separation is required.

For example, a university wants to stop students communicating with facility members, or an organization with multiple subsidiaries wants to restrict employees from communicating with other subsidiaries.  One option is to run multiple tenants, however, that introduces extra complexity and administrative effort. Often, a better solution is to create and use Exchange Online Address Book policies.

Address Book Policies

Address Book Policies (ABPs) aren’t new to Exchange Online. They exist to provide separation by grouping users into “Virtual Organizations,” each with their own Address Lists, Global Address List (GAL), Room Lists, and Offline Address Book (OAB). This is different from a Hierarchical Address Book which imposes a structure on address lists but does not enforce segregation. ABPs can also be extended to Microsoft Teams to scope directory search – with some caveats.

In this article, I detail the configuration of Address Book Policies, and how they can be extended to include Teams.

Configure Address Lists

Before creating any ABPs, you must define the objects that the policies will manage. Each ABP needs a minimum of one GAL, one OAB, one address list, and one room list. To create two ABPs, at least two of each component will be needed, scoped to the sets of users you want to separate.

In the PowerShell example below, I created each component based on the company users belonging to (Contoso or Fabrikam) from their Azure AD account. You can also create additional address lists for things like Distribution Lists based on the code:

##Create two GALs
New-GlobalAddressList -Name "Contoso GAL" -IncludedRecipients AllRecipients -ConditionalCompany Contoso
New-GlobalAddressList -Name "Fabrikam GAL" -IncludedRecipients AllRecipients -ConditionalCompany Fabrikam

##Create two Address Lists
New-AddressList -Name "Contoso" -IncludedRecipients MailboxUsers -ConditionalCompany Contoso
New-AddressList -Name "Fabrikam" -IncludedRecipients MailboxUsers -ConditionalCompany "Fabrikam"

##Create two Room Lists
New-AddressList -Name "Contoso Rooms" -RecipientFilter {(Company -eq "Contoso")-and (RecipientDisplayType -eq 'ConferenceRoomMailbox')}
New-AddressList -Name "Fabrikam Rooms" -RecipientFilter {(Company -eq "Fabrikam")-and (RecipientDisplayType -eq 'ConferenceRoomMailbox')}

##Create two OABs
New-OfflineAddressBook -Name "OAB_Contoso" -AddressLists "\Contoso", "\Contoso Rooms"
New-OfflineAddressBook -Name "OAB_Fabrikam" -AddressLists "\Fabrikam", "\Fabrikam Rooms"

Note: To manage Address Lists your account must be assigned the “Address Lists” role in Exchange Online – this role is not part of the Organization Management role group.

Create Address Book Policies

To create ABPs, enable “Address Book Policy Routing” in your Exchange Online transport configuration. This enables the ABP functionality in the tenant by running the Set-TransportConfig cmdlet to set AddressBookPolicyRouting to True. The effect is to instruct the Exchange transport service to regard users in different GALs to appear as external recipients to each other, which means that functionality like tagging external recipients works:

Set-TransportConfig -AddressBookPolicyRoutingEnabled $true

Finally, use the New-AddressBookPolicy cmdlet to create the ABPs. In the example below, I create two ABPs based on the objects created earlier for Contoso and Fabrikam:

##Create two ABPs
New-AddressBookPolicy -Name "Contoso" -AddressLists "\Contoso" -OfflineAddressBook "\OAB_Contoso" -GlobalAddressList "\Contoso GAL" -RoomList "\Contoso Rooms"
New-AddressBookPolicy -Name "Fabrikam" -AddressLists "\Fabrikam" -OfflineAddressBook "\OAB_Fabrikam" -GlobalAddressList "\Fabrikam GAL" -RoomList "\Fabrikam Rooms" 

Once created, the policies can be verified using the Get-AddressBookPolicy cmdletas shown below in Figure 1:

Separating users in Office 365 using Address Book Policies
Figure 1: Creating and viewing two ABPs.

Assign the Policies to Users

ABPs can be assigned to individual mailboxes in the Exchange Admin Center. At scale when assignment is needed for hundreds of mailboxes, that’s not practical. It’s much quicker to set the policy using the Set-Mailbox cmdlet.

For example, below I find all user mailboxes with the correct company attribute and add them to the relevant ABP. The nice thing about this method is that it can be scheduled so that new users are added to the correct ABP as part of a nightly job. How you assign the policy is unimportant. What is important is to assign the right ABP to the right mailboxes.

##Assign ABP to users
Get-Recipient -Filter '(Company -eq "Contoso") -and (recipienttypedetails -eq "usermailbox")' | Set-Mailbox -AddressBookPolicy Contoso
Get-Recipient -Filter '(Company -eq "Fabrikam") -and (recipienttypedetails -eq "usermailbox")' | Set-Mailbox -AddressBookPolicy Fabrikam

Read more: “Right to Disconnect” – Implementing a Timed Disclaimer in Exchange Online with Azure Automation

With the policy applied, users now only see the address lists and members defined by the policy assigned to their mailbox, as shown below in Figure 2:

Separating users in Office 365 using Address Book Policies
Figure 2: Users assigned an address book policy will only see their own lists.

Managing Exceptions

There can be times when a user needs to see the members of multiple address lists from different policies. There is no way to bypass the assigned address book policy for a user, so a new policy is needed. This policy should contain the address lists for everyone that the user needs to contact.

For example, if Contoso and Fabrikam share a CEO, they would need visibility to all staff, regardless of the company. A new policy can be created as shown in the example below to allow the CEO to see all address lists:

##Create “All Staff” ABP
New-AddressBookPolicy -Name "All Staff Visible" -AddressLists "\Fabrikam", "\Contoso" -OfflineAddressBook "\Default OAB” -GlobalAddressList "\All Users GAL" -RoomList "\All Rooms" 

In this example, a single additional ABP can be used but catering for every use case and combination of users can become difficult to manage so it’s best to keep things simple.

Using ABPs in Teams

ABPs can be extended to Microsoft Teams by enabling the option to “Scope directory search using an Exchange address book policy” from the Teams Settings section of the Teams Admin Center as shown in Figure 3:

Separating users in Office 365 using Address Book Policies
Figure 3: Extend ABPs to Teams from the TAC.

With this setting enabled, users who search in Teams see results limited by their assigned ABP as shown in Figure 4:

Separating users in Office 365 using Address Book Policies
Figure 4: Users in different ABPs no longer shown up in Teams results.

There are some side effects to be aware of when enabling scoped directory search in Teams, so it’s important to keep this in consideration before you decide to enable it.

Information Barriers

Information Barriers (IBs) are like APBs because they are also designed to provide internal separation. The difference is that IBs also prevent collaboration entirely for SharePoint, OneDrive, and Teams. IBs replace ABPs in the tenant so they cannot be used while there are any ABPs still in the environment. When IBs are provisioned and segments are assigned, users will be scoped to the segments they are assigned to.

Note: IBs require a minimum of Office 365 E5 licensing or Office 365 A1/A3/A5 licensing

Read more: How to Generate an Office 365 Licensing Report Using the Microsoft Graph SDK for PowerShell

When to use ABPs

Before deciding to deploy ABPs, there are some considerations to be aware of:

  • Replication of changes will not be instant; it will take a few hours to update a policy change and even longer if the user is using cached mode in Outlook
  • Information Barriers can’t be used if you have ABPs in place. Removal of ABPs in preparation for Information Barriers requires some effort to remove the policies from all users (Including inactive mailboxes)
  • ABPs do not prevent emails (neither do IBs) or Teams messages from being sent
  • Extending ABPs to Teams impacts Team discovery
  • A large amount of ABPs can become complex to manage
  • ABPs will not prevent users from viewing others through the other Office 365 apps (except for Teams if scoped directory search is enabled)

In Summary

For most tenants, ABPs are not needed and will only complicate management of the environment. But if you’re in a situation where you need to segregate communication across different groups of users, ABPs can be extremely helpful.

About the Author

Sean McAvinue

Sean McAvinue is a Microsoft MVP in Office Development and has been working with Microsoft Technologies for more than 10 years. As Modern Workplace Practice Lead at Ergo Group, he helps customers with planning, deploying and maximizing the many benefits of Microsoft 365 with a focus on security and automation. With a passion for creative problem solving, he enjoys developing solutions for business requirements by leveraging new technologies or by extending the built-in functionality with automation. Blogs frequently at https://seanmcavinue.net and loves sharing and collaborating with the community. To reach out to Sean, you can find him on Twitter at @sean_mcavinue

Comments

  1. Nick tsemoni

    How do you get to the command line for Office 365, I want to separate to GAL. Is they a way to do it from Exchange Admin Center?

    I cannot install the cmd line.

  2. Rok

    Hi Sean, thanks for this. Much appreciated. Question: Does when performing a Team search for other Team members, does Teams leverage the GAL (Global Address List) or does it use AzureAD to perform those look ups?

    1. Sean McAvinue

      Hi Rok,
      This is managed by configuring the Scope directory search using Exchange ABP option

Leave a Reply