veehexx

Thats the bit i didnt understand - we dont use Apache HTTP Proxy, so the Troubleshooting steps i figured were not applicable. Turns out they are applicable and it's (so far!) fixed it for us; clients are staying 100% ok and all green.

Is this still an active issue, as we're seeing the problem and not got some of the updates (still in pre-release channel?) that have been mentioned. I've updated to v9.0.2032.6 EES yesterday with the intention to deploy company wide and i'm seeing the same issue. we use linux Eset Protect VM (iirc the eset provided VA), no http proxy (clients can freely connect direct to internet) but do cache updates, licencing interval is 'automatic'. Direct Cloud comm module is still 1122.2 (4/nov/2021). admittedly, i havent done any of the cfg file changes mentioned in this thread as they all appear to be "try this and see", most seemed not applicable to our environment. telneting to epns.eset.net:8883 appears to work (blank screen, but no failure to connect), pings fail. if i've understood the connectivity correctly, 8883 is preferred, 443 is fallback so worst case is we should see 443 fallback and EPNS should never fail for us, and it has no effect on connectivity to our onprem Eset Protect VM; EPNS is globally available provided by eset.

unfortunately we dont have the exchange scanner on our licence. while not native via Protect, it looks like we could script this via other tools (SCCM maybe) using ecmd.exe - https://support.eset.com/en/kb7277-use-eset-command-line-ecmdexe-to-importexport-security-product-configurations-in-eset-endpoint-products-7x Probably wont get time to test this today but should find the time by the end of the week.

think i got too excited with the first fix. we're still seeing the message conflict although with a slightly different error in Outlook Sync Issues.

Ok, i've looked into adding it to our Protect policies but it's not obvious (or xml importable) to what i need to actually set. How would i either manually replicate the correct policy option changes of the xml, or how do i import that xml into a new policy? based on a client-side export, and using your fix it appears to set the following under 01000800 which are not entirely clear what Protect policies i need to define to our userbase: ... <ITEM NAME="01000800"> <ITEM NAME="settings"> <NODE NAME="OutlookIntegrationEnabled" TYPE="number" VALUE="1" /> <NODE NAME="OEIntegrationEnabled" TYPE="number" VALUE="1" /> <NODE NAME="WLMIntegrationEnabled" TYPE="number" VALUE="1" /> <NODE NAME="DisableInboxChangesChecking" TYPE="number" VALUE="0" /> <NODE NAME="OutlookIntegrationChangeCounter" TYPE="number" VALUE="0" /> <NODE NAME=" " TYPE="number" VALUE="33" /> <NODE NAME="OutlookCOMAddinForced" TYPE="number" VALUE="0" /> <NODE NAME="DeliveryByEESessionEventsEnabled" TYPE="number" VALUE="0" /> <NODE NAME="ExportToMsg" TYPE="number" VALUE="0" /> <NODE NAME="OEAlwaysUseEplgHooks" TYPE="number" VALUE="0" /> <NODE NAME="ExportToEmlEnabled" TYPE="number" VALUE="0" /> </ITEM> </ITEM> ...

looks to have worked on my outlook. will push it out via Protect to all devices now and confirm with users. Thanks! what exactly are the implications of this fix - anything reduced functionality that i need to be aware of?

ok, turns out i DO have the info message on normal emails "this is the most recent version, but you made changes to another copy". subtle enough that i've just not noticed!

We've been having issues with outlook & conflicting for a while. While i've only been informed of our users having issues, it has been ongoing for over a month. My outlook confirms there is an issue. the symptoms do appear to be different as some users are reporting "this is the most recent version, but you made changes to another copy" which i have not seen on my local Outlook when replying to emails, however i do see it on emails in the Sync Issues\conflicts folder. Users appear to see it on their new emails (outside of sync issues folder) Local installs: EES v8.0.2028, Office 2019 x86 & Windows 10 x64 RDS: Server 2019, office 2019 x86, EFS 7.1.12006.0 Our users mailboxes are currently onprem Exchange 2019, with my mailbox in o365 as we are planning to migrate soon - this doesnt appear to have a bearing on whos affected though. The following quote is an Outlook Sync Issues message on my local Outlook which only occurs when the Eset outlook addin is enabled and appears on every new email. Disabling the addin and sending a test email does not generate a conflict message or the "this is the most recent version, but you made changes to another copy" message.

file attached. dated 7-oct-2016, file version: v1.0.0.15 am i good to go on removing v7.2 now? stdcfltn.zip

in safemode, EES 7.2.2055.0, EMA 7.1.717.0 shall i just go ahead and update to EES v7.3, or need some more info?

just had it on my dell 5490. apart from what appears to be an unrelated 1.13.1 bios update (contains 2 intel security advisories), then i'm upto date. thankfully this is the first pilot machine testing 2004 update in our environment so just affecting me. trying to get laptop into safemode now to check things out further....

That was my assumption when i couldn't find anything in regedit or install folder. Shame. the deployment guy manually activated the clients so at least they're licenced and protected. He only thought to tell me there was an issue today. Hopefully he has a record of who&what went out in the time period (or look at AD creation timestamp) so we can manually confirm their last connected timestamp in ESMC and handle from there.

Redeploying is fine once we discover what devices are affected. what i'm wondering is if there is a way we can query (regkey, script, etc) what the Agent's Server address is currently set as?

We've recently discovered that I missed the install_config.ini file along side an update to the latest agent.msi. fresh installed clients have the server as localhost and not our esmc FQDN. i've done a search in redgedit HLKM for our fqdn and the install dir but neither have a result. Is there a way to confirm what the agent is currently set to via an external method? Yes, i know we can check the server via add/remove programs and modify the agent install but that requires admin rights and only useful for machines we know are affected. We use SCCM to manage software so looking for something i can use for either deployment detection, or a Compliance Item.

above is from support. changed from full to terminal and a test user doesn't have eguiproxy.exe running so seems good. guess we'll see for end users ever the next few days...