All Activity

Just wondering if there's a way to sort all our system's by the Management Agent Version rather than just the Endpoint Antivirus version. The product filter on our server doesn't seem to have an option to search "ESET Management Agent" and only "ESET Endpoint Antivirus and ESET Server Security". We have a ton of offline systems that we are currently sorting through, however we would like to push the Management Agent update out so it's a little bit difficult to figure out which ones are left we need to update. (Sorry in advance if this is the wrong forum. A bit new here)

Well, I'll be damned! It appears AT&T is indeed forwarding IPv6 DNS requests to Cloudflare:

@Marcos, I found a workaround to my IPv6 networking issues and it was by sheer luck. More on that later. First, a brief review of my network situation. My ISP is AT&T Uverse. It is a long known fact that they require you to use their DNS servers. Next up is how IPv6 network and connectivity is established. It is not done via conventional DHCPv6 methods. Note that AT&T Unverse provider routers are programmed to perform the actual IPv6 network setup and connectivity to it at system startup time. First, limited IPv6 connectivity is established. Next the router using ICMPv6 sets up the actual local device IPv6 network and establishes full AT&T IPv6 connectivity to it. This includes, and most important, IPv6 connectivity between AT&T actual IPv6 DNS servers, a dedicated IPv6 relay DNS server, and a dedicated IPv6 local device DNS server as shown in the following diagram: ATT real IPv6 DNS servers <----> reserved AT&T relay DNS server allocated within local device Ethernet IP address range <----> local device IPv6 DNS server controlled by IPv6 gateway. The above takes about 1 - 2 mins after system startup to perform and the IPv6 network and DNS servers to initialize and become fully operational. The above IPv6 network processing co-existed with Eset network processing aside from an occasional "hiccup" until ver. 17; with 17.2.24 totally breaking the processing. My strong suspicion is overly aggressive Eset Network Inspection processing "choking" on the setup of an IPv6 network "on-the-fly." Now for the workaround. Trying over time every solution "know to networking mankind," I thought "what the hell." Let's try Cloudflare IPv6 DNS ervers. To my utter amazement, it worked! At least. so far. Note, I did not change my IPv4 DNS servers to Cloudflare ones. I am now receiving full IPv6 network initialization at boot time resulting in Eset Networking not "going bonkers." All system startup modes; restart, win 10 fast startup, and resume from sleep all work presently w/o issue. My suspicion is AT&T is using IPv4 DNS server settings to determine that their DNS servers are used and allowing third party IPv6 servers. I also believe that the third party IPv6 DNS servers are now acting as the relay DNS servers to the actual AT&T IPv6 DNS servers.

The old admin is away forever 😞 and me has to try a migration-attempt, but still not successful. 😥 - sorry for bad english and sorry for much text, I'm trying to solve this since 2 days (and yes, I read much here, but cant get the information that helps) - f.i. I read this (but does not help): https://help.eset.com/era_install/65/en-US/clean_installation_different_ip.html https://help.eset.com/esmc_admin/70/en-US/fs_agent_connection_troubleshooting.html https://help.eset.com/esmc_admin/72/en-US/certificates_certificate_era.html Actual configuration (all Windows Server and Windows Clients): - ESMC Server 7.2.1278.00 - all clients (Eset-Mgmt Agent: 7.2.xxx and Eset-AV: 8.0.xxx) are working well New configuraion: Because the old server is old :-) I installed 1 additonal new server: - ESET Protect 8.1.1223.00 Idea: To tell all clients, that they have to connect to the new server, with as less impact as possible (ideally no install of new client components, only to give the information regarding the new server, f.i. via policies) New server is installed and runs well (as soon I can see). Now I'm trying to move an existing test-client from old server to the new server. First I removed all policys from the client on the old server (may be this was the first error). May be I also triggered "stop administatration of this client", I made much things during last 2 days 🙂 The new server found the test-client via Rogue Detection (I think) and it is shown as unwanted device in the Protect-Console. I was able to move the test-client then to the "lost-found" group but its totally grey with no further informations. So, the communication between test-client and new server seems to be distorted. 😞 1.Idea: May be a certification-problem? I exported all possible certifcates from old server and imported into new server and tried to build a new peer-agent-certificate, but does not work. (I read later, that serverbased install of agent is only with the certificate possible, that the server himself generates during its installation). The idea of this attempt was, that the client can may be still communicate with old server and get a new policy, that describes, what his new server is ... 2. idead: May be a proxy-problem? The status.html shows, that the test-client wants to use a proxy for replication. But this proxy is not configured for ESET, its only a dumb proxy for internet-surfing and the Eset-AV can use it to download updates. So I dont want, that the client-replication (agent) tries to connect the server via proxy) And I dont know from which source the test-client knows of this proxy. May be read from some browser-configruation on this machine ... So, may be I have a problem with certificates and proxy, but first I want to get rid of the proxy. Because I'm sure, that the client-agent should no use a proxy. I made a new policy on the new server, with empty proxy entries (and overwrite option), but I dont think, that the client proccesse the new rule, because the replicaton-connection is still distorted. I made also new policy for the test-client on old server, with no proxy too, but gave also the IP for connection to new server. No real effect 😞 So the test-client is to be seen on new server in grey, but they dont talk with eachother 😞 Or may be, the server talks to client, but the client dont talks back on the correct way. Then I tried to deploy a newer agent version on the test-client via serverbased install. And yes, the test-client has now installed the agent version: 8.1.1223.00 (all other clients still have 7.2.1266) But this seems to be a oneway too. The client installs the agent but did not find a way back to communicate with his new server. May be because he tries it still via the proxy, but the proxy does not know how to handle this (and should not handle this) Could someone help me, to get rid of the proxy within the client-agent? attached: a pic of the status.html on test-client (behind the blue color occurs everytime the new server, so this part is correct)

It doesn't matter since Eset blocks the conhost.exe startup from cmd.exe. As such, the script would never proceed to the point where the elevate process executes. Are you stating that this elevate process you're using spawns wscript.exe to run iexplore.exe? Note the way to run iexplore.exe as you are doing is to create a .vbs script containing the following code: https://stackoverflow.com/questions/1340355/launch-programs-whose-path-contains-spaces

elevate "C:\Program Files\internet explorer\iexplore.exe" itman the issue is that the allow rule for the action above does not match the same command when "internet explorer" above is written as "internet Explorer".

I created a .cmd script containing the following: wscript.exe "C:\Program Files\internet Explorer\iexplore.exe" I then created an Eset HIPS rule to block any process startup from cmd.exe. The result was: Time;Application;Operation;Target;Action;Rule;Additional information 9/17/2021 11:00:59 AM;C:\Windows\System32\cmd.exe;Start new application;C:\WINDOWS\System32\Conhost.exe;Blocked;User rule: block child process startup from cmd.exe; It appears you are using this utility: https://code.kliu.org/misc/elevate/ ; i.e. elevate, to bypass UAC and elevate to admin privileges. In any case, that should have no bearing on blocking the conhost.exe startup from cmd.exe.

You can add your wish here: https://forum.eset.com/topic/14259-future-changes-to-eset-endpoint-programs However, I'm afraid that notifications about blocked websites could generate email flood.

Thank Marcos, what is the best way to make the email notification a successful feature request? Our block list looks like this: # {"product":"endpoint","version":"8.1.0","path":"plugins.01000200.settings.stProtocolFiltering.stUrlLists.2.strAddresses"} *?.exe *.*.exe *.docm *.xlsm *.pptm *.vbs *.bat *.wsf *.rar *.winzip.com

An email notification can be sent when a threat has been detected but I don't think you can do it for blocked urls. Moreover, it's not possible to reliably block executables; download links may not necessarily end with ".exe".

I want an email when a client attempts to download an executable. We are using URL Address Management in Web & Email via /era/webconsole/#id=POLICIES to block executable downloads. I have tried configuring notifications via /era/webconsole/#id=NOTIFICATIONS, but haven't stumbled on the correct solution. We block the download, the client sees: Website blocked The web page is on the list of blocked websites specified by the user. Access to it has been blocked. Please help

Not sure if this is a bug or not (I think it is though). Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains: elevate "C:\Program Files\internet explorer\iexplore.exe" This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie: elevate "C:\Program Files\internet Explorer\iexplore.exe" It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well. Can someone from ESET check if this is an issue indeed, and, if so, provide a fix?

@Marcosthank you for your intervention. ESET support replaced the key with another one! Much obliged!

This sounds like the same issue I had, which I added to the posts on here I had noticed the updates generally had been quicker as of lately, and didn't notice much system issue. However while this update occurred, the PC was very sluggish, with Google Chrome for example taking a while just to open, and browsing seemed very slow, like Eset was causing it to be slow. However I did download a test download from https://www.thinkbroadband.com/download, using the 512MB one which was a lot bigger than Eset's update. I was able to download that in about a 1-2 minutes while as Eset took well over half an hour and even crashed at the end and had to restart. The thing is I can't remember any update issues before the updates where designed to use less resources. I don't know if this feature is any good because if anything it seems to be causing more resource issues/slowdowns, like everything is waiting for Eset to finish

The module was released to the pre-release update channel yesterday and is gradually released for all other users.

It was informed here in the forum on Monday 13/09/2021 that there would be an update of the HIPS but so far nothing. as shown in the image below. I believe the last update was on 8/27/2021

After today Eset once again stuck to the update and even after 1 hour waiting nothing changed, I doubt the reliability of Eset now more than just! The last few months are just too many errors that Eset has had since several builds and therefore I doubt so slowly the reliability of this AV's

I will discuss this with colleagues, maybe the help needs some corrections. The thing is that the so-call uPCU updates are installed only after a computer restart, ie. the user or admin decides when to restart the machine and install the program update.

Would that be okay even on the beta version I'm on? Also not sure if related but because of the crash went to https://www.eicar.org/?page_id=3950 to test things where okay - the first download eicar.com 68 Bytes allows me to download it and only blocks/removes once downloaded while the others block me from downloading.

You could try switching between release and pre-release update channel which will enforce download of all modules.

Had to restart but it seems to be up to date. What I might do is set the stuff ready to log but not go on my desktop for a little bit - As mentioned it can be quick someday but possibly if not been updated in a week, that could be where the issue is.

Hard to say. Theoretically there was a problem determining your location and you were routed to US update servers but your ISP had slow connectivity to the US at the moment. Logs would show what server you download update files from as well as what utilizes the disk or CPU at the time of the update.

I will try and do it next time - What about how long the update should take to download - now its showing 3/11 - but it's been downloading the updates for at least half an hour. Okay now Eset went 9/11 and completely crashed.

I've asked the developer of the updater to read your comment and neither him has an idea how ESET just downloading update files could slow down the whole system. We would need you to enable in the advanced setup -> tools -> diagnostics: - advanced operating system logging - advanced update engine logging Then run update and wait until it completes. Should it take too long, stop logging after 10-15 minutes. Next collect logs with ESET Log Collector, upload the generated archive to a safe location and drop me a private message with a download link.

Hello, See https://help.eset.com/efsw/7.3/en-US/idh_config_update_source.html Program component update Auto-update mode restarts your server automatically after the component update has been completed. this sounds bad for servers in production!