Migrating Large Oracle Calendar installations to Exchange by Subsets

Migrating Subsets of Larger Oracle Calendar Server Installations

April 9, 2010

Background: In re-creating meetings as live meetings from OCS, Sumatra uses the calendar of the meeting ORGANIZER as the definitive source for guest status. Since Exchange is a message-based system, it is crucial that in re-creating the calendar state calendar invitation come from the meeting owner. However, in the case where migrations must be done in phases, it is desirable to maintain as much as possible information from users external to the subset being migrated. This process deals with that.

As an example, let's say that we have an OCS installation in Europe that consists of about 2000 users in the Local users (NL) and 20,000 FOREIGN users (FR). Let's say the NL server is the first to migrate.

We have two issues, NL users as guests of meetings originated by FR users, and FR users as guests of meetings originated by NL users, as per the following table.

		As Owner
		NL	FR
As Guest	NL	OK	Case FR OWNER => insert as appointment in NL calendar?
	FR	Mail Contact	NOT YET MIGRATED

 

Process Change xCalReader Phase

1. Create an additional Users export file of the FOREIGN users and name it FOREIGN.TXT
   

1. Use the following command to generate this file from the FOREIGN OCS server:
   

uniuser -ls -format "%s%:%g%:%uid%:%id%:%node-id%:%email%:" -n 1 -p jimmorrison >foreign.txt

NOTE the additional %email% which will give us the email of that user as defined in OCS. We will need this information for the foreign users.

1. Place this file in the same directory as your USERS.TXT and UNICPOUTU export files. This means both of these files will be read and populated into the database at the same time before any calendar data.
   
2. You will have a new option in xCalReader to ANNOTATE calendar items from Foreign (FR) users.
   
3. Server NODE numbers MUST be different between the USERS.TXT and the FOREIGN.TXT files (see below – we want to assure that our created User ID numbers are unique – and NODE is one of the concatenated elements in this)
   

Notes In converting the users, invitations to NL users from FR users will be appointments in calendars. When the FR users who are OWNERS migrate, these will be overlayed with LIVE meeting data in Exchange. The user can then delete (or keep as they will) the appointment knowing that the meeting data will be updated with changes.

Using a mail contact has the following requirements and repercussions:

We do not (*think*) French users must be on NL server as MailContacts. Valid regular email addresses should be enough to generate invitation from NL owners to FR guests– but we want to encourage you to try it. French users will then receive Outlook calendar invitations to their mail accounts.

French users can accept/decline/ignore, Sumatra process does not create state for these users.

NOTE: this means there will be the original OCS meeting and the new meeting in their calendars, but the new Exchange/Outlook one will be the one updated when a NL user makes changes.

 

Code changes in xCalReader will act so as to

1. Automatically read FOREIGN users
   

1. Convert meetings from foreign users into appointments in guest calendars
   
2. Allow for an administrator defined "Tag" for foreign user originated meetings.
   

 

Process Change User Mapping Phase

User mapping proceeds as documented, except the FOREIGN users will need to be mapped as well. We're documenting this and will forward ASAP.

 

Process Change SuExchange2007

Code changes in SuExchange2007 will act so as to

1. Automatically validate foreign users
   
2. Not generate error messages for foreign user validation
   
3. Create FOREIGN users as guests
   

This will be transparent to current operation but will require testing.

 

 

Things we want you to be aware of

We already know we are not going to get access to any of your data – so we need you to be looking at it for us.

1. Once both USERS.TXT and FOREIGN.TXT are in – we need you to make sure there are no duplicated USER IDs in the USER table. We can tell you how to do this if need be.
   
2. We need you to test this first in miniature and then in full-scale as quickly as possible.
   
3. We could really use sample data from you "users.txt" and "foreign.txt", plus a user's export file that has foreign user meetings (both as an owner, and as a guest)