j-gray
-
Posts
620 -
Joined
-
Last visited
-
Days Won
5
Posts posted by j-gray
-
-
6 hours ago, Marcos said:
As for Npcap, unfortunately it is not free: The Npcap free license only allows five installs (with a few exceptions).
We are currently in the process of making a decision about the future of RD Sensor and evaluating the possibilities.
@Marcos Thanks for that --totally missed the licensing limitation.
RD Sensor could provide functionality that we desperately need, but just isn't viable with the current model. There's no way we can deploy them at every site and on every subnet, particularly given there is no install for macOS. The manual install is painful, as well.
It would be great if this functionality was built into the existing agent and could be enabled if/when needed on any client.
-
The following seems to work:
- Install WinPcap then install RD Sensor
- Stop RD Sensor service
- Uninstall WinPcap and install Npcap (must choose the option to "Install Npcap in WinPcap API-compatible mode"
- Restart RD Sensor service
Based on the trace.log file it appears to be working properly.
The bigger issue is that we have 15 sites with 3-5 subnets each. I can't see doing this manual process a minimum of 45 times.
-
4 minutes ago, itman said:
Have you tried Win10Pcap: https://www.win10pcap.org/ ?
That one hasn't been updated since 2015, wich gives me pause. It did install successfully on Windows 11, though RD Sensor looks specifically for WinPcap and won't proceed with the installation if it doesn't find it.
I'm going to try installing WinPcap so I can complete the RD Sensor install. Then I'll remove it and install the current supported version of Npcap and see if that works.
-
According to documentation, RD Sensor requires WinPcap wich was last updated in 2013, has been deprecated and is unsupported on current operating systems. It also has documented DLL hijacking vulnerabilities.
I tried installing Npcap, the recommended alternative, but the RD Sensor did not detect WinPcap, so would not complete the installation.
Is there any workaround for this or any plans for ESET to accommodate Npcap?
-
@Marcos The underlying issue is that when it's unable to scan a file, it considers it an 'antivirus detection event'. Which then triggers a Malware Outbreak Alert to be sent, creating a false alarm.
Is there a way to exclude 'unable to scan' from antivirus detections so that we only get notified of actual detections?
In this most recent case it appears to be due to a password protected file, which generated 143 alerts.
-
Hi @Marcos Here's an example we see frequently across our Macs. It's an ESET pkg file that triggers a critical alert in the EP Console. The specific detail is in the screenshot below.
Another we see continuously is from pkg files in the OS X update repository where a bunch of pkg files live:
file:///System/Volumes/Data/Library/Updates/
-
We get a ton of these alerts flagged as critical. Always specific to OS X and frequently either dmg or pkg files. These are triggered by the on-demand scanner using the default archive scan settings.
Assuming it's expected that ESET can't fully scan these archives is there a way to reduce the severity reporting in the console?
We'd prefer not to exclude these files from scanning and it's not entirely limited to dmg and pkg files, though those are the bulk.
Are there any best practices or ways to address this?
-
This issue appears to be specific to OS X and the EI Connector in EP Console.
In this case, ESET icons indicate the product is installed (see pic below). EI Console shows the connecter installed and checking in, EBA Console shows current activation of the correct version, etc.
It's just not listed in 'Installed Applications', which throws off our dynamic groups because EP Console thinks that it's not installed:
-
Hi @Peter Randziak No, unfortunately I don't have ECP logs for any of those.
I did have a small handful of candidates to upgrade but they weren't in the EBA Console at all, which is one of the issues we've been encountering.
-
@Peter Randziak Any luck with the logs?
My case (#00521603) got auto-closed without resolution.
While it's a prevalent issue, I can't recreate it consistently at will. So end up wasting a lot of time manually enabling ECP logging to then not have the issue occur. And we hit the end of the upgrade cycle some time ago, so I don't have much to work with until the next upgrade is released.
FWIW, support did identify the issue upgrading from v6.11 to v7.3 and identified a fix for that scenario specifically. But apparently that fix does not apply to subsequent upgrades. I'm not sure why that would be the case, though.
Thanks again for your help.
-
I know there was previously a lengthy discussion on this issue but it has since been archived.
Unfortunately, OS X activation failure is still an ongoing issue for us since October of 2022, shortly after we implemented EDR.
OS X clients typically activate successfully initially, but at some point the Connector becomes corrupted and will no longer activate successfully.
Is anyone else still experiencing this issue? Or found a resolution?
-
Thanks @Peter Randziak This issue presents during an upgrade cycle, which we've mostly completed (for now). Support recommended we bump our license purge to 30 days, so most duplicates have cleared by now.
I did share one log file I was able to find, but this instance doesn't look quite the same as what we typically see.
-
FYI; I tried the task with the parameter specified in the documentation (--no-productlogs). The file size this time was almost double the first one at 368MB. So this task failed.
I'm not sure if the syntax is correct in the documentation, but it clearly is not smaller.
I ran a test on Windows, as well and the referenced paramater (/Targets:EraAgLogs) seemed to work properly as it generated a 487KB log file versus ~100MB file without the added parameter.
In short, the Windows paramater to create smaller log files works as expected. The OS X parameter had the opposite effect and created a file double the size.
-
1 hour ago, Marcos said:
The limit for diagnostic logs should be 200 MB according to https://help.eset.com/protect_admin/11.0/en-US/computer_details.html.
@Marcos That documentation is specific to the on-prem solution, but we're talking about the Cloud version here.
The documentation I just found for the Cloud Console indicates there is a 15MB limit, which clearly is not sufficient to provide the information requested by support.
There really needs to be a viable solution to collect logs remotely.
-
Just found the additional error details: "Log collector output with size of 161MB exceeded 15MB and will not be transferred"
A 15MB file size limit does not seem very practical.
I know there is a downloadable/executable log collector but we need an effective remote option.
-
When running the Log Collector on remote OS X systems, the task consistently fails. The error: "Log collector archive is too big to be transferred".
Is there a way around this? Have the log files been successfully collected and just can't be retrieved? If so, where can they be found?
As frequently as ESET Support requests log files, it would be helpful to have a way to collect these remotely.
-
It seems like the multiple license assignment issue has been discussed in at least two other recent posts:
https://forum.eset.com/topic/38170-msp-licence-overuse/#comment-173043
-
I've been working with support for around 8 months (#00521603) and haven't had much luck with two issues. Posting here in hopes of more visibility and hopefully some options.
-
Frequently, activated devices in EP Console are not found in EBA Console at all (neither device name, nor seat name). They are clearly activated and are licensed
- Is there a way to force these clients to update in EBA Console?
-
OS X devices consume multiple licenses when upgraded
- Many times after and upgrade of either AV or EI Connector, the OS X clients consume a license for the previous version and the new version. So we'll frequently see an OS X device with a 7.3.x license and a 7.4.x license at the same time. So we frequently run out of licenses when upgrading. This is not an issue on Windows devices.
Regarding #2, support indicated they were able to reproduce the license issue when upgrading from v6 to v7 and reportedly fixed this for this specific case. However, we found that the problem exists for other upgrade paths, as well, including the EI Connector.
It would make sense that this license issue is not version specific, nonetheless, support wants us to collect logs during the upgrade process. Unfortunately, this is not possible because 1) it is not consistently reproducible and we have no way of knowing what workstation might exhibit this issue, 2) there is no way to remotely start and stop log file creation to capture the process. Interactive login is required for log capture, which is not an option for remote sites and production systems, and 3) frequently systems can't be found in EBA Console so test cases are even more limited as we can't see what licenses are consumed.
I've presented multiple examples of the issue (see below), yet the onus for resolution seems to always be placed on the end-user to reproduce the issue, log the results, provide the log files, etc.
Here is an example of one device consuming 5 licenses for two products:
-
Frequently, activated devices in EP Console are not found in EBA Console at all (neither device name, nor seat name). They are clearly activated and are licensed
-
FWIW, I've experienced the same, as well. However, we've since shut down our on-prem EEI server.
-
Seeing quite a few instances of OS X Connector upgrades to v.2 failing.
The task history shows, "Deployment token activation request could not be delivered. Request message send failed".
The following entry indicates task failure with 'Managed product not available' and "Message task was canceled because maximum retry count was reached".
Anyone else running into this error?
-
Licensing question; documentation states that for this functionality, you must have EP Elite or Complete.
We have Enterprise licenses, which is a tier above Complete.
Is there a reason that this would be available in a lower tier but not a higher tier? It's definitely not an available option for us.
Appreciate any clarification.
-
^^ This may be an isolated incident. Looked like the agent may have gotten corrupted.
Regardless, we are observing a significant increase of activation issues over the last week.
-
Just checked status.html on one of the recently affected clients and see the following:
"Device authentication request failed with error: Received http2 header with status: 400 (code: 1) for request Era.Common.Microservices.Authentication.DeviceAuthenticationRequest (id: a7db0940-c40f-4f55-8a1e-36d34303ef20) on connection to 'host: "xxxxxxxxxxxxx.a.ecaserver.eset.com" port: 443"
-
We've been running ESET for quite some time, moved to the cloud this past July. We've noticed over the last week that a lot of workstations and servers lose their activation status for antivirus. Typically running an activation task clears the issue, but it seems to be recurring.
Is anyone else experiencing this? I'm not sure what may be causing this lately, but it's noticeable.
Future changes to ESET PROTECT (cloud)
in ESET PROTECT
Posted
Description: Streamline licensing and ESET components
Detail: Too many components and licensing is cumbersome. Currently, we have three cloud consoles (EP, EI, EBA) to manage all functionality. We have two agent installs (macOS and Win), two EI Connector installs (macOS and Win), three AV installs (macOS, Win desktop, Win Server). We need separate hosts and installs for RD Sensor, another install for the Bridge and another install for the Active Directory Scanner. All with constant updates, etc.
Major competitors use a single agent install that can have any functionality enabled or disabled as needed. So much simpler to manage versus these myriad components.