kingoftheworld

Yes, I can confirm this behavior on at least macOS Big Sur devices. I opened a ticket with support and was essentially told that ESET support for Big Sur is not fully available even though their public facing support page says it is fully supported minus the firewall and device control. I was told full support is coming in March with a new version that I hope fixes this. It is rather annoying to have to uninstall ESET to install critical OS patches.

I already have, and they pretty much gave me the option of hiding the GUI entirely or upgrading. I just hope the feedback received makes the decision makers behind these decisions re-think this next time.

This is not accurate. The current notification causes a Windows notification and alert sound upon logging into the machine which draws attention to the GUI.

You are assuming that I plan to deploy 21H1 in the near future. The users in my environment will actually never have access to 21H1.

At least for me, the issue with the notification is causing me to receive un-necessary support tickets from my end-users thinking there is an issue with their computer when in fact there is nothing wrong.

That's not the point. This was not well executed by ESET. This message should have been displayed to the admins in the console and not on all endpoints without the ability to control it.

On a similar note, can I ask why there isn't a way to hide this message on the client via policy? There is an option to disable every other alert message on the client but this one. In my environment, the end-users need to not worry about the agent/product being out of date as that is handled by IT. We are actively working on it and don't need users calling and telling us.

I seriously don't understand why these settings cannot be the same between platforms. There are those that prefer to use the simple password protect settings mechanism on macOS.

I know many are reporting widespread issues, but I have seen this exact error message when the HDD fills up.

I am interested in getting a copy! Is this product geared towards file servers, linux desktops, or both? Also, would I need to have ESMC 7 deployed to manage it? We are running 6.5 and planning our upgrade to 7 for later this year.

The way that I have gotten around this is to make a "Shared Permissions" static group. Then, give the permissions to both user groups that need to access the license.

Please include me!

It looks like you provided full access to only a select few Static Groups and the license it probably in the top-level (All) access group which this account doesn't have access to. You will either need to provide access to the static group that the license is at, or move the license to a static group that this account has access to.

Any ETA on a fix for this issue? Yesterday, I experienced this popup no less than five times throughout the day without any interacting with the ESET GUI.

Not necessarily related to ERA, but for the enterprise A/V products Description: Consistent handling of update profiles between Windows and macOSDetail: I would think that two products that are essentially branded the same should operate the same between platforms, ESET Endpoint A/V 6.* for Windows and macOS. When configuring update profiles to pull from an internal mirror on a PC, you essentially have to go in an update the the task for the update to use your internal mirror first, then use ESET's servers second. However, when you manually trigger the update now using the GUI, this fails at doesn't know to use a secondary profile and only uses the primary. In my mind, the macOS behavior is ideal method where you specify a primary and secondary server. It attempts the first, if it doesn't connect, it fails to the second. P.S. I am not interested in using the caching proxy that has been recommended me more times than I can remember. I am confused on why these products from a administrative standpoint are so very different. Another example is the ability to password protect the settings on Windows, but a horrible method of using groups/accounts on macOS. I simply want to apply a password before dropping into the settings panel. I am forced to mark all of the settings as Forced on my macOS policy to prevent users from modifying them which is a real pain if I have to have a technician troubleshoot something with an end-user.

Any timeframe or beta for v7?

@pps @MichalJ It is currently available under the sync task. See screenshot below

This is already an option in the task settings. I believe you can choose the behavior.

+1 for this request. Or some other way of accomplishing this

I would just do this ASAP well ahead of when you plan to make the change. Any clients that are not on or otherwise don't receive this policy will require manually changing them.

Yes, please sign me up for any beta releases. I am ready to get it installed on my dev server.

When can we expect v7? It has been promised for far too long, and we have many existing problems that are promised to be fixed in this version. I was originally told we should have it available Q1 of 2018, but it doesn't appear to be the case. Should we expect some type of release to be around the RSA conference, or are we still a long ways out?

I have experienced this on my mac as well. I believe I have the stock update policies set as well.

I can confirm that I have a server that is behaving in the same manner. Configured exactly the same as three others, and only one has the alert.

That is correct. However, if you click Download from the menu bar on the left side, then click on "Show Additional Download options", there are different binaries that do not include the Fusioncore PUA. I guess they probably receive some type of revenue for having the bundled one on their home page. You will notice the one on the homepage has "bundled" in the filename as well.