Sumatra Development leads the field of migrating entire calendar servers to Exchange. We migrate Oracle Calendar Server, Oracle Beehive, Apple iCalendar, and Zimbra to Microsoft Exchange keeping all meeting information and resource bookings intact. We migrate calendars server-to-server between Exchange and Office 365 while keeping meetings live and doing incremental syncs quicker than any other solution.

Featured Post

Free trial if you qualify and contact us . First: you can always get help at the PowerShell prompt with: get-help Get-suDoubleBookedMeeti...

Friday, February 06, 2009

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.

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.