speakerbox

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.

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, sometimes it's 2-3 days between breaking and on todays occasion it was 2 weeks. We also had this issue on ESMC and recently upgraded to ESET Protect hoping this would fix. We have also installed the latest version of Apache manually but still same problem. Has anyone seen this before or any ideas why this would happen? Thanks

We've excluded the detection, bit of a pain having it alert 1000's of times a day over all our clients!

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.

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.

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 module update? I do have that exact module and software on my own machine but ESET doesn't detect it. This was detected by idle state scanning our client and so far flagged up on about 20 machines in the past 1-2 hours. Anyone aware of known issue here?

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/trending_cross_certificate.html 100 server upgrades in 5-6 weeks is going to be a real struggle.

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 additional security risks caused by this? My thought is anything running at startup or user logon should be caught by Real Time protection so maybe duplication and something we can avoid for performance reasons. Thanks

Thanks Marcos, noted.

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.

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 work to go to 7.3 only for V8 be released and have to do it all again so be good to know! Thanks

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? Thanks

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 resolved immediately. We confirmed this on another PC which had successfully visited the URL’s before I added the file extension, clearing cache then allowed the block to work immediately.

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.

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.