Why are the Russians Binge-Reading this Blog?

Dear Binge Readers in Russia,

You never write and we never get any inquiries, but periodically throughout the week we get a few hundred views from you guys in the space of an hour.

What goes?

New Option on Oracle Calendar Server Migrations to #MSFTExchange

When we recreate response states from Oracle Calendar Server 10.x to Exchange we have a new option:

As a default your un-responded meeting invitations are "Tentatively Accepted."

However, you can also set this to "Accept"  "Decline" or "Do not apply a response."

I cannot see a reason you would want to Decline all instances -- but (and I am still flabbergasted) we got asked for it.

One thing that is possible is that if you originally Do not apply a response (i.e., leave them as invitations in user inboxes, you can then go back and "Accept" or :Tentatively accept" since we are keeping track of the responses.

UNDO gives you the option to limit removing guest responses by our alpha limits.

This capability is in oCalReader v 5.0.7.

Meeting Responses in a Full-State Oracle Calendar Server to Exchange Migration

How do we deal with Meeting responses in a full-state migration from Oracle Calendar 10.x to Exchange?

• The response options in Exchange are Accept, Decline, Tentative, and No Response
• Oracle Calendar Server allows you to NOT respond to a meeting and it still shows up in your calendar. So in the field lots of people do not bother to actually Accept. Migrating these meetings to Exchange, we insert a non-response as “tentatively accepted” more as a sensible convenience than anything else.
• Exceptions to guest responses to recurring meetings are not inserted. E.g., if a guest accepts all but declines a few occurrences, or declines the recurring meeting but accepts a few occurrences.  The latter situation actually cannot happen in Exchange but is possible in OCS.

Oracle Calendar Migration to #MSFTExchange #Office365 - Full State via new methods

We've further developed our oCalReader methodology so that now in addition to doing a partial migration it will also execute a full-state calendar migration from Oracle Calendar Server 10.x into Microsoft Exchange or Office 365.

You can see the new configuration options below:

A couple of notes on this:

RESOURCES

• Works best for resources that are booked on a first-come-first-served basis.
• Does not work well when the resource owns the meeting.  You cannot have a resource organize a meeting in Exchange!
• Requires a manual mapping of resource names to Exchange SMTP addresses (since resources in Oracle Calendar server don’t contain email addresses, or, worse, point to the admin managing the resource.)

The mapping file looks like this (OCS Resource name on the left, Exchange SMTP on the right) :

You can get your resource names from OCS with UNIUSER.  A command something like this:

uniuser -resource -ls "R=*" -n 1 -p PASSWORD >resources.txt

should export them.

The new buttons "Guest Response" and "Cleanup" come into play if you are running individual migration steps. 

#MDaemon Calendar Migration to #MSFTExchange Trial Software

Trial software for our MDaemon to Exchange calendar, task, and contact migration may be downloaded here.

Oracle Calendar Migration to #MSFTExchange @Office365 Recurrence Patterns

The question came in: "Which recurrence patterns migrate from Oracle Calendar Server to Exchange?"

The short answer to this is that NONE of them MIGRATE – our technology RECREATES them.
Oracle strips every recurrence pattern out of ICS exports in part because Outlook cannot handle the patterns OCS can produce.
Sumatra technology analyzes these patterns and produces the best matches it can for recurrences.

A couple of rules in this:

• THE WORST CASE is all the data goes in as one-time events or meetings.  You do NOT lose data.
• You need at least 5 instances before we try to form a pattern recreation
• We look for exceptions with a 80% regularity by default  (you can change this – but do not screw with it yet)

The patterns most likely to get picked up and transferred:

• Every 15th (for example) Day of the Month
• Every 2nd Wednesday (for example) of the Month
• Every MTWTF and variations of that, e.g., TuTh, MWF. etc.
• Weekly meetings / every other week / every fourth week
• Yearly meetings

Over the last 15 years of doing this kind of migration – this is over  90% of recurrences in most environments

The patterns that are not going to get re-created as patterns:

• Random selections of dates
• Every 1st AND 3rd Friday of the Month  (sometimes with enough exceptions and a forgiving exception rate these will show up as “every other week” recurrences, but do not count on it)
• ANY recurrence with LOTS of exceptions.  I.e., over 20%