Migrator Notes-Exchange and editing items through EWS

Hello Alexander,

Thanks for posting to the Migrator for Notes to Exchange (MNE) community forum. I understand you are experiencing issues when editing migrated calendar items using Exchange Web Services (EWS).

1.) MNE is designed to migrate Notes data to Exchange by mapping the source Notes information to the target Exchange mail system. Although MNE allows you to manually change the target mailbox to which items are migrated, it may be possible that this change could introduce limitations. We would suggest creating a Service Request to investigate this issue further.

2.) Just to clarify, you are stating that MNE migrated an appointment as an appointment, but after you manually edit/update this appointment in the target it is being changed into a meeting, is that correct? We would suggest creating a Service Request to investigate this issue further.

3.) Just to clarify, you are stating that MNE migrated the calendar entries using the correct time zone, as verified in Outlook, but EWS is showing the incorrect time zone, is that correct? Is this before or after modification? Have you compared this behavior to calendar entries that were natively created in Outlook/OWA? We would suggest creating a Service Request to investigate this issue further.

4.) Just to clarify, you are manually updating migrated all-day calendar events that were created in the W. Europe time zone, to include a new time frame and those mail items are being updated to UTC time instead. Have you compared this behavior to calendar entries that were natively created in Outlook/OWA? We would suggest creating a Service Request to investigate this issue further.

The issues you are describing here are advanced topics that will require further investigation. We will need additional information, such as the exact version of MNE used for the migration, the exact version of Domino you migrated from, the exact version of Exchange you migrated to, code you are using to make changes, migration log files, etc. In order to protect the privacy of your information, we would suggest creating a Service Request for each of these issues so that they can be thoroughly investigated.

Hello Alexander,

I will bring your question to the attention of the product team. In order to better help us understand your situation, are you able to provide details about the edits you are making to migrated items and the process you are using to edit them?

Thanks,

Hello Trevor,

I think it does not make sense for me to provide the full code, since it cannot be understood easily. Let me see whether I can get an excerpt tested against our customer's test accounts in the near future, which I could provide to you.

Until then, I expect the relevant excerpt to be as follows:

We are using the most recent EWS Managed API library from github, opening the service object with the StartTimeZone that we want to set:

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2016, TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time"))

then we provide credentials and do autodiscover, and then we load an EWS item through

Appointment.Bind(service, new ItemId(uniqueId), propertySet)

with the propertySet defined as:

new PropertySet(AppointmentSchema.Id, AppointmentSchema.Start, AppointmentSchema.End, AppointmentSchema.Subject, AppointmentSchema.Location, AppointmentSchema.AppointmentType, AppointmentSchema.Body, AppointmentSchema.RequiredAttendees, AppointmentSchema.OptionalAttendees, AppointmentSchema.Resources, AppointmentSchema.Recurrence, AppointmentSchema.Organizer, AppointmentSchema.ReminderMinutesBeforeStart, AppointmentSchema.IsReminderSet, AppointmentSchema.IsMeeting, AppointmentSchema.IsAllDayEvent, AppointmentSchema.LegacyFreeBusyStatus, AppointmentSchema.Importance, AppointmentSchema.Sensitivity, AppointmentSchema.Categories, AppointmentSchema.StartTimeZone, AppointmentSchema.EndTimeZone, AppointmentSchema.TimeZone, AppointmentSchema.HasAttachments, AppointmentSchema.Attachments, AppointmentSchema.AppointmentState, AppointmentSchema.MyResponseType, AppointmentSchema.LastModifiedTime, AppointmentSchema.LastModifiedName, AppointmentSchema.IsRecurring, AppointmentSchema.IsCancelled, AppointmentSchema.AppointmentState)

When we bind to an all-day event that has been created in Notes in W. Europe Standard Time and migrated through MNE, and then we read appt.StartTimeZone.Id, we get tzone://Microsoft/Utc (see Item 3 on the list of issues).

Then we update some values as provided by the user (the user said the only change was a new category), most notably we try to correct the time zone because the current value doesn't match any system time zone:

appt.StartTimeZone = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time")
appt.EndTimeZone = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time")
appt.Categories = new StringList(new string[] {"TestCategory"});

and then we call update:

appt.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendToNone);

and when bind again and check (or check through Outlook), we find that the all-day event has been aligned to UTC days (was aligned to W. Europe Standard Time days before), presumably because Microsoft EWS could not process the existing time zone on the entry correctly.

Hi Alexander,

Thanks for the update and additional details. I have passed along these details to the product team for further investigation. I will keep you posted on what I hear back.

Hi Alexander,

After initial review, the product team was not able to replicate the issue you are experiencing using the current version of MNE. There were some recent improvements made to MNE in the way it handles time zone information. The product team would like to know the exact version of Migrator for Notes to Exchange (MNE) that was used to perform the migration of the objects you are editing.

Within the MNE Migration Manager console, you can click on the menu button in the upper-right and select About...

Otherwise, if you have any of the MNE migration log files available, the exact version can be found there as well.

Hello Trevor,

I have received a migration log, but I am unable to submit it to you since I don't have an asset number ("license number or service tag, this field is required").

However, I was told that the MNE version used for migration is 4.14.1.119, and that the target is the most recent version of Exchange 2016.

Today, instead of extracting parts of our code, we tried and reproduced the issue on migrated entries using the most recent EwsEditor 1.19.1.0 from github, so it is not just our code that is affected.

Unless the issue has been fixed in MNE 4.15, which I have been told should be the latest version of MNE, your technician should be able to reproduce this behaviour on migrated all-day events from Notes using EwsEditor. After changing the date (e.g. one day more), saving the entry, and reopening it, the entry is incorrect.

Kind regards,

Alexander

Thanks for the update. I understand that the items in question were migrated with MNE version 4.14.1.119. In a later hotfix version of MNE, 4.14.1.155, the following enhancement was added:

TFS 674823

Added support for the additional MAPI time zone properties that were introduced in Office 2007. Support for these additional MAPI time zone properties corrects a scenario where mobile devices that sync their calendar to the migrated mailbox using ActiveSync (such as iOS and Android devices) may display All Day calendar events spanning multiple days instead of one day as expected. The new configuration parameter [TimeZoneNames] has been added.

IMPORTANT This enhancement contains a breaking change to the [TimeZoneInfo] Program Parameter. If your installation currently contains configuration data in the [TimeZoneInfo] section, this configuration data must be updated. See the [TimeZoneInfo] section in the NME Program Parameters Reference for details.

This Enhancement Request included a redesign of the way MNE handles time zone data, which may have resolved the issue you are experiencing, as the product team is unable to reproduce the issue in the current version of MNE.