Meeting Maker Discussion List Closed

The Meeting Maker Discussion List hosted for years at Emory is shut down as of today (not that it's had many postings for the last year or so). They sent out this announcement earlier this week:

Dear MMXP subscribers,
Over the years, this list was a great asset to
those of us who ran Meeting Maker. Over time, the company(s) made
advancements in the support offerings. Thus, we have not needed this list
as much.

Emory has changed direction in how we use calendaring, and
have migrated away from Meeting Maker.
This is to serve notice that this
list
is to be shutdown effective 12/12/08.

Thank you.

Since the world is running ever lower on Meeting Maker, we're very glad that Oracle Calendar migration has stepped in to take its place.

Migrating Oracle Calendar Permissions to Exchange Part 2 DIY

So you want to migrate from OCS to Exchange and you can handle your own data migration (i.e., you don't want live meetings or recreated recurrence patterns) but you still want to migrate permissions.

We'll tell you how you can accomplish that using free off-the-shelf tools from Oracle and Microsoft.

The process proceeds in two phases:

1. EXTRACT the permissions data from Oracle


2. INSERT the permissions into Exchange

You may need to modify your user names between the first and second step, but if you're handling your own data migration this should not be too difficult. You're also going to have to write your own script to convert the output from the Extract phase to the input for the Insert phase. Since we get these requests from universities and they have lots of undergraduate computer talent that programs in between beer blasts we don't think this will be too difficult.

Extracting permissions data from Oracle Calendar Server

This is done using the OCS tool UNIACCESSRIGHTS. See the Oracle Calendar Reference Manual for your full set of options.

Let's take the example of John Lennon giving permissions to Jerry Garcia.

Running UNIACCESSRIGHTS to get the Designate data for Lennon is simple:

uniaccessrights -ls -grantor "S=Lennon/G=Johnny" -grantee "S=*" -n 1 -p PASSWORD

This results in the following output (which you can redirect to a text file), split here for clarity:

Grantee: S=Garcia/G=Jerry/UID=Jerry.Garcia/ID=256/NODE-ID=1 Designate Right: CONFIDENTIALEVENT=REPLY /CONFIDENTIALTASK=NONE /NORMALEVENT=MODIFY /NORMALTASK=NONE /PERSONALEVENT=VIEWTIME /PERSONALTASK=MODIFY /PUBLICEVENT=MODIFY /PUBLICTASK=MODIFY

The connections between the OCS User Interface and the output are pretty clear.

You have now successfully extracted the data. Part 1 is complete.

Inserting permissions data into Exchange

This is done using PFDAVAdmin, whose formal name is the Exchange Public Folder DAV-based Administration Tool. You should check out our earlier postings on PFDAVAdmin. First let's say that on Exchange in Active Directory we already have a John Lennon who has created the same Calendar permissions for his co-worker Jerry Garcia. What would those look like in Exchange saved with PFDAVAdmin?

So glad you asked. Running our friend PFDAVAdmin and looking at John Lennon,


we first EXPORT his permissions to see what our end goal is:

Pick the easiest format to read,

We get a LOT of data for folders. I invite you to look at your own output.

However, we can comfortably reduce it to the data we need for Calendars and Tasks:

SETACL Mailboxes\john.lennon\Freebusy Data SUMATRA\jerry.garcia Editor NO SETACL Mailboxes\john.lennon\TopofInformationStore\Calendar SUMATRA\jerry.garcia Editor NO SETACL Mailboxes\john.lennon\TopofInformationStore\Tasks SUMATRA\jerry.garcia Reviewer NO

Your step is to turn your UNIACCESSRIGHTS export into a file of this format that you can IMPORT into PFDAVADMIN to set the ACLs for Exchange. This is not very hard.

Of course it's in our test domain so everything is "SUMATRA," and "TopofInformationStore" should be "Top of Information Store" (but it breaks oddly in Blogger). You might also want to set the INBOX and OUTBOX permissions if you want them to respond to meeting requests for you.

NOTE: Be careful making any modifications to this file – it is very important that it be tab-delimited.

But you get the idea and there is enough information here for you to fly on your own now should you so choose.

Note the key things about this:

• With your own scripting the cost to you is zero for additional tools
• It puts the permissions part of the migration entirely within your hands

Migrating Oracle Calendar Permissions to Exchange

Exchange and Oracle Calendar Server (OCS) are different in how they assign their Delegate / Designate permissions, but it’s less an apple vs. orange difference as a grapefruit vs. orange difference: both are noticeable more for their similarities than their pronounced differences relative to other calendaring systems.

There are two levels of permissions relevant to this discussion:

• Object level permissions (for individual calendar entries and tasks)
• User level permissions (e.g., to an administrative assistant or co-worker)

Object Level Permissions

Let’s deal with Object Level Permissions first since it’s a simpler comparison.

Oracle has four different permission levels for Calendar and Task objects:

Outlook and Exchange have only a “Private” option:



Translating these during a migration is pretty simple: “Personal” and “Confidential” in OCS map to “Private” in Outlook/Exchange. In the case of a Sumatra migration this happens as the data is being converted from OCS export format into our intermediate database.


User Level Permissions
OCS starts with object permissions and then allows the calendar owner to set permissions for other users based on those object permissions. Where OCS is Data-oriented in its permissions model, Exchange is Folder/User oriented. This leads us into the User Level Permissions.

Let’s take a look at the Oracle Calendar Server side.

John Lennon makes Jerry Garcia his Designate in Oracle Calendar:

Here you have the only options relevant to a migration being: “Modify” and “View.”

Why is “View times only” not relevant for a discussion of calendar designate rights migration into Exchange? Because Exchange has no mechanism to deny access to free/busy information on a user basis.

Also note that in OCS a user has the option of specifying different access for different object types. That is – you can be more stringent with Confidential as opposed to Public data. This capability does not exist in Exchange. At all. So we’re going to revisit this issue later when we’re trying to decide how to migrate these permissions from OCS to Exchange.

So let’s turn our attention to Exchange and see what options there are when Zyg Furmaniuk makes Judy Morrison a Delegate via Outlook:

You basically have three levels of access (other than the trivial case of None) you can grant:

Reviewer
Author
Editor

And the scope of these is pretty much on an Outlook Folder level (though in the case of Calendar you need to also grant access to the Calendar and the Free-Busy information). I.e., You can selectively grant access to the Calendar or the Email Inbox.

So you can think of “Modify” in OCS mapping to “Editor” and “View” mapping to “Reviewer” pretty easily.

Oracle Permission "Modify" maps to Exchange Permission "Editor"

Oracle Permission "View/Reply" maps to Exchange Permission "Reviewer"

Oracle Permission "View Times Only" is irrelevant in Exchange Permissions

But there remains a question: Given that OCS users have several gradations not available in Exchange – how do we do a mapping?

We at Sumatra at this point broke it down to as simple a question as we could put to the Administrators: “Do you want to give the maximum rights or the minimum rights?”

The way this manifests itself on our OraCalReader utility is the choice between ALL designate access rights set to Modify or ANY set to Modify.

Since the only other option is “Reviewer” in the target Exchange any rights not set to Modify are set to Reviewer.

Any View rights are automatically set to “Reviewer” rights since the object level access in OCS does not come into play in Exchange.

We do not set “Delegate can see my private items” on the Exchange side. Why? Because there’s enough else going on in a migration – folks can forget that they don’t want some information shared post-migration. Keeping private on means maximum security and you can always dial it to where you want it post-migration.

Other Exchange Delegate notes:

• Exchange has several possible clients (Outlook, Entourage, Outlook Web Access) at several different release levels with varying degrees of cross-platform and cross-version capability. Be sure to examine your own environment carefully.


• The Sumatra process only handles Calendar permissions, not Task permissions. Could we do Tasks? Yes. But you’d need to convince us it’s a valid business case.


• Regardless of the level of Delegate access set by the end user in Outlook, Delegate rights in OWA are read-only. See http://calendarservermigration.blogspot.com/2008/11/seeing-delegated-calendar-in-outlook.html
  
• MOST IMPORTANTLY: Using these methods to set Delegates in Exchange will overwrite any delegate rights a user has set prior to migration. Consider yourself warned.

The User Perspective

What does the user GETTING permission experience?

In OCS, Jerry Garcia as Designate of John Lennon simply selects File-Agenda-Open As Designate and sees the following:

Jerry gets a convenient list of everyone he has permissions for:

And it is very simple to orient yourself:

This user experience is VERY DIFFERENT in Microsoft Outlook. Here we use Outlook 2007 as our example. Zyg has given Judy permission to view his calendar.

In Judy’s calendar, she has no indication of this (except for a possible email notice from Zyg). In order to set up her client to see Zyg’s calendar she must first explicitly open it and select “Zyg” from the directory list:

Once selected once the option to view is a check box.

More Calendar Weirdness in Exchange 2003

We keep hearing about calendar bugs in Exchange 2003.

Cases in point:

A meeting update does not appear in Outlook Web Access after a meeting organizer updates the time of one meeting occurrence in an Exchange Server 2003 environment

When you use a CDO-based application to manage calendar items in Exchange Server 2003, the application crashes intermittently

Keep in mind: None of this has anything to do with a calendar migration. It's what seeps into Microsoft products when the Redmond Belle tries to "encourage" you to "upgrade." Both of these are related to CDO and the most prominent CDO-based application is the Blackberry Enterprise Server.