Finally Microsoft does something to fix the terminated user problem of ghost meetings.
Remove-CalendarEvents -Identity user@domain.com -CancelOrganizedMeetings -Confirm:$false -verbose
Arm yourselves with knowledge!
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.
Finally Microsoft does something to fix the terminated user problem of ghost meetings.
Remove-CalendarEvents -Identity user@domain.com -CancelOrganizedMeetings -Confirm:$false -verbose
Arm yourselves with knowledge!
Our latest version of Kerio migration code adds two options to the XML file to deal with autocomplete contacts.
We found some weird calendar stuff in Kerio when using BusyCal.
RRULE;X-BUSYMAC-REGENERATE=TRASH:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=16
This (really weird) addition to the iCalendar format was causing us some problems with the recurrence pattern until we coded around it.
Apparently it's been reported as a bug in in their forum since December 2020. https://github.com/jens-maus/node-ical/issues/67
But rather than waiting for someone to fix a moribund client to moribund server we coded around it to make it easier for folks to get into Office 365.
Microsoft must have realized this was an issue – they finally made it easier to temporarily change EWS Throttling under admin control.
And by "easier" I mean it is "possible if you know exactly what you are looking for."
So to remove EWS Throttling
Login to Exchange Admin
Click Support and
follow with New service requests.
In the search field, search for Increase EWS Throttling Policy.
Select that from the list
Click Run Tests – it will first tell you are throttled (big surprise)
Click Changing EWS Settings – select 30/60/90 days
Run Tests again. – Should now be good to go.
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.
One of those things we always worry about is data integrity.
We've seen weird stuff.
And now it's Kerio's turn to provide us with weird.
Take a look at this raw ICS file from some recent field data:
Not hard to generate odd situations with a variety of clients on a technologically moribund server.
We recently announced that we've started work on a Kerio Server Migration to Office 365. One of our clients gave us test data from a few departed/terminated users to test our code. It's easy to test in our Exchange on-prem sandbox to ensure no "external" email gets sent to their users -- we unplug the Ethernet connection to the Router. It's a little more complicated in Office 365, but not all that difficult. Here are the steps:
In the Exchange Admin Center, under Mail Flow, Rules, click the "+" sign to create a new rule.
Here is a screen shot:
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.
Got this in the mail today from our friends in Redmond, Washington:
We
are updating our receiving limits in Exchange to help prevent attacks on your
mail flow experience. Earlier this year in (February MC239262) we announced a
stricter enforcement of our mailbox receiving limits. Taking your feedback
into consideration, we are
releasing an additional limit to block single-sender mail storms and deter
DoS attacks. Our mailbox receiving limits, as previously stated, apply to the
messages received by a Microsoft Office 365 mailbox. If volume exceeds 3,600
messages in a given 60-minute window, the mailbox will no longer accept
messages from the Internet, from other tenants, or from on-premises senders. Starting in September 2021, we are adding a limit on
sender-recipient pairs (SRP). This feature will apply to the messages received
by a Microsoft Office 365 mailbox from each specific sender. If a single
sender sends over 33% of the threshold (3,600 per rolling hour) to a specific
recipient, the SRP limit will kick in, and the mailbox will no longer accept
messages from that sender. The mailbox will continue accepting messages from
other senders. Note: If the identified sender is from a
Microsoft Office 365 mailbox in the same tenant, messages will be allowed
even after the limit is exceeded. If the identified sender is from an on-premises
mailbox, a Microsoft Office 365 in a separate tenant, or outside of Microsoft
Office 365, messages will be blocked. This change helps prevent a malicious user from blocking mail
flow to a Microsoft Office 365 mailbox, as part of our continuing efforts to
improve your Exchange Online experience. Key Points:
How this will affect your organization:
Rollout of the mailbox receiving limit as detailed in (February
MC239262) is ongoing. We are continuing to lower the threshold over the next
few months until we reach 3,600. Rollout of the SRP limit will begin in September 2021. This limit
is set to 33% of the mailbox receiving limit. Note: Most users are not likely to be
impacted by this, as only a small percentage of mailboxes are currently
hitting SRP limits. If a mailbox exceeds the SRP limit, messages to that mailbox from
the identified sender will be throttled. Affected mailboxes will receive an
email informing them of the throttling, while the identified sender will
receive a non-delivery report under response code 5.2.121. Emails from that
sender will be throttled until the limit resets one hour from when the
threshold was exceeded. Administrators will be able to view users that exceed their SRP
limit through the “Mailbox exceeding receiving limits” report in the Exchange
Admin Center. Please contact affected users to understand why they are
receiving so many messages from particular senders. What you need to do to prepare: No direct action is required on your part, though it is
recommended that you review the new limits and update training and
documentation as appropriate.
|
OK folks, we have an updated version of our Travel Time add-in for you.
Documentation
Privacy and Permissions
We hate spyware. Sumatra’s Travel Time Outlook addin does do not collect ANY of your calendar information, passwords, usernames, etc. Only you know what you’re using this for. We will rely on you to let us know what you think.
This applications runs only on your machine, and only if you are logged into Office 365. You do not need your administrator to modify your company’s server permissions. BUT, this add-in requires read-write access to your mailbox (otherwise we can’t create new appointments).
You will need to side-load with this address:
Throttling is a wonderful feature to get rid of during a migration. You have the need -- the need for speed. Throttling can sometimes be the annoying speed bump or rumble strip that at best slows you down and at worst halts your migration.
Fortunately there's a good guide to how to disable using the user interface on Office 365: Disable EWS throttling in Office 365 – Exchange Online
We don't re-do work that's already been done -- this is a good, straight-forward guide.
If your interface does not have this option, open "Help" and type in "Increase EWS Throttling Policy." Should bring up this page and you're good to go.
If you're migrating from Apple's calendar offering, you need to map the user GUIDs to target email address in Office 365 / Microsoft Exchange.
Your mapping text file should look like:
------------------------------------------------------
DB9F0913-DC4A-41CA-8017-6EF5814F01CD, jimi.hendrix@xxx.onmicrosoft.com
FB5CA163-99B8-4436-A906-CC72000E931D, janis.joplin@xxx.onmicrosoft.com
....
------------------------------------------------------
How do you GET the GUIDs?
Via an LDAP Query is most convenient.
https://krypted.com/mac-os-x/export-data-open-directory-migrating-users-groups/
and
https://github.com/krypted/swift-ldif-csv/blob/master/ldif_to_csv.swift
Go to it!
What can we say? We're market-driven.
We didn't get much response the first time we did a travel time add-in for Outlook / OWA, but in the last few months our volume on this has improved so we re-wrote the code.
Our thinking is that we'll keep the version we currently have available for free (it's based on version 1.4 of the Outlook JavaScript API) while we work on a more full-featured version for the enterprise..
Want to try it out -- contact us.