Visual Representation of Calendaring in EHLO

You know, actions tell you a lot.

So just for chuckles we took this screen shot of the Tags on The Exchange Team Blog.

We see that to Microsoft calendaring gets slightly more tags than Compliance and Jobs (as in positions, not Steve).... 

....WAY fewer than Biography (what does the life cycle of a Microserf really have to do with Exchange?)....

.... And lower mention than whale dung to almost everything else.

Now this is not scientific, and it is not necessarily significant.  Tips 'n Tricks and Troubleshooting could be calendar-specific at times and not be cross-classified.  And E-Mail does not get a separate specific mention, which would provide the most direct comparison.

All we're measuring is the relative time it's tagged vis-a-vis the other tags.  Could be it's not mentioned because it's stable and not a problem (we find a lot of problems here, but that's out specialty), or it could be that other priorities are higher.

Interesting Google v. Microsoft in the Enterprise Story

Reading Google Pushed This 4,500-Employee Company Into Microsoft's Arms.  Our experience is that this makes sense.

We do not even bother looking at calendar migrations INTO Google anymore (the sites we found that were considering Google were really light on any kind of enterprise expertise in the first place).

Our prediction: we will soon be seeing people looking for full-state calendar migrations OUT of Google and into Exchange.

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!),

Preview: Oracle Beehive to Exchange 2010 Calendar Migration

We have Oracle Beehive to Exchange 2010 migration working pretty well in our lab and are about to release it to one of the few test sites we trust with these things.

We chose a different path on this new code.  Instead of going through an intermediary "extraction" step  we read directly from the Beehive Database and insert from there into Exchange 2010.

We still allow for individual mappings (so if Hillary Rodham in Beehive needs to become Hillary Clinton in Exchange we can handle that, or if you want to take this opportunity to recast your Conference Room nomenclature that is completely possible).

Of course, this is a FULL STATE migration so we preserve all of the recurrence patterns (and in this case we can preserve ALL of them), the Guest Lists, and the guest responses.  In short: meetings are completely "live" after migrating with this code.  It is like your users were on Exchange all along.

Just so you folks can get a glimpse of it:

And since one of Zyg's personal hot buttons is making sure international characters come out correctly, this hybrid German-Spanish text in Outlook on Beehive:

Migrates perfectly correctly to Office 365:

We're still working on some performance tuning -- but you can get a good idea of where this is all heading.

We're also considering migrating all the user preferences and email if we get strong enough demand.

Calendaring Incident in Office365 March 15

Sometimes clients wonder about our paranoia religion of checking and re-checking everything in migrations.

This is the latest battle story of WHY.

Last night as we were running a migration we started noticing that invitations were not being sent for migrated meetings.  Appointments and regular email seemed to be going in fine.

This in our world is a first-rate fuster-cluck disaster.

First we naturally suspected a bug in our own code or throttling changes.  This led us to a code review, soul-searching, and much sweat-producing anxiety.  We did solve this, and it was enlightening.

Wait for it.

Office 365 ITSELF was DOWN for all practical calendar migration purposes.

We never START with blaming Microsoft. It is with great regularity their fault, but it's better practice to look at ourselves first.

So adieu this weekend's migration into Office 365, we'll have to reschedule since as of this morning this is what the situation looks like in Service Health.

Was there any kind of alert to either THEIR administrator or say OUR Office 365 administrator that this was going down?  No.  I suspect there is some way to configure these, but am perfectly willing to give someone else credit for showing me how.  Right now with the tension buzz just coming down I feel more in need of documenting the situation.

To the credit of the Office 365 team they did acknowledge that the system was throwing defecation at the ventilator.

The way this presents itself in a migration is that invitations will seemingly disappear. (Amended from earlier posting where I showed a DIFFERENT issue.)

Oracle Beehive Calendar to Exchange Migration

With three requests (two of which we consider serious) we're working on an Oracle Beehive to Microsoft Exchange migration path.

And we're going to leave all the data in your hands and simplify our usual process.
Want to get in on the ground floor?
Drop us a line.

SuHoliday cmdlet and Exchange 2007

We've gotten a few inquiries about running the SuHoliday cmdlet on Exchange 2007 instead of Exchange 2010.

Short answer: Yes you can do it.  Nothing the the was we use the EWS API is specific to Exchange 2010 to the exclusion of Exchange 2007.

However, setting Permissions in Exchange 2007 IS VERY different from Exchange 2010, so you will have to adjust for that.  Taking all of the Exchange 2007 permissions stuff out of the documentation made it substantially shorter and clearer,

If you need help look at posts in this blog involving Permissions and Exchange 2007.

Read "Freedom for Users, Not for Software"

We've been watching the migration to the cloud for a while now -- wondering when everybody was going to wise up that data centers were farming them into cruelty-free meat by-products.

I was recently at a Christmas party with some people from a Redmond-based software corporation that makes Exchange.  Their take: Office 365 made their lives and their customers lives much more convoluted.  Where they could work solutions in on-premises servers, any changes to Office 365 need to be escalated at the corporate level.  And we all know how convenient and easy that is.  So they're increasingly seeing combined Office 365 and on-premises Exchange environments, precisely the opposite of what they and the customer predicted or wanted.

SO it's is with great fervor that I suggest you read Freedom for Users, Not for Software by Benjamin Mako Hill.

He hits it right on the money with his analysis of the market confusion initially arising from "free software" which was re-cast as "open software" (goals with which it is hard to disagree! What's so funny about peace, love, and understanding?) and the way this term was used and abused in the industry.  The aspect that I suggest you pay closest attention to is the emphasis on users. Focused on the server-side of the client-server model, we at Sumatra would substitute the term "consumers" for "users" to avoid the further linguistic confusion that comes from the distinction between "users" and "administrators" in such environments.  Both the admin and the user are consumers, and the user-admin collective together face the "user" conundrum.

After years in this business, I'm pretty sure the dynamics of the industry are never going to allow the ideals of the open software movement to be fully realized in any software that is both marketable and useful.  The lure of dollars is too strong.  When software remained the exclusive domain of academics and cowboys it was possible.  These guys were happy to have a car and an apartment.

But once venture capital and the stock market took hold these ideals were not going to stand up to the motivation of owning a private jet and a McMansion.

What's this have to do with the movement to the cloud?  It's all the same dynamic based on much of the same software with the scions of the same corporations promising freedom while actually building feudal digital fiefdoms.  Do not go mindlessly with the flow when you hear that your support problems are going to go away and your life is going to be easier.  You might luck out, but really look at what your business goals are and how you're going  to deal with realistic software disaster scenarios while your business processes are directly under someone else's control.

As we often quote Ronald Reagan: "Trust, but verify."

Retiring Meeting Maker Migrations December 20, 2013

Folks, it has been a great evening out but now the bartender is calling for last orders.

As of December 20, 2013 we will no longer be doing Meeting Maker migrations.  We of course continue to do both full state and faster-simpler migrations from Oracle Calendar to Exchange, and faster-simpler migrations from Zimbra to Exchange.  Our Holiday cmdlet continues to thrive and our custom calendar engineering is unparalleled.

To those of you who have been asking us about migrating in the last few years: we'd recommend starting your test cycles sooner rather than later.

We're sympathetic to your budget cycles, so if you need to discuss timing we're open to that.  But we do need to put a stake in the ground so we can all move on.

Exchange 2010 Permissions Debugging Protocol updated

It being a new year and we having found a few new ways that Permissions could be problematic in Exchange, we've modified the Debugging Protocol.

The latest is available at this link: Exchange_2010_Permissions_Debugging_Protocol.pdf and supersedes all earlier versions.

Changes mainly affect the holiday cmdlet.

Turn on calendar publishing so people can share information

In general we don't just re-publish other links, but this one is so useful I feel the need.

How do you make your calendar available on Office 365 to users external to your organization?

Check out this article: Turn on calendar publishing so people can share information

A darned useful ability if you use it well.

#Exchange #PowerShell cmdlet for server-side holiday insertion updated

We're happy to announce we've updated the trial version of our Microsoft Exchange cmdlet for inserting holidays server-side.  This works on Exchange 2010 and Office 365.

You can read about it and get a download link by going here and filling out a form (we want to keep track of who is using it).

You can read the documentation here (and this includes how to insert class schedules using the tool as well as how to use the web-based version we've done).

We have had tens of thousands of people using this version since last year, but only a handful actually made any donations to the project.  So we're setting up a payment mechanism for the non-trial version.  When that's ready we'll let you know.

Oracle Calendar / Zimbra to Microsoft Exchange faster/simpler trial.

We've been getting lots of requests for the simplified method of going into Exchange from Oracle Calendar System and Zimbra.  So you can just download the trial here.

This version is quicker and simpler than our full method, and it will work for you IF:

• You are not changing your base SMTP addresses for users in your migration
• You do not want your recurrence patterns re-created
• You have no need of re-mapping email addresses of a subset of your users 
• Your users can deal with responding to their invitations again

If you really want the full-state, map-able, recurrence pattern recreating version you'll still need to do a trial.

Holidays into #Exchange and #Office365 via Server-Side Tools

We've just upgraded our cmdlet for inserting holidays server-side into Exchange 2010.  We'll give you some more details about that in a later post.

Mainly we're writing because we've just completed a site that lets you upload holidays into Office 365 without the cmdlet.

The full URL is: http://www.sumatraresourcewatch.com/holiday

We're treating it as a beta right now -- but we want folks to try out the online experience since it's one of the easiest ways to actually see how the full cmdlet works.  The "Buy" button will not be active until next week or so.

We've tried to make the web interface as easy as possible.  Folks who have been through a migration with us will also recognize our 1930's Soviet tractor style of user interface (not pretty but it works -- if the market responds well to this we've already got plans to update it). And since we traditionally use Jimi Hendrix as a sample account we are announcing this shortly after after his birthday.

You will need credentials for a service account that has Impersonation permissions to any of the accounts you want to modify.  This will be no surprise to any Exchange administrators.  The full manual for the cmdlet goes over how to do this.  

Then you select if you want to insert into a single calendar or upload a list of calendars to insert.

And the default calendar list goes right into Jimi's calendar.

Note that you can also remove inserted holidays automatically but leaving all other calendar data intact.

The web-based version allows you to do select a list of SMTP addresses to insert at once.  In the unlicensed version we limit this to 25 users per day, and only allow you to select US or UK holidays that we have already defined.

The full cmdlet allows you a lot more functionality: multiple time zone support, script-ability, and LDAP query insertions.

For the record, US Federal Holidays came from http://www.opm.gov/operating_status_schedules/fedhol/2013.asp  Our default file will insert JUST THIS LIST (i.e., NO “Day after Thanksgiving”) and we left Veteran’s Day a ”Free” day rather than a Busy day,

UK bank holidays came from this list https://www.gov.uk/bank-holidays