j-gray

Agreed. Hence my concerns. I believe something must have changed with the recent upgrades, as everything had been getting remediated properly. No policies have been changed, but ESET is no longer remediating much of anything. Sk8r is classified as a PUP, so potentially forgivable. It's the items flagged as trojans and malware applications that are being retained that are more concerning.

This is what how we have on-demand scanning configured. Cleaning is set to 'always remedy detection':

Thanks for the reply. That would be an option if I were sitting at these various computers. But we have 12 different campuses so my only viable option is pulling info from the ERA console.

This is what most look like with Action = retained and no apparent error or indication why it was retained:

That looks helpful, though I'm not finding such a log. Where is that located? It looks like you're working with Endpoint Security, whereas I'm using Endpoint AV, so there may be some differences?

Thanks for the reply. Scans are occurring after hours, so folks should be logged off, though we know that doesn't always happen. I'm not sure how ESET defines system files. My assumption is an installer (msi) wouldn't necessarily be a system file, nor would those files in the user space, specifically in the user's Chrome profile. Just not sure if my assumption is correct. ESET in the past has indicated when a reboot is required for remediation, but it's not reflecting that, either. I haven't been able to find in the reports or elsewhere any indication as to why ESET is unable to remediate. I'm sure this is logged somewhere, just not finding it.

Scheduled scans and on-demand (scan with cleaning) are not removing most malware lately. MSIL/Adware.BrowserAssistant.B: these are just .msi files flagged as applications, not PUPs and are located in the C:\Windows\Installer directory. I can manually delete them without issues. The others that aren't getting cleaned are HTML/ScrInject.B, JS/Adware.Chromex.Agent.E, JS/Mindspark.G, and a handful of others that are located in the user profile space. Scan settings are set to 'Always remedy detection'. Systems are showing no reboot required. I can't tell from the reports why none of these are being remediated. Any suggestions?

Thanks. I just came across this while researching, because we're getting the legacy extension compatibility error noted here.

That link is 404.

In the ESMC console, go to Help > Update Product It will step you through backing up the required pieces and performing the upgrade.

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.

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?

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.

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!

Ok, it looks like the task actually ran even though it showed as offline. I think we're good now. Thanks for the help!

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?

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.

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 7.2.11.0. 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 (7.2.221.0) Also, after the upgrade, the ESMC still shows there is a product upgrade available. It references the 7.2.11.0 changelog

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.

It looks like adding port 8883 to the httpd.conf file resolved the connection issue. Thanks for that tip.

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.

Are there any options if we do not want these frequent/persistent outbound connections?

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.

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.

If nobody is triggering these, why are they occurring so frequently? Is it possible to disable this?