Jump to content

speakerbox

Members
  • Content Count

    28
  • Joined

  • Last visited

  • Days Won

    1

speakerbox last won the day on January 8

speakerbox had the most liked content!

Profile Information

  • Location
    U.K.
  1. Hi Martin, thanks for the response. I think your first suggestion may be right, the era.war does still sit in the apache webapps directory and a few weeks ago I deleted file this but that seemed delete the webapp as well. I'll do some investigation down that route, must be some way in apache to turn auto deploy or similar.
  2. Hi, We have a bit of a weird one with our ESET Protect windows server and Apache. We use a custom port 8879 for the web console rather than the default 2223. Our web console intermittently breaks and will not load, when I check the windows server the Apache Tomcat service is stopped - but when started it loads but can't login with error "not connected". I've discovered the web console port within erawebserverconfig.properties appears to revert to the default port 2223. Once I change this to 8879 > restart apache > it works fine as normal. I've not yet found a pattern, some
  3. We've excluded the detection, bit of a pain having it alert 1000's of times a day over all our clients!
  4. Ah OK, that explains why we are seeing that now. If we do exclude it and the software is comromised then that could be a problem, as we won't get any alerts via ESMC possibly. Will need to look into that.
  5. Thanks Marcos, any reason why this would have started detecting now? It was the idle state-scanning we have enabled on this particular client which has been running this afternoon and detecting. The file has been in place for weeks and months so bit strange for it start now.
  6. Hi, We've just had a spate of alerts via ESMC on the below file being detected as PUA which is our installer for ScreenConnect (Remote Control). Name Win32/RemoteAdmin.ConnectWiseControl.A Uniform Resource Identifier (URI) file:///C:/Windows/Temp/ScreenConnect/20.11.1622.7619/ScreenConnect.ClientSetup.exe Detection engine version 22982 (20210317) Current engine version 22982 (20210317) This is legit software and no evidence to suggest malicious so not sure if a bad mo
  7. Hi, We've around 100 servers using versions 7.0 and 7.1, these are all now displaying the below warning: According to the End of Life page, there's nothing to suggest 7.0 or 7.1 on Server 2012+ will no longer function after 15th April? https://support.eset.com/en/kb3592-is-my-eset-product-supported-eset-end-of-life-policy-business-products 7.0 + 7.1 in limited support until v8. Struggling to find real detail for this but is this due to cross-certificate expiration? Closest thing I can fine is this page which says mitigated? https://support-eol.eset.com/en/t
  8. Hi, We currently have an overused RDS server which we're working with the client split into 2 servers/increase CPU/MEM but becoming difficult. The server resources are struggling and we've found everytime a user disconnects and reconnects, the automatic schedule task within ESET File Security runs for startup file check - https://help.eset.com/efsw/7.1/en-US/idh_startup_app.html This appears to spike the CPU and Memory temprarily high causing performance issues. We're going to disbale these 2 tasks until the client increases resources with an new server but is there any addition
  9. Bumping thread as no response, would really appreciate some rough guidance so we know where we stand - can see a few others in the same predicament.
  10. Hi, We're currently reviewing our server protection, we have around 150 on a mix of ESET File Security 7.0 and 7.1 (Windows only) which according to the EOL page is in support (Limited for 7.0, Full for 7.1). With ESET Endpoint AV V8 being released for clients is there any rough estimated date/quarter/year on when the next major version for File Security will be released? I've noticed 7.3 released for ESET File Security last month (EOL page not updated to show that?) but we're reviewing whether we should upgrade all our 7.0/7.1 servers to 7.3 or wait for V8. It be months of wor
  11. Hi, We're having some trouble removing an old XP agent that was retired but recently checked back into our ESMC console (V7). We have no physical access or remote access to the machine other than what we can do via the ESMC console. When we use the "Stop Managing" task, this fails (Task failed, try to uninstall software manually.) so the agent contionues checking in. I've tried via the "Software Uninstall" button via installed application but this fails with the same error. Is there anything we can do to stop this old retired agent from checking into our ESMC console? Thank
  12. Sorry that was just a random URL, we've been using various URLS. For example: https://gallery.technet.microsoft.com/Turn-off-screen-4d173e0a/file/147696/1/Turn off Screen.bat I think I’ve manged to identify the problem however, completely bizarre but on my test PC – the HTTPS URL was only blocked after I cleared cache and cookies in Edge (I done this after testing InPrivate browsing which worked and blocked immediately). So I think ESET or Edge must have cached my test URL’s (Which I visited before adding the URL blocks) in some form and the act of clearing cache in edge
  13. Yeah have also tried that, I don't think it's relating to the extensions i've added - it doesn't seem to intercept HTTPS traffic at all. Again, fine with HTTP.
  14. Yes that doesn't work i'm afraid. Still works fine if the link starts with HTTP and ends in bat but if it starts with HTTPS and ends in bat it doesn't do anything an allows the downloads.
×
×
  • Create New...