michalp

Unfortunately there is no such way - only complete agent reinstall. But future version (probably summer release) should have same way of automatic renaming of computers. So you would just select what information should be pulled from Device identifiers and applied to computer name.

Some files in Quarantine may be flagged as non-excludable. Then ERA will not allow to exclude them from next scan. If you think that it is false positive, then please send sample to our virus lab so they can add exclusion for it.

It seems that there is some inconsistency in databases on server and agents (internal counters that mark data that have been sent to server). This can happen if there were agents on computers that were reverted from backup (e.g. virtual machine snapshot) or time is not correctly synchronised on all machines (it was advanced into future and then it was set back). There is a mechanism that should automatically correct all data after some time. Make sure that time synchronisation is enabled and let server and agents run few days - it can take some time, at least 24 hours. To force agents to drop their internal state, you can use "Reset cloned agent" client task. But this should be really last resort action.

Set it to: AUTOSELECT

Problem is caused by wrong password for server peer certificate or empty server peer certificate that was set in Server Settings. Unfortunately there is a bug with not working validation in Server settings that enables you to change peer certificate to not valid one. After that, server won't start up after restart. If you have exported certificates, then you will be able to repair installation. Certificates can also be retrieved from the database and be used for the repair. Other option is to revert to original backup snapshot of the appliance. I would suggest to contact our support team to help you.

Yes, the reactivation will dissociate EEA from old license and associate with selected one. Also this should be reflected in ELA in seat count.

The correct way is to use Product Activation task. Select proper license and it should re-activate security product.

Only thing that does not support proxy at the moment is agent deployment using push method. That is why other methods work. This will be changed in the future. There were both 32-bit and 64-bit links in the trace log and installer service has chosen correct one to download and install. I just picked first.

I went through the trace log. It seems that 'gli2-dc-02.gliwice.pl.root.net' computer can not access this link: hxxp://repository.eset.com/v1/com/eset/apps/business/era/agent/v6/6.1.365.0/Agent_x86.msi, that is why installer is not able to download and install package on the target computer. Exact error is 'This installation package could not be opened.'.

The trace log starts after remote installation errors - it is cut. See first lines in the log as they are actually end of the remote installation itself. I will need a log where those errors are present. If you are having troubles to deploy agents with remote deployment - push install. You can try Live installer - please see: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3595

Proper 32-bit or 64-bit installer version will be automatically selected on a target computer. Don't be mistaken by Changelog and Eula links as they point to same content for both bit versions.

That should depend on configuration of Active Directory server you are using. For Windows domain controllers, just username is sufficient.

If you have successfully deployed ESET Remote Administrator Agents on target machines, then installing ESET Endpoint Antivirus is done by Software Installation client task (Admin -> Client tasks -> Software Install). Please see hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3605 You don't have to modify account for ERA Agent, where exactly did you read about it? KB reference - SOLN82, point 5, talks about changing account for ERA Server just for push agent deployment.

This is how ERA Server Appliance configures Kerberos for TEST domain. [root@era ~]# cat /etc/krb5.conf [libdefaults] default_realm = TEST.COM ticket_lifetime = 24h forwardable = yes [realms] TEST.COM = { kdc = dc.test.com } [domain_realm] .test.com = TEST.COM Then call to kinit: kinit <username-from-domain> should obtain a valid ticket.

You don't have to revoke them. Revocation is meant to be used when you want specific certificate to be not valid.

When you run this command : less /var/log/eset/RemoteAdministrator/Server/trace.log (Use 'q' to quit and 'page up/down' to navigate). Are there any errors from the last startup?

The problem is that the agent does not yet know that EEA is installed - it is not communicating with the security product. It takes about a minute for the agent to detect installed EEA. The best way to automatically activate product is to use dynamic group called "Not activated security product". This group will be joined only by agents that are already connected to EEAs without activation.

First try to refresh ERA login screen - e.g.: in Chrome it is F5 key and try again. If it is not still working, then it is possible that ERA Server or MySQL database is not running. Please login to management mode, exit to terminal and type 'service mysqld stop', 'service eraserver stop', 'service mysqld start' and finally 'service eraserver start'. Then refresh login screen a try again.

Thank you for reporting. More languages are affected. It will be fixed in the future.

There is report Outdated applications (hxxp://help.eset.com/era/6/en-US/?outdated_applications.htm) that should report out of date components in ERA. ERA upgrade infrastructure task is intended for automatic upgrade. It will be enabled in future service release.

At the moment, IP address shown next to a computer name is any IP address from Network adapters section. There will be change in the future to reflect adapter binding order.

SOLN3637 instructions were misleading. In Figures 2-4 and 2-6, there were missing Apply next to the modified parameters. It should have been already fixed. HTTP proxy and "regular" proxy are used as synonyms. Update part in Windows EES policy is only meant for special cases when you want only updates to be redirected through proxy or different proxy. 1. Live installers support HTTP proxy. It must be set in server settings beforehand. Agent deployment task for Linux and Mac also support proxy. Only agent deployment task (push install) for Windows does not support proxy at the moment - this will be changed in the future. 2. Yes, it is possible to cache everything through proxy except agent installation using deployment task on Windows. Software installation task also supports proxy settings. It means that product updates, product activation, repository access, agent installation with live installer and EES/EEA installation through Agent, all can be cached. 3. Repository will also use proxy settings. Autoselect option does not need to be modified. As far as know, there should be no more steps in configuring HTTP proxy for ERA as only access point to internet.

Select threats that are fixed and click Mute button. Active threats number can be cleared only by full scan executed through ERA as Marcos said.

To suppress any dialogs shown by EEA or EES after installation, you can use INSTALLED_BY_ERA=1 msi parameter. To apply policies faster during upgrade, I would suggest to deploy Agent, let it replicate all necessary policies from a server - this depends on replication interval. And then install EEA 6.x using Zenworks. Agent should detect the upgrade and in a minute it will start managing EEA by applying policies.

For ERA 6, please see Admin -> Server Tasks -> Generate Report task. Supported formats are PDF, PS, CSV. Generated reports can be stored to a file or send by an email. Generated reports can also be sent automatically by setting up proper triggers.