Update 10/3/2014: This article was updated to include new defaults/limits information for Office 365 for Enterprise.
Since we added the Address Book Policy feature in Exchange Server 2010 Service Pack 2, one of the questions I frequently hear (related to ABP’s that is) is, “when are you adding ABP’s to Office 365?”
Well dear reader, the quick answer is, as we deploy our next round of feature upgrades to Office 365, and more specifically to Exchange Online!
There are few things to be aware of however, which is the reason for this post, but before we lose anyone who is not on Office 365, let me say that it’s not only a good thing for our Office 365 customers, it’s also good for those of you with Exchange on-Premises who are using ABP’s as we’re adding a new feature to better control what users experience when sending and receiving mail. More on that later on.
So ABP’s and Office 365. The first thing to know is this feature is an Exchange Online only feature. Just so that’s clear.
The second thing to know is that the ABP features are only available to customers with Office 365 for Enterprise (‘E’ plans) and Education (‘A’ plans). We are not making ABPs available to small business (P Plan).
The third thing that happens when we add support for this feature to Office 365 is that it allows you to create custom additional Address Lists (ALs), Global Address Lists (GALs), Offline Address Books (OABs), as well as ABPs within your tenant. So even if you don’t use ABPs, you can add additional custom Address Lists to your tenant if you so choose.
For example, you could create an Address List containing all the users with mailboxes in Chicago, and have Outlook and Outlook Web App (OWA) show that additional Address List. You don’t need ABPs, just the smarts to create a new Address List (we still recommend using custom attributes for filtering as they are consistent on all the mail enabled objects).
The fourth thing, and wow, these things just keep coming don’t they, is that we are creating a limit to the number of ABPs and OABs you can create by default. Why? Well, these things all consume resources and when you are a tenant on a multi-tenant shared platform you have to ensure one tenant doesn’t consume all the available resources. One way of doing that is by restricting the number of objects or actions one tenant can take.
And the last thing you need to know is that the Address Lists RBAC role is not assigned to anyone out of the gate. Why? To avoid the creation of Address Lists, GAL’s and OAB’s for fun (we are running a service the number of objects is important after all). So, if you want to create Address Lists, GAL’s, OAB’s and ABP’s, you’ll first need to assign the Address Lists RBAC role to someone. You can do that either using PowerShell or the EAC, your choice.
So that’s ABPs in Exchange Online. I’ll add that it’s all command line configuration; there’s no Exchange Administration Center UI for it, and there’s no AutoMagic directory/config sync between on-premises and the cloud. Though it’s pretty simple to re-use the commands you used for creating ALs, GALs etc. in on-premises, and just to re-run those same commands in the cloud to get the same results.
Transport and ABPs
Ok, now that really is all I have to say about ABPs in Exchange Online. Except for yet one more thing, and this is the bit that will also interest some on-premises customers, particularly those selling or providing a multi-tenant like offering to their company or customers.
We have built a transport agent into Exchange that respects ABPs. Now I don’t mean respect as in “whoa, Mr. ABP dude, you rock and I bow down to your greatness”, no, I do not, as that would be ridiculous and anyone who even came up with a pathetic attempt at humour like that should be kicked swiftly in the OABs. I mean respect. R. E. S. P. E. C. T., find out what email can do for me.
Let us break from song by understanding the issue.
Well, take the case where you and I share different ABPs, we cannot see each other in the GAL, and yet we decide to Exchange email. Perhaps we didn’t know we were even on the same email system. We went for a beer one day, or perhaps a juice if you don’t drink beer (as an aside, one day when my daughter, 5 years old at the time, was upset as her brother was getting taken for a Jamba juice but she wasn’t. I told her they made Jamba juice by squeezing a small creature called a Jamba really hard to get the juice out, and that it takes a lot of fluffy cutesy little Jamba bunnies to make a 32oz super Aloha Pineapple Smoothie – suffice to say, no longer do we have an envy problem when her brother gets taken for a juice…why tell you this story? Well, it’s Valentine’s Day today and who doesn’t love a story about squeezing bunnies or suchlike on such an occasion?) and we decided to chat over email. You emailed me. When it arrived, in Outlook I saw a fully resolved Exchange object with your name next to it. Heck, I could even see your phone number. And job title. And office. I can’t see DL memberships or any of that, ABPs do take care of that, but I can see more than I should. Here’s an example of a mail sent from someone outside Chris Contoso’s ABP, but on the same Exchange system.
Why is that? Because to Exchange we’re both just users in the same organization, and so as the mail was internal (at least to Exchange) it promotes/resolves the sender and recipient to fully resolved Exchange objects – i.e. it matches you to your GAL entry. Now OWA does the same, or rather, Exchange does the same, and OWA displays you as a fully resolved Exchange object, but the ABP code in 2010 prevented you, as an OWA user, from seeing more details than you should. Outlook didn’t work quite the same as you just saw.
Why is all this an issue? Well, it’s potentially a data loss issue, if the two users discover more information from the GAL than they should.
Now the way we suggested people solve this in 2010 was to write a transport agent, to send mail out and back in when certain conditions are detected – which makes the message appear to originate from the Internet, which means not internal, which in turns means, respect. Getting your due respect in this case meant developing or buying an agent, and, and this is the kicker, there were cases even an agent couldn’t solve – if you cc someone else internal to the Org on the mail for example. The bottom line was, the way the messages were processed inside Exchange, an agent developed externally, with a limited ability to interact with the message, could not get at it early enough. We needed to do this. We needed to teach Exchange respect.
The diagram above tries to convey the same concept in an easy to understand manner, recipients get to see different copies of the same message, with recipients resolved according to their ABP. This example is based upon the ABP guidance (Joint CEO Example), documented here. From that guidance you’ll also know that GALs can be a subset or a superset of each other depending upon how the filters are defined. The new agent doesn’t worry about that though, it simply groups by ABP, and then resolves each copy based upon the GAL associated with that ABP, so each copy is always correctly resolved.
This is good all round I’m sure you’ll agree. Particularly in the cloud for the large number of educational customers we have – if students start emailing each other (as kids do, when not IM’ing, texting, facepoking, checking four squares or whatever it is these days) then they don’t get resolved to directory objects, even when inside the same tenant, as long as their GALs are scoped correctly. There are a few ways to plan for EDU Office 365 for Education customers with large numbers of schools/GALs but that’s a post for somewhere else.
Enabling this stuff
So the natural way to wrap this up is to explain how you can get the respect you want, you deserve and you need.
So to enable this new found respect in Office 365 you do one thing:
Set-TransportConfig –AddressBookPolicyRoutingEnabled $True
It takes up to 30 minutes to kick in as we cache that setting for performance reasons.
For our on-premises customers we will ship the agent in Cumulative Update 1 for Exchange Server 2013. You need to install and enable it.
- Firstly you install it using this easy to remember PowerShell one-liner (this example is copy and paste fodder (note the word breaks) assuming you have Exchange installed at c:\rossisagod);
Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBook
PolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory" -AssemblyPath "C:\rossisagod\Exchange Server\V15\TransportRoles\agents\AddressBookPolicyRoutingAgent\
- Enable the ABP routing agent:
Enable-TransportAgent "ABP Routing Agent"
- Restart the Transport Service.
- Run the following cmdlet to enable ABP routing:
Set-TransportConfig –AddressBookPolicyRoutingEnabled $True
- You are finished. Off to the races we go.
So there we go, another odd ball blog post to explain a tiny corner of the product that only some of you care about. But if you do care, and you read this far, thank you, and remember, the Jamba has feelings too, so squeeze it fast so it doesn’t suffer too much.
Principal Program Manager Lead
Exchange Customer Experience