Throttling in Exchange 2013

The way you control throttling changed in Exchange 2013.  If you recall, we set a different set of throttling attributes in Exchange 2010 when impersonating users.  Those attributes differ from user throttling attributes (this is a good thing for migrations!!) In Exchange 2010 there were seven throttling attributes.  In Exchange 2013, there are only TWO (again, we're focused on EWS impersonation access):

• EWSMaxConcurrency
• EWSMaxSubscriptions

To define a policy "SuThrottlingPolicy", and set it to your service account, "exsu", use the following:

 New-ThrottlingPolicy SuThrottlingPolicy -EWSMaxConcurrency $null -EWSMaxSubscriptions $null
 Set-ThrottlingPolicyAssociation -Identity exsu -ThrottlingPolicy SuThrottlingPolicy



For the inquiring minds, the following are set in Exchange 2010, but NOT used in Exchange 2013:

• EWSFastSearchTimeoutInSeconds
• EWSFindCountLimit
• EWSPercentTimeInAD
• EWSPercentTimeInCAS
• EWSPercentTimeInMailboxRPC

Here are the errors will you see in our log files if you hit the throttling limit (taken from MSDN:)

Error	Throttling policy parameter	Description
ErrorExceededConnectionCount	EWSMaxConcurrency	Indicates that there are more concurrent requests against the server than are allowed by a user's policy.
ErrorExceededSubscriptionCount	EWSMaxSubscriptions	Indicates that a user's throttling policy maximum subscription count has been exceeded.
ErrorExceededFindCountLimit	EWSFindCountLimit	Indicates that a search operation call has exceeded the total number of items that can be returned.
ErrorServerBusy	EWSPercentTimeInMailboxRPC EWSPercentTimeInCAS EWSPercentTimeInAD	Occurs when the server is busy. The BackOffMilliseconds value returned with ErrorServerBusy errors indicates to the client the amount of time it should wait until it should resubmit the request that caused the response that returned this error code.

Or, the HTTP status codes that are returned by throttling errors:

HTTP status code	Description
HTTP 503	Indicates that EWS requests are queuing with IIS. The client should delay sending additional requests until a later time.
HTTP 500	Indicates an internal server error with the ErrorServerBusy error code. This indicates that the client should delay sending additional requests until a later time. The response may contain a back off hint called BackOffMilliseconds. If present, the value of BackOffMilliseconds should be used as the duration until the client resubmits a request.
HTTP 200	Contains an EWS schema-based error response with an ErrorInternalServerError error code. An inner ErrorServerBusy error code may be present. This indicates that the client should delay sending additional requests until a later time.

Enterprise Calendar Metrics: The View from 10,000 Meters

Our last post was a start at getting at what kinds of time-based information is in Microsoft Exchange / Office 365 calendars that can help you get a hand on what is going on in your organization.

We want to draw the distinction between time management (something individuals either do or not do for their personal schedules) and calendar metrics (something you can read from the aggregated calendar data in your Microsoft Exchange server).

Here we'll start taking a look at some of the global reports you can extract that enable some insight on what your corporation is doing.

Some data we extracted a while ago generated the following results:

Not surprising (to anybody who's worked in an organization with more than fifty people) the number of meetings drops at lunchtime.  We interpret this as people wanting to get some private time, but any anthropologist out there will ask how we normalized our results, set up proper controls, and did double-blind studies.  None of us are anthropologists.  What is more interesting to you the manager are the twin peaks of mid-morning and mid-afternoon for the most popular meeting time.  Plan your resource use accordingly.

The outlying time of midnight - 1 AM we think was either security or manufacturing.

Which hour do people meet leads to the question which DAY is favored.  In the above report we found that meeting frequency peaks on Tuesday.  In LOTS of both legacy and Exchange data we have seen Wednesday and Thursday being the peak, but almost never Monday or Friday.

For the true calendar cartographer a totally nerdy but relevant question is: what kinds of recurrence patterns are established in my organization?  While recurring meetings and appointments are really neat, there data shows that the majority of meeting objects (we'll get to that in the next sentence) are one-time.  But I said objects.  So a weekly meeting counts as ONE object even if it occurs 52 times in the course of a year.

These combined with lists of the top users of calendar functionality are a good place to start to get a handle around enterprise-level metrics.

What can we do about individual resource metrics?

So glad you asked.  Hang on for the next post.

How does your enterprise spend its time?

Linkedin blogs contain interesting thought pieces.  Three recent posts caught my attention – they talk about how to cut down/eliminate unnecessary meetings:

Jeff Weiner (CEO LinkedIn) notes his managers complain about managing their inbox and their meeting schedules in his post: A Simple Rule to Eliminate Useless Meetings, and The Importance of Scheduling Nothing.

Rajat Taneja (CTO, Electronic Arts) wants to Cut Down on Unnecessary Meetings.

I found Rajat Taneja's post most interesting.  He talks about understanding "how we spend our time," and then he tracked how he spent his time.  We think the act of measurement is a critical component that will drive the CEO to force the organization to change the meeting behavior.

Both of these are geared towards the meeting organizer, that is, changing individual behavior.  But both of these being high level executives, the more interesting question they do NOT pose is: can we get a handle on how the enterprise is spending its time?  Are we being efficient or not?  And can we read this out of Microsoft Exchange?


Having been looking at scheduling metrics off and on over the years we've been trying to figure out how to interrogate the Exchange server to derive useful metrics on this for analysis on the organization / enterprise level.

It's easy to use server-side tools to get a handle and do reports on how much email traffic is generated and disk space is in use.  Email analysis has relatively little dependence or significance on job title or function.

But calendars are precisely the opposite!

As a Tech CEO you usually want your engineering staff working on engineering problems and not in any more meetings than they need to be.  But your sales people need to be meeting with clients or they're not doing their job.  In between there's a wide gulf as much dependent on individual corporate culture and goals as on anything taught in a management course at Business School.

We took a cut at that measurement, in our recent Oracle Beehive migration tool.  See "The Oracle Beehive Calendar Metrics" post for a screen shot of the metrics.  Those of you who have been through migrations with us have seen similar reports on your legacy data.

We've learned over years of analyzing data that the top ten meeting users is sometimes a surprising revelation to corporate management -- usually when they find that one of their top users is a conference room.

And this actually is where we made what we think of as our first big break through: that the inanimate objects in the corporation have a lot more importance than you would first think.  

In fact -- since the only major issue with them is "how much are they in use?" it's relatively straight-forward to do reporting on them and we've already sliced that a few different ways for people.

We'll show sample reports in a follow-on post.

More #Oracle Beehive Calendar Metrics

Our latest version of the Beehive to Exchange / Office 365 migration code includes more table of metrics of Beehive calendars.  I show some of the additional stats we generate here using only two users in our test server so it's easier to take in.