How long is your migration to Office 365 going to take?

 Your rate limiting step in a migration is moving and synchronizing your email.

It's going to take weeks at a minimum if you have a site of any size.  More likely it will take months.

Why?  Because likely you have over 100 Gb of email files and that's just going to take a while to process and (thanks to the IMAP protocol) continuously synchronize until your cut-over date.

The IMAP protocol is a godsend for these purposes.  So getting started early and watching the amount of data you have and have moved is going to be a key part of the process. 

Sadly, no ready protocol exists for calendars, contacts, and tasks.  So you need to one-off those and you should expect them to take hours just before cut-over.

That's why testing the snot out of everything is our mantra.

Daylight Savings Time might be permanent? Your legacy systems might be in trouble.

So Congress voted to make Daylight Savings Time permanent.

 Last time the DST changed Microsoft got caught with its pants down.  Actually they were completely off and their underwear was dirty -- but who needs to remember that?

Well, actually we all do now -- because if you've got a legacy system -- and SOMEBODY keeps reading on our blog about Exchange 2007... you might need to do some legerdemain on your data to keep it working.

OR if you're migrating from a legacy system into Office 365 you are going to be facing problems.

If it's BIG for you -- drop us a line.

We did this before.

Video of Kerio calendar and contact data migrating to Office 365

 

Return with us to the days of the silents.  

To start -- a blank calendar and a single contact in Office 365.

We insert data using our latest tool from a single user.

You see the calendar data insert and then the contact data.

We then use our selective UNDO capability to remove the data.

This is all happening in real time -- no editing.

Omicron’s silver lining, or why this pandemic is a good time to migrate calendar data to Office 365.

If you've had a legacy calendar migration on your to-do list for a while -- the global pandemic is actually a really good time for it.

Why? You might ask. Short answer: conference rooms.  That makes no sense since everyone is working remotely.  Have the Sumatra guys lost it?

We’re going to share a secret about calendar migration for you today that will save you tons of future agony.

There are three groups you have to consider in a migration – CxOs, end users, and conference rooms.  Your most important calendars are the CxO’s.  Our tools migrate those correctly and with guest lists and responses intact.  

The next most important calendars are not your users – it’s your conference rooms.  

HUH? 

Sumatra has 20 years of real-world experience that users will accept disruption associated with data migration if you tell them in advance and apply the rules equally to everyone.  The exception to the rule is conference room bookings.  There will be hell to pay the second you mess with users' conference room bookings. 

Sumatra’s customer would usually chew on this for a few seconds and then go "Darn -- you're right!"  

With users working from home for the past year, there is minimal demand on the conference rooms, and therefor minimal risk in upsetting the proverbial apple cart.  Eventually there will be a return to the office, and that will complicate your future migration plans.   

So start your migration plans today and avoid the potential for future conference room migration headaches.

PS: in a future log post, we’ll talk about how to minimize the dreaded “double booking” found in conference rooms in Office 365 (we've been doing that for years, but somehow it's always a topic).

Kerio Connect to Office 365 Migration Field Proven

So we at Sumatra are very happy to announce in 2022 (entering our third year of the COVID pandemic!) that we have successfully field-deployed a Kerio Connect to Office 365 full-state calendar migration tool!

Huzzah!!!

A couple of screen shots of the capability:

We ran it in December 2021 at a law firm in the Boston, Massachusetts area!

Many thanks to all involved there for their testing and attention to detail that made it a success!!

The user IDs from legacy Kerio are mappable to new IDs on Office 365.  

We of course re-create meetings as meetings with guest lists and responses so it's a huge level above any export-import methods you see out there.

And we can also preserve resource bookings in a Kerio to Office 365 migration -- though our client did not migrate resources so we're looking for a partner to prove that works as well.

Details on request -- please just drop us a line.  Please also let us know the specifics of how many users you'd like to migrate.

Multiple Domains in a Kerio Calendar Migration

You know how it is -- you've had your legacy system for YEARS and sometime in there you changed domains from say OLDCOMPANY.com to NEWCOMPANY.com or something like that.

And now as you are migrating into Office 365 you wonder if you can take all that over and have it work in calendars the way it used to.

Have no fear -- you can do that.  Just put both in as in the screen shot on your configuration page.

 

Kerio Connect Migration to Office 365

So we got a request for a Kerio Connect to Office 365 calendar migration from someone who we discovered was an old pal from the early days of group scheduling.

How could we say no?

So we've got that under development now -- anyone else interested in testing it out please drop us a line.

We've got full-state calendar migrations going, as well as contacts and tasks.  

Notes become tasks (because Microsoft's EWS API does not allow us to create Notes). 

A few of the recurrence patterns do not transfer to Office 365 so we insert them and flag them as problem children.  Biggest example: Last weekday or weekend day of the month is supported on Kerio but not in Office 365.  

Of course we include our UNDO functionality for testing and remediation. 

DAVical to Office 365 calendar migration in beta stage

You guys might remember our earlier posting on DAVical migration to Exchange / Office 365.

Well, we went ahead and started it based on a request from Europe.  

If there's anyone else out there who's looking for this please drop us a line.

SOGo calendar and contact migration into Office 365

We have migration from SOGo calendar and contacts to Office 365 working in  our lab.

As usual, drop us a line if you're interested.

Zimbra to Office 365 Calendar Migrator trial download

We went ahead and made the trial for our $499/server 30-day activation Zimbra to Office 365 calendar and contacts migration software available on line and via online download syndication.

You can download the trial software here.

You can see the PAD file here.

And on this very blog there are a variety of other posts about the product as well as the current state of Microsoft Graph (spoiler alert: functional but incomplete) upon which we built this.

Microsoft Graph Permissions for Zimbra to Office 365 Calendar Migration

This application uses Microsoft Graph, and follows its permissions reference so that this application can obtain access without a user

There are THREE STEPS you must follow

1.       Find your Office 365 Tenant ID

2.       Create a new App Registration for the Z2O365 application

3.       Update the appsettings.json file

This is the walk-through:

1.       Find your Office 365 Tenant ID in the Azure AD Portal:

a.       Login to your Microsoft 365 Admin Center or Microsoft Azure as an administrator.

b.       We found the “PREVIEW” version to be a better experience (as of 1/30/2019)

NOTE: if you select preview, you can skip this step -- you will be able to see the tenant id in the second step

c.       In the Microsoft Azure portal, click Azure Active Directory.

d.       Under Manage, click Properties. The tenant ID is shown in the Directory ID box

2.       Create a new App Registration for the Z2O365 application

a.       Login to your Microsoft 365 Admin Center or Microsoft Azure as an administrator. (you just did this above)

b.       In the Microsoft Azure portal, click Azure Active Directory.

c.       Under Manage, click App registrations (preview)

d.       Create a new Registration

                                                   i.      Enter a name (your choice)

                                                 ii.      Select accounts in this organizational directory

                                               iii.      Click Register

                                               iv.      Under View API Permissions, Add permissions calendar read/write, contacts read/write

                                                 v.      Grant Admin Consent

                                               vi.      Under Certificates & Secrets, create a Secret

3.       Update the appsettings.json file

·         Under the AppSettings, add:

o   The APP Name

o   AppTenantID

o   AppID

o   AppClientSecret

Calendar Recurrence Patterns NOT supported by Microsoft Graph and What Sumatra Does About Them

Microsoft is obsoleting Exchange Web Services (which is too bad since it's been working like a champ) in favor of Microsoft Graph (which is too bad since it's.... immature.)

One of the sad consequences of this is that some recurrence patterns for calendar events which can be created in EWS are impossible to create in Graph.

For example:

What does this have to do with the price of tea in San Francisco?

We're in the business of migrating calendars.

When the recurrence pattern isn't something we can re-create we get testy.

We insert in the standard format, hoping that when Microsoft Graph gets its act together to deliver something like this we're going to be seamlessly running.  Even though the results are a little weird on insert you can correct them by opening the series and re-setting in Outlook.

But we do make it easy to find these.

We tag problem recurrences with "ZimbraRecurrencePatternNotMigrated" (this is configurable on a server-basis).  So you can readily find them.

You can easily sort them all together in Calendar List view:

You can also set the color for these categories to find them in your calendar.

Note that in the above example we have the category "ZimbraMeetingsYouOrganize" (yes, the names are configurable on a per-migration basis) to help you find meetings you organize and re-propose them.  Our full-state migration process makes this step unnecessary.  But full-state is also more expensive.

Migrating Zimbra calendars and contacts to Office 365 via the Microsoft Graph API

Folks,

Microsoft is sun-setting Exchange Web Services (EWS) which we have been using for about 10 years for migrations in favor of Microsoft Graph.  So we're porting our code to the next generation of technology.

We've got Zimbra calendar and contacts going into Office 365 via the Microsoft Graph API in our lab and are looking for a few test sites wanting to move calendars and contacts as next generation early-adopters.  

If you can run imapsync or the Microsoft email migration you can use the same permissions to move calendars for all users server-side with no intervention.

And we've radically simplified our interfaces.

If interested drop us a line via our contact page.

Exchange online: Conference Room Provisioning changed to AutoAccept

A heads up for admins who plan to provision new resources in Exchange Online: the defaults will change from AutoUpdate to AutoAccept.  This change will occur on November 15, 2018.


What does this mean? It's another 80/20 rule: depends on the type of resources and if you are a new or existing customer.


For existing Office 365 customers:  

• 80%: Most of our clients configure resources (rooms, equipment) as AutoAccept. If the user wants to book a room on a particular date/time, Exchange will book it if it's free. 
• 20%: "Managed" rooms.  Those are the ones only specific users can book, or an admin has to approve. Examples are the Executive conference rooms, HR Interview rooms, the Auditorium, etc.  For those rooms, this will be a problem. 

For new Office 365 / Sumatra's Migration customers,

• NO IMPACT:  For all migration customers, we recommended you set ALL of your rooms to either None or AutoAccept (depending upon the migration tool). You will replace the defaults.

To check:
Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing | Format-Table-Property Identity, AutomateProcessing





See the MS announcement here: Exchange Online - calendar AutomateProcessing changes through PowerShell

False positives in antivirus software

So last week we had a low-level inquiry from a company wanting to migrate MDaemon calendars to Office 365.

They'd already tried the arduous PST method and found it wanting.

So we set them up with a trial version of the migration software.  Next thing we heard from them was that TrendMicro AV was flagging it as containing ransomware.

Seriously?

Like, how realistic is it for us to send out ransomware when we maintain a blog going back to 2005 (you're on it), a public web site, a Twitter account, and we give you our direct email addresses?

A quick search in the spirit of JFGI for "false positives antivirus" gives some insight.

So this is not just something that is affecting us.

We can understand your caution.  We in fact encourage your skepticism and welcome your desire to challenge us.  Anyone who's been through our various doc sets for migrations knows that we promote planning and preparation.

Since our code works on Exchange / Office 365 servers it is by definition server-modifying, so I can understand how detection algorithms could get wary.

Keep in mind, though that Sumatra Development is one of the few companies you deal with where if you're not talking to the people who wrote your migration code you're only one degree of separation away from the person who did.

A migration WE were put through......

This is a bit of a departure for us.

Most of the time when we write about migrations it is us at Sumatra enabling a migration from a legacy calendar server into Microsoft Exchange for someone else.

Recently though WE were the recipients of a migration.  In this case of our web site and associated on-line presence from one hosting company to another.  

Initially this was not our choice as IX Webhosting got bought by Site5.

We had a completely miserable experience! We want to share the points of failure.  Doing our own migrations since 2001 (really?  It's been that long?) we've battle-hardened our own processes and documentation to deal with all of these issues -- but the fact it happens in a scenario that was much simpler than a full-state calendar server migration shows how easy  it can be to slide into the Upside Down.  We'll first talk about the timeline, then the lessons learned.

Timeline  If you want to see a rough timeline as it played out in Twitter -- check out our feed.

This email was our first warning this was happening:

Note the up-beat tone, the promise that all of our content should be there for us, and the lack of any warning to back-up or how to escalate if/when things go wrong

Yeah....  already the Spider-sense was tingling.

But I figured I'd get another communication telling me WHEN they were transferring our site since that's kind of a big deal.

Nope.

"Ruh Roh Raggy!"

Our first indication was when our email, site, and FTP access went down on Tuesday April 17, a week after this missive.


We were able to get email up pretty quickly thanks to our knowledge that the MX records and DNS servers needed updating, and we were almost... kinda... (*sort of...*)  not not really anywhere near getting our web site running again.  We just ignored other things like FTP by this point.  

To be fair our data and settings DID stay the same (as promised) -- they just weren't set in any of their systems properly.  I'm sure years of weasel-like business practices went into that intro letter without considering the customer impact.

We waited three business days for them to resolve the problems.  But by Friday morning when they misconfigured our SSL certificate, causing visitors our site to be redirected to a site in Peru, we pulled the rip cord, fired Site5 and went with TMD Hosting who got us up and running in really good time.

How bad was Site5?  Seven days after we'd severed relations with them, gotten our site up and running on TMD, and propagated our new DNS, Site5 support contacted us to tell us they were still working on the problem.  Yeah, guys, you keep us in that loop!

Lessons Learned (from what went wrong):

• There was no honest communication from the get-go -- and I mean zero.
• There was no public time-line
• There was no back-out plan
• There was no opportunity to test.
• There was no parallel hardware available (literally copy data to new machine then decommission the off old machine)
• There was no ability for quick response and communication

Happy to say that this debacle did not affect the main migration going on at the time.  Why? Because we're big in up-front communication, warn people that things can (and do) go wrong, create a plan that deals with things when they do.

DAVical and Open Source Calendar Migration to Exchange / Office 365

We got an inquiry a while back about migrating DAVical to Exchange.

They vanished as happens in the way of people with more ambition than budget, but it did get us thinking about how to do Open Source calendar server migration to Exchange or Office 365.

This is made easier because we already have a full-state migration method out of Zimbra into Exchange and Office 365.

Works like this:

Short answer is I'm pretty sure we can do it using the REST implementation we already implemented for Zimbra.

In Zimbra the format to download an ICS to our migration is:

http://SERVER/home/username/calendar?fmt=ics

In DAVical (https://www.davical.org/clients.php) it's

http://SERVER/caldav.php/username/calendar/

The ICS is close enough that it presents no problems, and there is admin access to all accounts.

So we have a decent chance of getting this to work.

Also Zyg's tried it out in the lab and got it to function, but undoubtedly there's a bug or two in there that real-world hardening will discover and squash.

So sites with several hundred users and a willingness to spend part of their test phase in careful mode can feel free to contact us.

DAVical is built on top of PostgreSQL which we read in order to migrate Apple's iCalendar server, but there's no indication that's a superior migration path.  And it represents a little more work so -- nope.

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.