ewong

Hi, I'm having some issues with two specific systems that while having ESET Agents installed, they aren't connecting to the ESET PRotect server. I used esetuninstaller to delete all ESET products from one of them and rebooted. While I had a GPO policy to install the latest Agent, the agent isn't being installed. Anyway, the main question is that in the past, all non-monitored systems would be listed in the Rogue Computer list. So with the removal of both the AV and the agent from the problematic system, shouldn't it appear in the Rogue sensor's rogue computer systems list? Thanks Ed

Hi Marcos, I didn't even notice I didn't have the Product+subproduct columns included. So when I added those two columns, the warning disappeared. As in it shows "No Data Available" in the place of the data. And now when I refresh the "Problematic computers" view, that system disappeared. I don't think "Adding Product + Subproduct Columns" to the Problem Detail table would've been the right solution; so colour me stumped. That is so strange. Edmund

Hi, I am noticing some errors on a few of the systems here and they have the following Yellow Warning: "Windows Security Center indicates that the feature is not installed or is not running properly." There is nothing that is highlighted in the list of applications. This is a little bit of a useless warning since it doesn't say what feature is not installed or not running properly. Can someone point out if there's somewhere I can find more about this warning? Thanks Ed

I was about to ping your support personnel; but I think I solved this issue. The problem was indeed the firewall. Unfortunately, not being familiar with CentOS7, I had thought it was using iptables; but it was actually using firewalld. After doing the following command: firewa sudo firewall-cmd --zone=public --add-port=8445/tcp It now works. Ed

Hi, I have followed https://support.eset.com/en/kb7857-set-up-an-https-ssl-connection-for-eset-protect-linux but I'm finding it confusing because the server.xml changes for an Existing Certificate vs. a New certificate are different. I am creating a new certificate and have changed the server.xml to include the following: After saving, and restarting tomcat, I still can't use https. I used iptables to open the port 8445. That didn't work. So I changed SELinux to Permissive. No go. I took a look at netstat, and 8445 is certainly opened. Going to https://<ip>:8445/era/webconsole gives me a timeout error. At this point, I'm somewhat stumped. So i took a look at the tomcat logs and came across: Which after searching, gave me the result of changing the following: I added the secretRequired="false" and that "fixed" the issue (but from my search, it wasn't a good idea.. but at this point, I just want it to work. 19-Sep-2023 13:34:01.992 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib] 19-Sep-2023 13:34:02.266 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"] 19-Sep-2023 13:34:02.298 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-jsse-nio-8448"] 19-Sep-2023 13:34:02.608 INFO [main] org.apache.tomcat.util.net.AbstractEndpoint.logCertificate Connector [https-jsse-nio-8448], TLS virtual host [_default_], certificate type [UNDEFINED] configured from keystore [/etc/tomcat/tomcat.keystore] using alias [tomcat] with trust store [null] 19-Sep-2023 13:34:02.611 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 19-Sep-2023 13:34:02.612 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [806] milliseconds 19-Sep-2023 13:34:02.638 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 19-Sep-2023 13:34:02.639 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/9.0.80] 19-Sep-2023 13:34:02.663 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/tomcat/webapps/era.war] 19-Sep-2023 13:34:07.690 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 19-Sep-2023 13:34:08.506 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] ERA Web Server starting... 19-Sep-2023 13:34:08.507 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] ERA Web Server Version: 10.1.277.0 19-Sep-2023 13:34:08.512 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: server_certificates=all 19-Sep-2023 13:34:08.513 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: server_address=localhost 19-Sep-2023 13:34:08.513 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: server_port=2223 19-Sep-2023 13:34:08.520 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: remote_address_source=connection 19-Sep-2023 13:34:08.520 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: HSTS_enable=no value loaded 19-Sep-2023 13:34:08.521 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] Loaded config value: file_size_limit=20 19-Sep-2023 13:34:08.523 INFO [main] sk.eset.era.g2webconsole.server.modules.logger.LoggerWithPrefix.info [] ERA Web Server has started. Now I have no idea what to do. I can go back to 8080 for now. Which also makes me wonder since I thought the following lines: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8448" /> Wouldn't it redirect to port 8448 when I go to http://<serverIP>:8080/era/webconsole? Any help appreciated Thanks Ed

It's difficult to pinpoint the problem with your policy without knowing what the policy is. Is it platform dependent? While it may be applied to all PCs, it may not be applicable to all PCs.

Aside for the database, don't forget about the server configuration files.

After much wrangling, I can log on but only for a minute or so before the ERA Server chokes and I'm brought back to the login screen. I've raised a support ticket, though I'm thinking of just junking this whole system and starting anew. I'm finding that even if I do log in, it's a little sluggish, so I guess my CentOS system is no longer a viable platform as it's a dual core system w/ 4GB ram. ESMC was pretty ok. ESET Protect is a little sluggish on it. Ed

Unless you've found the password, my solution is to run ESETUninstaller to get rid of the old agent.

Hi, Having realized that I'm a bit out of date, I went and tried to upgrade my Linux-based PROTECT installation. Unfortunately, I couldn't upgrade it via Component Upgrade as the Trigger couldn't even find the PROTECT server (which kinda makes me wonder if my whole setup was bad in the get go). So I opted to manually upgrade the setup. [This is on a CentOS 7.9 system, which is still supported.] I followed the Upgrade/migration site and was going to Login to the webconsole, which I couldn't due to a login error. I followed the instructions to reset the password; but that didn't help. I took a look at the /var/log/eset/RemoteAdministrator/Server/trace.log and I noticed that I've got errors. And the ERAServer service wasn't even up. It would try to start; but would invariably fail. Here's a snippet: 2023-09-14 09:06:44 Error: NetworkModule [Thread 7fbc483d4700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:192.168.1.48, ResolvedHostname:<esmc server>, ResolvedPort:54385 2023-09-14 09:06:44 Error: NetworkModule [Thread 7fbc483d4700]: Protocol failure for session id 8, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations. 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc48bd5700]: Verify user failed for all computers: <system1>: NodVerifyCertificateChain failed: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, certificate: [Subject='CN=Agent at *, C=US', Issuer='CN=Server Certification Authority, C=US', NotBefore=2021-Mar-31 16:00:00, NotAfter:2031-Mar-29 16:00:00, Serial=01109d5b79c4ab44b9bcf2b04e4f20f78801, SHA256=dcab9e658a599580a536c19ba0994a13329c3fe69f5a2d447ef8bb09aaa78ad3, SubjectKeyIdentifier=f0faf641b6eb98db2b08891ae97cd6d013e9a3aa, AuthorityKeyIdentifier=73a236ece5a28a2422db74f18398adb362405238],192.168.1.50: NodVerifyCertificateChain failed: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, certificate: [Subject='CN=Agent at *, C=US', Issuer='CN=Server Certification Authority, C=US', NotBefore=2021-Mar-31 16:00:00, NotAfter:2031-Mar-29 16:00:00, Serial=01109d5b79c4ab44b9bcf2b04e4f20f78801, SHA256=dcab9e658a599580a536c19ba0994a13329c3fe69f5a2d447ef8bb09aaa78ad3, SubjectKeyIdentifier=f0faf641b6eb98db2b08891ae97cd6d013e9a3aa, AuthorityKeyIdentifier=73a236ece5a28a2422db74f18398adb362405238] 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc48bd5700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:192.168.1.50, ResolvedHostname:<system1>, ResolvedPort:50003 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc48bd5700]: Protocol failure for session id 12, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations. 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc483d4700]: Verify user failed for all computers: billy.kdtc.local: NodVerifyCertificateChain failed: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, certificate: [Subject='CN=Agent at *, C=US', Issuer='CN=Server Certification Authority, C=US', NotBefore=2021-Mar-31 16:00:00, NotAfter:2031-Mar-29 16:00:00, Serial=01109d5b79c4ab44b9bcf2b04e4f20f78801, SHA256=dcab9e658a599580a536c19ba0994a13329c3fe69f5a2d447ef8bb09aaa78ad3, SubjectKeyIdentifier=f0faf641b6eb98db2b08891ae97cd6d013e9a3aa, AuthorityKeyIdentifier=73a236ece5a28a2422db74f18398adb362405238],192.168.1.50: NodVerifyCertificateChain failed: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, certificate: [Subject='CN=Agent at *, C=US', Issuer='CN=Server Certification Authority, C=US', NotBefore=2021-Mar-31 16:00:00, NotAfter:2031-Mar-29 16:00:00, Serial=01109d5b79c4ab44b9bcf2b04e4f20f78801, SHA256=dcab9e658a599580a536c19ba0994a13329c3fe69f5a2d447ef8bb09aaa78ad3, SubjectKeyIdentifier=f0faf641b6eb98db2b08891ae97cd6d013e9a3aa, AuthorityKeyIdentifier=73a236ece5a28a2422db74f18398adb362405238] 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc483d4700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:192.168.1.50, ResolvedHostname:<system1>, ResolvedPort:50004 2023-09-14 09:06:48 Error: NetworkModule [Thread 7fbc483d4700]: Protocol failure for session id 13, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations. 2023-09-14 09:06:59 Error: NetworkModule [Thread 7fbc48bd5700]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:192.168.1.48, ResolvedHostname:<esmc server>, ResolvedPort:54435 2023-09-14 09:06:59 Error: NetworkModule [Thread 7fbc48bd5700]: Protocol failure for session id 17, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations. Now I feel that's just a bad communications between the server and a workstation. So I took a look more and waited for the server to start up again and came across the following: 2023-09-14 09:11:07 Information: Kernel [Thread 7f8d07fc4740]: Starting of modules took 1988 milliseconds 2023-09-14 09:11:07 Information: Kernel [Thread 7f8d07fc4740]: Used memory after modules start-up is 110792 KB 2023-09-14 09:11:07 Error: CDataMinersModule [Thread 7f8ce7f67700]: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, online verification: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain 2023-09-14 09:11:08 Error: CDataMinersModule [Thread 7f8ce7f67700]: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, online verification: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain 2023-09-14 09:11:08 Error: CDataMinersModule [Thread 7f8ce7f67700]: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain, online verification: NodVerifyTrustResult: 42, NVT_NotTrusted, X509ChainStatus: 0x10000, X509CSF_PartialChain 2023-09-14 09:11:08 Error: CDataMinersModule [Thread 7f8ce7f67700]: CThreatAnalysesDataMiner: EdtdWorldwideUsage: Connection to r.edtd.eset.com failed with: Failed to connect to URI: /v1/ping. Code: 214, Reason: NodSSL error occurred in completeHandshake.RecvEncryptedData (Certificate verification did not pass). Local: 192.168.1.48:40746 Peer: 137.117.138.135:443 TLS protocol: SSL: KeyUsage: 0xA0, PubKeyType: 6 SSL: AlgKeyX: ECDHE, KeyUsageReq: 0x80 SSL: fatal:certificate unknown (write) SSL: error:1416F086:lib(20):func(367):reason(134) (ERR) I've no idea what's going on but it can't be good. Can someone point out whether it is fixable or whether I should just kill the whole system and start anew? Now I don't mind junking this whole setup again(though I would rather not). I don't think I've ever had a good experience with upgrading major versions. I would always had to junk the setup, go to each workstation and use that ESETUninstaller to delete all traces of everything, and then install the ESET PROTECT/ESMC server and start using group policy to distribute the chores. Any help appreciated Ed

Hi Marcos, Please accept my apologies. I goofed up. Another case of PEBCAK. The problem I realized was that a policy wasn't being applied to this offline machine. After applying the actual policy, it's now registering as Green. Sorry for the bother. Thanks ewong.

Attaching to this message. era-diagnostic-logs_2022-06-16_13-49-44.zip

I'm using ESET Protect and just installed Server security on a Windows 2008r2 system. After installation, on the webconsole, I'm getting an alert for this system. "Product Setup failed We couldn't set up protection. Some features may not be fully working." So I went to the problematic system and took a look at the logs and noticed these entries: I'm not entirely sure what the problem is. The date/time is correct and this system can ping the ESET Protect server. Any clarifications appreciated. Thanks ewong

Hi, IIRC, The .msi file must be stored in a shared folder accessible to the clients. i.e. file://\\server\install\third_party.msi ewong

Hi, Sorry for the delay in response. What I ended up doing (iirc) was to junk the whole install by removing the whole installation and installing it over again. I think there was a hiccup during the installation process. Edmund

To answer my own question: Error code 4122 = Error Copying file. Which led me to believe that (and confirmed) that I was running the mirrortool during a crontab job. So I'm going to assume my other error is due to the same thing. Which leads me to a different question. What is the right time to run these MirrorTool jobs? I thought @hourly; but apparently it could take over an hour for a update? [no clue... will test.] Thanks Edmund

Hi, When I do the following command: MirrorTool --mirrorType regular \ --intermediateUpdateDirectory /tmp/updates \ --offlineLicenseFilename /mirror/offline.lf \ --outputDirectory /updates I get an Error of 8452. After running it again, I'm getting: "Error: Perform full mirror failed with error: Undocumented serious error. Error code is: 4122" What do these errors mean? If I recall, I asked about 4122 sometime ago. But then it seemed to have disappeared. Also, do I ask about MirrorTool here or in the "Other ESET Business products"? Thanks Edmund

Hi Help Desk San, It looks like you'll need to upgrade to the latest (at least V7) in order to get updates. Edmund

Ah never mind. PEBCAK again.. Had an extra ".0" at the end of the version field. Sorry Incidentally, this option is *MUCH* better as I won't need to download all sort of stuff that I don't need. Thanks! Kudos to whoever thought of this. Edmund

Thanks Marcos! I was just setting up a filter file but I keep on getting an error "Error: MirrorRepositoryFilter: Failed to parse file with filter rules, check if all fields are filled correctly, error: std::exception". I copy and pasted the sample JSON to a filter file and ran MirrorTool. I looked at the list of options for Mirrortool. Is there an option to show what field MirrorTool is expecting but I'm missing? Thanks Edmund

Ah thanks Marcos. I didn't realize that also applied to the Linux server. Which is why I followed the 'upgrade' link Edmund

Hi, I just updated to MirrorTool v 1.0.2226.0 and realized that the --languageFilterForRepository option was removed. As I don't require other languages other than en-US, is there a way to filter out non en-US languages? Thanks Edmund

Having spent a few hours figuring this out, I realized that while I *could* use GPO to add a new Software Package install to upgrade the current 8.x agent, it doesn't seem to work if the server that the 8.x agent expects isn't the same one as v9. So what I ended up doing was to delete the old GPO software installation package and create a new one with the updated install_config.ini file. (just fyi, and posting it here just in case in the near future I or someone else encounters the same thing.) Edmund

Having fubar'd my V8 server, I opted to install V9 anew. This new v9 system is on the same system as the v8 one, so in theory, agents (pointing to the same IP but expecting the v8-server response) would complain/not connect with the new server. I'm not sure how the new server will react, I'm just hoping it'll show 'rogue' computers. I'm unsure how to proceed forth. It seems as if I *always* hit this issue whenever I do an upgrade. What I would eventually do is go through each system, run esetuninstaller and have the GroupPolicy get applied when the system boots up. So what I'd like to know is what I'm doing (running Esetuninstaller) the only way of doing this? I apologize for being an idiot. Thanks! Edmund PS: Would it be possible if there is a future setting in the Agent such that the administrator can set up a 'password' so that even if the certificates between the agent and the server are different, if this 'shared' password is the same, the Agent will then grab the new set of certificates?

Complete PEBCAK.. I totally messed up the database. So I'm now in the process of installing PROTECT v9. Oh well.. live and learn.