Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by j-gray

  1. In the ESMC console, go to Help > Update Product It will step you through backing up the required pieces and performing the upgrade.
  2. I found an issue with Reverse DNS in our environment. Once that was fixed and OS X clients started registering, the issue was resolved. So the following appears to be the case: If HostName = abcd, kern.hostname returns abcd If HostName = blank, kern.hostname returns Reverse DNS value (typically FQDN) If Reverse DNS value is not present, kern.hostname returns abcd.local So it seems in order to get this to work, one must either 1) make HostName = FQDN, or 2) leave HostName blank and ensure Reverse DNS registers FQDN.
  3. More testing: if HostName is blank, kern.hostname = computername.local If HostName = computername, kern.hostname = computername So where is kern.hostname getting its value when HostName is blank?
  4. Previous thread for reference below. We used to populate 'HostName' in our imaging script for OS X devices. We found that got populated into kern.hostname and caused clients to report with just hostname and not FQDN. Our fix was to clear the HostName value so it was blank. Then, kern.hostname would actually populate correctly with the FQDN. However, now we're finding that if HostName is set, kern.hostname = HostName. When we clear HostName, kern.hostname becomes %ComputerName%.local and no longer reflects the FQDN. Has the agent behavior changed with later releases? I'm not sure why it's now reverting to hostname.local These systems are all AD domain-joined.
  5. This was the case, and I stepped through the dialog presented there. Because it was showing as offline, I didn't think the command would run against it, but it did and is functioning properly now. Thanks again for the help!
  6. Ok, it looks like the task actually ran even though it showed as offline. I think we're good now. Thanks for the help!
  7. Thank you. This got me on the right path. I now recall the ESMC was migrated from Hyper-v to Vmware a few weeks ago. So essentially it was cloned. Now ESMC sees the server as offline, so I'm not sure how to reset it?
  8. Thanks for the clarification, that helps a lot. My console is still prompting me to update the product. How can I tell what it thinks needs to be updated? Or alternatively, if it's a false message, how do I clear it? And/or should I attempt to run the upgrade task again? The server was rebooted after successful completion of the all-in-one installation.
  9. Thanks for the reply. Sorry -I was in a hurry so I just downloaded and ran the all-in-one installer. It completed successfully in about 10 minutes. I guess I prefer this method anyway, as I can actually see what's happening. Bit confusing though; the forum says latest version is The all-in-one download says the same version, as does the changelog. However, I actually ended up with a different version than indicated: ESET Security Management Center (Server), Version 7.2 (7.2.1266.0) ESET Security Management Center (Web Console), Version 7.2 ( Also, after the upgrade, the ESMC still shows there is a product upgrade available. It references the changelog
  10. Trying to upgrade via the Help menu from version 7.1 (7.1.717.0). The task is created, executions planned = yes, triggers = execute asap. Job status does not change after 30+ minutes. I've rebooted the server and attempted again with the same results. Audit logs only show successful task creation, so I can't tell what is causing the hang up. Any help or suggestions appreciated. TIA.
  11. It looks like adding port 8883 to the httpd.conf file resolved the connection issue. Thanks for that tip.
  12. I just picked a random one from within the error logs. It is an OS X client running ESET Endpoint Antivirus 6.8.400.0 with ESET Management Agent 7.1.840.0 (latest). Another random client with the same errors is also OS X, running agent 7.1.840.0 (latest) but older av version 6.7.900.0 A third random client in the error logs is a Windows client with ESET Management Agent 7.1.717.0 (latest) running ESET Endpoint Antivirus 7.1.2053.0. So far, the random clients showing the connection error to epns.eset.com are all running the latest agent.
  13. Are there any options if we do not want these frequent/persistent outbound connections?
  14. From both Windows and OS X clients, nmap results show both ports open (epns.eset.com:8883 and epns.eset.com:443). So I have no idea why the connection is being blocked. Any thoughts? That said, we'd prefer to minimize outbound traffic, particularly given we don't require that functionality. Is there a way to disable this outbound traffic within the product? Thank you.
  15. No. I'm the only console user and I never use this feature. The logs show multiple entries per minute from a number of different clients. There are 429 entries in today's log file, alone. There's no reason it should be doing this that I know of.
  16. If nobody is triggering these, why are they occurring so frequently? Is it possible to disable this?
  17. @Marcos Thanks for the reply. We are not blocking this traffic on our networks at the client or server. Based on the error messages, it appears that the remote server (epns.eset.com) is blocking/rejecting the communication. Or is the error indicating that the epns server cannot connect to our client? I'm also confused, as the documentation indicates these calls are triggered by a Web Console user. I am the only Web Console user and have not triggered these ever (intentionally, at least). Could you please clarify how to resolve this issue? Ideally we would not want this outbound traffic to ESET. Thanks again.
  18. I'm getting the following repeatedly logged on the proxy server: [proxy:error] [pid 6596:tid 10020] [client x.x.x.x:52075] AH00898: Connect to remote machine blocked returned by epns.eset.com:8883 This specific remote server is constantly blocking these connection attempts. Any idea what's going on here and how to rectify this?
  19. We have around 1600 clients, total. The software update task I usually run against 20-40 clients at one time.
  20. The rest of the message is "See trace message for more details." I see this randomly on clients when trying to upgrade the antivirus and it causes the tasks to fail. Typically running the task again results in success, but it happens frequently enough to be a pain. I see a lot of the following error: [cache:error] [pid 1212:tid 8480] (OS 5)Access is denied. : [client x.x.x.x:55030] AH00779: Could not stat a cache lock file: C:\\Windows\\SERVIC~2\\NETWOR~1\\AppData\\Local\\Temp/mod_cache-lock/3/b/3bpPDdRsi0BQcSLS9D9z_g Also, a lot of errors returned from i3.c.eset.com and i5.c.eset.com ('error reading from remote server' and/or 'connection was forcibly closed by the remote host'
  21. I see ESET Endpoint Antivirus for OS X version available in the repository, but find no release notes, nor any mention here. Any info available? Thank you
  22. From support; developers thought it was a reverse lookup issue. From statement above, it would seem like reverse lookup is no longer used by ESET. Once I demonstrated that reverse lookup was functioning properly, support pretty much told me I'd need to figure it out. Can anyone clarify how the 'Rename' task based on FQDN is supposed to work? Thank you.
  23. Thanks for the info. Any idea why the 'Rename Computers' task no longer renames these clients? Restart agent command gave the following and did not seem to do anything: //Contents/Resources/com.eset.remoteadministrator.agent_daemon.plist: No such file or directory //Contents/Resources/com.eset.remoteadministrator.agent_daemon.plist: No such file or directory //Contents/Resources/com.eset.remoteadministrator.restart_agent.plist: No such file or directory
  24. No specific method. Domain is provided by DHCP option to all clients. This value is returned via ifconfig on any OS X client. While the commands above typically return just the hostname, the 'sysctl kern.hostname' returns either just the hostname, or in some cases the FQDN. I don't know how kern.hostname gets set. I can set kern.hostname to the value of the FQDN. In this case, HostName remains as just the hostname (no FQDN). But in this case, I believe I have to uninstall/reinstall the agent for the client to then report the new FQDN properly.
  • Create New...