#MDaemon calendar to #MSFTExchange Migration Trial

Is available here.

For documentation start with this and look at our other posts.

For email you can use Microsoft's tools. but we've found imapsync more effective.

#Oracle Calendar Server to #MSFTExchange Migration and Years of Historical Data

Our latest version of Oracle Calendar Server to Exchange migration will allow you to surface a keyword in our XML Configuration file.

If you're in trial with us now we've told you about it.

If you get a trial from us and this is relevant we'll clue you in on what to do.

But basically you will split up your migration into two runs: the "Current" and the "Historical" -- and for each run you want different keywords.  Why?  So that if something goes wrong in the second run you can remove only THAT data and not the data you inserted before.  At Sumatra we're always looking out for you guys.

For historic data, we recommend inserting without sending email invitations – the process will go faster and you will still have the guest list in everyone’s appointments.  Use this setting:

It’s like “printing” your calendar into Exchange.

So the meetings are not live meetings (but they’re historical so – what’s the problem?) – but everybody’s who had a meeting or appointment in their calendar will have it in their calendar post-migration.

One other thing: For testing using the date range in ocalreader's "Calendar Selection Dates" configuration option is fine.

For a production run, use OCS's UNIICAL date ranges to specify the date ranges in your ICS files.  Why?  You ask.  Fair question.

If we interrogate the date and get a null answer in a migration into production, we’re spending cycles checking when we could be inserting.  This inefficiency adds up over lots and lots of data.

Final word: be careful managing the keyword.

Resources before and after your Microsoft Exchange calendar migration

Please consider this a follow-on to Russ's previous post.

We've got scads of migrations right now at various phases and something that keeps coming up is resource handling ("surprise, surprise" which I always imagine in a Gomer Pyle voice).

Before inserting calendar data into resource calendars, use PowerShell to enable all mailboxes and to disable automatic calendar processing, scheduling horizon, and conflicts.

To enable all resource accounts (pre-migration): 

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | enable-mailbox 


This script will disable automatic calendar processing, scheduling horizon, and conflicts for ALL resources: 

Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | 
           Set-CalendarProcessing -AutomateProcessing None
           -deletesubject:$False -AllowConflicts: $true 
           -EnforceSchedulingHorizon: $False

Post migration you can set these to whatever policies you wish -- but this allows us to re-create the calendar as it was in your legacy system.  A lot of field data has conflicts and double-bookings which get decided closer to the date.  The scheduling horizon on some legacy systems is 2039.

Post-migration to set resources to autoaccept which in Exchange 2013 is done via set-calendarprocessing:


Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | Set-MailboxCalendarSettings -AutomateProcessing AutoAccept -deletesubject:$False -addorganizertosubject:$True

Post-migration to DISABLE all resource accounts:

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | disable-mailuser

For private conference rooms you may want to set some policies like “book-in”, “request-in” that allow admins and other authorized people to either send in a meeting request, or be allowed to book a meeting in the room. This way the admin, as a delegate to the boss, can create a meeting in the boss’ calendar and invite a room. And everything flows through Exchange without issue.  A Look at Exchange Server 2013 Resource Mailboxes goes into good detail showing you how to accomplish that.

You don’t want to have rooms organize meetings because they are disabled accounts and cannot respond to email traffic.  Since this is a feature of the ICS exports from Oracle Calendar Server there is little we can do to remedy that situation (since OCS does not indicate the human who should be organizer). 

If you are migrating “shared” calendars, e.g., “carpool van”, “IT vacation schedule”, ”Help Desk Coverage Assignments” then create that entity as a user account in Exchange, migrate the ICS resource data into that entity, and then re-type the account from user to “shared.”  We wrote about the right sequence for migrating Shared Calendars into Exchange and setting them up.

Final note: now keep in mind: this is relevant to do the kinds of calendar migrations we do where meetings are actual meetings when you get done.  For every other kind of calendar migration out there you can ignore this and focus on having your users re-create all their meetings.

Two ways to grant access to a Resource in #MSFTExchange

A client asked us to explain the difference in the two ways for an end user to have "delegate" rights to a conference room.  It is confusing -- Microsoft calls them both "delegation"  and tried to explain them in a recent Exchange Team Blog post, Booking Delegation Vs. Classic Delegation.

Here is the summary:
1. Grant delegate permission using Outlook or OWA (aka "Classic Delegation")
2. Grant delegate permission using Exchange Control Panel (aka "Booking Delegation")

There are three problems with the "Classic Delegation" for conference rooms:

• First, since rooms are "disabled accounts", it's hard to log into them.  
• Second, Classic Delegation creates two rules -- one visible (IPM Subtree folders), and one invisible (think NON-IPM Subtree folders.)  When you change/remove a classic delegate, the hidden rule does not always get deleted and thus still remains in force. (Why? Outlook tries to be helpful, and when it sees there is a hidden rule, it uses the hidden rule.) 
• Third, the classic delegation rules run at a higher priority than  booking delegation rules.  More ways to confuse administrators.

Moral of this story: don't use Classic to delegate access to rooms. Sumatra urges all our migration customers NOT to migrate delegates -- once set they are difficult to remove (see our post from '08).


Sumatra recommends you assign room delegates using the "Booking Delegation" approach.  You can either use Exchange control panel to assign booking delegates, or PowerShell.  We prefer PowerShell.

There are several things you must do, depending upon how you want to handle room reservation requests

For auto-booking:
Ensure automated processing of meeting requests is set.
Example: Set automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing AutoAccept

For a managed room:
1. Ensure automated processing of meeting requests is disabled.

Example: Disable automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing None

2. Decide on your room administrators,  grant them permission, and allow the room to receive requests but NOT allow direct booking.  (You and also play with Book-in and Request-In policies starting with this old but good Technet Article....this is beyond the scope of our post, though.)

Example: Allow Russ Iuliano to manage Auditorium meeting requests. 

Set-CalendarProcessing Auditorium -AllBookInPolicy $false -AllRequestInPolicy $true -ResourceDelegates "Russ Iuliano"

3. Grant administrators permission to send on behalf of the room.

From time to time, you may not
Example, Grant delegate "riuliano" send as permissions on behalf of Room CR 101B
Add-ADPermission cr_101b -Trustee riuliano@sumatra.com -AccessRights "Send As"

Finally, You can read more about creating and managing room booking on Microsoft Technet.

Which version of Exchange should you be on for a calendar migration?

For a Sumatra calendar migration you should be on the latest update to Exchange (currently Cumulative Update 9).

At the very least, CU6, owing to that fixing problems with Contact Notes.

We spent an hour last week diagnosing problems with Exchange 2013 CU 4 -- once the Exchange environment was updated the issues went away.