Making Exchange Recipient Policies some what scaleable in the hosted environment

Yesterday I ran a piece of automation on our AD that redesigned how we store Exchange RPs. 

An issue (there are MANY) with using exchange in the hosted environment is limits of the number of Recipient Policies that can exist in the AD.  In theory there is not a limit to the number of RP objects that can exist.  But for performance reasons there is a default limit of 1000.  Any query that returns more then 1000 results (by default is considered inefficient (  A query that has too many results may return a LDAP_SIZE_LIMIT_EXCEEDED error.

So when you are a hoster and have about 9,546 domains hosts on your system how do you search through them?

What we did to work around this issue is take advantage of the fact that you can up to 800 entries in the gatewayProxy attribute.   The AD has a limit of 800 entries in a multi-valued attribute.

First let me know if you want any of the code that I created to do this work let me know I will send it to you.

We created RPs (recipient policies) based of the domain name that is to be hosted.  The RP name is generated on the following logic:

  • extensions are removed from domain name for RP logic
  • first two letters of the domain name
  • Allow char in the first position are [a-z0-9] (not counting brackets)
  • Allow char in the second position are [a-z0-9-] (not counting brackets)
  • If domain is 1 char long then create RP that is that single char
  • if second char is not a-z or 0-9 (i.e. a Dash) then create RP on single char

What this allows is if I want to add to my hosting environment it will go into RP 'do'.  If I want to add it will go in RP 'd'.

This logic will allow for up to 1332 Recipient policies.  While that number is above our 1000 limit there are very high odds that RPs like qs or qf or qp or zc or zy will not be created. 

Each RP allows for 799 domains (the x400 address takes up one value).  So you can have 800 domains that begin with do and 800 that begin with dp.  While this is not the perfect solution it allows the hosting to grow to a fairly large limit (if each RP is full 1,064,268 domains). 

A domain can exist in more then one RP.  Each RP must have a Primary SMTP address.  All other addresses are not primary (entered as lowercase smtp).

From an automation stand point.  When it comes time to cleanup a domain from your system (i.e. the owner does not want it hosted any longer) you do not have to search through all your AD to find which RP it is in.  You can call the function that generated the RP name in the first place to tell you exactly which RP it will be in.  This will lower the time/performance hit in your AD and automation.

The end result will look like this


Note:  I am not an Exchange person, I just know enough to get myself in trouble.  If you find something wrong with my statements please let me know).