avielc

This is a 3 years old question by now. I have 2 client tasks that update the automatically AV software. for some reason a total of 5 machines are stuck on "Task started" (one of them is stuck on "waiting for product, so let's ignore this one) How can I cancel these job\session on these clients to rerun it again, without needing to wait for a timeout Another question, can we shorten the time out? adding screenshots Thanks

@Peter Randziak @Marcos Waiting for reply from you for 14 days now. Any chance for an update on the matter? (doesn't have to be a solution, but even knowing you guys are working on it, is good enough) Thanks!

@Peter Randziak - I'm back, Unfortunately, I have checked and found out the gui\ESET app itself doesn't appear in Ubuntu 20.04 (using the latest version you mentioned 7.1.6.0) I can see it is running in the processes in the back (using `ps -ef` in the command line) but there is absolutely no way to find the actual gui and see what is happening with it. I carried on with uninstalling it and reinstalling 4.0.95, and it just worked. GUI and everything. Can we get it checked somehow? Thanks

Thanks you @Peter Randziak I'll look into it, hope it'll be fixed.

still waiting for an update here. (just keeping this post bumped and updated)

@Marcos - That may be true but a new version has to be released for Ubuntu 20.04. Waiting to updates on that frontier. (Consider an operating system released 5 months ago and no support for ESET given for it..

Got it, Thanks, I'll make sure to do so.

Why raise a ticket with the local distributor, isn't that something that should be investigated on a global level? (This is a generic ESMC version after all)

Let me throw in another solution possible (Though it's hard to understand the security level of it) You can create a proxy in the cloud that will only be used for ESMC reports (and not mirror for AV Installation files\images to minimize the data usage costs) that way whenever the agent fails to report the local server, it use a failover using the proxy to reach it the other way around. (I managed to perfect that method in my case, where we do not allow local servers access from the external network internally.)

I would be glad to hear about it too, as There is no way right now to make certain all computers receive a scan properly, and when I pull out a report I can see that some machines haven't been scanned for a couple of months or more which is highly not good (even though I specified for Windows machines a weekly schedule it seemed it didn't work. Can you mention them maybe so they'll take notice of this thread? Thanks!

Well, apparently the answer exists somewhere in this forum(the differences between the smart and in-depth scans), found a user asking it eons ago, so that's been understandable now. Regarding: Actually, no, On a Windows policy you don't have to choose a target, but you can select "scan all targets" so there's no issue there On a Mac policy it seems there's no "Scan all targets" option for some reason, which is kinda odd, I would've expected some basic scanning option for Mac OS X. Don't you think @Marcos?

Well, Apparently I solved my own issue. But it's kinda weird. For Mac computers you can only add a scheduled scan if you add targets, Why is that? Can't you just let it do a scan on everything? Also,that raises another question How do I choose\ create a standard profile for ESET scans? (so there should be 3 scans, quick, smart, and in-depth - without needing me to suggest what they should scan) How come those don't exist?

Hi Everyone I noticed that when trying to schedule a weekly scan task for MacOS X or Linux using the ESET Policies it doesn't allow me to click "Finish" and save the policy. Any ideas why this is happening?

So the previous post with the same title was back in December 2019 - I was wondering if anything has changed and if its possible to filter out those computers that haven't been scanned, and if we can automatically trigger these machines to run a quick scan to make sure all checks out. Thanks

Thanks for answering @MartinK! and also, Thank you for explaining that. I am facing a problem now, I hope you can help me resolve. I'll sum up everything you said into the following statement: "This is the application level security between the agent and the ESMC" Which is great, but in terms of Apache\Proxy, I would like to add a layer of security there. Problem is I tried to add HTTPS as well as password protection, but both failed to allow the agent to report. Could you help me with what solution is supported by the agent (we are talking about replication purpose only, if there are any updates, I allow the agents to download from ESET-servers directly wherever the employees are (home etc)) Looking forward to hear from you Thanks for helping!

@MartinK @MichalJ @Marcos Hi Guys, Can I ask you for the specifics of how Agent reports to ESMC via Proxy? I need to provide my company the specifics on how secured it is. I understand that the agent needs to report replication to ESMC in order to receive updates\policies, dynamic groups etc. But in difference to receive updates - this HTTP Proxy can NOT use HTTPS and can not have credentials on it for replication. So to understand better and provide the right info to my company. What is secured in the replication process via PROXY if I can't use credentials or HTTPS communication to it. (and please be as detailed as possible.) Thanks!

Not sure I fully understand, but will an agent still be able to report back to ESMC using squid?

So, how come that feature exists in the first place. and also, if it's not supported, what other options do I have to secure an agent connection to an ESMC server without exposing the ESMC to the internet?

Hi @MartinK Thanks for the reply. I'll answer following your points. it is mandatory in my organization to have some safety over opening connection to the outside world. so having a proxy without any kind of security on it, is simply not allowed. - so Could you please elaboarte why it's not possible? I'm adding the credentials to the agents using an agent policy, should be good enough, no? That might be from the trace.log - agent trying to find the eset-server while changing to an external network. which would make sense and then create a "fallback" to the proxy. That's what I fear I might have missed some settings on the proxy for it to communicate with the eset-server. Is there somewhere clear enough to give that information? any settings I need to do on the server side for it to accept connections from the eset-proxy? After all the proxy is simply a linux machine with httpd pre-installed + mod_ssl and some conf file I'm trying to mash up from all the instructions lying around for windows and linux (non are clear enough on what should or shouldn't be, e.g. windows have "Virtual Server:3128" while the Unix doesn't... it's quite confusing) as mentioned in 3, you're probably right, just found out half hour ago about that "Allow CONNECT 443, 569 2222" no idea what that is about or how to make it work. Also, another point that might matter. I added to the eset-server certificates to make it SSL approved. unfortunately the proxy doesn't have - and it seems to return a lot of Curl(60) or (56) errors about certificate not set correctly (i'm testing with Curl --proxy to see if it works. which I either get html code 403, or 407 as mentioned in the logs. any idea how I should set it up right? If you can help me with a proper .conf file (at least as close as possible without some specific names like domain\authentication that'll really really help! Thanks

Hi, So I'm trying to setup apache proxy to allow clients to reach the eset server while being connected outside the office network (e.g. home) I've setup an apache machine in the cloud with open port to the outside (currently set it up on something random) Deployed agent policy on a test machine made sure it was received through the statue page. moved to external network - checked welcome page and saw I have access there. but the agent fails to report on the following error: attaching text of trace + message from the status.html on the agent data. - trace.txt Also attaching the apache logs in debug level. - apache.txt Please notice the following points: 1. a unix machine installed on the web with ESET Management agent that is reporting back to ESMC without a problem 2. Basic httpd installation part of a centos machine, on the server followed the instructions on https://help.eset.com/esmc_install/70/en-US/http_proxy_installation_linux.html 3. changed it a little to try and make it work better (somehow managed to lose the grant deny error I had at first - but it might not be a good thing according to the log. Something I noticed but i'm Unsure of. is there some configurations I need to do on the server side to accept these connections from the apache? adding a certificate or something? (Just noticed I have a proxy certificate available in ESMC) Thanks trace.txt apache.txt

Can I remove the other jobs that say "Task started" Using some command directly to the mysql? (I assume this is where it stores the status, but I could be wrong here)

Thanks for replying Marcos for some reason the attachment didn't catch so I'm adding here. As I mentioned the task is already on "Running" state for 3 computers, and nothing changes because they are off the network.

Hi everyone I have a client task that is running ESET Endpoint Antivirus installing on Macs and got stuck on 3 employees that aren't on the office network anymore.(attached screenshot of the tasks stuck) any chance I can stop them or make ESET stop trying? (maybe via mysql or something?) Thanks

Hi @Compuco I managed to find to resolve it by removing some library from Ubuntu 18.04 (I believe you may have the same issue, so might be worth trying If you don't want to bother seeing the post here is the command You need to remove a amd64 lib and that solves it. Best.

Thanks a lot! Glad to hear it!