j-gray

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: Server Task for 'Agent Deployment' requires that Target is specified. For Target, it will not allow me to assign to a Dynamic Group, nor will it allow selection of any clients within a Dynamic Group (the option/checkbox is grayed out). Available filter options for Target do not include options for Agent version or other method to target clients needing agent update. Column for Agent version in the 'Select Target' window are not present, so cannot sort by version to find older. How can I target clients with old agents, without having to manually select them and create an upgrade task each time, given the above?

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

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

You will need an RD Sensor on each and every subnet. Is this the case in your environment?

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

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.

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

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?

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

I'm interested in this information, as well. Can anyone clarify?

Based on issues noted in these forums, I'm holding off upgrading to v7.5 at least until the first service release is available.

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.