Corporate Microsoft Exchange to Google Calendar migrations: Is there anybody out there?

One of my favorite lines from Pink Floyd's The Wall: Is there anybody out there?

In this case, corporate users going from Microsoft Exchange to Google Calendar who want to move corporate calendars.

We've gotten asked about this several times in the past few weeks. But no requests have been from actual corporate customers wanting to preserve calendar data. All requests so far have been theoretical discussions or from universities adopting the free Google Apps ride and wanting full-state migration to be free while they're riding.

I mean it's not hard for me to believe that most corporation would not be really psyched about putting their data in the hands of a third party.

McKinsey & Co learned the hard way: Corporate data slips out via Google calendar.

Since free Google Apps for Education is an easy sell to most cash-strapped universities, we've mainly been hearing about this from the education sector. And I've not seen any company with more than 1000 users even considering Google.

Or am I just thinking about this wrong and have not yet realized that the real corporate market is something that keeps Exchange data completely out of the hands of Google Calendar?

Anybody have any feedback?

New Means of Creating Broken Meetings in E2K7. Part 1: Getting them

Broken meetings used to be relatively simple to create with Outlook 2003.

Outlook 2007 did a good job of correcting some of the problems by tightening the behavior when an owner deletes a meeting.

BUT in Exchange 2007 using Outlook Web Access (OWA) it turns out to (still) be relatively simple to create broken meetings to clog up your resource calendars.

I'll admit this is slightly convoluted AND bad user behavior, but we can do this using standard, completely legitimate commands. This makes us leery about what other methods remain to be discovered.

So first let's look at my calendar:

Three meetings each with Conference Room 222 already reserved.

Highlight the one at 10:00 AM and press DELETE. This dialogue box displays:

NOW for the deviltry. If you press "Send" right now everything will be hunky-dory and the meeting will be cancelled cleanly. But let's not.

Instead, let's say that you DELETE the conference room AND add "zyg" as a required guest:

THEN hit SEND. In Zyg's calendar we see the meeting has been cleanly deleted.

Aside: Adding "zyg" is a crucial step. If you try to send without a Required user you get an appropriate warning.

Anybody care to guess what the calendar for Conference Room 222 looks like? Right. The meeting is still in there.

Kudos go to Russ and the insertion team for discovering this.

So ends Part I: Creating the broken meeting. Watch this space to see how you can find and remove the broken meetings.

Note that KB 954284 Outlook 2007 does not send out meeting cancellations if you remove all invited attendees from a previously created appointment describes a similar situation using Outlook 2007 rather than OWA.

When your self-signed E2K7 certificate expires

We worked with a client who saw a self-signed certificate error (mismatch, expiration) in their lab. It took a while to figure out how to update the self-signed cert. You have to create/update the certificate, enable it, and restart IIS. Here are the steps we took (using Exchange Management Shell):

There are two ways to generate a new cert. One is to add another year to the existing cert, the other is to create a new cert.

1) a) Add one year to the existing (expired) cert:

Get the thumbprint of the expired certificate:

Get-ExchangeCertificate -DomainName fl NotAfter,Thumbprint,certificatedomains

Then use that cert's thumbprint to generate a new cert

Get-ExchangeCertificate -Thumbprint xxx New-ExchangeCertificate


1) b) --or--Create a new cert:

New-ExchangeCertificate -PrivateKeyExportable $True -Services "IMAP, POP, IIS, SMTP" -SubjectName "cn=yourOutlookAnyWhereExternalDomainName"

Once you create the cert, you'll be given a thumbprint. Use that to enable the cert:

2) Enable-ExchangeCertificate -Thumbprint [thethumbprint] -services:"IMAP, POP, IIS, SMTP"

3) Stop/Start IIS:

i.e., iisrestart /start
--or--
net stop "World Wide Web Publishing Service"

net start "World Wide Web Publishing Service"

net stop "FTP Publishing Service"net start "FTP Publishing Service"

net stop "Simple Mail Transport Protocol (SMTP)"

net start "Simple Mail Transport Protocol (SMTP)"


Install the certificate on your client Windows machine via Internet Explorer:

4) Tools / Internet Options / Content / Certificates / Trusted Root Certificate Authorities / Import


-RVI

Best Practices when Migrating Calendar Data

We've noticed the current economic climate has encouraged a passel of folks to evaluate their options.

And these same folks tend to call us to outline their options.

Now, we like to be as chatty on the phone as the next guys, but going over the same stuff does get to be a little repetitive. So in Sumatra fashion we stuck everything in a document and are encouraging you to read it.

It's way shorter than the tech documentation, and maybe even some managers would be able to digest it.

Click to download the PDF: Eight Best Practices when Migrating Calendar Data.

As always, we encourage feedback.

Compliance, legal discovery, and your Meeting Maker data

Remember to look at calendars as part of the legal discovery process.

Last year we migrated a university (sorry, I can't give out the name here). During the migration, the CIO wondered why legal discovery solutions only focus on email (because it’s the only data that can be easily read, and there is a lot of it).

He saw their calendar data in a database and mentioned they might need to revisit their historic calendaring data (via Meeting Maker) for legal discovery or forensic analysis.

We’re calendaring guys. Reading calendar data is what we do, we said, so let us know if you need it.

Last month they asked if we could extract calendar items for a set of users. The caveat: they wanted the output to contain all meetings, agendas, appointments, along with the names of all people they met with in an easy to read format.

The "easy to read format" was the really hard part.

However, we believe in the old virtues of hard work and entrepreneurial solutions. We also noticed that since the Microsoft Exchange base is growing and the Meeting Maker base continues to contract that we'd rather solve this on Exchange.

We had their Meeting Maker data in an Access database. We could have written some code to expand the calendar data. But this method seemed pointless since Sumatra’s insertion into Exchange does most of that work already. So our solution was to take advantage of Exchange - insert their data into our test lab, and then create a tool to read the calendar data directly from Exchange.

The report contains ALL calendar entries (meetings and appointments), showing with organizer, subject, date, attendees, including the agenda.

For current Sumatra clients who can’t wait to try this, here’s the command syntax for a report of Bela Bartok’s calendar in 2008 (it would all go on one command line but we format here for clarity):

suExchange2007.exe
/usersrc:alias
/user:bela_bartok
/cmd:report_all
/dtstart:”1/1/2008”
/dtend:”12/31/2008”

Note: If you do not want to see the agenda, you can use the /cmd:report switch. It’s much faster!

True Inquiry Stories Part 2: "Which one is easier to migrate into?"

Most times people have decided where they're going on vacation before they get in the car and start driving.

What this has to do with calendaring migrations is that in the past month we've gotten questions from two separate sites: Which is easier to migrate calendar data into -- Exchange or Zimbra?

Short answer: Zimbra.

Hands down. No question about it. It is much, much simpler to completely migrate calendar data into Zimbra than it is to migrate into Exchange. Please remember I'm talking about the kind of migrations we do: keeping meetings and guest lists live, preserving recurrence patterns, and maintaining guest responses. If you are content to just do a Palm synch you're wasting your time reading this blog.

Exchange's bugaboos in permissions alone vault it to a different scale. Then we start adding things like BES servers, backup strategies, forest trust architecture, yadda yadda yadda.... The documentation we have on Exchange migrations is about 150 pages total. The documentation we have for a Zimbra migration is about 50.

However, we really do not think this should be your criteria for deciding which one to migrate to.

But why do we say that?

Because we should really be the last part of your decision - not anywhere near the first.

Your calendar migration will take either several hours or a possible weekend when you go into production. Your user community on the other hand is going to be living with the decision for years. Focus on what is going to work for your users, not on whether you're in the lab overnight watching a migration.

Let's go back to the vacation analogy. Say you're in New York. You could go to Paris in 6 hours or Hawaii in 12. BOTH are very desirable destinations. You should not make your decision based on how long the flight is -- you should make your decision based on what you want to do when you get there.

True Inquiry Stories Part 1 "We want it all, but one user at a time"

Recently we got a set of requirements from a government agency that read like this:

We're looking to migrate our existing Meeting Maker 8.5.3 user, resource
account and conference room calendars to an existing Exchange 2007 server. Here
are the requirements from our customers:

1. Preserving as much of the meetings, activities, tasks, category information and contacts as possible....

2. If possible, we'd like to be able to import the Meeting Maker information on a per-account basis.

3. For the most part, our Meeting Maker server is actively used by only about 40 users at this point. However, because of a requirement from our customers, we have not deleted many older accounts from Meeting Maker to help maintain a historical record of meetings and activities. ....

The main problem with this is that 2. and 3. contradict 1.

Those of you who have been through the process or even the evaluation have heard us talk about the "spider web" that calendaring represents: Moving email is relatively easy since the data is static. But migrating calendar data while preserving guest lists and responses is harder -- you are literally picking up a spider web and moving it from one proprietary environment to another.

So moving one user at a time destroys the links between other users. Move all your users at once and you can preserve the links and associated information.

The corollary to this is also no surprise, keeping users on your original server for historical purposes works fine -- but you'll need to decide what to do when the time comes to migrate them. Not taking old users to Exchange is the same as removing them from your original system: their data disappears. Think of it this way: if a user does not exist - how does Exchange react when you put them on a live guest list?

Since we have gone through an intermediate database in our migration technology (a very wise design if I do say so myself) we do have options to reformat data on its way into the eventual target system, but this does require time and expertise. There really is no such thing as a free lunch.

After their initial inquiry they went out and tried to write their own tools (our recession-era tax dollars at work).

I leave the results to your imagination.

Keep an eye on this blog: we're working on a guide for evaluating calendar migration solutions. You don't have to go with us, but whatever solution you choose you should choose with open eyes.