I created a similar thread here: http://forum.avast.com/index.php?topic=101270.0 (since 13-7-2012)
The purpose of this thread is not discussing wanted changes like it happened in the other thread but to organize changes we want to see in the console on which the Avast team (hopefully) can give us input by giving us details about the progress of implementation if the change requests are accepted. So they can also say which changes will be incorporated in the next console release.
ENTERPRISE CONSOLE ONLY
RFC 1: Free choice mirror location URGENT
Since this is an ENTERPRISE product I as the administrator NEED to have control over the product installation and locations. I need to be able to control where the program places the mirror location (user data) and separate it from the program location and OS partition. This issue has been addressed in the SBC forum to a big extend and build with arguments. It was present in the SBC console, now in the Enterprise (bigger) brother its gone.
Its needed to be able to comply to company policies on where to store program data, user data and such.
Running the program from the C: partition where the OS resides is EXPENSIVE, usually this partition consists of mirror disks (50% space loss). The program itself can be installed there, but user accessible data should be on another volume which is cheaper in usage (different RAID setup, less loss of space) and less performance straining on the OS volume.
RFC 2: Active Directory integration
Make AD integration possible so that we can appoint AV administrators that can access the console with their AD username/password. Possibly even set drill down rights on just logs or only deploying stuff like that.
Next to that the sorting of objects can be based on the OU layout of the corporation build in AD, which eliminates to keep another list of how it is buildup.
I have several free products in use that enumerate the computers based on OU layout. (EMCO software)
RFC 3: Logfile display consistency, inside the console
Right now there are at least two ways of opening logfiles from the menu, one opens the file directly in notepad, the other opens IE first, downloads the logfile and then opens in notepad.
This should all be possible to show within the console with an option to save the logfile and date/time filtered when the administrator wants to save the file. If it is not in the console then only use notepad directly, not a browser to download first.
RFC 4: Change the starting dashboard
I would like to see that the starting dashboard directly after logging in shows information that is useful:
- Mirror information like status of update (plus reason if failed), server receiving updates from, versions (console, enginge, VPS), streaming update status, counting of clients behind in VPS or engine update?
- Total licenses, modules that are licensed and expiration date of the licenses, amount of licenses in use
- Last computers with infection and which infection and action taken on the discovery of infection, or a counter with the days free of infection (this second one is just a bonus)
- notification of program updates for clients and console
- Anybody has other suggestions?
RFC 5: Protected the Endpoint with password from uninstall
In previous versions uninstalling the product was protected with a password. This option is gone in v7. Since there are users with local admin rights in corporations for different reasons, it is not wished that the product can be removed by others then the systemadministrators.
The option to protect uninstallation would be useful in the CONSOLE. Turn on the option to protect, turn off to be able to uninstall when needed.
RFC 6: Autorefresh console
Every time you change something, run a task/job, move a machine… you have to press F5 to refresh the info on the screen to reflect the changes. When you make a change like that, it is more efficient to do an automatic refresh.
RFC 9a: Automatic program updates
In the settings for updates there is only a posibility for ASK or MANUAL updating the program. The option for automatic updating would be desired by several customers.
Right now you have to wait for a computer to be online to be able to update it and start a manual created task to do the updating.
This also imposes a threat if the program update causes problems like blue screens and the update should NOT be rolled out
RFC9b: Approval of program updates (inherent on 9a)
In the business part, the program updates are NOT regular like in the consumer product. The consequences of a program update are mostly financial loss if the update crashes. Therefor if there is an update ready for the program it would be good to have an approval of the update, which can be placed in a test container to see if the update gives trouble.
This is much like the WSUS approval system. Ofcourse this is not wanted for VPS updates (even tho the same risk is involved).
With this request it is also important to have a dashboard at login that states the versions
RFC 10: Client-Side & Server-Side session tasks remove fold-out
Remove the fold-out option in the folder structure at the tasks. When you click on that option (client-side tasks) the tasks are listed in the right side already. No need to be able to fold-out to see exactly the same but ordered on name of the task and descending.
RFC 11: Session → Local scanners / on-access scanners: Add object info and actions
There is no info about which computer has the infection or any possible actions to take on the infections.
At least give the computer name on which the infection was detected and the possibility to quarantine or delete the file.
In general more information is wanted in the console.
RFC 12: Generate MSI package instead of EXE package
ADNM (4.x) used to create an MSI package which in turn could be used in AD group policy (or other deployment tools) to deploy. To comply to company policy it should be possible to have 1 solution for software deployment which is the choice of the company (by policy) and therefor it should be possible to have an MSI file for deployment. With an proper MSI file there is no extra tweaking needed for deployment.
RFC 13: Manual VPS/Program update on mirror server
In rare cases it is not possible to get connected to the internet anymore to get updates (internet down, hacked, u name it). In these cases it would be useful to be able to update the VPS and program versions manually on the AES server for clients to pick it up, preventing the administrator to have to go by every desktop to update manually.
The manual VPS is already present for download but its for individual updating.
In some other cases (to be found in the ADNM thread) it is possible to send such update to a ship that is without internet but has several stations managed.
(this would be considered a bonus)
RFC 14: Have unmanaged clients without consuming licenses
All computers found by the console automatically receive a license. This is not desired since not all discovered computers need a license (other AV, no AV, u name it). The license becomes available when you delete the object again. When the discovery task is automated then every time the computer is discovered it gets the license again.
Make a container option that prevents the console to give the objects in that container a license. This is like the SOA where there is an unmanaged container.
RFC 15: Targeting specific Organizational Unit in Active Directory for computer discovery task
It should be possible to have the ability to configure a task like the default “find computers” task in AEA to scan a specific OU in AD. Since this is an enterprise solution, the option of scanning workgroups seems a bit out of place.
In larger companies there are several administrators responsible for a certain part of the network (think of multiple offices)
RFC 16: Set the client user interface language in the console (Internationalisation)
Right now the clients automatically choose the language of the OS. For user friendliness the OS in the native language so Avast adopts that automatically. As administrator (and problem solver) you also get errors in the native language, this means finding results to solve the problem are very limited. This mostly has it cause in the translations from either the Avast translator or the administrator.
An option to choose which display language is used would be useful.
RFC 17: Clean AES server log files
You can see several log files from the View option in the menu: Server, remote install… but you cannot clean them or empty from the console.
RFC 18: Test SMTP/database settings during setup and SMTP also inside the console
There is no option to test the settings for SMTP and database connections during setup. This was introduced in the setup for the SBC 6 console. This should be available for the Enterprise console setup too.
When there is no SMTP configuration during setup, then there should be a test option for the configuration in the console itself.
RFC19: semi-integration of the maintenance tool into the console with smart-decisions
Right now there are two tools: the console and the maintenance tool
When the console doesnt work you need to use the maintenance tool to do troubleshooting.
Re-write the console login procedure to be smarter: When the console cant login offer to start the maintenance tool or start it automatically when the console is started from the AEA server.
Since the maintenance tool requires administrator rights, a person that dont have those right will not be able to use the tool so its secure to offer the program this way.
