Jump to content

MartinK

ESET Staff
  • Content Count

    2,031
  • Joined

  • Last visited

  • Days Won

    63

Everything posted by MartinK

  1. No problem. Installation log contains following errors: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error that break ESMC upgrade in initial phase, during database connectivity check. Unfortunately I do not recall seeing similar errors in relation with ESMC -> any chance there is some custom DB configuration used? Maybe modified DB connection string for ESMC created after upgrade to previous version? As error indicates some problem with SSL connection, maybe there is no-longer-valid certificate used by DB server?
  2. Most probable reason for this is that tasks were referencing product versions that are no longer available, so re-execution would fail.
  3. As @Marcos mentioned, would it be possible to test with different browser? Also please provide us current configuration, especially type of browser and version of ESMC/WebConsole. Also note there has been multiple bugfixes targeting Safari browser issues in recently released ESMC 7.2.
  4. Those errors indicates there is probably a certificate related issue. It is not clear from those lines, but in case AGENTs are not able to connect to ESMC, please check troubleshooting documentation. Most common errors are: AGENT is missing CA certificate used to sign ESMC Server certificate currently used - mostly happens when non-default configuration is used. I would focus on this one in case you have generated your own certificate or performed any of migration scenarios described in documentation ESMC certificate is not signed for hostnames or IP address, that are AGENTs used to connect to. This would result in state where AGENT are rejecting connection due to this missconfiguration.
  5. Thanks for letting us know. Just out of curiosity, could you provide hint what could have been wrong? Both computer name and FQDN are accessible also from console in client details: Maybe there was just wrong case sensitivity? Or completely wrong/unexpected computer name was reported for those devices?
  6. Thanks for logs, they shows that ESMC upgrade is failing (unfortunately for some reason, it is not communicated correctly, which we will have to report): 2020-08-05 14:41:29 Error: CSystemConnectorModule [Thread 12f0]: UpgradeInfrastructure: Installation command 'cmd.exe /c msiexec.exe /qn /i "C:\WINDOWS\TEMP\de14-602f-e362-4140\server_x64.msi" /l*v "%TEMP%\ra-upgrade-infrastructure.log" ALLUSERS=1 REBOOT="ReallySuppress"' exited with 0x643: Fatal error during installation 2020-08-05 14:41:29 Error: CSystemConnectorModule [Thread 12f0]: UpgradeInfrastructure: Skipping webconsole upgrade. Server upgrade failed As it is failing during installation itself, there are no more details. Could you please search for log: %TEMP%\ra-upgrade-infrastructure.log" i.e. for log placed in temporary directory of local system user? It will be located somewhere on system disk, depending on operating system version. Just be aware that search for log will require full administrator access. Alternatively, manual upgrade might be performed, it will probably fail with the same error, but it might be easier to get to the logs. PS: timestamps in ESMC trace logs are in UTC format, so in case offset one hour corresponds with timezone where ESMC is installed, it is expected.
  7. You will have to create configuration policy for ESET Management Agent with enabled trace log verbosity - ideally lowest possible value should be enabled to that all details are present (Advanced->Logging, see documentation). Once policy is created, it has to be applied to problematic client, in this case server that is hosting your ESMC server. Once done, please re-run upgrade task and after some time or after task success is reported please provide trace log: C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\trace.log Ideally it should be verified that log captures moment of upgrade, as relevant information might be already "rotated" in case logging will be enabled for longer time.
  8. Could you please double check that client task configuration references version 7.2.1278.0 which is supposed to be your new version after upgrade? Any chance you are using some custom repository server, for example offline repository created by mirror tool? Could you check also version of WebConsole, especially whether it has been updated to version 7.2.230.0? If possible, could you please enable full trace logging on ESMC Agent (i.e. via ESMC Agent policy assigned to ESMC server), re-run task and attach it for further analysis? It is probable that for some reason, suitable upgrade package is not found, which might be related to already installed components or version of operating system.
  9. Unfortunately it seems that VS dependencies are probably not correctly mentioned in ESMC 7.2 documentation -> I would expect that runtime libraries Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019 for x86 platform are required to run latest MirrorTool. Could you please confirm? If it won't help, could you please capture failed startup using ProcMon utility which is part of SysInternals suite?
  10. Could you please clarify your usecase? Provided policy seems to instruct endpoint to create local mirror, i.e. endpoint will connect to internet and download all required files for creation of mirror. But there are no instruction to actually use any mirror in this policy - this policy should be probably used only one one client, that will be downloading files from internet and sharing it on local network. Other endpoints, those supposed to update locally from LAN should use different configuration, where especially "Modules update - Custom server" should be probably configured to point to your LAN mirror, instead of default.
  11. Not sure, but by mapping you meant that newly installed endpoints are to be placed in specific group? If so, what method you actually used for this purpose? In case mentioned GPO installers were created with "initial static group", i.e. with pre-selected group where endpoint should be placed, it won't work in case GPO installers were generated with old ESMC, but client are connection to new one - is this the case? Problem is that placement group is protected by secure token, tied to ESMC that generated is, so that it cannot be misused -> failure of token validation would result in Lost&Found placement of devices. Most straightforward solution would be to create new installers in newly deployed ESMC: how many such alternatives are actually used? There might be also alternative to move "secret" from old database to new, which would probably result in working installers, but would also invalidate installers created in ESMC ...
  12. Actually at least login screen should open regardless of ESMC service state. In case "Spiceworks" opened, it either mean that it took tomcat's port 443 and thus preventing tomcat from listening on this port (i.e. conflict of services using the same port), or it is some kind of firewall that is intercepting requests - hard to be more precise without more details.
  13. Were there any changes in system performed when it stopped working? For example Java was updated or older/possibly used version was removed? Or was there any attempt to perform ERA/ESMC upgrade that might have corrupted deployed console?
  14. Thanks for confirmation. Actually even upgrade to Microsoft SQL Server 2019 should be fairly straightforward, but there is too much combinations to test them all, so migrations should be performed with caution and backups.
  15. In case classification means "dynamic group", it is not technically possible, as dynamic groups are evaluated on client devices, but remote host is "computer" by ESMC itself. Client actually might no be even aware of theirs remote IP address, especially in networks where various NAT routers or VPNs are used.
  16. Could you please provide version and platform of ERA/ESMC Agent installed on client? Just to be sure there is not an older version which might not have regex support yet. Regardless of that, we will try to reproduce with similar configuration.
  17. Depends on how migration was performed. In case new AGENT had to be installed on new server, there might be two separate entries in console reporting present of ESMC, one obsolete, probably no longer connecting, and new one, representing new server. The no-longer-connecting one might be actually reason for false update report. There is also alternative that AGENT is not connecting due to significant hardware changes detected during migration. This should be visible in console in this AGENT's details in section "Questions", where approval of such changes have to be made. There are few alternatives, where at least one of those will result in duplication of entry as shown in console, and thus possibly resulting in the same state as I mentioned.
  18. Notification is based on version reports of ESMC Agent installed side-by-side with ESMC: could you please check what version of ESMC components is it reporting in console? This might be the same issue as reported initially where upgrade task was not starting - might indicate some problem in AGENT-to-ESMC communication, especially for agent installed on ESMC server machine. Also is there any chance there is some other ERA/ESMC server installed in network? Asking as we have known issue where such older server, reported from network would trigger update notification of "main" ESMC.
  19. Finally I had access to environment and there seems to be some problem in ESMC 7.2, which will have to be investigated. Your language data is correct - it was prepared around 2 months ago.
  20. Unfortunately I cannot verify but I would recommend to construct regex without "^" and "$" -> even without those, whole string has to be matching regular expression, so those characters are not required. Maybe regex (kas|kam)-.* will work? Just to be sure, after each modification, it might take some time until new template is re-evaluated by clients.
  21. Could you please check whether AGENT installed on the same machine as is ESMC Server is actually connecting to ESMC? Also please check configuration of created upgrade task, especially whether it references 7.2.* version of ESMC.
  22. There are multiple alternatives: you can request product configuration from ESMC (client details -> configuration) which will provide you current product configuration you can check protection status alerts reported by product into ESMC (client details -> alerts) but user with access to endpoint configuration might have disabled it so it might not be reliable, but it can be enforced by policy, which will prevent local users from overriding it.
  23. One you mentioned ProxyMatch I realized that also this might be an issue, as it is not clearly communicated in referenced article. Could you also check, that your httpd.conf contains lots of other ProxyMatch directives, enabling clients to access ESET servers? If not, I would recommend to check httpd.conf which is part of proxy package for windows. In case directives are matching, clients won't be able to access resources on ESET servers, including updates. Configuration file from windows version contains directives enabling communication with all ESET services that could be possibly accessed by ESET products via HTTP proxy + it just has to be extended with your internal hostnames or addresses in case proxy is to be used for accessing also other resources - this applies especially in proxy is expected to route also AGENT-to-ESMC communication.
  24. There should be file named LangData.dat stored in ESMC's ProgramData directory: could you please heck whether it was updated during ESMC 7.2 upgrade? It might have happened that file was not upgraded in case it was manipulated manually. If file is upgraded, it would be probably an issue in ESMC 7.2 or in incomplete migration from previous version.
  25. As AGENT->ESMC protocol currently used gRPC on application layer (not guaranteed to the future), there are many small projects and proxies that can be used to routing, but in case of security, most reliable solution might be standard TLS termination and forwarding of requests on TCP layer, i.e. without interpreting data and requests itself. This is supported by most of the commonly used proxies ad mentioned previously. It would just require some basic "magic" with certificates. In this configuration, proxy should be just "repacking" TCP traffic from one TLS channel to another, instead of interpreting it + it is possible to configure proxies to be transparent for AGENTs. This kind of configuration is very often used for load balancing. Your case would be probably best matched by something like TLS pass-through with additional client certificate checks, but it is probably not supported by common proxies, I think it not possible to validate client certificate before connection to backend service (ESMC in this case) is opened, so it would somehow reduce security benefits.
×
×
  • Create New...