sreece

We are on ESET Protect Server 10 virtual appliance. We are trying to deploy Protect to a VM that does not have internet access. The module update fails because the VM does not have internet access. As far as I can see, the VA does not support ESET Bridge. Is there a setting to allow the ESET Protect VA to cache module and signature updates for clients? Thanks!

I'm able to go into the detailed view and update them one at a time, but I can't seem to select all hosts in the list. How do I update all clients with outdated management agents from the dashboard?

I'll give that a shot, Greg, thanks.

Marcos, updating via task is easy enough, but it would be useful if you could simply click on the outdated agents list in the dashboard and the update the management agent. Currently, you always get a message saying that no products that can be updated automatically can be found. Additionally, it's time-consuming to go through the list of PCs and match up the hosts that need to be updated while excluding the hosts that already are, especially since you can't sort the older version list by host name and have to export to csv, open in Excel, and replace the "spol. s r.o.;7.X.XXX.X;" string with nothing to get a sortable host name. Maybe I'm doing this wrong? What happens if a host already has the latest version? Will it re-install and require a reboot or will it skip that host?

It's not blocking the connection. I get to the login and can login fine, but I get a black screen after the password and Duo prompt are handled. The only process running under that user is the eGUIPpoxy.exe, and trying to reset or logoff the disconnected session using Remote Desktop Manager fails. Other users are able to log in fine, it's just that the user with the hung exe is not able to log back into the disconnected session (which also can't be killed because no users have access necessary to kill it). I do not have that hotfix installed, but we aren't facing an issue where the computer stops responding. The server is still up and functioning as a file server and other domain admins can log in; it's just that my session can't be reset so I can log into the server again. Based on this (https://help.eset.com/efsw/7.1/en-US/idh_config_epfw_scan_main_page.html), we do not have Protocol Filtering enabled since those features are not shown in the GUI.

Hello, I am running ESET File Security 7.1.12006.0 on a Server 2008 R2 VM. Several times now, I've been unable to log in via RDP or console, getting just a black screen and hourglass mouse. Even after attempting to kill the open sessions, my user still has one open process that can't be killed remotely or locally: eGUIProxy.exe. When I try to kill it locally, I get a message that access is denied. The only fix I've been able to find is to reboot the server, which is not an ideal situation. Has anyone else run into this? Any ideas on how to fix it? Thanks!

Hello, Having no success activating endpoints from ERA after updating the license in ERA successfully. Activation tasks fail over and over. This post had the same issue, but rather than a solution it was taken offline: Going to the EDF shows this: <?xml version="1.0" encoding="UTF-8"?> <ecp:message xmlns:ecp="hxxp://www.eset.com/2012/02/ecp"> <ecp:response><code>20101003</code> <message>Unsupported Content-type: unknown</message> </ecp:response> </ecp:message> Has anyone successfully activated from ERA lately?

Performed the upgrade from a newly deployed appliance and it worked great. https://help.eset.com/era_deploy_va/64/en-US/index.html?pull_db_from_other_server.htm After updating the tasks to just use the admin name without the domain in front, the tasks completed successfully. Case closed!

I'm attempting the appliance migration route, but Step 5 (service eraserver stop) fails because that service doesn't exist. Should I just bring up the new appliance and use the database import as mentioned in this article: https://help.eset.com/era_deploy_va/64/en-US/index.html?pull_db_from_other_server.htm

Hello, We started on 6.2 and have updated through to 6.4, but our appliance appears to be fundamentally broken. The management console does not have any of the option to rejoin the domain, factory reset, change the password, etc. I've attached a screen shot. The result of all of this is that static group syncs do not work and can't authenticate against the domain. In fact, the keystore seems to indicate that the certificates just stopped renewing in December and are expired. We've rolled out the agent and client to all of our hosts, and I'm wondering how difficult it would be to migrate those hosts to a new ERA appliance. I don't care about the historical data since we've never had an active infection. Is this possible? Thanks!

So was this ever implemented? When I go to the static group to view a client, I can see that 4 policies were applied in the policies column. However, when I try to manage policies, it shows 0 for the client.

I was able to fix the push issues by editing the smb.conf file. Just an FYI, my version of samba (use smbd --version) is 3.6.23-30.e16_7. Go to the ERA appliance command line. Run: # nano /etc/samba/smb.conf Add the following value/string under the [global] section: client ipc signing = auto Save the file and write the changes. Restart the samba service with: # sudo /sbin/service smb start Now, to figure out why the server stops updating the client "last connected" times after a few days.

This is becoming a huge headache. Even if I install the agent locally using the batch file, the hosts still don't phone home, and I still can't push the client. Was 6.3 truly tested, because I find it a bit difficult to believe these bugs weren't found.

As far as I can tell, here is no specific client or server task that can force the re-application of an existing policy to a client. Crazy, I know. You can try to create a duplicate policy, then move the client to the new one. Once it applies, you can then place them back under the old policy. Go to the Policies under Admin, select your policy, then the gear or Actions, and then duplicate.

I'm not going to get into the issue of "it should just work". That would be ideal, but here we are. I would just like the ERA server to be able to determine if the pre-requisites are met, and, if not, indicate exactly why they aren't. Listing 7 possible reasons isn't sufficient for a failed remote installation.