Brambb

Okidoki; But that policy changed recently? Cause I am quite sure this was not the case earlier? But its OK. So now we learned to look at our install task names better

Hi, Is this something new which is supported by Endpoint Security [10.1.2046.0]? Cause in the past this could not be done and returned an error 'This product version is not intended for server operating systems.' Now due to a 'brain fart' (I can blame a collogue) something happened that we launched the wrong install job from our PROTECT server which plain installs 'The latest EES from here: https://download.eset.com/com/eset/apps/business/ees/windows/latest/ees_nt64.msi' to my surprise now a mix of 2012R2, 2016 and 2019 (RDS) servers are all protected by ENDPOINT SECURITY. ..Is this possible by design? Cause in HELP/KB files I cant find SERVER SUPPORT for EES. Does the documentation lack or this shouldnt have been made possible? [I have no problems ATM - I am running uninstalls and launching the correct TASK instead but just for my information]

That make's sense cause not every endpoint behaved like this. I remember those 'hibernate' shutdown madness in Win8, I though W10 changed the shutdown behavior to be a proper shutdown again, at least in my experience, but there may be a lot of installations where it is not behaving like that.. Thanks for the suggestion, will definitively look into this!

This is only with the upcoming (u)PCU? Cause with (ESMC 7.2) normal software install task (without required reboot turned on) I get a reboot required alert on my client: But this probably just removes v7.3.2032 and installs 2036 and then always requires a reboot? or? Also just to be clear: The 'warm reboot' is actually a thing? So a shutdown + cold start does not trigger the update/upgrade process ESET required the reboot for?

+1 ESET been telling for years PCU is a thing but actually they never release such update? Does this not suppose to be a thing for minor upgrades like this? And the the reboot warning is fine if this is actually needed but agreed as said above, for minor upgrades this should not be a thing? Also I notice that the reboot also needs to be a 'warm reboot', we have a lot of clients who TURN OFF and next day TURN ON (shutdown, cold start) but this does NOT trigger ESET to do the module update or whatever the reboot is required for. Users actually need to do the 'warm reboot' for the message to cleared and update to be fully complete. I actually still have a few remote computers/users who still need to do a active reboot of 7.2 which was pushed in November but realtime protections is at least working.. Now we just recently pushed 7.3.2032 which 90% does reboot but we still see a few endpoints with a reboot warning and now due this this upgrade the realtime module is not active.. which is very painful for a AV software. Can ESET also look into this? Or should ESET fully upgrade when you also let the user shutdown and do cold start next day? I can most likely reproduce this with ease..