Outlook 2019 - Office 365 Fall 18 Release - Calendar Recurrence Unexpectedly Cached

From CompanionLink Support
Jump to: navigation, search

Issue in Outlook 2019 / Office 365 v1808 and higher release

Summary

We are seeing a problem where the customer creates a recurring event, and then makes an instance of it at a different time. When we read the recurrence record, Outlook Objects API is passing and exception count of zero instead of the correct number. This causes sync to miss the exception time.

Affects

Office 365 v1808 - A customer has reported this.
Office 365 v1809
Office 2019 Pre-release - We see this inhouse.
MAPI and Standalone folders (PST Files)
NOTE: We have tested on Outlook 365 v1809 and v1808 extensively on other computers, and it is performing as expected. So currently we only have a single computer showing the problem, and that is using a v1811 which is a pre-release Outlook 2019.
Reference: update for Office 365 ProPlus: https://docs.microsoft.com/en-us/officeupdates/update-history-office365-proplus-by-date

Does Not Affect

Exchange folders
Office 365 folders
Outlook 2016 v1807 and earlier. Outlook 2013, 2010, 2007 or earlier

Details

Steps

1. In Calendar, create a timed recurring event for one hour, recurring weekly for three instances.
2. In the middle instance, move it ahead one hour.
3. Edit Primary record in the series, and choose "Entire Series".
4. Make any change. Click Save and Close.
5. Issue: Receive an error trying to save the change "The item cannot be saved because it was changed by another user or in another windows. Do you want to make a copy on the default folder for this item?".

Notes: If Outlook is closed between steps 2 and 3, the edit step 4 works fine (cache is flushed)
Other actions between step 2 and 3 have no effect; changing to contacts and back, adding another calendar, performing a send and receive.

Recovery

After closing Outlook, the cache is flushed and Outlook behaves normally. For customers of our sync products, a reread of the Outlook data will recover any unsynchronized values.

Workaround

For customers who use IMAP folders, instead of using "change this one", add a new event instead.

Discussion

October 1, 2018: First report from end user OL v1808

October 2, 2018: Reproduced inhouse using Outlook 2019 Pre-Release. Found no problems with Exchange folders (OST). Also we have two other computers on v1808 and v1809 that work as expected.

October 3, 2018: Validated our code against published API specification. Examined spec for any note on caching or expectation of data state (none). Examined folder settings to see if there is a close (none).

October 4, 2018: We are checking MAPI interface, to see if this problem is limited to Outlook Objects layer. One workaround would be to automate a reread of all recurring events modified the prior day.

October 5, 2018: Testing whether this is 64-bit only. Unable to confirm. Testing a workaround that may go into place. We are now presuming this is a MIcrosoft API bug. The workaround functions by identifying that the record is being mis-reported which takes one additional function call. In this case it uses an alternative technique to read the Recurrence Exception information. If Microsoft fixes the bug, the new logic will not execute.

October 10, 2018: We have refined the steps to no longer need sync. The Calendar will fail all by itself.
1. Create a recurring event in Outlook Calendar (Weekly, 3 occurrences)
2. Edit the second instance by dragging and dropping to another time.
3. Edit Primary record in the series, and choose "Entire Series".
4. Make any change. Click Save and Close.
5. Issue: Receive an error trying to save the change "The item cannot be saved because it was changed by another user or in another windows. Do you want to make a copy on the default folder for this item?".

Note: If you edit A DIFFERENT instance, make a change, cancel the edit, it prompts do you want to save, and say no. However the pattern commits and step 3-4 will succeed.

Note: Some PCs with the same releases work fine.
Note: Closing Outlook and reopening will clear the error.
Note: 32-bit and 64-bit both exhibit this problem.
Note: Exchange folders - no problem at all - this is standalone folders only ost and pst.
Note: ScanPST does not change the behavior. On the systems affected, this is 100% reproducible.

October 10, 2018: We have scripted a workaround based on what we know. This is a program update to CompanionLink 8 build 2024 and higher. We expect to have this in Beta by Friday Oct 12, and full release early next week.