Just added Categories to our Oracle Beehive to Office 365 migration

We got bored waiting for feedback from our current Oracle Beehive migration sites so we added some functionality we've been meaning to anyway.

Now you can take categories along.

But there's a little subtlety involved.

Let's look at our favorite test user Jimi Hendrix in Beehive (via the Outlook client): With appointments on International Worker's Day with categories assigned.

Nothing out of the ordinary here.

Now let's run our process and migrate Jimi to Office 365.
Here are the results of the migration into his specific account.
Note that the "Red," "Orange," and "Yellow" categories come over, are retained, and the color pops up as we would expect.

But categories "Migration," "Microsoft," and "Travel" are uncolored, while category "Hayley" HAS a color associated with it.  What goes?

The answer is of course: User Configuration.  Since on the Office 365 side we used an off-the-shelf configuration, the defaults common to both Oracle and Microsoft came in and displayed.  Custom categories need to be created user-side in the defaults (which is a one-time action).  Once you assign a color to a category (as we did with category "Hayley" below, it's propagated to all calendar objects with the same category.

Offers to Acquire our #Oracle #Beehive to #Office365 Calendar Migration Technology

It has been a weird few weeks here at Sumatra.

And it just keeps coming.

A company from the Indian subcontinent and another company from the former Soviet Union both contacted us within days of each other looking to acquire our Oracle Beehive to Exchange calendar migration technology.  I'll let you guess which one started with "Please send us all your source code....."  The other one was a slightly more realistic.

Anyone else pick up a disturbance in the noosphere?

The fact that there were two makes me wonder that is going on here.  We are open to licensing this to someone else but as it needs to be a serious inquiry.

Preliminary video of #Oracle #Beehive to #Office365 Calendar Migration

We're back to normal functioning around here.

We did this preliminary video on how our Beehive calendaring / contacts / task migration into Exchange / Office 365 works.  

Look at it on full screen so you can catch all the details.
Updated July 18, 2013 to point to the final video.

Sumatra will be unresponsive today #keepcalmandcarryon

Most of us being based in the Boston-Cambridge area, and ALL of us having significant ties to the area, Sumatra Development is going to be glued to current events today.  We'll get back to you when we can.

Before and After a Beehive to Office 365 Migration

Just so you can see the consequences of a migration, this was the Inbox of Janis Joplin before we synced:

It is purposely sparse.  

Post-migration we have all of her email with attachments  (including her meeting invitations).

But these meeting invitations are still tagged with Janis's old address:

Making them inert and sub-functional in this context.

How to Migrate #Oracle Beehive Email into #Office365

Migrating email from Oracle Beehive to Office 365 is not as easy, graceful, or efficient as it should ideally be, but it can be done.

We're going to show you how.

IF you are confident with accessing your IMAP set up, you (*should*) be able ignore this step with Test-MigrationServerAvailability.  Sashay over to Migrate E-Mail from an IMAP Server to Cloud-based Mailboxes,

You really need to get to the point where you run Test-MigrationServerAvailability:

Test-MigrationServerAvailability -IMAP -YourIMAPServer  -Port (143 or 993)

To do this you need to execute PowerShell (do this as an Administrator) and re-direct your session to the Exchange Cloud.  You need to execute these commands in PowerShell, filling in Administrator credentials (call 'em the SuperUser, the Big Kahuna, whatever you want, but you need the rights to administer your entire Cloud account)

These commands in PowerShell will do it.

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

When all goes well it will look like this:

Note that it did not work for me the first time through the lengthy command but it did immediately after with another simple try.  Go figure.

When in doubt refer to one of the most useful short webpages you will ever find: Connect Windows PowerShell to the Service.

Now you are in a position to run Test-MigrationServerAvailability.

I have done this here.  Note that I was having trouble resolving my FQDN, but just used a the 127.0.0.1 localhost address and was in with no problems.  This is not something that will work for you in a real world migration, but I wanted to illustrate it here and did not feel like making my test system available to the wider internet,

If you have reached this point you are knocking on the door to success.  

Again, since as nearly as I can tell this is exclusively to test if you can get access to your IMAP server, and the real work of the migration gets done below, you can in all likelihood skip this step.  Please feel free to drop some comments if you discover something to the contrary.

A final word:  ALWAYS Clean up your PowerShell session by ending with Remove-PSSession $Session.

NOW YOU ARE IN A POSITION TO REALLY BEGIN MIGRATING BEEHIVE EMAIL TO EXCHANGE,

First you owe it to yourself to review Migrate IMAP mailboxes to Exchange Online: Roadmap.

If you successfully complete the instructions in Step 3 you will see this:

Click New and select "IMAP"   Not a lot of choice in this if you're coming out of Beehive.

The next one you're going to need to fill in all your Beehive server particulars.  Note that I did not use a secure port here.

I am going to take only ONE user in this case, but you should feel free to scale it up as you need to.  By long tradition in Sumatra all our test users are rock stars with "J" names.  Here's Janis Joplin.  Note that we need a CSV file I'll show you the details on later, and we can specify mail folders not to migrate (here I specified we should ignore "Junk", "Drafts", and "Mercedes Benz" for all these users.

That CSV file is really simple -- just the email, user ID, and password.  But keep in mind you want the email to be the email of the target user on Office 365, and the UserName and Password to be for that same user on the legacy Beehive system!! 

When that's done you go through one more screen:

And then start your migration.

Now it's passed into the hands of a greater power than any of us has ever known -- Microsoft's data center.  

May they have mercy on your data.

Read the logs and check over any errors. In practice I'd really try to end the process here and not keep a periodic synch running -- that's just asking for trouble.  But your circumstances will vary.

And of course I cannot resist saying that while http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff683630.aspx tells you you cannot take calendar and contact information:

We at Sumatra have just put full-state calendar migration (meaning: meeting will be actual meetings when you're done) and contact migration technology into a couple of test sites.  Contact us (infoATsumatraPERIODcom) if you want to try it out.

Automatically Updating Domains / SMTP Addresses in #Lync Meetings in #Exchange

So for the last few months we've had an interesting tool running at a client site.

The initial motivation was a corporate re-organization where a group of users were  transferred into a new domain.  Being a communications-intensive environment this brought a number of issues with it.  One of them was how to update all their Lync meetings to the new domain automatically.

We built this into SuUNDO, one of our flexible utilities for modifying Exchange calendars (usually to clear stuff out).

You're going to need to do be issuing commands from PowerShell.  There is of course installation and configuration, which in the interests of brevity we cut out here.  The great thing about PowerShell is its scripting flexibility.

Let's take a look at a sample Lync meeting in Office 365.

If we just wanted to find out how many current meetings are in Zyg's calendar we could just do this:

#ReportONLY
get-StringsinNotes @LyncCmds -NewPrimarySMTPAddress: "zyg-furmaniuk@sumatra.onmicrosoft.com" 

Output to the screen generates this (telling us this user has one current Lync meeting)

This is recorded in a log file as well.

So far so good -- this can tell us the extent of the number of online meetings that would need to change for all users.

Now, let's take the next step and update them.

Let's say this was an on-premises Exchange installation (it's not, but one of the Cloud's best attributes is as a test system) and we needed to modify just the domain names for these users, from "lync.com" to "sumatra.onmicrosoft.com"

This command will do it:

set-StringsinNotes @LyncCmds  -NewPrimarySMTPAddress: "zyg-furmaniuk@sumatra.onmicrosoft.com" -OldPrimarySMTPAddress: "zyg-furmaniuk@sumatra.onmicrosoft.com" -OldSIPAddress: "lync.com" -NewSIPAddress: "sumatra.onmicrosoft.com"

And we see the results in the original calendar here:

And now for the magic part, it has been automatically updated in the ATTENDEES' calendars as well!

Of course, you could also use this for updating when users change SMTP addresses only (or both together!),