Sync conflicts with Outlook and Endpoint Security 9.0

[HolmPC 0]

I administer a company's IT using Protect Cloud and have been seeing the issue described repeatedly in the past with Sync Conflicts in Outlook, described in this thread.

I recently updated all users to v9.0.2046.0 and set the option to "Disable checking upon inbox content change" and all users are still getting all incoming mail copied to the Conflicts folder and filling up their mailboxes.

Is there any more news on a fix for this issue? It's happening across all the companies I administer and has been mentioned in postings online going back over 10 years now! When will I be able to push a fixed version to users where checking that setting will actually make a difference?

[Marcos 5,074]

You can download and install ESET Endpoint v9.1.2049 from https://forum.eset.com/files/category/3-early-access/. The new version has the Outlook plug-in completely reworked and sync issues should not occur with it. It will be released in a few days.

[HolmPC 0]

Thanks. I'm eager to test it out!

[CraigC 1]

Hello @Marcos, pleased to see some progress 😀

However, still seeing some Sync issues, not as often as previous versions (I'm running 9.1.2051):

 

09:59:49 Checking local modifications
09:59:49 Ignore property: 0x3FFA001F
09:59:49 Compare named property: ESETAntispamStatus
09:59:49 Getting remote properties
09:59:49 Checking remote modifications
09:59:49 Compare (conflict) named property: ESETAntispamStatus
09:59:49 Local: {I4:17}
09:59:49 Remote: {Error (0x8004010F)}
09:59:49 Not equal (conflict) named property: ESETAntispamStatus
09:59:49 Local modification: {08:59:32.0879  04/07/2022 [DD/MM/YYYY]}
09:59:49 Remote modification: {08:59:51.0021  04/07/2022 [DD/MM/YYYY]}
09:59:49 Conflict generated, remote item is winner

 

 

 

[Marcos 5,074]

Since now the ESET plug-in doesn't modify message at all, I'd recommend opening a support ticket for further investigation.

[rekun 43]

Could it be that the mailbox is shared with other users, or setup on multiple computers , some of which is still running an old version?

that is the only way it makes sense.

[HolmPC 0]

Version 9.1.2051.0 has fixed the problem for me. When will the same fix be available in the home user products (specifically Internet Security) so I can roll it out to home user customers with the same problem?

[Marcos 5,074]

1 minute ago, HolmPC said:

Version 9.1.2051.0 has fixed the problem for me. When will the same fix be available in the home user products (specifically Internet Security) so I can roll it out to home user customers with the same problem?

Home products v15.2 already contain the new Outlook plug-in.

[CraigC 1]

@Marcos I upgraded from 2046 to 2051 on 30/6, 4 sync issues since then, 2 with "Compare named property: ESETAntispamStatus". I don't recall seeing these in 2046, so I suspect something has regressed from 2046 to 2051. The sync issues are no where near as bad as they were in previous versions, so new plugin is better.

I did open a ticket last time, but unfortunately it took many hours of my time to get various diagnostic info to support, and the end result was "it was a known issue and will be fixed in next release". I did seem to have been fixed in 2046. As the sync issues are minimal, 1 every few days, I can live with this.

Possibly a conflict of Junk email detection? Microsoft trying to move item on Exchange Server and ESET trying to move item on client at same time?

See sample below:

 

09:30:19 Checking local modifications
09:30:19 Ignore property: 0x3FFA001F
09:30:19 Compare named property: 0x859C0102
09:30:19 Compare named property: hxxp://schemas.microsoft.com/exchange/junkemailmovestamp
09:30:19 Compare named property: ESETAntispamStatus
09:30:19 Getting remote properties
09:30:19 Checking remote modifications
09:30:19 Compare (conflict) named property: 0x859C0102
09:30:19 Local: {CB:46, LPB:0x000000003D56237C84085C46BA3BC029E11F6729010077FEB5F191CB634E9C16A97EAF1B164300000056B1C60000}
09:30:19 Remote: {Error (0x8004010F)}
09:30:19 Not equal (conflict) named property: 0x859C0102
09:30:19 Local modification: {08:30:10.0431  07/07/2022 [DD/MM/YYYY]}
09:30:19 Remote modification: {08:30:19.0817  07/07/2022 [DD/MM/YYYY]}
09:30:19 Conflict generated, remote item is winner

12:03:33 Checking local modifications
12:03:33 Ignore property: 0x3FFA001F
12:03:33 Compare named property: 0x859C0102
12:03:33 Compare named property: hxxp://schemas.microsoft.com/exchange/junkemailmovestamp
12:03:33 Compare named property: ESETAntispamStatus
12:03:33 Getting remote properties
12:03:33 Checking remote modifications
12:03:33 Compare (conflict) named property: 0x859C0102
12:03:33 Local: {CB:46, LPB:0x000000003D56237C84085C46BA3BC029E11F6729010077FEB5F191CB634E9C16A97EAF1B164300000056B1C60000}
12:03:33 Remote: {Error (0x8004010F)}
12:03:33 Not equal (conflict) named property: 0x859C0102
12:03:33 Local modification: {11:03:27.0027  06/07/2022 [DD/MM/YYYY]}
12:03:33 Remote modification: {11:03:33.0919  06/07/2022 [DD/MM/YYYY]}
12:03:34 Conflict generated, remote item is winner

@rekun No, a single Windows 10 PC, using Office465 mailbox, not a shared mailbox. Mailbox is also accessed using Outlook App on iPhone, but no ESET on iPhone 😀

 

[CraigC 1]

@Marcos Just taken a closer look, all items with sync issues are in Junk Email folder. ESET will move the email and prefix subject with [SPAM], so ESET is actually modifying the messages if ESET detects them as spam/junk. This is where the conflicts occur. Maybe feed that back to dev?

 

[Marcos 5,074]

I was informed by developers that antispam still writes the property ESETAntispamStatus under the following circumstances:

• if the user manually reclassifies a message
• if a message is moved from the Junk folder to Inbox
• if a message is evaluated based on an address list while the ESET antispam evaluates it differently.

In this particular case, the property was written because the message was moved by ESET Antispam from Junk to Inbox, e.g. it could be a false positive of the Outlook filter or it was initially missed spam by ESET Antispam that was later recognized.

In the future we plan not to add the property at all at the cost that the Junk folder won't be scanned for spam.

[CraigC 1]

I reviewed the messages, they were definitely not manually reclassified, and were not moved from Junk to Inbox. 

They must have been moved from Inbox to Junk Email by ESET (client) and Microsoft Exchange Office 365 spam filters (server), hence the conflict.

Not scanning for spam makes sense for Junk Folder, I assume also the Deleted Items wont be scanned for spam.

[Marcos 5,074]

"Local: {I4:17}" means that the message was moved from Junk to Inbox.

[CraigC 1]

 @MarcosDefinitely not moved to inbox, item is in Junk Email. I have just had another one come in. The email is unread in Junk Email, is not in Inbox, 100% has not been manually moved, here is full details, notice:

11:24:48 Overwrite named property: ESETAntispamStatus

11:24:49 Compare named property: ESETAntispamStatus
11:24:49 Getting remote properties
11:24:49 Checking remote modifications
11:24:49 Compare (conflict) named property: ESETAntispamStatus
11:24:49 Local: {I4:17}
11:24:49 Remote: {Error (0x8004010F)}
11:24:49 Not equal (conflict) named property: ESETAntispamStatus

 

11:24:48 Inbox
11:24:48 Message class: {SU:IPM.Note}
11:24:48 Incremental Synchronization
11:24:48 Local subject: {...}
11:24:48 Remote subject: {...}
11:24:48 Local Message Entry ID: {CB:70, LPB:0x0000xxx22DF0000}
11:24:48 Remote Message Entry ID: {CB:70, LPB:0x000xxxDF0000}
11:24:48 Local Message ChgKey: {CB:20, LPB:0x215Exxx85A}
11:24:48 Remote Message ChgKey: {CB:22, LPB:0xB8DExxx3EA31}
11:24:48 Local Message PCL: {CB:44, LPB:0x14xxx23EA2D}
11:24:48 Remote Message PCL: {CB:23, LPB:0x16BxxxxxxEA2D}
11:24:48 OCN: {I8:0x00000000-0BC24545}
11:24:48 Checking local modifications
11:24:48 Delete property: 0x10060003
11:24:48 Delete property: 0x10070003
11:24:48 Delete property: 0x1008001F
11:24:48 Delete property: 0x10100003
11:24:48 Delete property: 0x10110003
11:24:48 Ignore property: 0x3FFA001F
11:24:48 Overwrite named property: ESETAntispamStatus
11:24:49 HRESULT: 0x80040109
11:24:49 HrConfMsgAutoResolved failure

11:24:49 Inbox
11:24:49 Message class: {SU:IPM.Note}
11:24:49 Mail Conflict Resolution
11:24:49 Local subject: {...}
11:24:49 Remote subject: {...}
11:24:49 Local Message Entry ID: {CB:70, LPB:0x0000000xxxx0000}
11:24:49 Remote Message Entry ID: {CB:70, LPB:0x00000000xxxxF0000}
11:24:49 Local Message ChgKey: {CB:20, LPB:0x2xxxF85A}
11:24:49 Remote Message ChgKey: {CB:22, LPB:0xB8DExxxEA35}
11:24:49 Local Message PCL: {CB:44, LPB:0x14215Exxxxx3EA2D}
11:24:49 Remote Message PCL: {CB:23, LPB:0x16B8Dxxx35}
11:24:49 OCN: {I8:0x00000000-0BC24545}
11:24:49 Checking local modifications
11:24:49 Ignore property: 0x3FFA001F
11:24:49 Compare named property: ESETAntispamStatus
11:24:49 Getting remote properties
11:24:49 Checking remote modifications
11:24:49 Compare (conflict) named property: ESETAntispamStatus
11:24:49 Local: {I4:17}
11:24:49 Remote: {Error (0x8004010F)}
11:24:49 Not equal (conflict) named property: ESETAntispamStatus
11:24:49 Local modification: {10:24:41.0902  07/07/2022 [DD/MM/YYYY]}
11:24:49 Remote modification: {10:24:49.0840  07/07/2022 [DD/MM/YYYY]}
11:24:49 Conflict generated, remote item is winner