Jump to content

j-gray

Members
  • Posts

    615
  • Joined

  • Last visited

  • Days Won

    5

j-gray last won the day on December 1 2022

j-gray had the most liked content!

About j-gray

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA

Recent Profile Visitors

5,308 profile views
  1. @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.
  2. 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/
  3. 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?
  4. 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:
  5. 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.
  6. @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.
  7. 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?
  8. 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.
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. 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 https://forum.eset.com/topic/37008-license-sincronization-increases-the-number-of-units/#comment-169318
  14. 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:
  15. FWIW, I've experienced the same, as well. However, we've since shut down our on-prem EEI server.
×
×
  • Create New...