Enterprise Calendar Migration @Zimbra to @Office 365 @MSFTExchange

Per request, a video of  migrating calendars from Zimbra into Office 365.

Of course this keeps meetings as genuine, functional, updateable meetings when they are migrated to the Microsoft Exchange side.

We are reading calendar data directly from the Zimbra database, a technique we also use for our full-state Exchange to Exchange migrations and our Oracle Beehive to Exchange migrations.

Microsoft Deprecating the REST API preview endpoint

Microsoft is Deprecating the REST API preview endpoint on October 15.

Now this is the PREVIEW endpoint, not the functionality.

Since we're on something of a roll, we're considering using REST to pull calendar, task, and contact data out of Zimbra at some point.  Our experiments make pulling the data from Zimbra look relatively straight-forward.

Our experiments putting data into Office 365 indicate more trouble and uncertainty than it is worth -- so we're likely to stay with our current methods.

Converting a Meeting Maker server to a relational database

We had someone ask us "Can you guys convert a Meeting Maker server to a relational database?"

Short answer is: Yes - that's how our migration process has always worked.  Raw Meeting Maker data exists in an object-oriented database format that I have described as a cross between a PhD thesis and a junior high school science project. 

Even though we formally ended our MM to Exchange migrations we've been contacted by some Friends of Sumatra who've been through migrations with us before so we've kept our conversion software running.

Time frame: depending on how much history you have and how many users are on your Meeting Maker server we can convert your data into an Microsoft Access database in (at the most) an afternoon.  Usually it's only a few hours but breaking out and spinning up the conversion server is the real hassle.

This converted database alone is insufficient to run a full migration into Exchange.  Do not allow that idea to entertain your mind.

The converted database is completely appropriate for converting / archiving Meeting Maker servers into a standard database format so that you can do searches for legal compliance, history, investigations, or whatever your data-driven needs require.

#Zimbra Email Migration to #Office365 using #imapsync

Today we'll show you how to use imapsync to migrate email from Zimbra to Exchange 2013 / Office 365.  We got some good feedback from our initial post on Zimbra calendar migration to Microsoft Exchange and wanted to add some value on the issue of email migration.  When we did that for MDaemon everyone was very grateful and it led to much calendar migration.

You can license the technology and purchase the support to migrate your email for 100 Euros. Remember this only moves email.  You will have to budget additional funds to move your calendars.  This gives your end users a complete solution -- email and "live" (with guest lists and responses.) Plus, your conference rooms and resources are fully functional when you're done with your migration.  That's what we do at Sumatra.

We found imapsync to be the most  efficient and cost-effective, email migration product.  Just license imapsync and get support at the same time.

Is this imapsync email migration guide exhaustive?  Hell no!  There is no way to document all the "creative" ways user behavior can wreak havoc -- and some of them are going to be downright pathological.  We are aiming for the 80% side or the 80/20 rule here.  You get that much down you can make a good stab at the rest if you find yourself in difficulties. Barring that imapsync is very forgiving and its model of incremental syncing is laudable in its simplicity and effectiveness.

Migrating your email probably also takes you through 80% of what you need in a migration.  If you're happy with that -- glad to be of service.  If you need the calendaring to come over with fully-functional meetings, guest lists, responses, resources, contact Sumatra and we'll set you up with a trial.

Preliminaries

Zimbra has excellent guide on using imapsync with Zimbra.  We would suggest you add a valid non-self-signed certificate to their requirements.  imapsync runs in Linux and Windows (via the Command Prompt.) We'll demonstrate the Command Prompt since Microsoft Exchange / Office 365 is our target system.  Editorial comment: one of the smartest things Microsoft could do is put Exchange on Linux, but it's more likely some weenie there will recommend porting Windows to the iPad first.

Remember before you test,  you will have to enable IMAP in Exchange 2013 and for your end users in Office 365.  See how to do this in our blog post.

Migrating one user Zimbra to Exchange

In the simplest case migrating from Zimbra to Office 365 looks like this for our user Jimi Hendrix (if you use individual passwords for users).

imapsync.exe ^

--host1 sumatra.com --user1 jimi.hendrix@sumatra.com --password1  "XXXX" ^
--host2 outlook.office365.com --user2 ^
jimi.hendrix@sumatra.onmicrosoft.com --password2 "XXXXX"  ^
--ssl2  --sep2 /

If you set up a service account with FullAccess on Office 365, you accomplish a migration without knowing any password except your service account by using a command like this (where password2 is the service account password):

imapsync.exe ^
--host1 zimbra.sumatra.com  ^
--user1 jimi.hendrix@zimbra.sumatra.com --password1 "XXXX" ^
--host2 outlook.office365.com --port2 993 --sep2 / ^
--user2 jimi.hendrix@sumatra.onmicrosoft.com ^ 
--authuser2 SERVICE_ACCT@sumatra.onmicrosoft.com ^
--password2 "XXXXX"  --ssl2

Note in  the above, for an Office 365 target system we need to use the "--sep2 /" command. 

Confused about Exchange permissions and setting up your service account?  Read our post The Cookbook Version of Exchange 2013 Migration Rights.

If you want to use a Service Account on Zimbra as well, similar syntax should work using either the "admin" or "zimbra" account.

Note also that this gives you the direct capability to map your user ID, for instance from "jimi.hendrix" on your legacy system to "jhendrix1967"  or "jimi.hendrix1967" on your target system.

Iterating over a user list

In any event you are going to need to generate a user list to migrate email.  Can you keep your migrating user list separate from your migration script?  Answer: YES. This method assumes your legacy ID is the same as your target ID, but allowing for this to change is not a hard extension.

The imapsync ZIP file contains a script for iterating on a user list:

sync_loop_windows.bat

Which also contains an excellent primer on running imapsync in parallel.  

This batch file assumes a text file in the form "User1;Password1;User2;Password2;..."

Zimbra's Guide to imapsync includes a couple of batch processing script examples.

To get  a user list from Zimbra you can use either zmprov (this gets a list of accounts without passwords, so use a Zimbra admin account to get data, and please edit out the spam, A-V, etc. IDs): 

cd /opt/zimbra/bin  

and 
sudo ./zmprov -l gaa >~/accounts.txt

You could also use ldapsearch if you already have scripts for that. 

It has been said that the "death is in the details."  We say, "success is set in the details."

Now come the details

Throttling in Exchange/Office 365: Your Migration Nemesis

Note that I did not write "enemy."   You're more likely to be throttled in Office 365 since the controls to that environment are largely out of your hands.

As per our usual mantra: test everything before you go into production.  

If you get throttled, there are two imapsync switches you can tweak.

One limits the transfer rate to a specific number of messages:  
--maxmessagespersecond

Start at 10 (say) and work up or down from there.  In calendar migrations we start with 25, but our gut experience tells us calendar data is smaller per object on average.

The other limits the transfer rate by byte if that works better for your network environment.

--maxbytespersecond

You can also check out our post Throttling in Exchange 2013.

Really helpful options

• --buffersize 8192000  imapsync has a default I/O buffer of 4 Kb.  Upping this to 8 Mb will probably speed things for you
• --syncinternaldates: some email systems misuse email dates and you therefore run the risk of the receipt dates on your target system (what imapsync refers to as host2) becoming the date of insertion.  This command avoids that unfortunate event. 
• --fast:  this prevents flags from being synced and therefore makes the process (wait for it....) faster.  Not an option to invoke if you want / need to sync flags! 
• --dry:  this is a really useful option for development and debugging,  It just goes through the motions of logging onto both source and target system and displays the status -- a dry run.  Use this or debugging options -debug and -debugimap

Other idiosyncrasies

The imapsync FAQ recommends these additional settings when migrating from Zimbra.

imapsync ... ^
--exclude "Conversation Action Settings" ^
--exclude "Quick Step Settings" ^
--exclude "News Feed"

Although we have not seen those folders in Zimbra in a while, your implementation could be different.

Sent, Junk, and Trash

However, there are differences in Folder names between the two environments that may be relevant to you.  Specifically what Zimbra calls "Sent, Junk, Trash" Office 365 calls "Sent Items, Junk E-Mail, Deleted Items" as seen in this side-by-side comparison.

To successfully migrate these folders, use this command sequence to map the folders: (see Zimbra Documentation):

--regextrans2 's/Sent$/Sent Items/'
--regextrans2 's/Junk$/Junk E-Mail/'

--regextrans2 's/Trash$/Deleted Items/'

Notice how we lined these up so it would be easy to repeat if you needed this for other systems, or different language packs.  These being regular expressions you could also take several related folders and migrate them into a single one on the Office 365 side, but I leave that to your wits and imagination.  If you do find something that works, let us know -- we'll update this post (of course, crediting you!)

Exchange IMAP Prerequisites

Did you configure IMAP?  If not, see how in our blog post:

On the Zimbra side:
Make sure you are enabled for IMAP access. 

Check "Enable clear text login" for the IMAP service via "Global Settings" or under "Servers" under IMAP in the Zimbra Administration Console.

If you need to install Perl modules, this is an excellent tutorial on how to do so.

Sample Scripts

These sample scripts for major migrations / multiple users will help you out a lot.

http://imapsync.lamiral.info/examples/sync_loop_windows.bat

http://imapsync.lamiral.info/examples/file.txt

Final word on really considering what you need in Zimbra migrations Diatribe: Migrating email is about moving tonnage.  Migrating calendars is about preserving responses, recurrences, and resources.

But a full migration methodology has to include more than just moving this data. We have a comprehensive suite of scripts and tools so that before any email or calendars are migrated we take care of:

• Reading the Zimbra user list (and passwords)
• Provisioning users in Exchange
• Re-configuring Outlook to point to your Exchange server and removing the Zimbra Outlook connector. (Note: there are publicly available scripts but we wrote our own after we found they did not work.)
• Pre- and Post-cut over scripting so that legacy emails are moved to the target system, and new emails redirected to the target system.

If you have a few dozen users, it's difficult to make an automated process cost-effective and you might as well do it on your own one at a time.  You can export PSTs or export files from Zimbra, then import those PSTs into Exchange.  Tedious and time-consuming, yes, but free.

If you are a larger site with the need to preserve your meeting guest lists, recurrences, responses, and resources post-migration feel free to contact Sumatra.

Quick guide to Enabling IMAP in @Office365 / #MSFTExchange 2013

Let's say you're going to want to start migrating email from a legacy system like Zimbra into Exchange 2013 or Office 365.  You're going to need to get IMAP running on either your on-prem Exchange environment or in O365.

This tells you how to do it.

In a few days we'll show you how to start moving your Zimbra email.  Why are we picking on Zimbra?  We're not, we're responding to market demand to move Zimbra (which is not hard to see since Exchange continues to improve linearly and Zimbra has developed in fits and starts from being independent to being a quizzical part of Yahoo to being remaindered to VMware to passed off to Telligent and now just sold to Synacor). 

There are three pieces to get IMAP working:

1. Start the IMAP service (Exchange 2013.)  Office 365 can skip this step
2. Enable the IMAP Connector
3. Enable the IMAP mailbox feature for user accounts

Start the IMAP Service

The first step is to start IMAP on your Exchange 2013 server (see below).  Once set, you can then enable the IMAP mailbox feature for each user.  (Office 365 customers can skip this step.)  These are the four shell commands:

Set-service msExchangeIMAP4 -startuptype automatic
Set-service msExchangeIMAP4BE -startuptype automatic
Start-service msExchangeIMAP4
Start-service msExchangeIMAP4BE

Step 1: Start two IMAP4 services (and configure those services to automatically start if you wish.)

By default, in Exchange 2013 the IMAP4 service(s) are stopped:

To start those services: On the computer running the Client Access server role:

1. Set the IMAP4 service to automatically start:

     Set-service msExchangeIMAP4 -startuptype automatic

2. Start the Microsoft Exchange IMAP4 service.

     Start-service msExchangeIMAP4

On the computer running the Mailbox server role:

1. Set the Microsoft Exchange IMAP4 Backend service to start automatically.

     Set-service msExchangeIMAP4BE -startuptype automatic

2. Start the Microsoft Exchange IMAP4 Backend service.

             Start-service msExchangeIMAP4BE

In our case, the CAS and Mailbox server roles are on the same box:

Configure Exchange IMAP4 External Connection

This allows users to see (and thus use) the IMAP server.  Here is how via the powershell SET-IMAPSettings cmdlet, e.g.:

     Set-ImapSettings -ExternalConnectionSetting {:993:SSL}.

Note: This requires you restart IIS.

This is true even if you are working within the firewall  Thus in our case, the External Connection is the same as the InternalConnection.

Finally,  Verify things are working, using OWA’s Options select Account, then pick the “Settings for POP or IMAP access” link.

For more information see: http://technet.microsoft.com/en-us/library/bb124489(v=exchg.150).aspx

Enable IMAP for your users
Next, ensure your user mailboxes are enabled for IMAP.
You can do this one-user-at-a-time using the Exchange Admin Center (EAC):

Or via Remote PowerShell for Office 365:

 Set-CASMailbox jimi@sumatra.onmicrosoft.com -MAPIEnabled $True

Which can be set for all users by piping from Get-Mailbox (note that this correctly excludes resource accounts for email migration):

Get-Mailbox -resultsize unlimited ^
  -filter {isResource -eq $false} | set-CASmailbox ^
  -MAPIEnabled $True

You know you are a calendar geek when....

You know you are a calendar geek when you go to the Museum of Modern Art and on seeing this painting:

your first thought is "Out of Facility."  

I'm pretty sure that is not the reaction Ruscha intended.

#Zimbra calendar behavior with different clients: what it means for enterprise @MSFTExchange migration.

There are a few acid cases we always look for in calendar migrations.

Welcome to one of them.  Well actually three of them all at once.

We are looking at these cases of course because we are revising our full-state calendar migration from Zimbra to Microsoft Exchange, but this will also be interesting to people who wonder why their different clients can sometimes give different results when looking at the same calendar data.

Let's say Jimi Hendrix invites Janis Joplin to a recurring meeting let's say we create it on Saturday November 14 and set it for recurrence every weekday for 5 instances.  Let's also say Janis declines the series and accepts ONE instance  (on the problematic nature of this capability see our previous post).  

Now, for the FIRST weirdness.

Jimi's calendar in Zimbra using the web client looks like this:

The recurrence pattern states every weekday, but the seed instance is on a weekend day.  The Zimbra web client lets you do this perfectly fine, and data is data, so there we are.

But if we open up Jimi's exact same calendar on the exact same Zimbra server in Outlook configured for Zimbra we see something different:

A few things to notice here:  Jimi's recurrence pattern now starts on the MONDAY, which is the next instance of a weekday and continues for 5 instances. The same thing happens with a similar "wrong" seed date "Every other Tuesday" which Outlook now interprets do be on the wrong Tuesday.  Opening up the SERIES shows this:

Which is a total brain-fluck  (note spelling those of you easily offended). 

If we look at Janis's calendar in Zimbra web client and overlay Jimi's, her declines are correct and her acceptance is in the correct spot.

BUT if we take her ICS file and just look at it in Outlook (without importing it though that does not make a difference), then we see data consistent with Jimi's calendar, except that Janis looks as though she's ACCEPTED all instances (they all in fact have BUSY Free/Busy status).

Keep in mind -- we do not deny these are some weird cases.  They are also weird cases that are really easy to create and propagate and we know they exist in actual customer data.

So the question becomes: in an enterprise Zimbra calendar migration which data interpretation do we take as definitive? Even if you're doing it yourself via PSTs (for gosh sake do not use PSTs, keep an eye on this blog for your better alternative) or export files you need to be aware of the issue.

We started doing full-state calendar migrations into Zimbra a few years ago, but interest has risen in the past few weeks from some larger sites and we’ve determined there are two paths we could follow:

Option 1  is reading the Zimbra database directly and then inserting into a database exactly like the one we used for Meeting Maker migrations.  It’s a little more complicated for admins since they need to map users in database tables.  This is well-suited to a big-bang all-in migration.

Option 2  is exporting Zimbra ICS files and using our tools to insert then and re-create meetings.  This simpler to implement and execute but it will probably take longer to run the process end-to-end.  This is also easier to run in segmented bunches of users rather than as a big-bang migration.  But it will also result in the kinds of behavior you see above.

Both of these options yield the result as though users had been on Microsoft Exchange or Office 365 all along: meetings will immediately be live and updateable including resources.  Nobody else does this with calendars.

Internally we all have strong opinions about the path we’d prefer to take, but we’d rather hear more feedback from the guys who’ll have to live with it.

Drop us a line if you have strong opinions on the matter.  In the meantime we're proceeding with Option 1 (though not taking it to the limits we can) because it's just so much less work on the customer side even though it is considerably more work on ours.

#zimbra client-side vs server-side calendar ICS exports for @MSFTExchange migration

Gotta give props to the guys at Zimbra.

Usually when there's client-side export method and a server-side export method, the results are different.

Here, exporting calendars as ICS gives exactly the same result regardless of doing it client-side (via Preferences-Import/Export)

Or server-side via zmmailbox

And here's the proof.  But stay tuned next week for some additional consequences of different clients on the Zimbra calendar and what it means for migrating calendars in a scheduling-centric enterprise.

..

#Oracle Calendar Server migration to #MSFTExchange: Users OUTSIDE your organization

Got this question in:

What do the partial and full Oracle calendar server migration options do with meeting invitations to guests outside the organization? 

Gentle reader of calendar migration-mindedness:

Re-sending proposals to users outside your domain is OPTIONAL, as below in yellow.

In general – this is confusing as heck to outside users, since they’ve already responded to an invitation and you probably do not keep them all informed about your migration plans. Your internal users KNOW a migration is going on (well, most of them, let's be realistic). But you have ZERO control over users outside your domain.

In general we recommend you NOT re-send them (though we've had one or two that demanded it).

We insert the address in the agenda, so it’s straightforward to keep track of these and add them post-migration if a meeting updates (which is the real issue)

Your call, but I’d treat it as a training and post-migration issue.

@Zimbra Enterprise Calendar Migration to @MSFTExchange Options

So we have one enterprise site that is serious about migrating calendars from Zimbra to Exchange 2013.

Again, we're talking full-state, live meeting migration we do, not the semi-functional, "well it's a calendar, so what if the meeting changes don't update now?" that some folks settle for.

This has caused us to look at our migration methods for large-scale Zimbra to Exchange calendar / tasks / contact migration.  We've got a long-standing weirdness.

In Zimbra an attendee can DECLINE a recurring meeting and ACCEPT a single instance.

This is NOT allowed in Exchange.  You decline a recurring meeting in Exchange and it is gone.

So what we've done in the past is have the attendee accept the series and decline all but that one instance.

We're re-thinking this and might just make the single acceptance a one-time meeting with appropriate modifications on the master recurrence pattern exceptions.

Strong feelings about this?  Let us have your feedback.

Au revoir #MSFTExchange PST

Our love/hate relationship with PSTs is well-documented in our postings.

It is therefore with an odd sense of both elation and dread that we see Redmond itself advocating Deep Sixing PST Files !

Elation is obvious. Dread because.... what proprietary data format horror will they come up with next?

Still, a good read with excellent references for how to handle your transition.

Windows 10 and Calendar / Contact Privacy

For those of you who have upgraded to Windows 10 (and if you had Windows 8 this was a no-brainer), you HAVE to read:  Windows 10 is spying on almost everything you do – here’s how to opt out and Windows 10 defaults to keylogging, harvesting browser history, purchases, and covert listening and Digging into and Understanding Windows 10’s Privacy Settings. 

The most sober reading I've seen comes from Lifehacker.

Now since we're calendar geeks, we're going to show you how to keep your calendar and contacts private, which should be the default in the first place, but is not.

You do not have many choices in your Calendar.  If you want to use Cortona to set your appointments, it needs to check your calendar.  If you are worried Cortona is a nosy rhymes-with-witch who is ratting you out at every opportunity, then turn this off.

You have more choices in your Contacts -- but what "App connector" and "Windows Shell Experience" are is 1.) unclear 2.) why these are options for contacts but not calendar and 3.) WTF?  Microsoft support ducks the question not only about what they are but why they need specific access.

Short answer: beats the heck out of me -- but I dialed my privacy settings to the max.

My main previously unanswered question:  I'm happy with Windows 7 on my desktop.  How do I get rid of the Microsoft annoyanceware in my lower left hand corner?

Simple.

Click that nearly invisible "Up" triangle:

Then select: GWX "Hide icon and notifications"

Yeah!  I get to keep Windows 7!!!!!  And NOT be badgered about it!!!!!!

Our conversion server for Meeting Maker to Exchange still runs Windows XP.  I needed to take the darned thing off the network to make sure Microsoft / Java / Whoever didn't "improve" it by making it unusable with an automatic update.

Mitigating bad user behavior during an #Oracle calendar migration

Got this from the field a few weeks back:
What if we set up inbox rules on each migrating account to redirect invites and responses to some other (non-INBOX) folder - would oCalReader still be able to find them when it comes time for it to respond and clean up responses?

Please do not do this.
Since Exchange delivers the invites to the root mailbox we look at the root mailbox.
Any other folder is strictly verboten.

But -- what you can do:

• Disable Outlook access for the migration period.
• Hide the conference rooms in the GAL (stops a preemptive land rush from users -- this HAS happened)
• Shut off ActiveSync/BES (handhelds are actually a bigger problem than Outlook)
• Tell your users we know who's been naughty or nice from the logs

#MDaemon calendar to #MSFTExchange Migration Trial

Is available here.

For documentation start with this and look at our other posts.

For email you can use Microsoft's tools. but we've found imapsync more effective.

#Oracle Calendar Server to #MSFTExchange Migration and Years of Historical Data

Our latest version of Oracle Calendar Server to Exchange migration will allow you to surface a keyword in our XML Configuration file.

If you're in trial with us now we've told you about it.

If you get a trial from us and this is relevant we'll clue you in on what to do.

But basically you will split up your migration into two runs: the "Current" and the "Historical" -- and for each run you want different keywords.  Why?  So that if something goes wrong in the second run you can remove only THAT data and not the data you inserted before.  At Sumatra we're always looking out for you guys.

For historic data, we recommend inserting without sending email invitations – the process will go faster and you will still have the guest list in everyone’s appointments.  Use this setting:

It’s like “printing” your calendar into Exchange.

So the meetings are not live meetings (but they’re historical so – what’s the problem?) – but everybody’s who had a meeting or appointment in their calendar will have it in their calendar post-migration.

One other thing: For testing using the date range in ocalreader's "Calendar Selection Dates" configuration option is fine.

For a production run, use OCS's UNIICAL date ranges to specify the date ranges in your ICS files.  Why?  You ask.  Fair question.

If we interrogate the date and get a null answer in a migration into production, we’re spending cycles checking when we could be inserting.  This inefficiency adds up over lots and lots of data.

Final word: be careful managing the keyword.

Resources before and after your Microsoft Exchange calendar migration

Please consider this a follow-on to Russ's previous post.

We've got scads of migrations right now at various phases and something that keeps coming up is resource handling ("surprise, surprise" which I always imagine in a Gomer Pyle voice).

Before inserting calendar data into resource calendars, use PowerShell to enable all mailboxes and to disable automatic calendar processing, scheduling horizon, and conflicts.

To enable all resource accounts (pre-migration): 

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | enable-mailbox 


This script will disable automatic calendar processing, scheduling horizon, and conflicts for ALL resources: 

Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | 
           Set-CalendarProcessing -AutomateProcessing None
           -deletesubject:$False -AllowConflicts: $true 
           -EnforceSchedulingHorizon: $False

Post migration you can set these to whatever policies you wish -- but this allows us to re-create the calendar as it was in your legacy system.  A lot of field data has conflicts and double-bookings which get decided closer to the date.  The scheduling horizon on some legacy systems is 2039.

Post-migration to set resources to autoaccept which in Exchange 2013 is done via set-calendarprocessing:


Get-Mailbox -resultsize unlimited  -filter {isResource -eq $true} | Set-MailboxCalendarSettings -AutomateProcessing AutoAccept -deletesubject:$False -addorganizertosubject:$True

Post-migration to DISABLE all resource accounts:

Get-Mailbox -resultsize unlimited | where {$_.IsResource -eq "true"} | disable-mailuser

For private conference rooms you may want to set some policies like “book-in”, “request-in” that allow admins and other authorized people to either send in a meeting request, or be allowed to book a meeting in the room. This way the admin, as a delegate to the boss, can create a meeting in the boss’ calendar and invite a room. And everything flows through Exchange without issue.  A Look at Exchange Server 2013 Resource Mailboxes goes into good detail showing you how to accomplish that.

You don’t want to have rooms organize meetings because they are disabled accounts and cannot respond to email traffic.  Since this is a feature of the ICS exports from Oracle Calendar Server there is little we can do to remedy that situation (since OCS does not indicate the human who should be organizer). 

If you are migrating “shared” calendars, e.g., “carpool van”, “IT vacation schedule”, ”Help Desk Coverage Assignments” then create that entity as a user account in Exchange, migrate the ICS resource data into that entity, and then re-type the account from user to “shared.”  We wrote about the right sequence for migrating Shared Calendars into Exchange and setting them up.

Final note: now keep in mind: this is relevant to do the kinds of calendar migrations we do where meetings are actual meetings when you get done.  For every other kind of calendar migration out there you can ignore this and focus on having your users re-create all their meetings.

Two ways to grant access to a Resource in #MSFTExchange

A client asked us to explain the difference in the two ways for an end user to have "delegate" rights to a conference room.  It is confusing -- Microsoft calls them both "delegation"  and tried to explain them in a recent Exchange Team Blog post, Booking Delegation Vs. Classic Delegation.

Here is the summary:
1. Grant delegate permission using Outlook or OWA (aka "Classic Delegation")
2. Grant delegate permission using Exchange Control Panel (aka "Booking Delegation")

There are three problems with the "Classic Delegation" for conference rooms:

• First, since rooms are "disabled accounts", it's hard to log into them.  
• Second, Classic Delegation creates two rules -- one visible (IPM Subtree folders), and one invisible (think NON-IPM Subtree folders.)  When you change/remove a classic delegate, the hidden rule does not always get deleted and thus still remains in force. (Why? Outlook tries to be helpful, and when it sees there is a hidden rule, it uses the hidden rule.) 
• Third, the classic delegation rules run at a higher priority than  booking delegation rules.  More ways to confuse administrators.

Moral of this story: don't use Classic to delegate access to rooms. Sumatra urges all our migration customers NOT to migrate delegates -- once set they are difficult to remove (see our post from '08).


Sumatra recommends you assign room delegates using the "Booking Delegation" approach.  You can either use Exchange control panel to assign booking delegates, or PowerShell.  We prefer PowerShell.

There are several things you must do, depending upon how you want to handle room reservation requests

For auto-booking:
Ensure automated processing of meeting requests is set.
Example: Set automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing AutoAccept

For a managed room:
1. Ensure automated processing of meeting requests is disabled.

Example: Disable automated processing for conference room 101B
Set-MailboxCalendarSettings cr_101b -AutomateProcessing None

2. Decide on your room administrators,  grant them permission, and allow the room to receive requests but NOT allow direct booking.  (You and also play with Book-in and Request-In policies starting with this old but good Technet Article....this is beyond the scope of our post, though.)

Example: Allow Russ Iuliano to manage Auditorium meeting requests. 

Set-CalendarProcessing Auditorium -AllBookInPolicy $false -AllRequestInPolicy $true -ResourceDelegates "Russ Iuliano"

3. Grant administrators permission to send on behalf of the room.

From time to time, you may not
Example, Grant delegate "riuliano" send as permissions on behalf of Room CR 101B
Add-ADPermission cr_101b -Trustee riuliano@sumatra.com -AccessRights "Send As"

Finally, You can read more about creating and managing room booking on Microsoft Technet.

Which version of Exchange should you be on for a calendar migration?

For a Sumatra calendar migration you should be on the latest update to Exchange (currently Cumulative Update 9).

At the very least, CU6, owing to that fixing problems with Contact Notes.

We spent an hour last week diagnosing problems with Exchange 2013 CU 4 -- once the Exchange environment was updated the issues went away.

Manifesto for Calendar Server Migration

What are the current gaps in calendaring migration?

Calendaring is fundamentally different from email even though it usually uses it as a transport protocol.

Historically all migration solutions have focused on email.  Not surprising since email is a mission-critical concern.

But where email is static once you have sent or received it, calendars have a crucial difference:  they contain evolving meetings that are linked to the calendars of other individuals in the enterprise.  In Exchange changing a meeting updates the calendars of attending resources and individuals.

And in a real migration you need to take these links and the data associated with them along or you’re only doing part of the job.

Nobody except Sumatra Development does this for calendaring.

Solutions other than Sumatra's treat calendars exactly like email:  they create the events but do NOT recreate live meetings because they ignore the guest lists, responses, recurrence patterns and resource  bookings.

Think if it like this: they take a print-out of a calendar and migrate that. We call this a “flat” migration. Most do not even take recurrence patterns. 

Sumatra re-creates the state, creating live meetings with guest lists (which you might have to map to new domains or addresses), responses, recurrence patterns, exceptions, and resource bookings.

We call this “full-state.”

Even in the on-premises Exchange to Office 365 world, Microsoft focuses on email and does not even offer a calendar migration path.  So we went out and blazed our own full-state migration method.

For small sites this is a tractable (if unpleasant) problem. It's still a productivity loss, but we’re talking a couple of hundred users.

For sites of 500 or more users the productivity hit can be immense.

Put another way:  after a full-state Sumatra migration the user and resource calendar data experience a seamless transition:  as though the enterprise had been using their new calendaring system all along.  With other solutions users actually need to find and recreate their meetings to make them live and update-able.

Finally, other solutions willfully ignore the possibility of failure.

We have an UNDO strategy to gracefully remove only the data we put in in in the event of catastrophe.  (We have seen servers fail in the middle of migration).

This is of course an overview from jet plane altitude and by the time we get through the first test phase with a client we’ve brought them to tree-top level.

Our web site: http://www.sumatra.com

It shows how our migrations work, and it also highlights some of the things
we’ve done in calendaring.

In a nutshell: if it involved MS Exchange calendaring / scheduling we can do it.

On-premises @MSFTExchange Migration to #Office365

A PowerPoint Presentation about migrating from on-premises Exchange to Office 365.

The Migration section does not specifically call out calendar migration -- but that's what we specialize in.



Towards the end the notion of a back-out plan is one of the main things we constantly harp on.  Our calendar migration can take Exchange to Office 365 preserving guest lists, responses, and recurrence patterns, and do it in BOTH directions and it includes an UNDO to selectively remove only the data inserted.