bouke

This has been resolved by ESET. Thanks.

It's still not fixed but ticket is in progress...

Dear ESET, Normally I absolutely like your product and adore ESET... but I am a bit disgruntled with ESET PROTECT Cloud and ESET at the moment. Please fasten your seat belts - because I am a bit in rant mode. Sorry. First we did notice that our installers weren't valid anymore. And now we can't create a simple installer anymore? Added to this: I did log a ticket at https://klantenservice.eset.nl/nl and now I can't find the ticket no under my profile? Another thing is that some of our servers en workstations did loose their activation some time ago... that seems to be fixed... but man... why are these issues happening to us? When I call ESET they want me to run a log collector. When I reply I don't feel it's right doing that the reply is that it has to happen first. What is going on ESET? Not much into delivering excellent service anymore? Apologies for the rant... I am hoping ESET still wants to work with me to fix this issue. Thanks. So now that's off my chest... here's the problem. I am trying to create a simple installer. I did select the license en next I would like to select the product. Then the following happens. Something went wrong... An unexpected error has occurred. You can either reload the application (recommended) or ignore the error and continue in your work (keep in mind that this might bring the application into an inconsistent state). If this problem persists, please contact ESET Technical Support with the error description below. Error description: *version : EPC9.1.85.0* *locale : en_US* *user.agent : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36 (safari)* *document : https://eu02.protect.eset.com/era/webconsole/072725C10C0DB6841B7CA8A7F0A9D74D.cache.html* *url: https://eu02.protect.eset.com/era/webconsole/#id=INSTALLERS:id=LIVE_INSTALLER_WIZARD_REACT;liveinstallerparams=0deffef2-a5f2-4a66-9f5c-bbc7f7a961ea* *error: * An uncaught exception has occurred! (" "TypeError: Cannot read properties of undefined (reading 'keys') ") @ at M (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:161:284487) @ @ at P (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:161:284619) @ @ at B (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:161:284689) @ @ at U (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:161:285374) @ @ at qo (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:57930) @ @ at Ac (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:104104) @ @ at su (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:96652) @ @ at cu (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:96577) @ @ at $c (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:93607) @ @ at https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:45314 @ @ at t.unstable_runWithPriority (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:193:3364) @ @ at zi (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:45023) @ @ at Yi (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:45259) @ @ at Hi (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:45194) @ @ at M (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:114278) @ @ at Zt (https://eu02.protect.eset.com/era/webconsole/static/js/main.7daa98ed.cache.js:185:22724)" @

I think this is resolved. The parameter autodisconnect under LanmanServer was set wrongly. Apparently the KeepConn parameter under LanmanWorkstation (for workstations) has to be set in seconds but the parameter AutoDisconnect under LanmanServer (for servers) has to be set in minutes. The latter parameter was set too high resulting in a lot of (very) old sessions...

I did also notice something else: In the documentation and posts I did find with regards to "KeepConn" under "LanmanWorkstation" the value is in seconds: - https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/mapped-drive-connection-to-network-share-lost - https://eddiejackson.net/wp/?p=16319 The equivalent for LanmanWorkstation for a server is "LanmanServer" When I enter eg "360" the time should be seen as 360 seconds (6 minutes) However... when I apply that via a group policy to my file server and run "net config server" the command will return the value like this: Idle session time (min) 360 ...and that are MINUTES and not SECONDS! When I look around in documentation the value should be entered in seconds but it looks like these are minutes! When I check the sessions there are sessions connected >6 minutes. So, the value "360" is not in seconds.

I might have found something. What I did notice is that the problem appears after some time (days). I did notice 3 things: the "Idle session time (min)" was insanely high: 14.400 minutes - I did find this by running the "net server config" command - 14.400 minutes = 10 days (I believe the default is 15 minutes) - I suspect that the policy was to be set to 4 hours and was accidentally set to 240 hours... when the option "Protocol SMB" under "Intrusion Detection" (of the IDS) is active on both the server and the clients then the amount of (passive) sessions seem to increase (and I think it happens because how this option works - but I am not sure) the other file server (for the factory) doesn't have that much sessions during the day (less users connect to the shares and there are no home shares on that server). When I reboot the affected file server the idle states will be gone and the problem won't appear directly. It will take one or two days. What I did is to change the idle session time to 720 minutes (12 hours). I did read that the default is 15 minutes. 12 hours should be more than enough to avoid complaints about temporary disconnected home shares during the workday. I intend to change this to 180 minutes (as I think that's how it was conceived). Besides that I could schedule a PowerShell command like the following which will clear any session older than 15 minutes to be run in the morning (eg at 05:00 in the morning): Get-SmbSession | Where-Object {$_.SecondsExists -gt 900} | Close-SmbSession -Force I can check the sessions with the "net server config" command again or list the session with PowerShell: Get-SmbSession Please note the difference: net server config is in minutes and Get-SmbSession is in seconds $_.SecondsExist). Further reading: https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/mapped-drive-connection-to-network-share-lost https://serverfault.com/questions/673742/group-policy-to-disable-auto-disconnect https://www.itprotoday.com/compute-engines/how-do-i-configure-lan-autodisconnect Please note the difference between LanmanServer and LanmanWorkstation! I am applying the idle session time for the file server - so I have to apply the time to "KeepConn" under "LanmanServer".

A quick update as I was tinkering with the file server. When I open "Sessions" under "Shared Folders" in "Computer Management" the list becomes populated with sessions. The issue is that the list disappears (clears) and then reappears. This happens 2 - 3 times in a row. And sometimes it "loops". I can only stop this by pausing antivirus and antispyware protection. This is at the server. What I did notice too is that - after enabling Antivirus and antispyware protection again - Server Security informs me about a security risk. The alert reads: Security alert; Email protection by client plugins is non-functional; The functinality could not be started and your computer is not protected against some types of threats. I can just dismiss this and everything seems to be fine. But after a few minutes the problem is present again. The status in ESET reads that everything is fine after logging in again.

Thanks. Technical support's advice was to only disable network drive scanning on the clients. It isn't disabled on the server. I just did a new test now the server's up time is over 13 hours. Everything works as expected: fast / smooth. There aren't much sessions / open files at the moment as it is weekend. I will check again this in about 10 hours (it's evening then). And i will check Sunday morning. If everything becomes sluggish again, I'll contact ESET Support Netherlands again. I will pause real-time protection during the test when the connectivity is sluggish (and report back).

Server: Windows Server 2019 (1809) DC | ESET Server Security 8.0.12010.0 Client: Windows 10 (21H1) Pro | ESET Endpoint Antivirus 9.0.2032.6 + ESET Endpoint Security 8.0.x - 8.1.x We are running a file server (details above this line). This server is connected to the 10 Gigabit backbone. We are having several client computers. Most are connected to access switches at 1 Gigabit. I did run tests from a test VM with Windows 10 and ESET Endpoint Antivirus 9.0.2032.6 (instead of Endpoint Security). When the file server is freshly rebooted everything works absolutely fine. We did assign 12 GB RAM and 12 cores to this Hyper-V. Everything runs smoothly. When we run ESET Server Security 8.x on the server the connectivity (SMB) becomes sluggish. However: when we downgrade to ESET File Security 7.3 everything runs fine for weeks - month (up time depends on reboots / updates). We had some modules disabled like HIPS during testing - and left it disabled. Running ESET without HIPS is not recommended. During the last update round we decided to upgrade to ESET Server Security 8.0. Unfortunately the connectivity (SMB) became sluggish again. We have had this issue before and that made us decide to roll back to version 7.3. I did call ESET (Netherlands) and was advised to disable "Network drive scanning" for the client computers. We did change this through ESET PROTECT Cloud by changing the policy. The policy has been applied to my test W10 VM - but the sluggishness was still there. I decided to disable the option "Protocol SMB" under "Intrusion Detection" (of the IDS) and see what happens. Still slow... I decided to reboot the file server and everything works fast as it should. Server up time is 02h 50m at the moment. Opening Word documents is fast and closing Word is fine. The users experienced issues with opening and saving files. Closing applications like Word took 8 seconds. Normally opening and saving files takes less than a second. Closing Word normally takes a split second. Some time ago (we are talking about months) we had this similar problem and what we observed was that the sluggishness / slowness appears in about a day. The server is a HP Proliant G10 with SSD storage. All other VM's aren't affected. It runs with 512 GB of RAM. There's also a second file server for the factory. The speed is less important - but I did some tests on that server too. I can open and save files as expected. That VM has only 4 GB RAM and 4 CPU cores. It runs fine with ESET Server Security 8.0.12003.0. I will re-test the affected file server during the weekend and see if connectivity becomes sluggish again. I would like to know if this is a known issue and if there's a known fix for this. Thank you.