j-gray

@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.

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?

We have around 1600 clients, total. The software update task I usually run against 20-40 clients at one time.

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'

I see ESET Endpoint Antivirus for OS X version 6.8.1.0 available in the repository, but find no release notes, nor any mention here. Any info available? Thank you

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.

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

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.

I've opened a case with support (312404) to see what we can do to resolve this issue.

Is there a recommended solution for this issue?

Thanks for the reply. That command returns the hostname only. How do we get the client to properly report FQDN? The problem is that this creates two objects when using AD sync: one object with FQDN and the same object with hostname only. The object with hostname only then gets dumped into Lost & Found. The rename task used to work in the past. We have too many clients to rename every duplicate manually. Is there a workaround?

This task has been configured to run on the 'Lost and Found' container for quite a while and has been working. The task still runs successfully, but we have 60+ Mac's that are not updating their FQDN. The show as hostname only. They reply/resolve on the network with their FQDN. They are in DNS and DHCP with their correct FQDN. Why does ESMC not show their correct FQDN and what can I do to resolve this issue?

@Marcos Yes, PUA's have been cleaned properly on the problematic systems. Thank you!!

@Marcos @MichalJ Where may I upload log files? I'd prefer not to post in the forum. Thank you.

@MichalJ The PUPs flagged as critical are JS/Mindspark.G, JS/Spigot.B, JS/Visicom.A, OSX/Mackeeper.DL, and on Windows, Win32/AirAdInstaller.A, JS/Visicom.A, JS/Spigot.B. Both Real-time and On-demand set for strict cleaning have been unable to clean. This a recent occurrence where nothing from PUPs to trojans and other malware are not getting successfully cleaned with 'strict cleaning' enabled, causing a high count of active threats. OS X is a mix of 10.12.6 and 10.13.6 running ESET version 6.7.654.0 Windows is a mix of 7 and 10 running ESET version 7.0.2100.4 and 7.1.2045.5

Yes, I should have clarified. On the Windows clients I see this for items typically flagged as Trojans. It's odd to me that a Trojan gets flagged with severity 'Warning', where a PUP gets flagged with severity 'Critical'. This seems backwards. I also don't understand why those that get flagged with 'Critical' and 'Active Threats' show up in the console with a green check mark indicating healthy status. See below:

On OS X clients, lately I've been seeing a lot of unhandled PUP's with little information to go on. This is the result of Full scan with cleaning: Policies are set for 'Strict Cleaning' on both real-time and on-demand scans. I'd like to understand what's (not) happening here. I'm seeing similar on Windows clients, though it typically says, "action selection postponed until scan completion" but never takes any action even after the scan completes.

I've found similar instances and attribute it to some form of agent corruption. I haven't found an easy way to repair the agent, but the majority of the time, simply uninstalling and reinstalling the agent resolves the issue. Not what I would consider a "fix", but does get things working again.

Can you please clarify the implications of this: "ESET Endpoint Antivirus is notarized by Apple and recognized by Gatekeeper" Does this mean that ESET kernel extensions will no longer be blocked by Mac OS?

Can you please clarify if 7.1 client is fully compatible with 7.0 ESMC? Is this what "Added: ESMC 7.0 compatibility" means? Thank you.

I updated the client to 7.0.2091 and rebooted last night. Today I attempted to run the log collector again. Still get the same timeout error. Any suggestions how to troubleshoot log collector failures? Does the log collector create its own logs somewhere?

@Marcos I've attempted to get the logs over several days, but each time I get the following: "Failed to start application | Log collector command timed out and was terminated" Didn't find any details why it's failing. Other tasks appear to be running without issue. Any suggestions how to troubleshoot this?

I have a Windows workstation (latest agent, AV = 7.0.2091.0). It has been scanned three times over two days. Each scan reports the same: 'Critical': 48 infected, 0 cleaned. When I go to the linked client details, it shows only 2 warnings for PUP's in the Threats/Quarantine section. In the ERA console view, the workstation shows with a green check showing status 'OK', but also reflects the two active threats. The 'High severity scans in last 30 days' reflects the three scans each showing 48 infections. I haven't yet found a report or view that details what items are infected. My questions are: Where can I look to see what items are infected and/or why they were not handled? If the system is infected, why is not flagged as such? It shows status 'OK' and only reflects the two PUP warnings. Nothing else in the client view indicates any infections or issues otherwise. Thank you.

FWIW, I get the same error on the latest version of Apache HTTP Proxy each time the service starts, though it does not appear to be causing any issues.

Thanks for the clarification. That makes sense!