Stop Auto-Updates

[T3chGuy007 16]

Hello.  I do not want my PCs to automatically update to the latest version of Endpoint Security when it's released, so I created a new policy to disable the auto-update feature per the article below.  I assigned this policy to my 'All' OU and then I unassigned the built-in auto update policy from the same OU.  However, I upgraded ESET Server Security on my ESET PROTECT server and I discovered the built-in auto update policy was reassigned to my 'All' OU again.  How do I prevent that built-in policy from reapplying to all of my devices after an upgrade?  I want to handle software updates manually and not have it managed by ESET PROTECT.  I cannot delete the built-in policy, but it seems unassigning only works until the server is rebooted or upgraded.

https://support.eset.com/en/kb8147-opt-out-from-auto-updates-in-eset-protect-and-eset-protect-cloud

[Marcos 5,074]

I would check the policies for "All" group, there should be the policy for auto updates so simply select it and remove it:

Since the "All" group is the topmost one, the policies cannot not be inherited from upper groups.

[T3chGuy007 16]

I checked the policies assigned to the 'All' OU and the only two that are linked are a management agent one and the one that I created to disable auto updates.  What happened is that I previously had the built-in auto update policy (which enables auto updates) removed from the 'All' OU, but after I upgraded Server Security on my ESET PROTECT server, that automatic update policy was linked again to my 'All' OU.  It's like after a server reboot or a server upgrade it re-enables the automatic update policy.

[T3chGuy007 16]

Out of curiosity, I verified that the only policies that were applied to the 'All' OU were my agent sync policy and my auto update policy, which disables automatic updates.  I then rebooted the server and when I checked the 'All' OU after a reboot, the built-in auto update policy was once again enabled on the 'All' OU and set to first.  So it appears that if you remove the built-in auto update policy and reboot the server, it gets added back.  I'm hoping this can be corrected in the near future or provide a way to prevent this behavior.

Edited December 16, 2021 by T3chGuy007

[kapela86 10]

I can confirm that after server restart this policy is reset to default, eg. "All" group is added automatically.

[Marcos 5,074]

Ok, it's a locked policy so it cannot be deleted. However, it's applied first so a custom policy disabling auto-updates would override it.

[kapela86 10]

I'm not 100% sure but it's not overridden. I need to do more testing, but right now I have this in my main policy config

Here's a screen from applied policy on one pc

And autoupdate is working on it because there's pending update

If it was really downloaded at 21:55 then something is definitely wrong because I unassigned autoupdate policy earlier than that, and I restarted server today for testing.

Right now 27 out of 100 PC we have have this update pending and two have it installed because users shut them down yesterday and turned on today. Is there some random schedule to install these autoupdates?

 

Edited December 17, 2021 by kapela86

[Marcos 5,074]

29 minutes ago, kapela86 said:

And autoupdate is working on it because there's pending update

If it was really downloaded at 21:55 then something is definitely wrong because I unassigned autoupdate policy earlier than that, and I restarted server today for testing.

That's because the setting is not applied for security and stability updates. V9.0.2032.6/7 is a security update.

https://help.eset.com/ees/9/en-US/security_stability_updates.html

[T3chGuy007 16]

So how do we prevent the built-in auto update policy from re-applying to the "All" OU after a server reboot?  If it's true that any policy applied after it to disable updates will overwrite it, why can't we configure the built-in policy to never apply to the "All" OU?  It seems odd to have a policy to enable auto updates only to have a policy to disable auto updates.  To me, it would make more sense to have one policy to disable auto updates and never have to worry about having the built-in policy re-apply after a reboot.

[Marcos 5,074]

Keeping the product up to date ensure maximum protection and prevents issues that were present in older versions and have already been fixed. As of ESET PROTECT v9, we use an opt-out auto-update system, ie. auto updates are enabled by default and those who need to disable them for whatever reason have an option to do so by creating a policy that disables auto updates.

[T3chGuy007 16]

I understand keeping ESET products up-to-date is very important, but why not leave it up to the customers who pay for your products to decide when to update their devices?  I always keep my products patched, but I decide when to apply them and schedule reboots.  I don't like it that you apply the updates without admin approval and when I login to ESET PROTECT, I find red alerts all of my devices.  What if you push out an update and two hours later, you find it causes a major problem?  You also said that you have an opt out policy, but I don't think you do.  If you did, you would allow customers to permanently disable auto updates and manage them on their own.  If some customers want to keep your auto update policy enabled, that's fine, but you should allow customers the choice to do enable it or keep it disabled without having to worry about it re-enabling.

[Tom Wright 0]

I agree with Techguy007, I must confess this seems like a very odd thing to introduce. I would like to be able to "choose" what it does. The only choice I seem to have in this decision for OUR infrastructure  is I can either wait for this to automatically turn on or turn it on now. If the above is true and you can't disable this built in rule that's really not helpful. 

A key question I have on this subject is does the rule trigger an automated reboot after an update is installed ? If it does this really presents a serious issue for some of my servers. I have several key products that if they where to reboot in our 24/7 operation would cause me some serious headaches and possible data loss. 

I think you should really make this an option we can choose to keep off and by that I mean not forcing an option that we have to disable. I would be happy to click a conformation box every month advising me to add a policy for auto updates but would like to retain the control.

Am I also correct in assuming that when an update happens some features are disabled until the update is fully completed depending on the update? I would rather have a few days old version of the software while I organise a restart with it all operational than have some features go offline until a restart.

 

[Marcos 5,074]

4 hours ago, Tom Wright said:

A key question I have on this subject is does the rule trigger an automated reboot after an update is installed ?

No. The program updates (also referred to as uPCU) are downloaded and installed only after the machine has been restarted so the upgrade is seamless.

4 hours ago, Tom Wright said:

Am I also correct in assuming that when an update happens some features are disabled until the update is fully completed depending on the update? I would rather have a few days old version of the software while I organise a restart with it all operational than have some features go offline until a restart.

No. Program updates are installed when the system starts next time. All features are fully functional and are not temporarily inactive while a restart is pending.

 

 

[PCS70 0]

4 hours ago, Marcos said:

No. The program updates (also referred to as uPCU) are downloaded and installed only after the machine has been restarted so the upgrade is seamless.

No. Program updates are installed when the system starts next time. All features are fully functional and are not temporarily inactive while a restart is pending.

 

The problem is that in the meantime all automagically updated clients are shown red in EPM console.

Also most users won't even pay attention to their upgraded AV-scanner and the reboot notice for which you need to open the application first, but they do complain about Push server notification error popups caused by new cloud protection functionality not available in their ESET Protect (non-cloud) server license.

At least make sure that when installed through task the option forced reboot is available. Yes, you can do that afterwards too, but it's messy because the EPM view is all red and even stays red a while after reboot depending on (re)connection interval, so you get lost easily.

Normally I don't even notify users when a new version will be installed (preferable done out of office hours) and by planning remote devices are scheduled late in the evening so first thing they do in the next morning is update to new version and reboot.

Some might not even shutdown their devices but put it in sleep mode, so the upgrade will not apply to their machines this way.
 

Edited December 17, 2021 by PCS70

[Tom Wright 0]

5 hours ago, Marcos said:

No. The program updates (also referred to as uPCU) are downloaded and installed only after the machine has been restarted so the upgrade is seamless.

No. Program updates are installed when the system starts next time. All features are fully functional and are not temporarily inactive while a restart is pending.

 

 

Marcos, Thank you for making that clear and while I'm still uneasy about certain options being implemented this makes it bit easier to manage.

[Marcos 5,074]

We understand that not all users want to update to the latest version automatically, that's also why we provide the option to turn off automatic program updates with the exception for security and stability updates. You can even specify the last version that you want to keep installed:

I'd like to emphasize that program updates (uPCU) are not released immediately with new versions of Endpoint. There is at least 1 month delay before the release and distribution to users. If a non-trivial issue is reported during the period, we fix it, prepare and test a new build which is then released and the 1-month delay period starts to count down again. Only then we start to distribute the new version automatically and gradually to users.

[Marcos 5,074]

11 hours ago, PCS70 said:

The problem is that in the meantime all automagically updated clients are shown red in EPM console.

Just to make sure, do you mean Endpoint v9 or v8.0 or v8.1 clients?

11 hours ago, PCS70 said:

Also most users won't even pay attention to their upgraded AV-scanner and the reboot notice for which you need to open the application first, but they do complain about Push server notification error popups caused by new cloud protection functionality not available in their ESET Protect (non-cloud) server license.

Does the problem still persist? We've made some improvements in a module update which resolved this issue in cases when VPN was used. Should the problem continue, we'd like to check logs from such machine - enable advanced direct cloud logging under Tools -> Diagnostics in the update setup and wait until the warning appears. Then disable logging, collect logs with ESET Log Collector and provide the generated archive with information about times when changes in network occurred (e.g. when the user connected to or disconnected from VPN) for perusal. Please open a new topic for this issue then.

11 hours ago, PCS70 said:

At least make sure that when installed through task the option forced reboot is available. Yes, you can do that afterwards too, but it's messy because the EPM view is all red and even stays red a while after reboot depending on (re)connection interval, so you get lost easily.

Normally I don't even notify users when a new version will be installed (preferable done out of office hours) and by planning remote devices are scheduled late in the evening so first thing they do in the next morning is update to new version and reboot.

Some might not even shutdown their devices but put it in sleep mode, so the upgrade will not apply to their machines this way.

How would you like this to behave? Ie. when a program update has been downloaded and is prepared for installation after a reboot, would you prefer a pop-up window where the user could choose to reboot the machine immediately or postpone the reboot by a specified time?

[Marcos 5,074]

On 12/16/2021 at 8:07 PM, T3chGuy007 said:

However, I upgraded ESET Server Security on my ESET PROTECT server and I discovered the built-in auto update policy was reassigned to my 'All' OU again.

I stand corrected, this is considered by developers as a bug so you can expect this to be fixed in the next version of ESET PROTECT.

[T3chGuy007 16]

That's good to hear @Marcos.  I found it strange that even after removing it from the 'All' OU, it would go back to assigned to that OU after a reboot. 

[PCS70 0]

On 12/18/2021 at 11:09 AM, Marcos said:

How would you like this to behave? Ie. when a program update has been downloaded and is prepared for installation after a reboot, would you prefer a pop-up window where the user could choose to reboot the machine immediately or postpone the reboot by a specified time?

First of all that bug of locked policy reactivation after reboot of VA should be fixed, but I can live with another applied policy that disables it again. Just a few non connecting clients are still affected and have auto-upgrade enabled. I would call it an upgrade as it's literally upgrading to a newer release.

Now we come to the part of auto-upgrading to latest versions without option to set minimum and maximum versions. In the locked policy you cannot adjust any of that, but manually configuring the auto-upgrade policy there is a version control option. I would like to see that if upgrade is required because of discontinuation of that version number (like 7) it should upgrade to the latest stable 8 version and not 9 e.g. including forced reboot (including the -g flag option).

Anyway like I said admins want to control Windows updates and upgrades because they know users don't like popups or even spend time in running any update required. So most busy users will click away that message and not reboot after work, not even sign out and run to their car to get home. Some don't shut down or even sign out and keep all their windows open, because in the evening they need to finish something using remote desktop. What would be useful is an easy view or filter option where you can see which devices don't have a user signed in (and inverse of that of course). Also while upgrading to a newer release always show all applicable releases within the version control mainframe. Especially in regard to Max OS X release the version selection could be smarter, it should not offer versions not compatible but it could or even should notify that there is a new OS X build available for that Mac device and model. 

I don't know how well new releases are tested in diverse environments with legacy applications like Exchange 2010 still running, but since version 9.0 of ESET EPM VA I do experience more problems with the latest releases and have had to revert back to the previous version. The same for the push notification error since version 9.0.2032.2 and above (.6 still gives the same problem). The error simply does not appear with version 9.0.2032.0. What I do notice that it seems to be restricted to internal domain clients, so external clients (who do not use the VA proxy). Also split DNS is used so internal clients can use the same server name for communication as external clients. I didn't try the workaround suggested in other post on this forum, as it's not an official confirmed fix and I think it's related to DNS or ESET Management Agent traffic that is being redirected to EPM VA but can not access due to firewall on Centos or required NAT rule in router to VA appliance. These are all non-cloud licenses with on-premises EPM VA's giving push notification errors on the internal LAN clients. Remarkable fact, those error don't show in EPM, so as administrator you don't see it until you experience it on your on workstation or hear it from users.

I would not like to see problems coming to ESET like with McAfee that managed to break the boot of millions of systems by an auto-upgrade failure. There also might be certain Windows updates in queue for installation on next boot time, which could interfere with ESET auto-upgrade functionality. These 3 systems give the reboot required warning, but are shutdown or maybe even at sleep, I can't tell for sure but will have to keep my eye on them now.



For that reason most administrators using EPM VA like to manage the version upgrades themselves by first testing newer version on a few workstations before upgrading all the rest.

In regard to the push notification error I will follow the other thread and test the VA workaround.

Sorry for the long post.

Kindest regards,
Peter

 

[PCS70 0]

Follow up. Upgrade doesn't seem to be applied yet, reboot warning is still there, so I will now have to ask this user if he did put his workstation to sleep yesterday and check the reboot required message in ESET Antivirus application.





Today I spoke to this user already, but he didn't say anything about this hidden notification.

Our company policy is that we upgrade to newer release (not necessary latest release) with forced reboots after 23:00 on all devices that are still on, signed in or not. So the only thing a user has to do is to leave their device on to have it upgraded to newer release. In the meantime it's a perfect window of opportunity to install Windows updates thereafter too. Decent planning, testing and preparation is half the job in ICT.