PCS70

Indeed it's confusing too. as the message is only shown at the client side AV and is not visible in the web console of EPM. They did update some troubleshooting sections on their help sections, so probably this fix is official now, although I can not find it there now anymore. It didn't hurt any functionality though, but was annoying for users. Glad you got it solved too.

This might help too for correctly configuring the proxy on ESET EPM VM, especially if you upgraded from older versions to newer versions using the web console. The proxy replaces the old mirror update solution and so after upgrade or when enabled it requires some additional configuration too. Maybe @Marcos can confirm this kb still applicable to correct proxy configuration in EPM 9 VA? [KB7848] Write a ProxyMatch expression for configuration of Apache HTTP Proxy with ESET PROTECT

Even if you don't use the provided EPM proxy server on the clients, the offered fix or work around needs to be applied on the EPM VM in order to get rid of the notices at the client side. They still refer here to Push Notification Error on the Web Console, while the notice strictly is shown on the AV client side and not even registered in the EPM web console, but yet is to be solved by adjusting the proxy config on the EPM VM. The proxy solution on the EPM VM is also used to cache and prepare all-in-one installer packages and for AV definition updates for all internally connected (LAN) clients. While having proxy on the ESET Protect Management VM enabled through policies on containers you can still configure (certain or all) external clients to not use the EPM proxy, but externally they will fallback to ESET's servers anyway as they are not connected through local network to EPM proxy (except while VPN connected to company network) as these ports should stay closed for direct access through the internet at all times.

Just like to add that the push notification error doesn't show in EPM Web Console at all, but at the client AV application only. You can have all clients show in perfect state in Web Console, but locally their AV application reports this error. And in regard to using EPM VA the notification only signals on internal clients that are using an incomplete or incorrect configured proxy after (auto-)upgrade of EPM VA to 9 version. I can remember I had disabled proxy use for a while already, as VA disk was getting too full, but after the automatic upgrade of VA it seems to be enabled again. Also here I would prefer the upgrade attention instead of just auto upgrading the appliance. This would go against your own advise in help center of preferably deploying new VM to replace old one, although I like the in-place VA upgrade functionality through component upgrade or later in the help menu. That link for (correct) configuration of the new apache proxy (although exists since version 7 if I remember correctly) will be useful to solve the problem for EPM VA internally connected clients. Thank you. Or just deploy a new policy that will disable the use of EPM VA internal proxy server again.

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.

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

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.