ESET Staff
  • Content count

  • Joined

  • Last visited

  • Days Won


MartinK last won the day on March 2

MartinK had the most liked content!


Profile Information

  • Gender
  1. According to provided status log, this AGENT is successfully connecting to ERA. Could you be more precise why you consider it not connecting? There is not even entry in ERA console? Or computer you are checking has outdated last connection time? Any chance you are using machine cloning in your environment - asking because that could cause confusion in ERA? There is also chance that this computer is named differently in ERA console, for example in case it changed hostname in ERA it will be named using original name it used during first connection ... only exception is automatic renaming task.
  2. Stable Client update

    Please check workaround for this issue in one of my previous posts. Adding one command line parameter to Software installation task parameters should resolve this issue for v6.6 desktop products.
  3. Force policy changes

    You can check applied policies in client details view of device -> configuration -> applied policies: where column "Status" indicates whether current version, or older is applied on client machine. This list is based on data sent from client, so it may be inaccurate in case AGENT is not connecting. Status "Older" means that version of policy as currently available in ERA is different than version of policy reported by AGENT as applied. Not connecting AGENT is also most probable issue in case policies are not applied correctly.
  4. I would recommend to run installation with full trace logging, i.e. run installation from command line: msiexec.exe /i "C:\Agent_x64.msi" /L*V "C:\agent_install.log" and either send me log in PM, or contact ESET support. We have seen similar error in case there was problem with crystallographic subsystem which is part of operating system. During certificate validation, import of PFX into temporary certificate store was failing. Any chance you tried to reboot system before installation attempts were made?
  5. Eset Mobile Device Connector SSL

    Just to be sure, have you fixed wrong installation parameter with password I mentioned in my previous post?
  6. This seems to be an misunderstanding of what it this task supposed to do. Update modules task does update only specific part of product, but not application itself. For example if you run Update modules task, virus signature database and detection engines in security product are updated, but not AGENT or EES itself. For upgrading AGENT, there is dedicated task Remote administrator components upgrade (see documentation). Similarly when you with to update EES/EAV from for example version 6.3 to 6.6, you have to run Software installation task - in this case, modules update will update detection engines and so, but not application itself.
  7. Eset Mobile Device Connector SSL

    I would recommend to follow documentation for MDM manual installation which describes command line parameters and possible installation scenarios. From parameters you provided I think problem is with parameter: --cert-password which should have actually been: --https-cert-password
  8. In case AGENT is not connecting (i.e. remote management is not possibly), only way how to force it co connect to different hostname or IP address is to use installation repair. I have described it in one of my previous posts. I would recommend to check whether AGENT will be able to connect to SERVER in case IP address is provided. Be aware that this will work only in case IP address or wildcard "*" was used in SERVER's SSL certificate (this can be verified in SERVER's settings). Does command: nslookup <hostname of ERA> return correct response on client machine? Hostname must be exactly the same as AGENT is using to be sure there is no typo.
  9. Next EFSW release will enable you to use this workaround. Once both products are released, this workaround won't be required anymore. I will leave answer to ETA-part to @MichalJas I am not sure.
  10. Unfortunately this workaround won't work for server-based products until next release.
  11. Does this happens only on specific machine or on all? Error " The requested name is valid, but no data of the requested type was found" seems to be generic and provided by Windows itself in case it is not able to resolve DNS name. Could you try to use IP address instead of hostname, or possibly some kind of alternate name? Is it IPv4 network, or hostname is using IPv6 addresses?
  12. Eset endpoint antivirus 6.6.2072.4

    Could you please specify also language of EES/EAV you are using?
  13. Error Downloading Installers ERA

    Unfortunately it is not clearly visible where the issue is, as we had an issue in error reporting, which was masking the real problem. In most cases, problem is with network connection to ESET servers. Could you please check whether is accessible from this machine? Any chance you are using HTTP proxy in ERA configuration? If so, please verify it actually works. Is it possible to capture network traffic between ERA and internet ( We had also seen this problem in case connection to was not stable enough or extremely slow - just to be sure, is connection capable to download ~200MB of installers data without significant delay or interruption? In a few scenarios we have seen that firewall could also block download of installer data (especially first one which is actually executable file).
  14. Rogue sensor confusion

    As already noted, detection of rogue/managed computers is based on MAC addresses. They are collected by RogueDetectionSensor and compared with list of MAC addresses reported by managed clients.There are unfortunately few drawbacks (and bugs) that may have triggered your issue, for example: when comparing list of "managed" MAC addresses, only active interfaces are used. This may be problem in case devices are changing MAC address in your network. For example RogueDetectionSensor might have detected your device when connected using standard network card, but in case device is connected using WiFi, it will have different MAC address -> MAC address of Ethernet card will be considered as rogue. devices might generate virtual connections with different MAC addresses, which are detected by RogueDetectionSensor but never actually reported to ERA, which results of reporting such devices as rogue. There are multiple examples of how to do so. As an example, running virtual machine on client machine with specific network configuration may be detected wrongly. The same applies for virtual interfaces spawned by docker ... they both generated traffic with different MAC address, but they are hidden behind host machine. Is it possible your issue is triggered by one of mentioned scenarios?
  15. Copy Policies to Agent outside LAN

    If you have administrative access to the machine, you can use installation repair: On client machine, run AGENT installer: c:\ProgramData\ESET\RemoteAdministrator\Agent\SetupData\Installer\agent_x64.msi Choose "Repair" when prompted for operation Fill in hostname and port and check "Keep currently used certificates". AGENT should be connecting to new hostname once installation repair is done. Just one note: be sure to fix policy that changed hostname on AGENT before it is actually connecting again.