anthonyh

I apologize for the inconvenience. Are you familiar with Process Monitor by chance? If you are, I would like to see what is winding up the WMI Provider Host Process. Typically we actually see this kind of activity when there is an application called Conduit, or Conduit search on the machine, which is considered a toolbar or "Potentially Unwanted Application. Here is the link to the Process Monitor download page: hxxp://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

I apologize for the delay, unfortunately the only supported remote upgrade method on Linux is through the remote install/remote upgrade function of the Remote Administrator Server/Console itself.

Based off of the settings in the screenshots that you have posted, the messages marked at 76 should have been quarantined just like the others. Can you open the logs and take a look at the Event logs to see if any modules have had any issues loading? Also, make sure there isn't anything in the allowed lists that would be letting these messages bypass the ESET antispam agent.

I apologize for the inconvenience, are the clients set to talk to the server over the standard set of ports (2221-2222)? With the push out to version 5, are you able to NSLookup both the hostname of the machines and the IP of the machines, and do they both return correctly? Also, are the firewalls down and is the RPC service available on the machines?

I apologize for the inconvenience, but it sounds as if there are policy rules or group rules in place. If you go to Tools> Policy Management it will pull up a window with two tabs. In the Rules tab, are there any entries?

Unfortunately as of right now, there is no official integration or best practices on our side. NetApp does have a PDF which can be found at the link below which they advertise as their Scanning Best Practices. hxxp://www.netapp.com/us/system/pdf-reader.aspx?cc=us&m=tr-3107.pdf&pdfUri=tcm:10-61066 Part of the reason ESET cannot be set to scan it automatically is that the ekrn service needs to run as a system service. Unfortunately services that run under System are not given rights to access network drives, so a scheduled scan will not be allowed to run on a networked drive. A scan can be triggered manually as long as the user initiating the scan has rights to access the network drive.

Hello, Any time a rule is tested, it only shows the variables because there is no client invoking the log entry which would generate the rest of the information which would replace the variables. When the rule is actually invoked by a a client, the variables will be replaced with the relevant information.

Hello, Unfortunately we do not have a website where you are able to download the updates as a package which you would import into your ESET product. To manually update your ESET security product on a computer that does not have Internet access, it must be configured to retrieve updates from another computer that does have Internet access. On a network, the computer connected to the Internet would periodically download updates from ESET and then be accessed as a Mirror server by the other computers on the network. More information on setting up a mirror server can be found in this link: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN374

I'm sorry to hear that you are having issues, but there are a couple things we can check: Is there a password required for replication? If there is, try removing it from both the upper and lower servers and see if they can connect. Also, is there an exception set for port 2846 on the firewall of the upper server? If there is a firewall between the two subnets, the exception/forwarding will also have to be done there as well. Here is a link to a KB article which may help: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN950&actp=search&viewlocale=en_US&searchid=1403803983778