Address Book Policies, Jamba Jokes and Secret Agents

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.

The default for Office 365 for Enterprise customers is to allow 250 GALs, 250 OABs, 250 ABPs and 1000 ALs.

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.

Note: The Update-AddressList and Update-GlobalAddressList cmdlets are not available in Exchange Online, so if you create Address Lists or GAL’s after creating users the users may not show up. There are two ways to solve this for now; you can create the Address Lists and GAL’s before the users if you have not yet created the users, or if you have already created the users/mailboxes and then create the Address Lists/GAL’s you need to ‘tickle’ the users to have them appear in the lists. You can do this by, for example, re-setting a property on a mailbox. If CustomAttribute1 is being used for your segmentation, reset CustomAttribute1 to the same value you set before creating the Address Lists/GAL’s. That action, using Set-Mailbox will tickle the user a little and make sure their Address List/GAL membership is updated.

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.

Figure 1: The chief bottle officer

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.

So what we have done is create an agent, which when enabled, and I’m explaining this at a very high level, examines each message submitted by a user, and looks up the ABPs of any recipients it finds, and buckets or groups the message by ABP, and then performs recipient resolution on them using the GAL specified within the ABP, not the entire directory, before it delivers the message.

Figure 2: Address Book Policies at work


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.

  1. 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\

  2. Enable the ABP routing agent:

    Enable-TransportAgent "ABP Routing Agent"

  3. Restart the Transport Service.
  4. Run the following cmdlet to enable ABP routing:

    Set-TransportConfig –AddressBookPolicyRoutingEnabled $True

  5. 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.

Greg Taylor
Principal Program Manager Lead
Exchange Customer Experience

Comments (30)
  1. Casey4 says:

    Fantastic update regarding native Transport Agent.  Any chance it will be backported to 2010?

  2. @Casey – No plans to backport this feature.

  3. Casey4 says:

    Thanks Ross – all the more reason to move toward 2013 for our next multi tenant install.  Now if only we had some guidance docs :)

  4. Greg Taylor [msft] says:

    Soon Casey. Soon.

  5. Sunder says:

    Very Nice. Any update on how it will work in a Mixed Mode scenario…

    Exchange 2010 with ABP…Do I have to upgrade them to 2013?

  6. Greg Taylor [msft] says:

    Yes Sunder. Only when transport is 2013 and the mailbox is on 2013 will the addresses be resolved correctly, according to ABP.

  7. DJ Grijalva says:

    Currently with Exchange 2010 the content conversion decision is made before we can reroute the message for different “tenants” inside the same Exchange org.  When we route the message out a connector when two tenants are emailing back-and-forth  it is in winmail.dat (RTF) format.  With the newly created E2013 Cu1 agent when a message is sent outside of an ABP, does it go into content conversion as a RTF message or is it turned into a "Internet Message"?

  8. Greg Taylor [msft] says:

    DJ, the agent removes the need to re-route the message. The format of the message does not change, it's an internal message, just with recipient information modified.

  9. Michael Frank says:

    Thanks for the info Greg. We use a transport agent to route the mail between tenants back out so it can be filtered and have any rules applied that run on our smarthost and inbound servers. This new agent will hopefully allow us to reduce the complexity of the logic in our routing agent in deciding what messages need to be routed back out since they are inter-tenant. One minor issue that we run into with this is when we're onboarding a new tenant, once their users are created. At that point the transport agent is routing mail out to the internet but the recipients are being resolved as local and no content conversion is being applied and this happens in the transport stack before out agent can grab the message. It's a minor issue, but we had speculated that perhaps with this new agent that the message was being formatted as if it was intended for an internet recipient. Hope that makes sense. It's a tricky issue. Thanks again for the fast reply.

  10. Greg Taylor [msft] says:

    not sure I fully grasp what you mean by this "At that point the transport agent is routing mail out to the internet but the recipients are being resolved as local and no content conversion is being applied and this happens in the transport stack before out agent can grab the message.". The agent changes only the recipient resolution, either promoting receipients to full Exchange objects, or stripping them back to just smtp/display names – we don't fiddle or change anything else with regard to formatting. Might be easier to test it when you get it to see if it meets your needs. I hope it does.

  11. KelvinChiggs says:

    Does this then solve the OOF issue, as in will the external OOF be delivered between tenants?

  12. Greg Taylor [msft] says:

    No it does not.

  13. It's a good Fix. ! And I was waiting for it ! Now ABP is completely Stable i would say !!

  14. sam says:

    Will There be any Definitive Guidelines to address NSPI connections , Number of NSPI connections required per AB, OAB, ABquery etc… Are there any scaling guidlines , let's say If I want to host 1000 Tenant Domains.

  15. Arjen says:

    As a last wish; please make ABP OOF aware in CU 2… So external OOFs are delivered between tenants…

  16. Greg Taylor [msft] says:

    Sam – we tested up to 50k tenants with 2010. Are you seeing specific issues or is this just a theoretical question?

    Arjen – thanks for the feedback, and we considered it briefly for this, but it's a hard problem to solve and so didn't get to it yet. It will not be in CU2, so don't expect it. It may happen one day, but likely it may not. You can always use a trabsport rule to delete OOF's – I  know that deletes all OOF's, but that's the only suggestion I have for you right now.

  17. Mailtips? says:

    what happens with the mail tips? if I am addressing a guy who belongs to the other ABP?

  18. Greg Taylor [msft] says:

    This change has no impact on MailTips – MailTips still show if configured or triggered.

  19. Greg Taylor [msft] says:

    Hey Casey, the guidance you seek was just published…

  20. Shabarinath says:

    Hi Greg,

    I am glad that Exchange team hear the feedback and porting the product based on the feedback.  :)

    Do you have tentative timeline?



  21. Greg Taylor [msft] says:

    Timeline for what Shaba? CU1? Sure. Q1 2013.

  22. Hassan Latif says:

    I just installed exchange 2013 on windows server 2012. I am unable to install ABP Routing Agent. As soon as I run this command in EMS I get an error.

    Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory" -AssemblyPath $env:ExchangeInstallPathTransportRolesagentsAddressBookPolicyRoutingAgentMicrosoft.Exchagne.Transport.Agent.AddressBookPolicyRoutingAgent.dll

    The Transport Agent assembly file "C:Program FilesMicrosoftExchange ServerV15\TransportRolesagentsAddressBookPol

    icyRoutingAgentMicrosoft.Exchagne.Transport.Agent.AddressBookPolicyRoutingAgent.dll" doesn't exist.

    Parameter name: AssemblyPath

       + CategoryInfo          : InvalidArgument: (:) [Install-TransportAgent], ArgumentException

       + FullyQualifiedErrorId : 34326F6,Microsoft.Exchange.Management.AgentTasks.InstallTransportAgent

       + PSComputerName        :

    I explored C:Program FilesMicrosoftExchange ServerV15TransportRolesagents there's no directory named as AddressBookPolicyRoutingAgent and no such file. Is my exchange installation missing this file ? or I need to download this file from internet ?

  23. Greg Taylor [msft] says:

    That's because it ships as part of CU1 Hassan.

  24. Hafiz Hassan Latif says:

    When CU1 will be available ? Q1 is almost at its ending dates now or it's available for download ?

  25. christoph says:

    This functionality might be possible for 2007/2010 on-premises with the 3rd-Party-Agent messageconcept ExSBR for certain but not all scenarios. Unfortunately Exchange 2007/2010 might send out the messages in TNEF instead of *whatever configured for the remote domain*.

  26. riyaz says:

    We have a customer that is looking to leverage the new GAL segmentation feature in Office 365.  

    They want use Address Book Policies to segment users on-premises from Exchange Online users, the tenant would be in Office 365 for Education.  

    1.       Can this be done in a Hybrid deployment?

    2.       If so, does the Hybrid (on-premises) Server require being on Exchange 2013 or will it also work with a an Exchange 2010 server?

  27. Greg Taylor [msft] says:

    Riyaz, the two have nothing in common technically speaking – you have ABP's on prem, and you will have ABP's in Exchange Online – there is no sync or knowledge at either end of the other – so sure, you can do it in Hybrid, and with 2010 on-prem, but you will need to configure it at each end, independently.

  28. bill says:

    Unfortunately per Microsoft Office 365 Tech Support some of these things are not supported in Office 365 Enterprise accounts, even those accounts that have been completely upgraded to 2013. Specifically custom Address Lists are "not a supported feature." I haven't been able to get them to work and Office 365 Tech Support does "not have any resources to go back on if the directions online do not work for you." VERY frustrating because having a GAL with a 1000 entries and not being able to divide it up is a problem for us. Our goal was to move 10 offices into Office 365 by next year but now we may have to significantly scale back our plans.

  29. Greg Taylor [msft] says:

    Bill, can you try and describe more about what you are trying to do, and what you are doing to accomplish it, and what happens when you do?

  30. bill says:

    Thanks, Greg. I am trying to create custom address lists in our Office 365 Enterprise account. I can run the New-AddressList cmdlet to create the address list and the address list gets created. However there are no records in it even though there are some records that meet the criteria. As I understand it I need to run the Update-AddressList cmdlet in order for the custom address list to get populated. However when I run the Update-AddressList cmdlet I can an error message saying essentially that the Update-AddressList cmdlet is not recognized as a valid cmdlet. Make sense?

Comments are closed.

Skip to main content