Sumatra Development leads the field of migrating entire calendar servers to Exchange. We migrate Oracle Calendar Server, Oracle Beehive, Apple iCalendar, and Zimbra to Microsoft Exchange keeping all meeting information and resource bookings intact. We migrate calendars server-to-server between Exchange and Office 365 while keeping meetings live and doing incremental syncs quicker than any other solution.
We in Sumatra migrate meeting data. We cannot however make your meetings any less soul-crushing.
I'd love to give credit to the originator of this if they tell us who they are (came to me by way of my cousin who got it from his feed who posted it from some other feed and yadda yadda yadda).
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:
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.
I went to a local Microsoft presentation that was supposed to be a "Deep Dive into Office 365 Security." Word of warning: Very rarely is any Microsoft presentation a deep dive. This one was no exception as the presenter spent way too long talking about weak passwords and putting up vague slides that were really good at telling you what your problems can be but way too vague on how to specifically, actually solve them. Still this Microsoft shill was up-front that the slide contents came from this posting: Security best practices for Office 365 Not a bad summary of issues you need to face as you move to Office 365. The links include how to activate specific security safeguards in your Office 365 environment. Now: It seems to me that since this environment is completely in the hands of Microsoft, which as a company should be really concerned about client security, perhaps a decent subset of these should be turned ON by default with instructions on how to turn them off, instead of OFF by default with instructions about how to make your Office 365 experience more secure. But that's just me wondering WTF?!?
If you've seen our earlier post Migrating Delegate Permissions: The 80/18/2 Rule, you know that in on-premises Exchange at least you can use the Add-MailboxFolderPermission cmdlet in PowerShell to set Delegate Access. Now Microsoft is allowing you to use this capability on Office 365. Sidebar: Is anyone else getting tired of discovering which cmdlets work in on-prem Exchange but not in Office 365 by Microsoft's tried-and-true method of "well, walk into the minefield and if you do not explode you'll be fine?" Log into your Admin account and you should be able to see this update:
This lets you use effective scripting and server-side methods to handle Delegates. As we always counsel: Be really careful how you set up Delegates in Exchange / Office 365. See our article: Two Ways to Grant Access to a Resource in MSFT Exchange. and use the "Booking" Delegation approach.
