Jump to content

MartinK

ESET Staff
  • Posts

    2,351
  • Joined

  • Last visited

  • Days Won

    67

Everything posted by MartinK

  1. Could you please double check that Apache Tomcat service is actually running on this machine? Also most common problems are: Apache Tomcat stopped working after Java upgrade or uninstallation -> to resolve this, tomcat configuration utility should be run and JAVA_HOME variable should be fixed to point to correct paths if this is the case. Some other service might have taken port 443 used by Apache Tomcat -> please check there are no other services, especially web servers, that might have done this. Verify there is enough free memory for Apache Tomcat to run - this might be relavant only for large environments.
  2. So I will provide just short summary, what was most probably the easies solution to do: Install new EP Server, with new certificates generate automatically during deployment Interchange public certificate parts of CA certificates. I.e. export all CA certificates from old server and import them into new EP server, and vice versa = export CA certificates from new EP server and import them to old ESMC server. This will ensure, that both servers will trust AGENTs using both old and new AGENT certificate. Move (= export/import) policies from ESMC to EP server, especially those that has to be there to ensure full security, exclusions, etc. Just be aware that policie for AGENT should be migrated carefully, and those configuration certificates and hostnames for connectivity should be ideally skipped or adapted to new environment. Create new configuration for AGENTs in old ESMC, where you set new hostname of EP server, or ideally you can set both servers, as an alternative hostnames, where new server should be first one to be considered as an priority. Please double check that hostname of new EP server you enter into configuration is signed in EP's serverificate, especially in case certificate with wildcard "*" was not used. This can be verified in EP console, in "server settings". Assign such policy to testing device -> you should see it connecting to new EP server. Once migration is done, you could possibly re-configure AGENTs via policy to start using new certificate, which would enable you to get rid of original certificates after some time. And regarding your specific problem, there is an error "Agent to agent communication is not supported" which indicated that your EP server is probably using wrong certificate - any chance you changed certificate in "Server settings" of your newly deployed EP to a way that certificate supposed to be used only by AGENTs was used?
  3. It depends on type of license you are using as of now. In order to managed devices, you will need license that has cloud-management included - it is possible you already have such license, but I would recommend to verify. Simplest check might be to open ESET Business Account with your current license and check whether you are offered creation of EP Cloud "instance" -> this is offered only for users with eligible licenses.
  4. Just to let you know, we had an configuration issue which was fixed almost immediately, but it might have affected ESMC/EP instances as they are synchronizing in hour intervals.
  5. As of now, only possibility is to re-configure management AGENTs on those devices to connect to new account. This can be achieved by running installation repair, i.e. by running installer created in the new account's console on devices currently managed by old accounts.
  6. Just a note that this issue should be resolved with version deployed recently.
  7. Could you please specify why would you do this? Mentioned update actions will list and offer execution of update on devices where AGENT is not on the latest version. Or problem might be specific of environment where online-based upgrade won't work? Also note, that AGENT will actually upgrade itself automatically after some time (there is a few weeks/random delay) so it might be easier, especially in case there are no new features introduced in AGENT that would require immediate upgrade.
  8. I would recommend to contact ESET support for more detailed analysis - we are not aware of any issues with this protection as of now, so it might be some missconfiguration of misunderstanding. More detailed description of step taken will have to be described, as is policy configuration, it's use and possibly also what method for uninstallation is actually used.
  9. Communication on port 2222 is using mutually authenticated (via certificates) TLS connection, so it should be fairly safe, at least until your certificates are leaked. We have seen also customers using proxy in between internet and ESMC server as an precaution, but that would possibly prevent only DoS type of attack which would be filtered on the proxy, as it serves just as an forwarder. Using your own VPN would definitely increase security, especially in terms you will have it under full control - this might be suitable solution especially in case you already employ use of VPN in your infrastructure. Also it might help you to fullfil security compliance, if it is enforced.
  10. Now it makes sense, and obviously retaining installed ESET applications is not a way. Technically after re-installation of ESET Management Agent, new "computer" entity will be created in the console (except in case so called Remote Deployment Task is used to re-deploy management agents) so you will end up with duplicate entries in the console, where original entities will be no longer connecting. In order to clean them up, simple removal from console is sufficient, where during this removal process, you will be asked, whether devices should be also deactivated - you should chose this option, otherwise you will end up with license overusage due to seeming duplicate use. This would automatically recover after some time but it would take probably month. Explicit deactivation performed by console does not require client to be connection to management console and it is similar to deactivation that can be performed from ESET Business Account or other licensing portals. Once devices are removed from console, upcomming cleanups that are performed once a day will remove also data tied to no longer removed devices, so detections and other similar data tied to specific and no longer existing devices will be completely purged. Just be aware, that policy assignments to specific devices or similar configuration will be actually lost by device removal and duplication, i.e. such custom configuration will have to be re-created afterwards. So in short, I would follow these steps: Mark devices that are to be re-installed in the console, for example by tags or by moving them to specific static group. This is just for purpose of later identification of such devices if it won't be possible to distinguish old and new installations. Reinstall devices, i.e. perform OS upgrade and re-deployment of ESET Management Agent and ESET security product Re-create device specific policy assignments and similar device-specific settings that will be lost once devices are removed from the console -> i.e. manual mirroring of such properties is required. This might mostly include policies assigned to devices, tasks to-be-executed on specific clients, tags and possibly also report filters for specific devices - if used. Remove already reinstalled devices from the console with enabled deactivation. In case history date for device is to be retained, deactivation without removal is also possible, even after device has been reinstalled already.
  11. When creating software uninstallation task, it is possible to configure it in a way that product will be uninstalled regardless of present version, so there is no need to create separate for each installed version. But still multiple tassks will be required to uninstall different products. Connection between device entity as visible in console and actually installed ESET Management Agent is based on identifier stored in it's database, so no changes in hardware nor software will change this interconnection. In this case, I would recommend to leave installation of ESET Management Agent intact, it should automatically reconnect to management console after operating system upgrade - only possible issues might occur in case connectivity parameters will change in a way that actually new installation or new configuration of ESET Management Agent is required. In case name of the device changes, it won't be reflected automatically in the console, but there is a task that can be executed regularly, which will synchronize real FQDN name of device with device name as seen in the console. There is also an alternative to use "multi-rename" mechanisms for one-time renaming procedure, once systems are updated and new hostnames/FQDNs are reported to console. Could you possibly provide more details of why would you follow originally proposed steps? Asking because I would expect that both ESET products should do "survive" upgrade of operating system, especially in case both of the product are upgraded and do support new OS version.
  12. Thanks for confirmation ... unfortunately we are not aware of such issue. Could you please provide version of ESMC (7.2?) and possibly also screenshot of "Management status" tile shown in the same dashboard? Are there actually any similar issues in other dashboards? Also could you possibly specify more details of your environment, as is platform of ESMC server (Windows, Linux) and database type used (SQLServer, MySQL)?
  13. Could you please check whether this issue persist? It is actually very rare error and it might indicate failure of underlying reports, that are failing to report required count. Also do you recall when this started to happen?
  14. This seems to be an common misunderstanding and we should probably improve communication to users so that it is clear. In case of components upgrade task, you are actually selecting version of ESET PROTECT Server component, that you can actually upgrade to. In other words, in case your infrastructure is based on ESET PROTECT Server for Windows, you will be offered only the same or later version for the same platform. This version is later used for selection of compatible AGENT installers. So for example, as you have selected version 8.1.1223.0 as compatibility version, when this task is executed on macOS device, ESET repository is searched for latest AGENT version for macOS, that is compatible with ESET PROTECT 8.1.1223.0. which is currently version 8.1.3215.0. So the most confusing part is that you are actually not selecting version of AGENT to be installed, but just reference version used for compatibility.
  15. Actually I was pointing out to fact that AGENT is actually configured to use HTTP proxy (it's hostname is visible in provided status.html log) and as that might be reason for connectivity issues, I was rather proposing to disable it. In case HTTP proxy is not configured via configuration policies, it is possible it was previously, or that HTTP proxy is set via installers, i.e. there might be install parameter specifying it. In case proxy as visible in logs is actually not accessible or even no longer used, I would recommend to check installers for this kind of configuration. Also in case problematic device started connecting, please check it's configuration - it can be requested via "Export configuration" task, or by action initiated from client details screen.
  16. Unfortunately it is not clear from provided logs what exactly us wrong -> there is definitely some kind of network connectivity issues, but not clear which one. As HTTP proxy is used, I would recommend to check it is configured properly so that it can redirect connections to your EP (this requires explicit whitelisting of it's hostname/IP address to work properly). Also enabling full verbosity logs of management AGENT might helps, as described in documentation: https://help.eset.com/protect_admin/81/en-US/fs_agent_connection_troubleshooting.html, but it might not help in case problems is actually on HTTP proxy.
  17. I would recommend to enable full verbosity trace logging on AGENT installed side-by-side your EP Server and re-run upgrade task (components upgrade task created via help as you mentioned). Before that, I would possibly recommend to check configuration of this task, whether it actually references EP 8.1. We could possibly analyze once log is attached or ESET support is contacted. Also note, that EP Server and also Management Agent installed on the same device as EP server is excluded from one-click updates as available via dashboards - this is due to possible negative impact on infrastructure -> EP server and it's management server is supposed to be upgrade either via in-product upgrade, or manually using various EP installer types
  18. Management of MDM service, and also propagation of mentioned last connection times is handled by so called managing AGENT, which is actually ESET Management Agent installed on the same server as is MDM. So please double check that there is actually and ESET Management Agent installed and running, and especially whether it is correctly connecting to EP server.
  19. Could you please double check that provided logs are from this problematic client devices? There seems to be different connection details, or more precisely those logs are probably from EP itself, not from problematic device. But regardless of that, I would recommend to check network connectivity, i.e. especially whether used EP is accessible on port 2222 from client device.
  20. As you probably found out, most basic information is available in main dashboard, in the following section: which also offers possibility to manually upgrade outdated ESET components. There is also dashboard named "ESET Applications" which do provides more detailed view of how many and what version of ESET products are outdated.
  21. Could you please double check problematic devices are connecting, i.e. they had chance to report status? If so, I would recommend to modify DG template in a way that it will use operator "AND" and "not equal" conditions, even it should be equivalent on first sight? Also please provide list of "IP subnetwork" values for all network interfaces (i.e. as reported by console for such devices) on devices that you expected to be present in defined dynamic group for verification of DG evaluation correctness.
  22. Could you please double-check that Java actually used by Apache Tomcat is of supported version? We have seen similar issues with OpenJDK 16 (non-LTS) which is not supported as it introduced breaking changes. Alternative might be to explicitly configure Apache Tomcat (via it's configuration utility) to use Amazon Correto 8 Java.
  23. Could you please provide more details of which reboot you are actually referring to? Asking as there are multiple scenarios where reboot might be initiated (explicit reboot task, post-upgrade reboot, post-OS-upgrade reboot) and each of them has slightly different behavior. Regardless of that, we are tracking these requirements, but there is currently no possibility to configure it. Explicitly requested reboot of the machine should provide at least basic notification to users, as you mentioned -> this has not changed for some time, but it does not provide user to delay or cancel reboot if requested by administrator.
  24. Could you please provide more details of your environment? For example version of Java? We do support only LTS versions, so I would start by checking whether it would work with different Java version (OpenJDK11?). Also have you tested with different browser just to be sure it is not browser-related?
  25. In case it stopped working suddenly, I would not expect upgrade of ESMC would help. As you have not made any ESMC changes, I would check configuration of SMTP servers, or possibly trace logs of ESMC where more detailed error might be indicated -> sudden change in functionality might be related to network, firewall configuration or maybe expired TLS certificate of SMTP server, etc.
×
×
  • Create New...