Home > Exinda Feature Request Summary

Exinda Feature Request Summary

Tags:  




Overview

DirSec is a network security reseller with over forty combied years of working in the reseller and vendor community.    During our interface with potential and existing Exinda customers, we often encounter repeated issues and/or compliants from customers.      Based on our experience in industry and knowledge of other vendor solutions, we filter the Exinda customer issues and present potential resolutions below.   The feature requests are tuned to two primary factors:  (a) simplicity, and (b) standard industry feature.

General Features

General Feature
Details Customer
Date
automated backups over network
Ability to setup scheduled backup over network to CIFS, FTP, etc.  Feature should include expiration -- ie.  store five backups max.  Use backup options of Barracuda SPAM firewall as model.
Maturity Feature



firmware release notifciations
Exinda admin should have various ways to be notified about new firmware releases.  Should should include (a) support email notification, (b) appliance email notification, and (c) notification in Exinda GUI about new release based on scheduled "update check".


M$ domain integration
Exinda should have central Domain Agent to allow user/groups to be leveraged for (a) reports, and (b) policies.   Use Palo Alto Networks domain agent architecture as model.
competitive, maturity

Firmware release info available in GUI
Exinda admin GUI should include (a) release "summary notes", or (b) URL link to version-specific release notes.


Search dialog for defined applications
As of 5.0x, it's difficult to easily locate defined Application object.   Exinda admin GUI should include search interface for defined applications to allow admin to quickly locate application based on search query.  Possible search criteria should include any element of application definition.


push policy to community

The acceleration policy management for two+ Exinda boxes within network seems somewhat cumbersome. Operating on assumptions that (a) TWO virtual circuits required for INbound and OUTbound, and (b) acceleration policies must always be directional (regardless of known origination source), insuring all exinda boxes have consistent acceleration policies and network objects defined seems troublesome. Example: three exinda boxes in community and specific VoIP policy for (a) QoS, and (b) Acceleration. Thus, the policy entry must be made in SIX places -- and policy can't have same name on each exinda box (ie. can't copy/paste via text from machine to machine without further text edit). It would seem reasonable to have "push policy to community" feature when creating policy -- so policy would be auto-replicated to all relevant machines in community (the same for network objects/hosts).

usability and ease of management


context sensitive HELP
clicking on "HELP" link in Exinda v5 GUI sends you to ToC of online help.    The help should be context sensitive.   A click on "HELP" should provide details on specifics of pane you are in (ie. details on elements of page).   This can leverage online help -- but should open directly to section of cotents appropriate for PANE.
maturity

need to leverage SUBNET objects
customer spends non-trivial amount of time defining subnet objects.  These objects should be leveraged EVERYWHERE in GUI.  Especially for reporting, real-time, and delegated reporting (many features that are enhancement requests -- see below).
ease of use

real-time reporting leverage SUBNET
when in real-time reporting, an available "filter" should be pull-down of defined subnets.
ease of use







x700 -- Bandwidth Optimization




x800 -- Traffic Acceleration



General Feature
DetailsCustomer
Date
Don't allow single virtual circuit
Based on feedback from Steve/Patrick @ Exinda, two virtual circuits (one each for INbound and OUTbound) should be defined on each exinda appliance when doing acceleration.    I understand that acceleration won't operate correctly if use single virtual circuit (ie. BOTH direction).   If true, the GUI should not allow single virtual circuit -- or should display obvious ERROR if trying to use single BOTH virtual circuit with acceleration.
usability and ease of mgmt



 RSS of this page