Hard Limit of 25,000 on Beehive Calendar Objects

While stress testing our migration methods -- we did a major push for performance optimization aka SPEED -- before a migration this past weekend and of course that meant a few bugs crept in, we got this message from Oracle Beehive.

So if you did not know it before, there's a hard limit of 25,000 meetings in Oracle Beehive Extensions for Outlook.  Hard as it is to believe we do know of users who have exceeded this in other legacy systems.

External Contacts in an Oracle Beehive to Microsoft Exchange Calendar Migration

External email addresses in meeting invitations.

We do not make them live in migrations.  The reason is simple: they confuse the heck out of the attendees and it's not worth it.  While you can communicate to your internal folks that a migration is going on and we are taking care of re-creating the meetings, we cannot reach out of your organization and re-accept or decline for your external guests. 

But we can let YOU know about them.

So as of all forthcoming version of our process we're keeping the record of external guests in the meeting agenda, exactly as you see here post-migration.

When Impersonate Permissions Fail DURING a Migration

Interesting case came up this weekend.  

An 850 user Beehive to Exchange Migration validated fine (notable for two things: First European Beehive migration and first multiple instance Beehive migration) and then while in migration started throwing impersonate errors for what became a total of ten users.

Now ten out of 850 is about 1% -- which to us is still too great an error rate for us to tolerate.  

But it seemed really wasteful to undo the entire migration for ten users.

Here's what we did.

We modified the insertion to allow for a single user.  Not via validation of that user which is a good test procedure but it would be insufficient here.  You need the validation file to be as entire as you can get it -- otherwise there will be inaccuracies.

First fix your permissions issues with those users.

THE ABSOLUTELY SAFEST WAY

Here are the steps we recommend:

•     Create a new sub directory for each of the accounts.  Remember to copy configuration and the two account validation and mapping files
•       Launch the bcalreader UI, and set the lower and upper limit for the first account’s SMTP address root, e.g.:  “jimi.hendrix” to “jimi.hendrix”
•     If there are multiple accounts that have this root, follow the limit values with an “@” sign.  For example, if you have two accounts “jimi.hendrix”, “jimi.hendrix2”, and you only want to process “jimi.hendrix”, set the limits: “jimi.hendrix@” TO “jimi.hendrix@”           Otherwise the tool will migrate “jimi.hendrix” and “jimi.hendrix2”, and you will end up with duplicates in the “jimi.hendrix2”’s mailbox.
•     Validate, then press the “process all” button.
•     Repeat for other users

NOTES

• This inserts all meetings/contacts/tasks owned by the user, and process all invitations received from other users.
• However, it will NOT process invitations sent from this account to other accounts.  Those invitations will remain in his invitee’s in-boxes.  We suggest you leave it that way.
• Communicate to your end users that the migration may have left some meeting invitations in their inbox.  Suggest they process those invites the way they did in Beehive (e.g., if they accepted the invite in Beehive, accept the one in Outlook;  If they declined the invite in Beehive, decline it in Outlook.

THE ABSOLUTELY BEST WAY

The best way in this case means getting the outcome you could have had if the impersonate had not failed.  But it is a little more intricate and has the possibility you press the wrong buttons.

Do this in the cold light of morning.  It is way too easy to hit the wrong button when you are sleep deprived and stressed. 

• Create a sub-directory that you will use to process the accounts that had impersonation problems.
• Copy bCalReader v2.0.11 or greater and the validation file.
• Change the limit to the account.  Put an “@” after the SMTP address, e.g.: “Jimi.Hendrix@”
• Press “Process All”.
• Repeat for the remaining accounts.

Once you have added data from the impersonation-problem accounts, return to the “main instances” of bCalReader.

For each of these instances:

1. Check the “show individual steps”, and re-process the invitations as follows
2. Press the “Respond to Invitations” button on each instance.  When they are all done,
3. Press the “Apply response Exceptions” button on each instance.  When they are all done,
4. Press the “Update Tracking Info” button on each instance.  When they are all done,
5. Press the “Final Cleanup” button on each instance.  
6. When they are all done, you are finished! 

Multiple Insertion Instances in Oracle Beehive Calendar to Exchange Migration

Now that we have Beehive to Exchange migration running reliably and in test in both the USA and Europe, we're working on improving the throughput with our old friend: Multiple Instances aka Segmentation.

Since re-creating calendar state in Exchange requires sending, responding, and creating exceptions for meeting invitations, this technique does require some special handling, which we're detailing here.

First, the screen morphs a little:

As we've done in the past, this is an alphabetic list, so 

1. Make sure when you do this you cover the entire alphabet.  Once a site left out the letter "k" -- yet another great example of why we built "UNDO" capability into the process.

2. Sometimes resources or rooms start with numbers, so make your first installation "SPACE" instead of "A".  If you try to use A this comes up: 

3. Remember what we said earlier about sending invitations and responding to them?  Suppose that Adam Ant invited Lex Luthor to a meeting, but Luthor is in a different segmentation.  It's possible one instance could be trying to respond for Luthor before he gets the invitation and suddenly everybody gets confused.  No worries.  After the invitations have been sent for each instance the code pauses and tells you to wait for all the other instances to catch up.

How to use this:

• Go to each computer you want to use 
• Install bCalReader and its associated .DLLs
• Validate and map all your users on one machine and then COPY the account_validation.txt and alt_account_maps.txt to the other instances.
• Proceed.

As always, TEST TEST TEST before you go live.

Performance Optimization in a Beehive to Exchange Calendar Migration

We've been fine-tuning the performance in the Beehive Calendar to Exchange calendar migration.

A little bit of background is due here.  We use the rate of 850 objects per minute as a rough gauge of Insertion time into Exchange in our Meeting Maker or OCS migrations.  But that is ONLY for insertion into Exchange from our own data structures and does not include the time for any processing of Legacy calendar data (the Extraction phase).

For Beehive, we've combined the EXTRACTION and INSERTION into one application where we read directly from Oracle's relational database.

And needless to say performance varies hugely with the Beehive topology and servers.

So a few general results:

• Your migration performance improves  20-30% if you SHUT DOWN Beehive (technically our results were 18% to 33%, in a variety of configurations, but rounding makes them easier to wield).
• Going into on-premises Exchange yields more reliable performance than insertion into Office 365.
• Extraction involves a certain amount of overhead that is difficult to remove and highly dependent on Beehive system and configuration.  Think of it this way: it always takes a certain amount of time to pull up a user.
• Given that, look at your summary report for you top users and use that data in conjunction with your test experience to gauge your insertion times.  If you need help analyzing this contact us.
• Calendars with more objects take longer to insert so only take data as far back as you need.  If we see serious requirements for lots of past data we'll modify the code to allow you to insert current data as quickly as possible (so you are functional) and then go back and insert your historical archive.  This has been a regular feature of our other migrations for a while now, but Beehive migrations are relatively new.