ESET in the Enterprise -- Desperately Needed Enhancements

I imagine this thread may grow as others chime in. . .what I want to do here is to start a list of enhancements that IMO are necessary to take ESET into the corporate enterprise market. I say this as an administrator of 135 licenses of ESS in my current position, and another 30 at a second company I consult. I'm sure there are bigger users out there, but these are items that IMO have got to be remedied for use in a centrally-managed environment.

1. Support, support, support! When an enterprise who spends thousands on software has an issue with a virus, or with the software not responding, or whatever, they are not going to tolerate logging a case on a website and waiting several hours--or even overnight--to get a response. Even if a support contract, incident pack, or some such has to be sold for extra money, there has got to be the possibility of pick-up-the-phone-now, get-support-now technical service. Until then, it may be satisfactory for individual users and small businesses, but it will not be enterprise-class.
   
2. Roadwarrior update support. When a laptop user is inside the LAN, it should get virus signature and/or program updates off the LAN's mirror server. When it's out of the LAN in the field, it should get updates from ESET directly. If that user moves from one subnet to another, each with its own local mirror server, it should get updates from the closest mirror. Right now, this is [GLOW="sort of"][/GLOW] possible using a weird hack described on page 74 of the ERA User guide, section 10.4 "Combined update for notebooks," but this is a ridiculous hack that only sort of works (if you don't turn off the regular automatic update task, you still get "server not found" errors too). Update selection should be possible by simply creating a list of authorized update servers, and detecting which is valid based upon current LAN settings.
   
3. LAN Subnet whitelisting. The enterprise network is going to have lots of traffic internally that needs to be unfiltered, without exposing the protected PCs to whatever garbage is on the internet. While the enterprise better have its own external firewall and NAT in place, there is still plenty of good reason for personal firewall software to add another layer of security. For ESS to provide that security, however, it has to be possible by policy, in one simple place, to whitelist an entire subnet (or more than one, or specific IP addresses/ranges) so that absolutely no filtering of any kind gets applied to them. The fact that this is not the case has forced me to turn off the firewall component entirely for a whole subgroup of my users (see this thread). This is unacceptable in the enterprise.
   
4. Rule/policy/settings management. It's nice that I can choose to apply a setting once to one or more computers, or choose to create a company-wide policy, or a group policy, or to an installation package. It's not nice that if at different times, different settings are applied via these dissimilar routes, there's no centralized place to update/reset that setting so all iterations are in agreement. There should be.
   
5. Policy/Settings Discovery. Related to the above, if you need to find where a specific setting is coming from, good luck. Is it local, is it in your policies, is it in your installation package, or did you just apply it to one or more computers? There's no way to know but to search.
   
6. Less redundant settings. There are at least four different places where you could set (or set incorrectly) your update username and password--in the program's own update settings, in the installation package's update settings, in the policy editor, in the bogus laptop settings described above. Get them wrong in any one place (or get a changed password due to license changes) and good luck finding where you need to change it. Something as key as the update password should be changeable once--at the ERA server--and replicate across all managed systems and settings.

OK, that's the beginnings of my list. What else can you think of? I want to be able to tell my geek colleagues that ESET products are the best option they could want for their large enterprises. Now I can say a whole lot of good things about security, performance, granular management, etc... and all these things are true and good. But I still have to warn them with these caveats, that it's really not YET an enterprise-class product.

 

Interesting Post dw..

I'm not using it on an Enterprise scale but I'd love to see a small SMB server for agents out there.

 

Hello,

Your feature requests have been forwarded to the responsible product managers.

Regards,

Aryeh Goretsky

 

Hi There,

I think I can address all of your concerns, let's see how I do.

We sell a Premium Support SLA already. It has dedicated phone numbers that skip the regular support queues, and hotline phone numbers for 24/7 response to critical issues. You can discuss this with your sales representative or reseller.

Have you seen this?
http://kb.eset.com/esetkb/index?page=content&id=SOLN761
This is far from being classified as a "hack" and it involves editing the default update task - no errors are generated.

I hear you. This is coming.

Currently we recommend not setting anything in the installation package if the targets of that package are going to be connecting to an ESET Remote Administrator Server. Everything should be done via policies, and a robust grip on the policy inheritance and merging model makes it easy to see which settings are actually being applied to clients. Policy management is continuing to improve as well, keep an eye on http://www.eset.com/support/news.php.

The current model doesn't give an individual setting a 'source' or 'home' like you are talking about. Our client software only has 'local' settings. Once a policy or task is applied, or a configuration file is imported, those are the new 'local' settings. It's not like a client has some checkbox checked for real locally, and the policy is overriding that. The policy changes the local settings. I think I know what you're getting at, maybe some kind of configuration version tracking? Like Aryeh said, it's been forwarded to the Product Managers.

I think this is a little upside down. I'll use your example of the update credentials. They can be specified locally on the client, in a preconfigured installation package, in a policy on the server, in a task from the server, or in a configuration file that is imported later. You only have to get this right once and it will work. If you put the wrong information in the package, you can fix it in the policy, and so forth. There aren't multiple places where this setting resides on the client - there is only one. You just have multiple ways to change it. This kinda ties into the previous point, I think.

I hope this is helpful, if maybe not the exact answers you were looking for.

Regards,
Carl Burnett

 

Thank you, Carl, for your response. I'm amazed to hear that there is premium support available, as I've been bellyaching to my sales rep for at least two years on this point. I'm a little surprised he never told me about it. . .

With all due respect, on the roadwarrior point, anything that involves that level of complexity to set up, if not qualifying as a "hack", is certainly in the "workaround" category. It's entirely unreasonable that something of this sort, which you guys have known about for years (I set up laptops in this way > 2 years ago according to the same instruction), has not been consolidated into a "Roadwarrior" setting in the management interface. To still have to go through these gyrations after all these years is ludicrous. And it doesn't address at all the issue of a roadwarrior who may plug into one of several corporate locations, each with its own local mirror. So I'd submit that one has yet to be adequately addressed.

Whitelisting. . .how soon, please please please, how soon? I literally can't run my firewall software on internal PCs till I have it . . .

I understand what you're saying about the installation package, and now that you say it, it makes a lot of sense. One exception to your rule, I'd submit, is the setting that whitelists the internal network for file & printer sharing; if that is not set in the package, you have to approve the network for sharing at the desktop level before it re-connects to either network or server (I learned this the hard way. . .)

I see, too, what you mean about the password setting. The rule of just setting it at the policy level does make sense. Thanks. The overall policy question, to maybe make it a little clearer, would be something analogous to the Active Directory "Resultant Set of Policy" report generator that Microsoft AD Group Policy Editor provides. I know it probably hurts to have Microsoft offered as a paradigm, and believe me I don't do that lightly. . . but in this case I think it's at least a useful concept.

So overall, Carl, I appreciate your response. Y'all have a ways to go, but you offered me several helpful tips. Again, thanks!