ewong

While watching the trace.log, something became very apparent. It was repeating the process of deleting tables/creating tables.. as evident by the following log: I've attached a log to this message. It basically deletes all the existing tables... then it recreates them... does some stuff in the middle. Loads modules.. then detects something "Checking if ETL DB required" and then it finds that is required. "ETL upgrade required"... I'm a little stumped as to why it's doing that. Any help appreciated Edmund test.log

Hi, With some time on my hand, I took the plunge and downloaded the necessary components to upgrade the PROTECT v8.0 (on a CentOS 7 system) to v9.0. I followed :https://support.eset.com/en/kb8150-manual-component-based-upgrade-from-eset-security-management-center-7x-for-linux-to-the-latest-version-of-eset-protect After running the server install, the rdsensor install and the era.war deployment to tomcat, I started the services. I tried logging on but get an error "Login failed: Connection has failed with state "Not connected" Having experienced that before, it has something to do with Tomcat. I did a "sudo systemctl start eraserver" (just in case), then "sudo systemctl start tomcat", and then I tried logging on, it still reported Not connected. sudo systemctl status tomcat -l Seeing the connection refused, I'm guessing it's an Era Server issue. But when I do a "sudo systemctl status eraserver" I get: So I try a "sudo systemctl restart tomcat" But when I try to log on, I still get the "Not connected" error. I do see a /var/run/eraserver.pid, so I'm guessing that it is running as well as seeing it in the process list. I took a look at the /var/log/eset/RemoteAdministrator/Server/trace.log and noticed that the last line was: Is this an indication that it is recreating all those tables and that this is normal? It was sometime since I installed v8 so I don't recall having this issue. Any clarifications appreciated, Thanks! Edmund PS: I just realized that I hadn't backed up the database... oh well. I guess if this goes fubar, I'll need to recreate this whole set up again. Lesson learnt.

While this isn't efficient, it is at least effective. Download the EsetUninstaller.exe and run it on the laptops manually (in safe mode). Just my $0.02.

I just managed to setup ESET Protect on a CentOS 7 system and had a hiccup with the ODBC version. I hadn't realized that "yum install mysql-connector-odbc" installed the latest version. After downgrading to 8.0.17, it worked. (Was 8.0.23). Just a minor note for any future references.

Coincidentally, I am also looking at the api and am wondering if the endpoint is just https://<server>:<port>/api. While I've tried that, it doesn't seem to output anything. Edit: I was using the same webui port when I came across the setting "webconsole port" which also is the ServerAPI port (I think). Haven't quite guessed what the endpoint url looks like. So hopefully someone in the know can chime in.

Hi @MartinK, A workaround that I noticed was downloading whatever version that's online and find the hash of both. Though this doesn't tell which is newest, at least I know it's different and probably get the latest off the site. As for the http proxy, I'll have a look at that option. Thanks! Edmund

@MartinK are there built in retries in the MirrorTool? Like after going through the list of files required to be downloaded, MirrorTool would go over the failed downloads again. I've tried running mirrortool on two different linux systems and both give me different file failures, so I'm guessing some transient network hiccups. Btw, how do I find the version of MirrorTool? Thanks

@MartinK Thanks for the suggestion. I think you're right in that there is something not quite right with the network. I can download that file manually so I'm sure why it's doing that it if can download the other updates/repository files.

Hi, I don't know if these two issues are one in the same; but I'm having difficulties with both the updates and repository mirroring. Firstly, the repository mirroring script fails with the following error: It's ok with the other files. Just not this one. With the updates, I get: There's no apparent errors shown. Any help appreciated. Ed

Fwiw, GPO is the best way to install the Agent in a Domain controlled network. That said, if possible, go to one of those systems that agent can't seem to be installing on and take a gander at c:\programdata\eset. Does it exist? If it exists, locate the log and post snippets of it (obviously redacting information that is private). If it doesn't exist, then take a look at the Event Viewer and locate any errors in the (I think) Application log.

What you can do according to [1] is change Spiceworks to use a different port and then reinstall ESMC, and ensure that Tomcat (et. al) are actually installed properly. PS: I don't use Spiceworks so if this isn't the same spiceworks, my apologies. [1] - https://community.spiceworks.com/support/desktop/troubleshooting/changing-sw-port

I've played around with the filter list and I'm still not getting it. If someone with experience with this part of the console can clarify it. I have added a bunch of ips to the ipv4 list[via the "Edit IPv4 list" Since I don't want them to be detected, I select the blacklist radio button [since as the description says: "By enabling filter, only computers whose IP addresses are part of the whitelist in the IPv4 filter list will be detected, or only those that are not part of the blacklist." I apply the policy to the server that has the RDS installed. I waited for about an hour and then I went to the Status Overview page, yet the number of Rogue computers detected still includes the list of supposed systems that it should ignore. Am I misunderstanding the function? My confusion stems from the description and what I want to do. I'd like the RDS to ignore rogue systems(not really rogue, since I know what they are). So with that in mind, I add all those ips to the IPv4 list. Now since I don't want them detected, that list should be a blacklist. Am I correct in my setup? Thanks Edmund

Thanks @MartinK. Looking forward to the fix.

Actually, never mind. I found it in EraServerApplicationData\Data\Localization. I assumed Windows search went through all the subdirs. I didn't realize it skipped Data\ as it required UAC prompting. And yes, I believe that file is circa the previous version as the date on the file is two months ago.

Yup. That's the notice I'm getting. Thanks for the info.

I've searched in the ProgramData\ESET\RemoteAdministrator directory (sub-dirs incl) and can't find this langdata.dat file. In fact, I even searched in ProgramData\ESET. Is this fixable without having to reinstall ESMC? Thanks! Edmund

Using ESMC v7.2.1266.0, webconsole @ (7.2.221.0). I clicked on the Reports->Automation->Client tasks summary - completed in last 7 days, and after it generated a pie chart, hovering over the chart gave me the attached image. What is this resource missing? When I upgraded ESMC, did I miss something? I admit, this is the first time I've checked on this report so I don't know if this is something that's supposed to happen. Can someone clarify if this is indeed something that's bugged up on my setup? Thanks Edmund

Hi, This is rather a nit though. I just went to www.virusradar.com and was looking at all the different percentages when I mouse overed Greenland. I was somewhat surprised to see it being labeled as Denmark. I've used SeaMonkey and Firefox and the mouse over still shows Denmark. Is anyone seeing this? Edmund

A minor note, I also had something similar though it was because the Tomcat service wasn't set to run automatically[ though, tbh, don't remember the Tomcat service setting and I'm not sure if it was set to Automatic run in the first place]. Starting the service again allowed ESMC to run. [this was after the upgrade to the latest ESMC v7.2]

I too wish to add my +1 to this suggestion.

if you're planning to upgrade the agents on the Windows clients, it isn't the ESMC Component task. It's the normal "Module Update" task that you should select.

I'm using ESMC 7.2.1266.0 with web console @ 7.2.221.0. In the status Overview, it says I need to set up a backup user. IIRC, all I had to do in the past was create a new native user. But even after creating two native users, I'm still seeing that orange warning. I've looked in the main User screen and also in the individual user profiles; but, I can't see that option that sets that particular user as the backup user. I've looked at the Administrator and noticed it was in the "Administrator Group"; but I've looked at the Users list and the Group list and I don't see the "Administrator Group". I attempted to "Move' the backup user to the Administrator Group; but when I click on "Move", it shows only the list of Computer groups, which is making me confused. Can someone clarify what I'm doing wrong? Thanks Edmund

Funny thing. I was just trying to figure this out. I have put all the Rogue IPs into a static group. The confusion that I'm having is how to set the filter. If I have a static group which contains rogue ips ( that aren't really rogue), how do I set the filter such that the they are ignored and aren't displayed in the list of computers when I select "All Subgroups"? Do I need to actually copy all those IPs to the filter list of the Policy? Thanks

never mind.. Sorry for the noise. [1] answered my question. [1] -

If I had used GPO to deploy the Agents initially, would upgrading the Agents require the same way? Or do I create a 'software installation' task? Would that mess up the workstation's list of installed Agents? Is there a more 7.2'ish way of doing things? I'm hesitant in modifying the initial GPO to add (as an upgrade) the new Agent binaries; mainly because the last time I did it, something went sideways and I had to re-do the whole agent installation (used esetuninstaller on all workstations to start anew). Any clarifications appreciated. Thanks! Edmund