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

Non-mapping contact info in migrations from Zimbra to Office 365

It happens.

You have data in custom contact fields in Zimbra that do not map one-to-one to existing contact fields in Office 365.

So this contact, Horatio Warmonger in Zimbra has info like this:

Note his current "Note:" field in Zimbra pre-migration:

Have no fear -- Sumatra's migration takes all contact data not readily categorize-able in Office 365 and inserts it into the Notes field.

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.

Migrate Zimbra Calendar and Contacts to Office 365

Since 2001 Sumatra Development has been doing full-state migrations of legacy calendar systems, where meetings are functional meetings and guest lists are functional in meetings.

This is our answer to demands for a less expensive, simpler, faster migration path for smaller sites and enterprises that do not need full-state meetings.

If you can migrate your email from Zimbra to Office, you can now migrate your calendars and contacts, using the same permissions and similar methods.  No limits on the number of users you can migrate but we cap code at 30 days (we're willing to talk on timing).

This is a fast, simple method for moving calendar and contacts from Zimbra to Office 365.

So Jimi Hendrix's calendar in Zimbra:

Becomes his calendar in Office 365 in a few seconds (as opposed to a PST or an export/import).

Since this is faster, simpler, and cheaper, we do not re-create meetings in this version -- but we do make it easy for you to find meetings you organized and the guest list:

Our experience so far shows this method takes considerably less than half the time and effort on the part of Admins than our full-state solution, and that it is of course much faster than client-side solutions.

Win-win!

Conference Room Calendar Migration from Zimbra to Office 365

Our latest version of Zimbra to Office 365 calendar migration is also moving resource calendars fine.

So for instance a Zimbra resource calendar (Room_222), has a schedule that looks like this one week:

Comes into Office 365 looking like this:

Keep in mind this is also server-to-server so it's fast and much less hassle than going via PSTs.

Since this is a fast-flat migration we make this convenient on the side of the end user by including the information that the resource was booked in Zimbra.

Remember Exchange 2010?? If you still have it, read on....

A friendly reminder that Exchange Server 2010 End of Support is (Still) Coming.

We don't normally see Exchange except for the current version, but we feel the need to pass on info like this.

Support for Exchange 2010 ends on January 14, 2020.

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

Travel Time for Outlook -- our first pass -- we want your feedback

We spend a lot of time making calendar data go into Office 365 / Microsoft Exchange.

So when one of us (Russ) needed to do all sorts of travelling for a community project he was on he immediately started wondering:  WHY is there no good way to add travel time to an appointment or meeting in Outlook?

February 2021 We've gotten three requests about this over the last few weeks.  If you're a corporate entity that's interested, drop us a line infoATsumatraDOTCOM.  We're in a soft re-opening of the code.

Of course since he runs the development group at Sumatra he was in a position to do something about it and over the past few months has been engaged in the admirable engineering tradition of skunk works projects.

Truth be told, EVERY project at Sumatra is skunk works, but no matter.

Herewith we invite you to try out our first pass at Travel Time for Outlook.  It's not as full-featured as we envision but it's as functional as other offerings we see people wanting to charge money for.  And we'll let you use this for free.

What this looks like on Office 365:

It's a small icon

Pressing that gives you these options:

Saving it gives you this:

So far pretty simple and we've got our directions for extending it.  But we're listeners.

You'll have to contact us for the URL to install from, but as long as you're willing to provide feedback we're game.

How to install this:

• Sign in to Office 365: https://outlook.office.com/owa/
• Pick the “gear” icon and select Manage Add-ins

• Choose Add-ins, My add-ins, Custom add-ins, Add a custom add-in, Add from URL

• Contact us infoATsumatraDOTCOM for the URL to use.
• Accept the warning, etc.., then close
• Go to your calendar. Create or open an event
• Select the Travel Time icon

Now you get to add travel and/or return time.

There's a lot more work to be done but this is a start and we'd welcome your input on how you're using it.

Make Several Gmail Addresses Out of One

Love this TechTip from the New York Times:

Make Several Gmail Addresses Out of One

Enterprise Exchange / Office 365 Resources: You can manage them better

As an enterprise Exchange / Office 365 administrator you've probably run across some problems that drive you bug-house: security, backup, compliance, forensics, response time, .... the list drones on like a "Wonderwall" knock-off.

But one thing we can help you with is RESOURCES.  There are a series of things you can do to make your resource management smoother from an end-user experience in Exchange.  AND you can do them server-side.

The resources we're talking about here are the resources in a calendaring sense: Rooms and objects/services that are scheduled with meetings.  (I mean, you KNOW this is what the whole blog is about, right?)

A (few) word(s) of warning on prerequisites here:  it helps to have experience with PowerShell and Permissions.  You are definitely going to need experience setting permissions for resources in Exchange. 

We've blogged on all of this before, but this is the first time we've put it all together in one convenient post.

Let us begin.

Have you really thought through Delegate Access?

You may be using Delegate in the less effective way.  In general you should use booking delegation instead of classic delegation.

See: Two ways to grant access to a Resource in #MSFTExchange

Explanation:  Booking delegation makes it easier to access the resource should you need to (since classic delegation resources are disabled accounts by default) and you do not have issues with server vs. client-side rules and priorities.  

This does mean having resource delegation managed by the administrator.  As we proceed you'll increasingly see how this saves you hassle later on.

Do you ever have two meeting groups showing up for the same room?

You have had a double booking issue and didn't think you could do anything about it.

We KNOW you do because Double-Booked Meeting Rooms in Office 365 (and how to avoid them) is one of our most popular posts EVER!

But you can

If you just want to see how big an issue you have, use our reporting tool:
See: Callable PowerShell script to report on double booked resources in Exchange 2016 / Office 365
it's a PowerShell script that will tell you which resources have double-bookings.


If you want to proactively manage the issue on an on-going basis -- check out our solution to the problem:

Three Basic Ways of Dealing with Double-Booked Resources in the Sumatra cmdlet

Zimbra to Exchange / Office 365 Calendar, Contacts, Tasks migration again field-proven

Once again we've migrated a domain from Zimbra to Exchange 2016 -- calendars, contacts, and tasks.  They also followed our guide to Zimbra email migration with imapsync.

This in itself is not noteworthy.

What was different about this was it was a municipality running at small scale (100 accounts) and they took the lead on running the migration themselves with little input from us. So they could keep their costs down while still getting a high quality calendar migration.

To quote them:

The migration went off without a hitch – no complaints that I have heard about missing items.  Thanks so much for the helpful tool!

Huzzah!

The system works!

New Zimbra Authentication Options in Office 365 Calendar Migration

Zimbra on-premise migration customers have typically kept their legacy directory services until they went live in production. 

When customers migrated from hosted Zimbra, they ran a hybrid deployment (i.e. ran directory services in parallel with Office 365.)  

Typically, both legacy and target servers were in the same domains. That is, until we received a request from a client who wanted to migrate from Zimbra to Office 365 AND change the domain name.  

In zCalReader 6.2.03 and above they can.

A pull-down on the configuration screen will let you choose your URL format based on your authentication scheme. 

Note: You should still use your Zimbra Admin credentials for the Zimbra side.

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.