mcrouse

no more issues on my end. Thanks for the confirmation!

The email address associated with this forum account is a personal email. My enterprise license should be valid 33C-PGW-62H My warning messages have decreased by about 75% in the past 10 minutes. Maybe the license server issue is resolving itself

I'm getting a similar message on some of my endpoint security deployments except it says "web control not fully functional because of a license problem". The warnings come and go but it notifies the users each time so it's very annoying. It would be nice to get some sort of confirmation from ESET's end that they are having server issues so I don't waste my time trying to diagnose an issue I can't fix

I've noticed on the majority of my endpoints that had this detection that ESMC would show the file as being quarantined but when I went on the endpoint to check, there was nothing in the quarantine folder and the files were still in their original location. It appears that they were never quarantined even though ESMC was showing them as quarantined. I was also seeing error when cleaning ESET errors on the detections. And if I sent a restore from quarantine task it would fail

To answer my own question, no it is not possible to end the isolation task for remote users. I had to uninstall and reinstall the client in order to get them back on our network via VPN

Hi, I'm currently on ESET Endpoint Security 7.2. I've read the description of the isolate task from the documentation online and it states that it allows the following connections computer obtains an IP address •communication of ekrn.exe, ESET Management Agent, ESET Enterprise Inspector Agent •login to a domain This all makes sense to me. My question is how this would work for remote users who connect to our network via VPN. They would be able to receive the isolation task but would it be possible to end the task or would they be unable to reconnect to VPN to receive the end isolation task via the agent because the connection is being blocked? Thanks

Ahh ok, I did not think to check that log and was going off of what was reported to the ESMC. Thanks for the heads up on that

Yeah, in a prior scan the following was detected and cleaned : file:///C:/eNNzmNj/wLrKvzZ/UQEZPGU.dll edit: It was not in the same folder but related to the initial infection I believe

Hey Marcos, tt doesn't exist/was deleted. There was also a DLL in that same folder which was deleted it looks like. That ArtPress task was deleted from the system scheduler. Thank you for taking a look at those logs. Based on the info provided and the fact that scans are no longer detecting anything, do think the issue has been remediated? or should I still reimage the machine?

Logs attached. It looks like the infection was caused by a freeware application called ArtPress that the user had downloaded. Checking the task scheduler today, I noticed a task set to run everytime the user logged on which I deleted. My most recent ESET scan showed 0 detections but hopefully someone can confirm via the logs ees_logs.zip

Good point, I checked the scheduled tasks and didn't see anything out of the ordinary. I'll be collecting logs and posting them tomorrow when the user is back in the office. In the meantime, the machine is isolated and off the network. Thanks guys!

I had a workstation which was infected with Trickbot and Kryptik. ESET found and cleaned several items related to this including a malicious Kryptik DLL and .MGB file. It also remediated malicious svchost and wermgr.exe processes which is consistent with Trickbot IOC's. However, it is still detecting Trickbot in subsequent scans. It does not detect any malicious DLLs or processes anymore. Only a single file:/// from the ERAAgent process. The following is the detection detail: Hash Name Win64/TrickBot.BU Uniform Resource Identifier (URI) file:/// Process name C:\Program Files\ESET\RemoteAdministrator\Agent\ERAAgent.exe Is this just picking up some sort of artifact or is this a persistant threat that ESET is unable to clean. I'm about to image the machine but thought i'd check and see if this has been seen before. Thanks!

Thanks for the respons Kristian. I chatted with a support agent and they informed me that the All-in-one installer is on version 3.1.0.1 I'm not sure if that's just a mistake in naming or if it is a new version however

Hi, Starting on April 29th, I began getting a notification that a new encryption server version is available when I logged into the management console. I'm already on version 3.1 from earlier in the year. This new version is also labelled 3.1 and the release notes weren't updated since February. Is this really a new version that I should upgrade to or is the notification just an error?

Hey Martin, Thanks for the response. It resolved itself a few hours after I posted this thread. Maybe a repository outage of some sort?

Hi, I've been updating some of my outdated clients via the software install task and selecting the newest version from the repository. This worked fine for about 150 of machines but now whenever I go to the repository it shows every other software version except the Windows Endpoint Security. Also, on the main security summary page of the dashboard there was a bar chart that told me the % of machines that were up to date. This chart is now showing 0 information. I'm on ESMC version 7.1.717.0 on a windows server 2012 The clients I'm attempting to update are all Windows 10

I made a similar thread regarding 5.0.4 and was told that 5.0.4 only contained compatibility for Surface Go. I see that 5.0.5 has been released and the changelog lists a few fixes. 5.0.5 is not currently listed in my Auto Update options. I'm on version 5.0.3 currently. Is an update recommended? And if so, when can I expect that new version to be added to the repository? Thanks

Has anyone tried pushing this out via SCCM yet? Also, are there any negative effects if apply the fix to machines that don't need it (specifically, other versions)?

Thanks for the update Marcos. You've mentioned that the patched module will fix machines that have not been restarted. The majority of my machines are workstations and I have little control over whether users decide to restart them or not. For those machines that are affected and have been restarted, will the module update not work?

Thanks for the clarification everyone. I have a larger environment so I guess I'll just have to wait until a fix is released via module update 😩

so just to clarify, pushing an update to the 7.x version on an affected product will fix it? or do I still need to do all of the sytem date change steps?

Thank you for the quick reply. I'm in the process of upgrading both the server and client to the latest version. Would that resolve the issue without going through the steps you described?

Are there any known issues related to the way ESET handles protocol filtering. In the midst of applying some policy changes, I disabled and then re-enabled SSL/TLS protocol filtering. After this was done, I began seeing widespread issues with clients not being able to connect to sites and services that they were previously able to access. I traced the issue to the protocol filtering which I now have disabled for the time being. For reference, I am on ERA server version 6.5.522 and the clients are on version 6.5.2118. Thanks!

Thanks! Just to clarify, 5.0.3 will support Windows 1909?

I see that version 5.0.4 has been released. I have workstation policy set to auto update to any version but it is not forcing the update to 5.0.4. If I select Auto update to a specific version, 5.0.4 is not listed as an option. Is 5.0.4 being added to the auto update repository soon? I have a fairly large deployment so I'd like to avoid manually updating machines if possible