j-gray
-
Posts
620 -
Joined
-
Last visited
-
Days Won
5
Posts posted by j-gray
-
-
On Mojave OS X clients, we're seeing the following alert:
"macOS is preventing ESET Security Product from accessing some folders"
This is on the latest Antivirus 6.7.600.0 and Agent 7.0.432.0
Search did not turn up any clues. Is there any info available indicating what is causing this and how to resolve?
TIA
-
On 12/22/2018 at 4:15 AM, MartinK said:
Unfortunately you are right. Issue has been discovered during ESMC "Early Access" but was not resolved yet. As you noted, it does not respect hierarchy of groups, only results of matching dynamic group templates.
Thanks for the info. I have a ticket open with support for this but haven't gotten any updates or confirmation this is a bug.
Do you have any info as to when a fix might be released?
TIA
-
19 hours ago, cesareset said:
hello I would like to know why the new version of the rd sensor does not have the same functionality as in version 6, because the version 6 of erac the rd sensor I found all the equipment in the network and in the new console of ESMC no longer gives me the same data or do I appear to act differently in this console or how is the rd sensor in this version of eset?
You will need an RD Sensor on each and every subnet. Is this the case in your environment?
-
On 12/31/2018 at 2:31 AM, Matus said:
Hi J-gray,
we're looking into these issues and splash screen as well as kernel extension error will be fixed within next update planned for beginning of the new year.
@Matus Are you saying the splash-screen issue is known? I have a case open (#216348) and support has advised that this is not a known issue.
-
4 hours ago, Marcos said:
Please post a screen shot of how the two dynamic groups appear in the groups tree.
It appears that sub-groups are not respecting the parent group filter.
I have parent group filter by OS, therefore, sub-groups do not specify OS in the expression. While it appears correctly in the console (e.g. only Macs are in the Mac group), because OS is not specified in any sub-group, sub-groups are applied to all clients.
-
@Marcos Groups are displayed on the left with client info in the main pane:
-
I have two separate dynamic groups to contain different operating systems; one for Windows and one for OS X based on the following two templates, respectively:
OS edition . OS type = (equal) Microsoft Windows
OS edition . OS type = (equal) Mac OS
When I look in the console, as expected I see only Windows workstations/servers in the Windows group and only OS X devices in the Mac container.
Yet, when I look at computer details of any client, it shows it being a member of both dynamic groups. Any idea what is causing this?
-
As a database is required, it installs SQL Express (free/no license required) by default.
You can install the full version of SQL, but will require a license: https://help.eset.com/era_install/65/en-US/sql_server_windows.html?sql_server_windows.html
MySQL is an option, too: https://help.eset.com/era_install/65/en-US/sql_server_windows.html?mysql_windows.html
-
I've created a case for the kernel extension error (#216378). Unfortunately, I was informed this is a known issue with no ETA for fix.
We'll be halting our upgrade rollout for now.
-
I've created a case for the splash-screen issue. I'll create another one for the Protection Status/kernel extension issue, shortly.
-
8 hours ago, MichalJ said:
Hi @j-gray The last behavior is intentional. Unresolved threats do not affect the status of the application. Application is working properly, however threats are reported.
With regards to the splash screen, issue is, that on the first startup of a newly installed version, this starts with default values before the configuration is applied, meaning splash is displayed. This should not re-occur on the other startup of the application. We are currently discussing a complete change of the splash screen behavior.
Concerning the protection status. Can you post a screenshot of what is reported locally, and how is your policy configured? Does this issue persist after the restart of the machine?
Screenshot of the last issue would help as well. I will send it over to our QA to replicate / validate.
Thank you,
Michal
@MichalJ Thanks for the reply.
Behavior is counter-intuitive; the client shows red exclamation indicating a security risk, but console shows green check indicating good status. I would not want to see a green/good status if security risks are present and unresloved.
The splash-screen appears at every reboot.
Regarding Protection Status, tray icon and gui status looks like this:
Protection Status policy looks like this:
Issue reproduces intermittently. Client was working properly and I just rebooted to verify splash-screen is still appearing on reboot. Client came up with the error. Reboots in the past have resolved the error, but it recurs randomly on subsequent reboots.
-
Also finding that systems are showing a green check in the status column, despite having active threats:
Properties of the client reflect the unresolved threats:
-
Anyone else seeing these issues on OS X?
I imagine the splash-screen issue is a bug?
-
We've upgraded our server to latest version, as well as some OS X clients (agent and av). I'm encountering the following issues:
- Splash-screen is displayed at startup. Policy is set (and locked) to not to display splash-screen at startup.
- Client 'Protection Status' shows an error and red flag with 'Web and Email' component on the client GUI. Policy is set for Protection Status to only show if Restart is required. Client GUI should not be showing other Protection Statuses.
- Web and Email error is appearing in client GUI somewhat consistently after reboots: "Kernel extension required for Firewall was not loaded because of an error. Try to restart macOS or reinstall the product." Though we have these components disabled by policy, something apparently is not loading correctly at start up.
-
What you have posted reflects the defaults, and this is how the clients are configured, both Win7 and Win10.
-
After upgrading to v7, I'm finding random systems with the following warning: "This feature is not monitored by Windows Security Center".
Product = Operating System, Subproduct = Firewall
We have the same policy applied to all Windows workstations, yet some have this warning while others do not. We do have the Windows firewall enabled on all systems.
This error appears on some Windows 10, some Windows 7 and various versions of antivirus and agent.
I'm unable to determine why the warning appears on some but not others, given same settings and policies. I can disable reporting of this, but would rather understand why it's being inconsistent.
-
17 hours ago, Marcos said:
Protocol filtering in Endpoint for Windows can be enabled here:
Thanks for the reply. That's confusing; the error specifies Firewall, but it's actually specific to Web and Email components. Also appears to only trigger for v7 clients and not earlier version, despite the same policy on both versions.
Regardless, we have Web and Email components disabled, as well as Firewall and Content Filtering. Seems we should not get errors/warning for something we've intentionally disabled. It would be another story if it was enabled but not functioning properly...
-
We successfully upgraded our server to v7 and we've upgraded some OS X and Windows agents to the latest versions, so far without issue.
However, after upgrading Windows antivirus to the latest version, they are all showing an alert in the console: "Protocol filtering is disabled".
The alert shows the subproduct as 'Firewall'. However, the Firewall is completely disabled via policy. Further, this alert does not show on Windows clients with earlier version of antivirus (e.g. 6.x). The client shows no errors in the GUI.
Where in the policies can I fix this?
-
I know there was a thread on this somewhere, but I'm unable to locate it...
This is an annual occurrence when we have a time change for Daylight Savings Time (DST). Scheduled tasks that were set to run at 4:30pm now run an hour earlier at 3:30pm.
The task uses CRON expression: 0 30 16 ? * WED
It is set to 'Use Local Time'
Time is correct on the server and on the clients. The task runs at 4:30pm all year as scheduled until DST when clocks are moved back. Then the task runs at 3:30pm every time until DST ends.
Is there a fix for this?
-
On 11/6/2018 at 7:21 AM, jimmy09 said:
Is there any way to force Youtube restricted mode in EES v7?
It looks like other firewalls and web filtering solutions do this;
https://kb.k12usa.com/Knowledgebase/YouTube-Restricted-Mode
Thanks!
You can achieve this using DNS, if that's an option in your environment. It is detailed here: https://support.google.com/a/answer/6214622?hl=en
-
On 10/25/2018 at 6:30 AM, Marc.H said:
other question, I saw on a different post that in the version ESMC 7 unresolved threats would be resolved automatically or could be via a rules but i don't find how ...
I'm interested in this information, as well. Can anyone clarify?
-
9 hours ago, MartinK said:
New AGENTS should be automatically backuping their databases and restoring them once main database is detected as corrupted. Could you please verify that "broken" AGENT actually created backup:
Based on issues noted in these forums, I'm holding off upgrading to v7.5 at least until the first service release is available.
-
1 hour ago, brandobot said:
Case #103515. It's been open for nearly a year. I've been told "our new version will fix this" at least 2-3 times. I've wasted countless hours installing their beta versions that they promised would fix the issue.
Our current workaround is to uninstall and reinstall as well. Do you have a good way of determining which Macs are losing connection to the ESET console?
Are you using Jamf? How long have you been experiencing this issue? As far as I can tell, half of our Mac population (~350) already lost its' connection in the past 1.5 weeks since we upgraded to v7 agent.
Thanks for the info.
We had a case (#39682) for this issue, opened 05/31/2017. I was also told it was resolved in this latest release. They didn't want to wait for me to upgrade and test, so they closed the case on 08/22/2018. I'll loop back with the support engineer and see where it goes. I spent countless hours testing beta agents, as well.
Unfortunately, we don't have a good way to find unmanaged Macs (or PCs for that matter). I occasionally run agent install tasks on unmanaged clients in the ERA console. If they return a successful install but still show unmanaged, it's a good indication the agent is broken again. We don't have JAMF. I use ARD to run the agent uninstall script, then re-run the agent install task via ERA. It's very tedious.
I'll let you know if I hear back from support. Good luck!
-
That's disappointing. We had the same issue with Mac agents, reportedly caused by 'unclean' shutdown. Only fix was to remove the agent via ARD and reinstall.
We were also told by support that this was fixed in the latest version. However, due to multiple and various issues noted here in the forums, I have not been in a hurry to "upgrade".
Do you have an existing support case for this? If you don't mind providing it I can refer it to our support folks.
Agent upgrade task
in ESET PROTECT On-prem (Remote Management)
Posted
I am no doubt missing the obvious, but...
I'd like to create a task to upgrade older agents to the latest version and have it available to run at will and/or assign to a dynamic group. However, I've run into the following hurdles:
How can I target clients with old agents, without having to manually select them and create an upgrade task each time, given the above?