"security product is out of date" notifications

[ShaneDT 13]

So this morning I'm receiving lots of emails from my customers all asking about a new prompt in ESET reporting that their security product is out of date.

"Your current security product is going to reach end of life on 2023-11-30"

Most of these computers are all on 9.0.nnnn.

So first question, what happened to ESET supposed to be able to finally do automatic application updates from v9?

Secondly, how can I disable this prompt so I don't inadvertently have customer clicking on this and making a right royal mess of it!?

 

[Marcos 5,071]

Are those endpoints managed by ESET PROTECT ?

[ShaneDT 13]

Yes

[ShaneDT 13]

The other strange and annoying part of this is there is no consistency on which clients are getting these alerts.

For example some computers with 9.0.2032.6 installed are getting this alert, while others aren't, all in the same group on ESET Protect with the exact same policy applied?

Is this some kind of bug in the software? 

I can appreciate maybe generating warning if still running 8 or below, but generating warnings on the client computers for a version that doesn't go end of life for another 12mths just creates headaches for all involved.

[Ryan Dey 6]

12 hours ago, ShaneDT said:

there is no consistency on which clients are getting these alerts.

I'm seeing the same thing... about 30% of the clients are showing the alert, and I haven't found a common thread.  They are spread across 9.0.x versions, network locations, and install dates.

We have decided to go ahead and update the clients to version 10, but we definitely feel like ESET has abused us as a customer.  It's not a good time for us to dedicate the resources with holiday out-of-office staff, year-end close outs, and a SOC2 audit on-going.

[GregA 3]

There are multiple posts about this issue. ESET says they are 'evaluating' changing how these end of life alerts are done. Just FYI, you need to be on ESET version 9.1 or newer to get rid of the alerts unless ESET does something on their end to get rid of the alerts. There is no way for ESET Protect admins to disable the end of life alerts per ESET.

Edited December 6, 2022 by GregA

[Peter Randziak 1,130]

Hello guys,

few moments ago we released a module update to pre-release update channel so far, which will adjust the EoL messages behavior and those will be reported in the management console only in the managed environments.
Thank you for the feedback and use cases provided.

We apologize for the inconvenience caused by this.

Peter

[st3fan 6]

26 minutes ago, Peter Randziak said:

few moments ago we released a module update to pre-release update channel

This is great news. @Peter Randziak please advise when this will reach the regular update channel? Thank you.

[ShaneDT 13]

54 minutes ago, Peter Randziak said:

Hello guys,

few moments ago we released a module update to pre-release update channel so far, which will adjust the EoL messages behavior and those will be reported in the management console only in the managed environments.
Thank you for the feedback and use cases provided.

We apologize for the inconvenience caused by this.

Peter

Great news, good to see ESET listening to their partners/customers and taking action.

This leaves the first part of my post still to be answered. Why do automatic program updates still not work?

The reason in my case for a lot of these alerts is because the only way program updates get installed on 95% of my client computers is when I schedule it and push the updates out from ESET Protect. Again strangely around 5% of my customers computers do auto update, I have around 4 out of 100 computers that have auto updated to 10.0.2034. All computers have the same policies assigned. All computers are similar in operating system and configuration.

It would be good to have automatic program updates work consistently.

An option to enable automatic update to the latest version and latest version minus 1 would also be useful to allow enabling a test set for each new version released.

[st3fan 6]

Good questions from Shane. Also looking forward to getting some answers.

I still find the auto-update process confusing. For example, where can I find out which versions are available as auto-updates? Is this documented somewhere?

A few weeks ago a few of our endpoints updated to 9.1.2060.0 when we manually ran a "check for updates". This was by design according to this comment. And according to this comment, the auto-update for version 9.1.2060.0 was enabled on Nov 1. Is this true? Is this documented somewhere?

What I have seen is that "Check for updates" no longer updates our endpoints to 9.1.2060.0. And the few test PCs that have the auto-update policy setting enforced also don't seem to be getting any more updates.

I really like to the idea of auto-updates as they are less intrusive for our users and they don't require immediate reboots, which is great. However, it does not work consistently in my experience and I wish this was documented and communicated better.

[Marcos 5,071]

Endpoint should update automatically to v9.1.2060. If it doesn't, please check the auto-update policy/policies that are applied to it. You may have an auto-update policy with the setting to stop auto updates at a specific older version in place which would prevent further product updates.

[ShaneDT 13]

Hi Marcos, all my managed computers across all customers have the same policy settings, only difference is the password. As of today, only around 5% have updated, and half a dozen have actually updated to the latest v10 release already. All with the same policy settings assigned. Most of them are still on v9.0 which I manually deployed a while back, any installed since then are still on the version they were installed as.

[Peter Randziak 1,130]

Hello guys,

the module which implements the new EoL messages behavior has been released for general public.

4 hours ago, Peter Randziak said:

will adjust the EoL messages behavior and those will be reported in the management console only in the managed environments.
Thank you for the feedback and use cases provided.

We apologize for the inconvenience caused by this.

Peter

[Peter Randziak 1,130]

When it comes to Auto-updates.

Auto-update to latest 9.1 should be offered / applied, as Marcos mentioned.

When it comes to Auto-updates to version 10, those should not be offered at all, yet.

Peter

[ShaneDT 13]

13 minutes ago, Peter Randziak said:

When it comes to Auto-updates.

Auto-update to latest 9.1 should be offered / applied, as Marcos mentioned.

When it comes to Auto-updates to version 10, those should not be offered at all, yet.

Peter

Hi Peter,

That's not what's happening in my environment.

I don't think any of my 9.0's have updated to 9.1, but I do have 7 computers that have auto updated to 10.0.2034.0. 

I'm right now manually pushing out 9.1.2060.0 to all clients re these EOL alerts.

[Peter Randziak 1,130]

20 minutes ago, ShaneDT said:

Hi Peter,

That's not what's happening in my environment.

I don't think any of my 9.0's have updated to 9.1, but I do have 7 computers that have auto updated to 10.0.2034.0. 

I'm right now manually pushing out 9.1.2060.0 to all clients re these EOL alerts.

Well I would like to check it for sure.

Can you please copy-paste the appropriate log records here so we can check it?

Users using the workstations, where the endpoints upgraded to v.10 do have admin rights? 

So is there a possibility that they upgraded manually, when they saw the notifications?

Peter

[Ryan Dey 6]

Checking my clients, I just discovered something interesting regarding auto-update policies.
The built-in policy that was created when we upgraded the server to 9.0 is enabled and assigned to all devices:

But the client on my computer (9.0.2032 just upgraded to 10.0.2034) is set to not auto-update:

I believe this is due to the order of policy application.  Our custom endpoint policy (which we've been using since version 6) has the auto-update setting disabled.  I'd need to dig through our change logs to see if this is something we chose to do, since I don't remember changing it.   I assumed we were set to auto-update, but we weren't.

//Ryan

Edited December 7, 2022 by Ryan Dey

[st3fan 6]

FYI, I noticed that the default auto-update policy always changes back to "All" after a server reboot. Not sure if this is normal.

 

[Marcos 5,071]

To me it's logical since there's one global auto-update policy that you set up for all machines at one place. However, you can set up individual auto-update policies for particular static or dynamic groups that would supersede the global one.

[MartinK 378]

On 12/8/2022 at 12:58 PM, st3fan said:

FYI, I noticed that the default auto-update policy always changes back to "All" after a server reboot. Not sure if this is normal.

 

Could you please provide more details of, especially:

• what are the changes you are doing on the policy before reboot - i.e. do you just unassigns it from all targets? Or you change target from group "All" to some other?
• what was the initial version of ESET PROTECT you actually deployed? Asking as there might be different behavior based on whether you already had ESET PROTECT deployed when this functionality was introduced (and communicated via specific dialog) or it was enabled to automatically during initial deployment of ESET PROTECT

More details will helps us to check whether this behavior is expected or not. But regardless of that, ESET PROTECT documentation recommends to create "disabling" policy which will overwrite the global one to be sure auto-updates are disabled or re-configured on specific devices (https://support.eset.com/en/kb8147-opt-out-from-auto-updates-in-eset-protect-and-eset-protect-cloud)

[st3fan 6]

On 12/12/2022 at 6:08 PM, MartinK said:

Could you please provide more details of, especially:

• what are the changes you are doing on the policy before reboot - i.e. do you just unassigns it from all targets? Or you change target from group "All" to some other?
• what was the initial version of ESET PROTECT you actually deployed? Asking as there might be different behavior based on whether you already had ESET PROTECT deployed when this functionality was introduced (and communicated via specific dialog) or it was enabled to automatically during initial deployment of ESET PROTECT

More details will helps us to check whether this behavior is expected or not. But regardless of that, ESET PROTECT documentation recommends to create "disabling" policy which will overwrite the global one to be sure auto-updates are disabled or re-configured on specific devices (https://support.eset.com/en/kb8147-opt-out-from-auto-updates-in-eset-protect-and-eset-protect-cloud)

I click on "Change Assignments", I remove "All" and I click "Finish". Afterwards I reboot the server. Immediately after the reboot "All" is back.

We have been using ESET for so long... we started with ERA many years ago and then migrated to PROTECT when it became available. Current version is 9.0.1144.0.

I created a custom policy (as per the KB article) a while ago. I was just concerned when I noticed that the default disable auto-update policy always reverts back to defaults. We don't enforce the custom disable auto-update policy (so that we can enforce a custom "enable auto-update" policy to certain, selected endpoints). As long as the custom disable auto-update policy still supersedes the default one, I'm happy.

[ShaneDT 13]

On 12/7/2022 at 11:59 PM, Peter Randziak said:

Well I would like to check it for sure.

Can you please copy-paste the appropriate log records here so we can check it?

Users using the workstations, where the endpoints upgraded to v.10 do have admin rights? 

So is there a possibility that they upgraded manually, when they saw the notifications?

Peter

Sorry have been busy end of year and trying to go on leave, and customers the same.

Yes these particular computers the users would have local admin rights, but can you actually manually download and run the installer if the client is managed and password protected? If you can wouldn't this break activation?

I've never tried it so don't know. If it's possible then this might explain it, but unlikely as they would have contacted me before doing anything like this.

[ShaneDT 13]

Update. So it looks like the users did manually download and install the v10 software. 

I guess they've seen the prompt about the installed version being end of life and taken the initiative... 

I'm surprised though being these are managed clients and password protected that they were able to do this?

Is there a way we can block this from happening?

[Marcos 5,071]

8 hours ago, ShaneDT said:

I'm surprised though being these are managed clients and password protected that they were able to do this?

Is there a way we can block this from happening?

Unfortunately this cannot be prevented once users have admin rights.

If installation / upgrade was password protected, administrators would have to enter the password each time they send a software install task. Needless to say that the password could be different for machines or groups of machines or it could be set by the user himself.

[Tomasz Trynkowski 9]

There's also another reason for why only some of the managed workstations get updated - the reboot issue. Basically, the autoupdate "queues" the update process, but the actual update doesn't seem to take until a system reboot happens. And the automatic update process (unlike a scheduled update from Protect) does not cause a reboot by itself. So, if you have workstations which never get turned off by themselves, they may never get an automatic update until it's force-pushed on them.