Some mysteries of Throttling Policy: Recipient Rate Limit
In this topic I would try to illustrate how the Recipient Rate limit works and where it is saved.
With more hybrid setups which are coming up these days we would certainly want seamless experience in both On-prem Servers and the O365
servers.
We did get a requirement stating that we need to have few users who would be migrating to cloud have the same recipient rate limit as in
cloud.
Creating the recipient rate limit:
Where does the throttling policy get saved?
The throttling policy gets saved in the AD under the following location
CN=Global Settings,CN=EMAIL,CN=MicrosoftExchange,CN=Services,CN=Configuration,DC=Contoso,DC=com
Where does the recipient rate limit gets stored on the policy?
Lets check where is 10 which we had specified on the New-throttlingpolicy
Now we need to add the users to throttling policy. We can run the set-mailbox to do so. In the below example I am adding
test_50 user to throttling policy mstest which we had created earlier.
We can add this by running set-mailbox test_50 -throttlingpolicy mstest.
We can check if the throttlingpolicy has been applied to the user mailbox by running
get-mailbox test_50 | fl throttlingpolicy
Now what does this mean? This means that after the 10th email what happens? Let us see the end users screen.
This means that the user can send emails to 10 recipient and as soon as the user adds the 11th recipient or more
you would see the error stating “Thismessage can’t be send. You’ve reached the limit of the number messages that can
be sent in a 24-hour period”.
Two conditions when the mailbox can again send another set of the messages.
1.
If the 24 hours have been completed.
2.
If we go ahead and restart the throttling
service on the mailbox server where the mailbox is located.
How does this work actually?
Before we start to know how it works let us talk some terms which would be used in the workflow:
Token: The token is the number of recipients which has been already processed.
Token Bucket Map: This is table where the guids of the mailbox are kept, this is obtained during the Start of Throttling service.
When the Service starts it maintains the Token Bucket Map in the memory. If the user has never logged in then there is nothing in the Bucket map so throttling
service would add this as a new table in the Bucket Map.
When the User Submits the mail, then the throttling service checks the Bucket Map with a request called Obtain token.
If the below condition is true, then the mail would be submitted or else it would stuck.
Obtain Token + Token bucket map <= Recipientratelimit
Let’s do the calculation why we are not ble to send an email.
Recipientratelimit=10
First email was sent with 6 recipients, so the Token Bucket map would be 6.
The email which failed to be sent has 7 recipients, so the Obtain Token count would be 7.
Let us do the above calculation
6+7 =13 > 10 hence the mail can’t be sent.
A special thanks to Escalation Engineer Shashi to look into the Code and help me understand the concept of the
throttling policy.
Naveen Vasudevan