Outlook Live: Bulk E-Mail and Daily Recipient Rate Limits

Folks looking to go into Outlook Live should check this out:

Bulk E-Mail and Daily Recipient Rate Limits

Because when you re-create calendaring state as we do in a migration you are very likely to find some people who are hitting into this limit.

We sometimes do get the question: Why do you need to send messages if you are migrating calendars?

(We do, oh we really do!)

The answer: because calendaring in Exchange is a message-based protocol (Duh). Single appointments do not fall under this limit, but meetings DO. And remember, with meetings there's the invitation AND the response.

Outlook Live and Outlook On-Premises Differences

You know.... there's a bunch of these differences between Outlook live and Exchange on-premises.
And like discovering land mines you're only going to know when you step on one of them.
Such is the case with Throttling Policies and the EWSFindCountLimit.
What does this have to do with calendar migrations? Just in our UNDO function (a prudent safeguard which many of you seem to find comforting).
Our QA team discovered weird behavior in Live @ Edu that does not exist in on-premises Exchange when we were trying to UNDO several test insertions at once. The default limit in ESWFindCOuntLimit is 1000 items (and this in our case includes things in the Deleted folder).
So some of our higher-end users were not being UNDO-ne.
We're fixing that and preparing for the next landmine.
Stay tuned.

Inserting into Live @ Edu vs. inserting into on premises hardware

We were working with a client doing a migration into Live @ Edu and wanted to get some absolute data on calendar migration performance on their machines versus everyone else. So in true Sumatra fashion we created a test database of 20 users and had them insert it in their test environment. It took 19 minutes.

And we then inserted the same database into our Exchange environment. That took 12 minutes (not surprising, we have good hardware and not an enterprise-level load)

Then we inserted the same data into Outlook Live @ Edu. It took 71 minutes.

Just to be sure we were not doing something really wrong we ran it twice and got the same manatee-like languid pace. We're used to measuring migrations with a clock, not a calendar.

We're sure we're not processor bound on our client system. The question is whether we're processor-bound on the server (likely) or network-bound (not as likely). The results are in any event troubling for anyone wanting to do a bulk calendar migration.

But wait -- there's even MORE BAD NEWS FOR calendar migrations!

According to Message, Mailbox, and Recipient Limits (tip 'o the hat to Duncan in London), there are limits of 30 messages per minute and 500 recipients per day. And the logs from London's test runs indicate they are already hitting this limit.

Taking calendar data over in a full-state method we re-create all of these and it is not unusual for the even moderately-scheduled user to hit these limits.

Stay tuned. We're working on creative solutions.
There is a ray of hope, though. This thread indicates others are running into the same absurd limits and Microsoft MAY be willing to make exceptions (check out the procedure at the end).

We suggest you folks who want to do a full-state calendar migration contact your Microsoft Rep and ask them if they can get these limits removed for the duration of your migration.