carmik

We have purchased Remote Utilities and installed it for IT support purposes. Some days ago due to our ESET license expiring and till the renewal taking place we decided to enforce the antivirus-maximum protection policy. Today around 100 Remote Utilities installations were eradicated. Upon investigation it seems that the specific ESET policy switches potentially unsafe application handling (reporting and protection) from off to balanced. This action had us running around, trying to restore connectivity for teleworkers. Until I found out that the policy to change was the one written above, I was trying to find how to effectively add exceptions for Win32/RemoteAdmin.RemoteUtilities.W (as well as .X and .H variants). What is strange enough is that some Teamviewer installations we have were not harmed at all, whereas all Remote Utilities installations were damaged to the bone! 1) What's the fastest way to add an exception to ESET Protect? From the KB, it seems as though this feature has been crippled on ESET Protect, whereas on ERA/ESMC worked just fine (IIRC) 2) Granted, Remote utilities is a remote control (hence potentially unsafe) app, but why on earth is it a "bad" remote access package and Teamviewer a "good" one? We switched to ESET upon my recommendation, mainly for the quality of the signatures, was I wrong in making such a decision? I'm off trying to salvage what I can from the broken installations...

It was a network/proxy issue after all. It was resolved today and I my tasks are operating just fine now (ie I can assign all products). Consider the case solved. And thank you for your help.

@MartinKsome more comments. First, I believe that the KB relevant for our case is kb7811, since we are using ESET Protect 8 and not 7. Now, after reading that KB article it would seem that if we are able to access hxxp://repository.eset.com/v1/info.meta we should be ok (considering our server was set to AUTOSELECT), but although we download the info.meta from this link successfully, we still do not see all the products available for inclusion for a ESMC task. My understanding of what is meant by KB7811 is that we should be ok and we should look no further? Perhaps the article should be rephrased a bit to have a more clearer workflow, especially if the first step succeeds. Ie: should one try to undertake the steps mentioned in steps II onwards or not in that case? Haven't had my first zip of coffee so I might not be reading some fine print correctly here.

Access to repository.eset.com is ok, whereas repositorycdn.eset.com fails. We are still waiting for resolution.

@MartinKthe issue is that trying to wget something from hxxp://repositorycdn.eset.com gets a zero sized reply (502 or 503 http error IIRC) from our WAN proxy array... Access to repository.eset.com is ok, and that is why we can "see" some products in the task, whereas others do not appear.

An update on the case. We had a thorough, multi-hour troubleshooting session with ESET local support and isolated the issue to be possibly located to the array of the network-transparent proxies. I've opened a ticket with them and anticipating a resolution hopefully by tomorrow. It really helped that a colleague of the ESET bloke I was discussing with had a similar problem from another organization within the same WAN, indicating some sort of network issue. Oil's well, will update when the thing is fully resolved.

I've sent the details at noon, containing a link to this thread, hope I'll be hearing soon. As for the network itself, your concern is well-founded, however there are another 6 LANs like my own, all in the same corporate WAN, that (AFAIK) are fetching updates without any issues. An array of network-transparent proxies performing layer 7 filtering intercepts all outgoing traffic, affecting all LANs. This is not under my control though. Of course something might have gone bad there and my colleagues at the other installations have not noticed it yet... Is there some tool I could use from a windows/linux shell to test whether anything eset-visible-infrastructure-related is ok from my side? That would help isolate a networking issue pretty fast.

Regretfully, the issue re-appeared. In the first place, the cause was my fault: after the network changes I neglected to change server settings on the eset protect web console to direct the server to fetch updates from the new network proxy (essentially the apache proxy running on the same VA). I updated the settings, setting protect to point to new ip and I started seeing again the ESET Endpoint Security repositories. It all went fine for a day or two. Today I tried to run the same task, but my eset endpoint install tasks failed with a unable to find repository message. Editing the task I see that again endpoint security packages were not listed, whereas other products (safetica, ESET file security and others) were. In addition to that problem, all my endpoint systems report that program updates have failed! @MarcosI have no other option but to open a ticket. However, you've not responded to my previous queries on how I should enable extended logging and which exact files I should send from my VA installation (see two posts above). Please get back to me as soon as possible, I want to have this reported today if possible.

Never mind, issue solved. It was a misconfiguration after the re-numbering of our ip range, which although it happened 3 weeks ago, eset protect just now complained... Case solved, thanks again for your help.

@Marcos please disregard my question about pcap, did not notice that you've mentioned tcpdump in the process. I do have a number of questions regarding the log files I should submit. Specifically at https://help.eset.com/esmc_install/70/en-US/log_file.html three files are listed for v7 of ESMC: /root/appliance-configuration-log.txt, /var/log/eset/RemoteAdministrator/EraServerInstaller.log and /var/log/httpd (which is a directory). I have ESET Protect (v8) as a virtual appliance (updated from ERA -> ESMC -> ESET Protect) installed, therefore I do not know if the files/directories above are valid or not. Questions: 1) Are the 3 files above sufficient? Or do you need the entire /var/log/eset/RemoteAdministrator and /var/log/httpd directories? 2) Do you need all access_log files from /var/log/httpd or is the latest access_log and error_log sufficient? 3) How do I turn extended logging on ESET Protect? TIA, M.-

1) Which pcap log are you referring to? Should I get a tcpdump on the network interface of the VA? 2) Should the ticket be opened with ESET local (national) support?

I believe I'm not using the ESET proxy (IIRC that was a product to mirror ESMC server installations). I'm using the bundled Apache HTTP proxy: # rpm -qa |grep htt httpd-2.4.6-97.el7.centos.x86_64 httpd-tools-2.4.6-97.el7.centos.x86_64 httpd-tools-2.4.6-93.el7.centos.x86_64 From the logs (/var/log/httpd/access_log) it seems it is running normally. Apache connects directly to the internet (no upstream proxy).

Thank you for your fast reply. I am not deploying an installer. I'm using a task for this purpose. All Endpoint Security/Antivirus are missing.

I have a 8.0.x (latest) ESET VA running for some time now without any issues. Today, I tried to run an ESET Endpoint Security task that I had pre-configured and ran successfully over the last weeks, but the operation failed. Editing the task showed that it does not display any endpoint security products for install, only file server products etc. I double-checked the task filtering options (in case I was excluding the options) but they seem ok. Any idea on what to try to fix this? I had this issue a year ago but at that time it seemed to be an intermittent ESET repository issue.

I'll consider that, thanks. I do know that ESET HQ was implicated in our support incidents. What I'm missing as a long time Kaspersky endpoint administrator, is the ability to open incidents directly with the HQ, via a ticketing mechanism. Hope you will implement something like that.

Used ip exclusions to do the trick. As for opening a ticket, I must say I have not received sufficiently good support from ESET local support here in previous cases...

Due to a network topology change, I had to create new certificates for the nodes. ESET was already installed. Does this mean that a different resolution should be followed? Also, is there any way to exclude this lan traffic from TLS filtering?

Hello, he have a number of Proxmox- (PVE-) based hypervisors. For the last weeks even though I was able to connect to the node web admin, I was unable to open a PVE console to any running VMs on the node. Today I saw a reference mentioning ESET and TLS web filtering. Disabling did the trick! My question is this: is it possible to exclude domains of the form something.lan or something.local entirely from TLS filtering? i want to keep TLS filtering but only for internet sites. Thanks for any information provided.

Yesterday, after searching a zillion of articles we finally stumbled upon the same Kb, which we followed. Now we have a working era 6.5, but in 64bit. I regret to say that even though it is a well documented procedure, it is not for the faint of heart. Many details had to be taken care off, like upgrading the old era installation to SQL express 2008 r2 sp3 etc. A strange thing is that after importing the database and installing the same Era albeit in 64bit, the old certificates were already there, we did not have to import them again. Clients are connecting just fine. On Monday we'll check if updates are going well too. If everything is ok, we'll upgrade to 7.x. would you suggest to upgrade directly to 7.2, or use an interim 7.x upgrade first?

Anyone? This is a complex (policy and group-wise) 1000+ endpoint installation, your help is seriously needed!

One more: if I understand correctly, with this procedure we'll be creating an entirely new (new ip etc) infrastructure, on which clients will "respect" as the new ESMC. However, custom static and dynamic groups, policies and templates will not be recreated on the new ESMC. Is that correct? If so, is there a less painful way to proceed, even if it utilizes a new ESMC on WIndows 64-bit?

EDIT: Strike that out, I understood what you meant. Would that work in a scenario using an ESMC VA appliance as the new system?

Please forgive me, I'm not sure that understand what you mean by stating that the new installation will not use the previous database (from the existing ERA server). Does this mean that we'll have to re-created policies/dynamic groups etc?

In that case, how would one go to update from 32-bit ERA 6.5 to 64-bit ESMC? Can I backup the database and certificates, and feed them into a 7.1 installation?