Unable to Delete All Data in a Google Calendar

So let's say you're testing your calendar insertion (a prudent step which we not only endorse but require).  You either have a large calendar or run several insertions to put in over 40,000 items.  I suspect the problem starts with 32K objects, just because we are so suspiciously close to a magic binary number.
You go into your settings with the hope of deleting all data from your test account (and please make sure it is a test account):

You select Delete giving you this dialog box:

Where you promise you REALLY REALLY DO want to Delete all events, and click the Delete all events button.

Less than 60 seconds later you see the following dialog box and all your data is still in the calendar.

We do not seem to be alone.  We posted this on Google Calendar's Help Forum (whose only value has been confirmation from another user with the same problem). None of our current clients are going to hit this limit unless they do multiple insertions without practicing calendar hygiene.  

So practice calendar hygiene.

But we do want to get this out as a warning to everyone.

Addition on March 3, 2015: This post is now hugely popular.  So if there are folk out there who want to take an entire Exchange server of calendar data (we're talking an enterprise here) into Google calendar, and keep all the meetings live, let us know.  We've done Exchange to Exchange that way but will only add the Exchange to Google capability if we have a real customer.

Shout out to the CalConnect Folks!

A shout out of thanks to the CalConnect folks for putting us on their Blogroll.

Thanks!

Preliminary Google Calendar Upload Speed Tests

We've made no secret about the molasses-in-Antarctica upload speed of EWS in Office365 and Live@ Edu. 

So for an interesting comparison -- how long does it take to upload calendar data into Google Calendar?

In a test derived from real world data set (legacy Meeting Maker being the organ donor in this case)  our current technology uploaded 13,651 appointments to Google Calendar in 9:12 (i.e., 9 minutes and 12 seconds).  Just in case I happened to hit a low time for network traffic I ran the test again with additional loads on my PC and got all data inserted in 15:54 (call it 16 minutes).

Using the more conservative figure, this represents an average upload rate of about 853 calendar objects per minute into Google Calendar!  The faster result gives 1480 objects per minute, but I doubt that is sustainable over the duration of a migration.

For those of you who do not understand why we get excited by these numbers: this is similar to the peak throughput we see inserting into an on-premises Exchange installation (you always hear us use the figure 850 calendar objects per minute for estimation purposes).  Our timings on hosted Exchange come in at about 120 calendar objects per minute.

So Google Calendar is about ten times faster than an upload into Hosted Exchange!

Let me repeat that -- our early testing indicates that calendar uploads into Google Calendar execute an order of magnitude faster than an upload into hosted Exchange.

Now, let me point our a few things to beware of: these numbers may vary as our code evolves, but are in accord with the field experience of one of our test sites (which motivated this timing).

I have no idea what Google does right that Microsoft does not, given that both companies are in total control of their data centers, server code, and APIs.  I do know that for purposes of migration speed Google Calendar kicks Exchange calendar's buttocks all the way to the curb and then slam dances its corpse into pavement pizza.

Since regular readers will know that your author does not believe in letting ANY of the guilty off without some sentence, I want to point out that as mediocre as Microsoft EWS documentation and support has been, it is light years ahead of Google's documentation of their calendar APIs which our team has taken to completely ignoring because it's led us down too many bad paths already. 

And after inserting 40,000+ objects into Google Calendar, the Delete under Settings does not seem to work:

iCal Sharing in Exchange 2010 Sp1

Sumatra is about to release a solution to migrate legacy calendar data to Google. A customer asked how his end users could read shared calendars from folks outside the organization (and who use Exchange for calendaring.)


We passed along this article, in which Steve Goodman wrote a superb post describing how Exchange 2010 Sp1 allows users to share calendars with non-Exchange users (e.g., Google, Zimbra) using public or encoded URLs. (And users can be alloweed to do this via OWA!)

And remember, this is calendar SHARING, not cross-server calendar synchronization.

Update Rollup 4 for Exchange 2010 - re-issued

I was working offiste for the last two weeked and missed the story: Microsoft discovered a problem with Outlook 2010's interaction with Exchange 2010 server, and had to retract Update Rollup 4 for Exchange 2010 they released on June 22,2011. KB251545 described the problem: moving or copying public folders didn't work "as expected."

The release was announced on Technet. Here is the new link to download the rollup

BTW, Update Rollup 5 for Exchange Server 2010 Service Pack 1 release remains "on-schedule" for release in August 2011.