Inconsistency between Remote Admin and Local Preferences

Discussion in 'Other ESET Home Products' started by tanstaafl, May 22, 2010.

Thread Status:
Not open for further replies.
  1. tanstaafl

    tanstaafl Registered Member

    Joined:
    Apr 8, 2005
    Posts:
    207
    I'm trying to figure out exactly which setting I need to change in the Remote Admin Policy Manager, to effect the

    'Web Access Protection
    > ThreatSense Engine Parameter Setup
    > Limits'

    settings in the local client (NOD32BE v 4.2.35 currently).

    Anyone?

    The settings in the Policy Manager really should be identical to the ones in the client, otherwise confusion reigns.
     
  2. tanstaafl

    tanstaafl Registered Member

    Joined:
    Apr 8, 2005
    Posts:
    207
    Ok, through trial and error I figured out that it is the setting under the 'Personal Firewall' section in the Remote Admin Policy Manager.

    WTF?!?!?!?!?!?!?!?!

    I am not using EESS, I am using the pure EAVBE, which does not have a firewall.

    This is really, really bad UI-fu. Look... I like ESETs products, and have been using them since NOD32 v 2.5, but after all of the mess of v3 and the early versions of v4, and now this inconsistentcy between the Policy Manager (which I really like that I can make a change to a policy and have it *automatically* picked up by the Clients now! So bravo for that!) - but the bottom line is, I am now seriously considering trying Sunbelts VIPRE Enterprise out. I already demo'd their enterprise interface, and it is much more consistent than ERAS/ERAC, and they claim a much higher success rate blocking these stupid Rogue Antivirus malwares, and as good or better success with all other AV/Spyware/Malware.

    ESET - you have about 6 months to fix the UI for the Policy Manager - meaning - have a separate section for each product (ie don't combine the EAV and ESS products into one, have a separate parent section for each one), and position and name each section, and each preference under it, identical to the ones in the client Advanced config tree.

    Otherwise, since we have 1.5 years left on our license, and Sunbelt will give us up to 1yr license/credit if we switch, I will be much more inclined to make the switch.

    And no, I am not threatening, merely pointing out a fact - your Remote Admin and Policy Manager interfaces should look identical to the local client config interface, as far as section/preference names and locations (in the tree) are concerned.
     
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,456
    The HTTP/POP3 scanner is part of the firewall which is partially present in EAV, too. For this reason, it's impossible to separate settings for a particular module into several different sections. Even though it might be confusing at the first sight, the HTTP/POP3 settings are placed logically in the configuration tree.
     
  4. tanstaafl

    tanstaafl Registered Member

    Joined:
    Apr 8, 2005
    Posts:
    207
    Irrelevant to my point/complaint.

    Excuse me? Impossible? Sorry, but I know enough about programming to know that is a ridiculous statement. You simply separate the GUI representation of the settings from the back-end settings themselves. I'm not saying it wouldn't require some work, but it certainly isn't 'impossible'.

    Again, why can the Policy Manager interface not simply mirror the UI/config/layout of the respective client UI/config/layout?

    To put it another way - currently, when editing a policy, there are 4 sections: NOD32 v2, ESS/EAV, Unix, and Remote Admin.

    What I am saying is, split ESS/EAV into separate sections, so that the tree for *each* can them be displayed identically to the actual/respective client config tree. Yes, some, even a lot of things will be duplicated... so what? Its computer code - code it such that the duplicated parts are only duplicated in the displayed GUI, in the back-end they can be the same settings being edited.

    Why combine them when you don't have to? It only complicates things. Keep it simple.
     
  5. mlynchit

    mlynchit Registered Member

    Joined:
    Nov 20, 2010
    Posts:
    21
    Thanks for finding this! THis drove me crazy!

    I'd just like to make note that simle in the UI is not always simple from adesign point of view, and in the long run simple design is more important.

    What is needed is better documentation. Perhaps an interface on the client interface that advises on the respective policy configuration.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.