Jump to content


  • Posts

  • Joined

  • Last visited

About circumpunct

  • Rank

Profile Information

  • Location
    Saudi Arabia

Recent Profile Visitors

456 profile views
  1. The main thing I'm not happy with in the current release is the way it serves up alerts to historic errors that have gone away. Here is an example: We have a lot of laptops that get carried around. When they are on site, the are on our LAN and the agent talks to the ERA - and when off site they do not. As soon as they get on the LAN after a trip outside, the ERA starts showing 'could not connect to server' errors. Obviously they could not connect to our server when they were off site and the time of the 'errror' reflects this. But as soon as they are back on site they connect and the 'last connected' time reflects this. So they seem to cache up the 'could not connect' error and report it to the ERA only when they CAN connect! The problem is this throws up a big red 'critical error' section in the doughnut chart when in fact there is no real current error at all. To tell if this is a real error, e.g.some horrible malware picked up on a customer site, I have click the chart, click 'detailed information', click the line, click 'click here to see the list' and only then can I see from the connect time that this is not a real error at all. That is four clicks mulriplied by the number of laptops and I have COMPLETELY WASTED MY TIME. I'm sure a lot of overworked people in IT will agree with me that time is the most important resource we have. I really don't need ESET taking it away from me.
  2. Problem solved. It was showing in the 'not connected' report of ERA, but it seems to have been old data. We deleted it from ERA and let it recreate itself and now all is fine.
  3. Yes, that is the tail of the log file including the last line. Status file shows all green. No errors.
  4. Thanks Jim. What am I looking for? No mention of the errant machine by name or ip. Just yards of this sort of thing: 2015-06-17 06:48:34 Information: SchedulerModule [Thread a4c]: Received message: RegisterTimeEvent 2015-06-17 06:48:34 Information: CDynamicGroupsModule [Thread a7c]: Refreshing static groups after replication 2015-06-17 06:48:35 Information: CDynamicGroupsModule [Thread a7c]: Retrieving currently matching dynamic groups with static groups path to root 2015-06-17 06:48:35 Information: SchedulerModule [Thread a4c]: Received message: GetRemainingTimeByUserDataRequest 2015-06-17 06:48:35 Information: SchedulerModule [Thread a4c]: Received message: RegisterSleepEvent 2015-06-17 06:48:35 Information: CPoliciesModule [Thread 588]: Applied policies list status log published 2015-06-17 06:48:35 Information: CPoliciesModule [Thread 588]: ReevaluateActivePolicy sent message CApplyPolicy 2015-06-17 06:48:35 Information: CPoliciesModule [Thread 588]: Apply policy message published 2015-06-17 06:48:35 Information: CPoliciesModule [Thread 588]: Applied policies count status log published 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CPoliciesModule (used 1604 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module CSystemConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CSystemConnectorModule (used 28 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module CEssConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CEssConnectorModule (used 28 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module ERAG1ClientConnector 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module ERAG1ClientConnector (used 0 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module CMDMCoreConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CMDMCoreConnectorModule (used 0 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module CVAHCoreConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CVAHCoreConnectorModule (used 0 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module AgentToProxyConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module AgentToProxyConnectorModule (used 0 KB) 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Starting module CRDSensorConnectorModule 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Started module CRDSensorConnectorModule (used 0 KB) 2015-06-17 06:48:35 Information: CEssConnectorModule [Thread aa0]: Connecting to product 2015-06-17 06:48:35 Information: Kernel [Thread 588]: Used memory after modules start-up is 23556 KB 2015-06-17 06:48:35 Information: CSystemConnectorModule [Thread a9c]: Connecting to product
  5. We have ESET File Security 6 running on Windows Server 2008 R2 Standard, and ERA 6 running on a separate dedicated Win 7 PC in the same domain. ESFS won't talk to the ERA. No errors. Just it does not make contact. All other PCs talk to the ERA with no problem. We suspected the Server firewall, but nothing obvious shows up and the agent has a free pass though both machines. I'm not yet up to speed on the ver 6 logs, but nothing jumps out. It just looks like the agent isn't trying. Where is a good point to start investigating this?
  6. Sorry, I don't really have time for this. We have installed another product.
  7. And... ? This is driving me nuts. We now have five machines doing this at least a coupel fo times per week.
  8. On a few workstations I am getting: "Virus signature database update ended with an error. General compiler error" Clearing the cache, rebooting the workstation and updating the sig again always clears the error. However this is happening repeatedly and is becoming a pain. Any ideas? Virus signature database: 11749 (20150607) Rapid Response module: 6136 (20150607) Update module: 1056 (20150113) Antivirus and antispyware scanner module: 1456 (20150512) Advanced heuristics module: 1154 (20150129) Archive support module: 1227 (20150511) Cleaner module: 1108 (20150424) Anti-Stealth support module: 1075 (20150504) Personal firewall module: 1264.3 (20150514) Antispam module: 1029 (20141103) ESET SysInspector module: 1246 (20150121) Self-defense support module: 1018 (20100812) Real-time file system protection module: 1009 (20130301) Translation support module: 1341 (20150429) HIPS support module: 1179 (20150512) Internet protection module: 1173.7 (20150428) Web content filter module: 1037 (20141103) Advanced antispam module: 2330 (20150605) Database module: 1065 (20150416) Configuration module (33): 1042 (20150327)
  9. Reports about an out of date OS from agent may be useful in cases when agent is already deployed and an admin wants to make sure that the OS is fully updated before continuing with Endpoint deployment (e.g. to prevent serious issues from occurring when certain hotfixes are missing). I'm trying to be constructive and not unreasonably critical, but I can't see that makes any sense at all. If it's a pre-installation check and it is so load-intensive, why keep running it after EES is installed? And what use is it as a pre-installation check if it can generate false alarms for 18 hours after an OS update? I really just want to know if all my PCs have the latest OS or not. Right now ERA generates too many false alarms. I have a bunch of other issues but no time to deal with them at the moment, so we are reverting to another solution. We are still running EES/ERA on a small test network and may come back to ESET if the product and documentation improve. Thanks for trying to help.
  10. If I understand you correctly, you have TWO separate systems on each PC checking that the OS is up-to-date? (Why duplicate a system that you have already said is resource-intensive?) One of them will incorrectly report to the dashboard for 18 hours that the OS is out of date if it happens to run just before an OS update? The other will check the OS, but will not report it to the dashboard? I really hope I have misunderstood something here, because that sounds quite ridiculous. I've been an EST fan for decades, but I'm seriously thinking of jumping ship. If the ERA is so borked up, how can we be sure the AV is any better?
  11. I had the same issue. Could never get the task to work. Solved it by installing 6.1.444 ERA component directly from the .msi on the local machine.
  12. A further comment: What has the agent to ERA server connection got to do with resource use? The EES already knows the OS is up to date and is reporting this correctly on the local machine. It is just the ERA that has outdated information. Surely all the agent needs to do is pull the info from the ESS and send to ERA? Can't be more than a byte or two at most, and all on the local LAN. Why does it need to wait 18 hours to do that to 'save resources'?
  13. Thanks for the quick reply. Option one is a bit confusing. I can supress the ERA OS update check by policy, but ESS iteself will take over OS update checks? I presume what you mean is ESS will do update checks but will not report them to ERA? If so, that's not an option. It's basically just turning off the feature - unless I inspect the PCs manually. Option two seems a bit of a cludge. Presumably this means running a perhaps unnecessary OS update job, just to force an OS check? Again, not particularly satisfactory. No way to force the check without the update? Is there at lease an option to delete the indidividual OS (and other) alerts? I would assume this was an incuded feature, but I can't seem to find it. I'll try a little longer with ERA 6, but I think we will probably revert to 5 until it gets fixed properly. IT is busy enough and I don't have time for this. Thanks for trying.
  14. This is probably just misunderstanding of how v6 works. By default, agent reports system issues you've mentioned, howe ver, youcan disable these reports via agent's policy. If you look at the details of the alerts, you would most likely see agent as the source. Then please explain how it works. Hey, I'm on your side. I used to sell the previous version and made a good living off it. But I can't figure this out or find any documentation to explain it. Here a sample issue. Please tell me how to resolve it. I'm getting a lot of alerts on the dashboard telling me there are problems, but in fact the problems have cleared. ERA 6 does not tell me they have cleared, so I'm wasting time chasing them down. Example: I have a machine showing in ERA6 as OS out of date. The OS on the machine has in fact updated and the EES 6 on the machine correctly shows no problem. Looking at the ERA, the machine last connected a few minutes ago. The problem is still listed, with a 'problem occurred' time of a few hours ago. How come it still shows in the dashboard donut (even refreshed) as a problem? It is now historic. I can see that having an archive might be useful, but I don't need summary notifications showing problems that have gone away. I also don't want to suppress OS currency messages as it could fail to update in future. I aslo dont need to supress messages older than 'n', because how do I know the problem has cleared? Basically I would like the ERA dashboard to show the CURRENT situation, in the same way the EES on the machine does. I don't need it showing me red and yellow donuts for problems that no longer exist. Multiply that by a few hundred PCs and it becomes a nightmare. Am I missing something here? If it is possible, how do I set up to show the current status? And why is that not the default? I hope this is a constructive post and I really do want to get this sorted out rather than revert to ERA 5. Thanks.
  • Create New...