Gmail outage. So why put corporate calendars there?

So we run on Exchange and have been leery of entrusting our infrastructure to a company that not only makes the software but hosts, updates, runs, and (pretty much) controls everything that has to do with it except what data we choose to put in and if we want more in this endless fraternity hazing-like ritual of submission and humiliation.

But when GMail was down and Google's response could be summarized as "yep it is" we looked on it with a certain schadenfreude. We've not been encouraging corporations to go to Google Calendar, and we're now less likely to encourage it anytime soon.

Does Exchange ever go down and strand a corporation for hours? Oh yeah -- believe me it does -- and we have the stories. But one Exchange installation going down doesn't bring EVERYBODY ELSE down with it.

To be fair, if you were using Outlook as a client Gmail seems to have worked through the storm, but that's got to be cold comfort to the crew coordinated out of California: "If you used our hated competitor as a front end interface you'd have been fine."

Cloud computing is just not yet a player for serious corporate infrastructure.

Sumatra at NERCOMP March 10, 2009 in Providence, RI

Normally we let the quality of our code and migrations speak for themselves but one of our clients at Wesleyan convinced us to do a talk with them at NERCOMP (The Northeast Regional Computing Program) in Providence, RI in March.

Not surprisingly, the title of our piece of it is: "Migrate your Calendar Data into Microsoft Exchange" on Tuesday morning.

You can see the agenda for the entire conference here.

If you've been wanting to meet Russ (known almost universally among Sumatra clients as "the calm polite one") that would be a good time.

Maybe you can convince him to talk a little bit about what we're doing with conference rooms in Exchange 2007.

Oracle Connector for Outlook differences from Oracle client and your migration

We take the Oracle Calendar Server export as the definitive source for data that is to be migrated.

Sounds pretty reasonable, right?

But now and then Oracle has the same sort of acquired inconsistency syndrome we're used to from Microsoft.

Case in point: in OCS create an appointment

and say you're not going to it:

As you see above, it keeps on ticking in the OCS client (and will show up in a UNICPOUTU export), but will not be displayed in Oracle Connector for Outlook, as this side-by-side comparison shows:

Just so you know.

In these cases our modus operandi is to take the data and display it, since it's a lot easier to remove something you do not want than it is to create all over something you do.

Meeting Maker to Apple iCal via Zinsert Field-Proven

We got a call a from a medical school in Silicon Valley asking if we could migrate 2 users out of a Meeting Maker server of 40 into ICS format.

This is not usually cost effective but they just wanted iCalendar files and they were very polite about the request.

Most times this would not be worth mentioning, but they had a novel approach -- they wanted to obsolete their legacy Meeting Maker server ASAP and move on so they took their data from Meeting Maker into Apple iCal before planning on putting it into Zimbra.

The good news: Seems to have worked fine!

To quote their plan:

...for now it will reside in iCal until Yahoo gets done with the updates that
(we) asked for. Then we will be able to sync iCal to Zimbra.

I really have to give them points for creativity.

Changing your Exchange 2007 resource behavior post-migration

So what happens when you migrate into Exchange 2007 with resources that are scheduled on an on-going basis?

Sumatra Development dogma on this is to have your resource AutoAccept turned OFF (i.e., in E2K7 terms to "AutoUpdate"):



This allows us to control how data gets migrated into Exchange. That is, we reproduce your Meeting Maker data as closely as we can (NB: this is mainly a Meeting Maker migration discussion, Oracle Calendar Server already wisely placed limits on how far ahead in time you can schedule). Interesting trivia: In Meeting Maker you can book a resource into the year 2039, which is an act of either supreme optimism or hubris, take your pick.
In Exchange Management Shell the command (broken here for clarity) is:

[PS] C:\Documents and Settings\Administrator> Set-MailboxCalendarSettings cr_testres_1 -AutomateProcessing AutoUpdate -AllowConflicts $TRUE -EnforceSchedulingHorizon $FALSE -ForwardRequestsToDelegates $FALSE -DeleteSubject $FALSE -AddOrganizerToSubject $TRUE -RemoveForwardedMeetingNotifications $FALSE

So you put your data in and then you want to establish some limits, like only allowing conference rooms to be booked 18 months ahead, and to have them manage themselves to avoid conflicts.

What happens then?

It depends on what happens to the meetings. If you have an ongoing meeting and it does not change, nothing, it will stay there quite happily in everyone's calendar.

If like us you live in the real world and you use the dynamic capability that this gives you, the first major update to an ongoing recurring meeting will cause it to be removed from the resource calendar until you give it an appropriate end date:

Now to proleptically answer the question "Hey, you guys know the start and end dates of all this data -- why don't you set this for us ahead of time?"

It's a fair question. The short answer is because there's so much else going on in a migration that hewing to the line of keeping the data we insert as faithful to what we pulled out is invariably the best course. Letting users learn to deal with the situations they're going to encounter in their new environment is better all around.

Google Calendaring and Imports

I have got to give Google Calendar some credit.

Since we got asked by a 4,000 user account about moving users into Google Calendar (there's a lesson for you, sinners, you want to get our attention have a 4,000 user migration base), we started looking at moving into Google via iCalendar files.

Most import mechanisms provide the kind of intelligence Geico likes to claim cavemen have, but Google Calendar actually did some checking and gave me the following error message:

Coolness.

But the cool factor is moderated by my noticing that the interest we've heard is decidedly not from the corporate market. I found 3 Critical Reasons Why Hosted Google Apps Won’t Work for Your Business a really interesting read. Though 10 Reasons Enterprises Aren’t Ready to Trust the Cloud does a good job expanding on it.

I also started looking at the issue of making meetings live when we migrate them over. Moving Gmail calendar to Google Apps For your Domain Calendar goes through the single user procedure, but for a few hundred or more users it would be tedious.

I also can't currently get the meetings to come over with guest lists and responses intact.