CraigC

We are seeing issues again in UK today. Also issues contacting LiveGrid yesterday.

Just turned my PC on this morning, still seeing error.

Or this URL: https://www.virusradar.com/en/update/info/2023/0 Support are aware, and said its being looked into.

We use virusradar.com to check pattern/updates, however there is no 2023 in the drop down (yet) : https://www.virusradar.com/en/update/info/?page=0

@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

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 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 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 😀

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

Thanks, obvious now 😀 However, if I click something that has 'edit' option highlighted, its not so obvious what has been added/deleted compared to 'default' eg WEB AND EMAIL > SSL/TLS > List of SSL/TLS filtered applications

If I look in a unmanaged 9.x client, Advanced setup, I see some numbers, I understand this to be the number of items that have been changed from defaults. How do I know what items have changed when I go into those sections?

Thanks @Marcos , so I assume all OK to delete the files manually if they exist?

We have been upgrading some servers from 7.x to 8.x and 9.x. The process we follow is the recommended process on ESET website, uninstall ESET, reboot, install new version. 50% of time when we try to reinstall it complains it can install into programdata\ESET\File Security. Looking in this directory there are 2 files left after the uninstall: fix_noembeddedui.mst fix_norepair.mst Deleting the files allows us to reinstall, but what are these files are why are they left by 7.1 and 7.2 versions?

Hello Peter, I maybe able to test this on a virtual machine, non production. Can you confirm that internal ESET testing has tested this with an office365 subscription using Office365 version of office? Regards, Craig

I see this many times in software where you have to 'enable' or 'turn on' an option that 'disables' or 'turns off' that specific feature, its not just ESET that do this. I agree, it is confusing, when someone says 'enable' what do they actually mean, unless you explicitly say 'enable' this option to 'disable' the feature etc. The 'Disable checking upon inbox content change' is a classic example of this.

Sorry @Marcos I posted too soon, I did not check date on Sync Issues. I installed 9.0.2032.6 on 14/12 and since then only 1 sync issue, but that does is not an ESET Sync issue, so it does seem with the disable setting enabled, it stops the sync issues.

Hello again @Marcos, I have tried 9.0.2032.6, using the setting you have posted above, but I still get Sync issues:

Hello @Marcos , can you clarify this please: 1) We have to 'enable' this option to 'disable' the checking, ie to fix the sync issues the settings should be as per your screenshot above? 2) What is the effect of this, ie is there less protection of the client? 3) What is the default of this option for a new un managed fresh install of v9? 4) What is the default of this option from an upgrade of a previous version, also un managed?

Hello @Marcos, will this disable setting be enabled by default (ie disabled) and accessible via GUI in v9? It makes sense if the default ESET product detects Exchange server configuration in Outlook that this is disabled by default and is easily modified in GUI rather than having to import a configuration file.

@Marcos maybe some confusion here. There has been an ongoing issue with ESET and Outlook Sync issues for many years. There may have been some fixes, that rely on importing config files, as the options are not visible on GUI, but the issue has not been addressed as a proper solution. It seems this fix is broken, and has been reported as a specific BUG in a specific version of ESET that I reported to ESET UK in July. If we look at the Windows Server ESET product, it automatically detects the environment its being installed on and will apply exclusions etc. I wonder if the same should be applied to the ESET client on Windows, if it detects Outlook and Exchange, any 'fixes' or configs should be automatically applied as default? I know this issue and specific bug are maybe not seen as high priority, as its only affecting performance, excessive IO/CPU cycles, disk space. On modern PCs this is masked with fast CPU, SSD drives, and massive Office 365 mailboxes, and most people are unaware of issue, so is not widely reported. I also don't understand the logic of prioritising a fix in a Home version before the Business version? In my experience Home users do not tend to use Outlook and Exchange. You can not avoid Sync issues even using one device with ESET/Outlook/Exchange, you will still get sync issues. ESET must be seeing this is QA/Testing?

Hello @Marcos, I originally started this thread specifically regarding v8.1, the business product that is more commonly used with Outlook and Exchange. You refer to v15, the home version? Will this ongoing sync issue also be fixed in the business version? When will this be release? I did open a case with ESET as you originally suggested, but I have not heard anything back from ESET with regard to this fix or release date? The ticket case ref in the ESET system is #CASE_00129486. Regards, Craig

It doesn't work. I was advised to open a case locally here in UK with version 8.1, I supplied some debug info, and ESET HQ confirmed its broken, with no timescale to fix. I would suggest you do same, and refer to this thread and the many others. TBH, I don't think this issue is an easy problem to fix, if it was we wouldn't still be chatting here about the issue that has been around for a long time. The issue is just hidden for majority of users, and is only noticed when looking at mailbox size. The issue is not just about mailbox size, but performance / overhead of the AV software on the device, again this is hidden with fast devices with SSD drives, but the issue is still there. I do hope ESET are having discussions with Microsoft on how to resolve. @Marcos There are a few use cases ESET need to consider when testing with Office365 mailboxes: 1) Multiple devices sharing same mailbox. This often happens in companies, users have their own mailbox and a shared mailbox, eg 'customerserivice@', 'finance@' etc. Also Manager / PA / Secretary type 2) Multiple devices with same mailbox, eg laptop and PC 3) Brand new devices with ESET installed, that will sync a whole mailbox.

If you are running Office365, you can run a powershell command to show how BIG the issue is for all the mailboxes on a single tenant: Get-Mailbox -RecipientTypeDetails UserMailbox | Get-MailboxFolderStatistics -FolderScope SyncIssues | Select Identity, Name,FolderSize Use the guide here to setup exchange online powershell if you haven't already: https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?view=exchange-ps I think the issue is compounded with shared mailboxes and/or multiple devices accessing a mailbox that are all running ESET Endpoint. It would be good if ESET can build these use cases into their QA tests for Outlook Plugin, rather than just a single mailbox with a single ESET endpoint device.

I have runs scripts on some of our Office365 tenants, and have notice all ESET users running various versions are getting issue, its not just 8.1. Also, and I think this is important, the issue is compounded if there are multiple devices accessing the same mailbox. Take the example of a manager who has a PC, laptop & mobile all connected to his Office365 Exchange mailbox, he also has his PA/secretary accessing his/her mailbox from their PC. So, 2 PCs and 1 laptop all running ESET, all with ESET Outlook plugin enabled accessing same mailbox, this is where the issue gets compounded. We are seeing 25%, 25GB of sync issues in a 100GB mailbox.

Hello @Marcos, I did as you suggested, the diagnostics have been been reviewed and the issue has been classified as a BUG. The instructions on the ESET website that I posted above, and are supposed to work with v8 do not correct the issue with ESET writing named property: EsetMessageFlag into the messages. The ticket case ref in the ESET system is #CASE_00129486. I am surprised other ESET and Office365 users are not complaining about this, we have seen some mailboxes that are 25GB of sync issues, due to the EsetMessageFlag property issue.