Jump to content

veehexx

Members
  • Content Count

    21
  • Joined

  • Last visited

Profile Information

  • Location
    U.K.
  1. 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.
  2. 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.
  3. 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" /
  4. 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?
  5. 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!
  6. 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
  7. file attached. dated 7-oct-2016, file version: v1.0.0.15 am i good to go on removing v7.2 now? stdcfltn.zip
  8. 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?
  9. 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....
  10. 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.
  11. 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?
  12. 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 so
  13. 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...
  14. had the issue again just now for another user, so it seems not isolated. will raise with support.
  15. us too! Just had this on our new server2019 RDS farm, running eset file security 7.1.12006.0. so far it's an isolated occurrence. One of our IT staff had a disconnected session from last night. When he reconnected this morning he was stuck at something along the lines of 'waiting for configuration profile' as the profile loads up. I forced a logoff of the session which mostly worked, but a single process remained; ' eGUIProxy.exe'. the process eventually ended but not sure what timeout this has. The time between him attempting to connect, me forced logging off that session and a
×
×
  • Create New...