Migrating calendar user settings into Exchange / Office 365

Today's topic on migrating into Exchange or Office 365 from a legacy system is USER SETTINGS.

Spoiler alert: I'm going to make the case that this is something you should put in the hands of your end users post-migration.  At best it's a necessary evil for a subset of high value individuals in your organization and at worst an example of sticking your finger in an already hopelessly broken dike hoping to keep it all together before the deluge overwhelms you and you needlessly drown.

In our 80/18/2 rubric, we're in the 2% in terms of user satisfaction, and that's also about as much of this as you can successfully automate server-side.

Let's begin with the end in mind and look at how the settings get put into Exchange.  Then we'll work back from there.

Set-MailboxCalendarConfiguration is your major asset in this endeavor.

Read it.  Study it.  Grok it. 

You can now take server-side control of SETTING user preferences in your organization. 
Notice I did not write MIGRATING user preferences, keep an eye on this.

Let's take DefaultReminderTime as a simple starter example.

Set-MailboxCalendarConfiguration ^
    -Identity "Jimi Hendrix" ^ 
    -DefaltReminderTime 00:30:00

Sets the default reminder time for Jimi Hendrix at 30 minutes.

We could also on the Exchange side set:  WorkDays, 
WorkingHoursStartTime, WorkingHoursEndTime, WeekStartDay, all really useful in calendar management.  You can set this via Group Policy “Microsoft Outlook”, “Outlook Options”, ”Preferences”, ”Calendar Options”.  We find it’s much more convenient to set the hours via “Set-MailboxCalendarConfiguration” than Group Policy since it allows the users to change their work hours. The down side of the cmdlet: you’ll have to run this for every new mailbox-enabled account you create.

Let's look at an Oracle Calendar Server legacy system

Now, working backwards, we need to get that default reminder time information out of our legacy system.  

In Oracle Calendar Server you can use uniuser to get your user lists and you can use it to provision users.  But you cannot use uniuser or any other server-side tools  to get individual user preferences.

Let me repeat: you cannot get the info you want on an individual basis from the server.

You CAN get the default user profile in $ORACLE_HOME/ocal/misc/user.ini 

Looking at that:

Notice that the TimeBeforeReminder is FAR MORE CONSTRAINED than Exchange/Office 365/Outlook allow.

Remember in an earlier post when I wrote about disconnects between your legacy and Exchange?  Welcome to the disconnects.

And just because this is more popular lately let's consider Oracle Communications Calendar Server which we access server-side via WCAP.  The user settings are not in general available by any of the options.  get_accountprops.wcap is the most obvious, but is highly limited.  We can get ACLs, but see our earlier comments on delegate migration.

So your users have more discretion than they had before and setting their preferences in the client user interface takes a few minutes as opposed to a few hours.

You COULD use the PowerShell cmdlet to set the same default for all users.  You could probably also apply a Group Policy to accomplish the same business goal.  But re-creating individual user preferences server-to-server is a no-go from the start.

Our conclusion: Don't bother.  But tell them in advance.

We've only looked at Oracle calendars so far.

Let's look at one more legacy system -- Zimbra calendaring.

From the administration console we can see the preferences information for a given user:

Yes, the data is there, but again there is no server-side means of exporting it.  You can get at all the users on the system but their specific calendar preferences require client-side methods (which are SLOOOOOOOWWWWWW and inefficient).  We've actually looked at the mySQL database where all this info is stored and while it is possible to extract, we also found significant reticence among migration sites when we used tools like putty and HeidiSQL to extract data.  And that was mainstream calendar data!  We've since refined our calendar migration methods to avoid those requirements.

Email and calendar migration get you accolades and you can accomplish them successfully.  Leave the user preferences in a new system where they belong -- in the hands of the users.

We recommend you communicate this to your users in advance.  95% of them won’t know or care, and you will force the remaining 5% to find something else to whine about.