[Database Connection (Ubuntu)]

You have put DSN into driver name parameter: --db-driver myodbc_mysql_dsn . Change it to: --db-driver myodbc_mysql

[See which users are logged into which machines]

As the report and its report template were not existing on the server, log filter did not send those logs to server to save traffic. Just wait some time after you saved the report until agents are informed about changes in log filter. Report preview shows just random data.

[CentOS VM Deployment of ERAv6 on Hyper-V]

The appliance configuration is done only once after first reboot. It can't be reconfigured afterwards.

 

These are supported locales: ar-EG, cs-CZ, de-DE, en-US, es-CL, es-ES, fr-CA, fr-FR, hr-HR, it-IT, ja-JP, ko-KR, pl-PL, pt-BR, ru-RU, sk-SK, zh-CN, zh-TW

[Time of Occur Web Control ERA dashboard]

The problem is that you are grouping data (Group by) and those time and dates need to be merged. Either change TIME INTERVAL UNIT (click those arrows next to the symbol) or change the report - remove group by operation from columns.

[Not happy with ERA 6]

The agent does the OS check independently from EES. By default they both check for OS updates. By setting policy for agent, you will only disable checking on the agent but EES will still do the checks.

[Eset appliance burst google.ca]

When you temporarily disable HTTP proxy (e.g. port 3128 is not accessible or you completely stop the service) does it help? I suspect that something is connecting through HTTP proxy on the appliance and that is causing this bursts. HTTPS communication is not cached so it goes always through proxy.

[See which users are logged into which machines]

You will need to create a new report from 'Logged users' symbols category and add 'Computer name' symbol from 'Computer' symbols category.

[Not happy with ERA 6]

OS up to date check is resource consuming as it needs to contact Windows Update servers and ask for new updates. That is why it is not done on every agent connection to server, but on Windows it is done each 18 hours or 10 minutes after agent startup.

 

There are two possibilities to change this behaviour:

1. Suppress this check by policy on computers where do you have EES installed. Endpoint will take over OS update checks.

2. Run OS update task from ERA. This task will update OS and run re-check afterwards.

[After putting Vmware tools, I got "First time appliance configuration was not possible"]

I see, did you unmount VMWare Tools ISO after installation and then finished installation in the virtual machine menu: VM -> Guest -> End VMware Tools installation? I had to do that and restart.

[Client machines with two NICs appear twice in ERA 6]

In ERA6, Agents are identified by unique identifier (UUID) generated during installation (manual, server assisted, live installer) or during push install (generated on Server prior to installation). MAC address is not longer used.

 

In your case it is possible that there is bug - Are you sure that those duplicated records, you can see in the console, are indentical? When you rename one of those computers, are both computers renamed?

[ERA6 - differences between Remote Administrator Components Upgrade, and doing it manually]

The only difference should be a check for error codes after installation completes or fails. Are you able to access agent's trace log on machine that is failing? And if possible also c:\windows\temp\era-updater-msiexec.log. There was issue earlier that did not handle required reboot and we would like to check if this is the case.

[Eset appliance burst google.ca]

Is the appliance configured as HTTP proxy and are you using it by client machines?

[Client Task Log?]

Please see ERA Agent trace log and c:\windows\temp\era-updater-msiexec.log and c:\windows\temp\ra-upgrade-infrastructure.log to see what is failing.

[After putting Vmware tools, I got "First time appliance configuration was not possible"]

Please check virtual machine properties -> Options tab -> vApp Options is set to Enable, then OVF Settings, section OVF Environment Transport, ISO Image is also checked. Save settings and restart machine.

[Monitoring Web Control Logs]

Web control report is not created by default. You will need to create it manually - new report template and add columns from 'Web control' category.

[ERA 6.1.33 Agent installation - cert and inet access]

The certificate selection is up to you. Probably the first one uses password to protect private key and the second one uses empty one (requirement for server assisted install).

 

Push install requires internet connection. There isn't any workaround for this.

[Force using FQDN of computer name instead of DNS]

At this moment the only option would be to rename the computer manually. In ERA 6.2 there will be a server task and GUI wizard to that for you.

[Remote Admin 6 on a Linux 12.04 virtual machine]

'--cert-path' parameter is not pointing to a certificate file. Check if that path is correct.

[Upgrade ERA Server Virtual Appliance 6.1.28 to version 6.1.33]

Same guide is for appliance (hxxp://help.eset.com/test/era/6/en-US/index.html?component_upgrade.htm). Version 6.1.33 is same as 6.1.28 except new installers.

[Critical error (executing database script)]

Please try again with released hotfix release.

[ERA 6 Install on CentOS - SQL errors]

You need to use MySQL version 5.5 or later.

[New clients alway show up in Lost & Found!]

End of summer.

[Migrate 6.x Clients From Old 6.x ERAS to New 6.x ERAS]

I think there is problem with certificates as appliance creates new certification authority. The fallback mechanism in Agent will try to connect to new server and then connect back to the old one. The KB article expects that server installation is same (same DB or same machine) but its IP address has changed. In your case, you can repair server installation in appliance with certificates from your Windows installation. Navigate to /root/eset_installers and run Server installer with certificates (CA and Server peer certificate) that you transferred to appliance (e.g. WinSCP).

[Active Directory authentication broken]

Check /etc/hosts and /etc/krb5.conf files whether they are correctly configured and that 'kinit <username>' works. Also error from server trace log (/var/log/eset/RemoteAdministrator/Server/trace.log) would be helpful.

[Rogue computers ratio - empty]

From the RDSensor detection log that chris375 posted, it seems that OS detection probes are not returning. If OS can not be detected for a network device, then it won't be sent to ERA as a computer. Idea was that network devices (printers, routers) should be filtered out.

 

RDSensor was compiled with libpcap version 1.3.0, please verify that you have this version installed on your system. Second requirement is bridged network from virtual machine where RDSensor is installed. If all those requirements are met, you can try to run nmap with OS detection (hxxp://nmap.org/book/osdetect-usage.html) to see whether it can detect OS on some computer. If not then RDSensor will no be able to that too.