st3fan

FYI, the settings I mentioned above are working for us at the moment. Outlook performance is ok using 9.1.2060.0. So to summarise, this is what we have configured. Special settings: Attachment handling optimization: enabled Advanced email client processing: disabled Email to scan: Received email: enabled Sent email: disabled Read email: disabled Modified email: disabled

FYI, the below settings are working for us at the moment. We are still testing on version 9.1.2060.0. Special settings: Attachment handling optimization: enabled Advanced email client processing: disabled Email to scan: Received email: enabled Sent email: disabled Read email: disabled Modified email: disabled How is everyone else doing?

I was unable to start the ESET Service manually. Rebooting the server a second time helped. Yesterday this affected every single server we updated (more than 10). Today I updated three more servers (same image, same OS, same ESET version) and I have not run into this problem so far. What changed?

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.

Hi everyone I am busy testing/installing the latest Windows Updates on Windows Server 2016. After the reboot I noticed that ESET (Server Security 9.0.12013.0) did not start. I am setting this in the Event Viewer. The ekrn service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion. Is anyone else seeing this?

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

I am also experiencing this issue on version 9.1.2060.0. Outlook often hangs and becomes unresponsive if shared mailboxes are connected. I have played around with the settings. This is what I am currently using and this seems to work better, although it is too soon to tell. @Marcos, Support mentioned that the new plugin they are working on has the same effect as disabling the "advanced email client processing" setting. Do you know if this is indeed the case?

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.

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

Disabling the plugin and Outlook email integration is not an option for us unfortunately. This is a key component in our environment.

FYI, regarding the Outlook plugin that is mentioned here (eplgOutlookFix-20221115). Support advised that a new setting/option has been released that does "virtually the same using this plugin". The new setting can be found in Policies here: Settings / Web and Email / Email Client Protection / Special Settings / "Advanced email client processing" Has anyone tested this setting or the plugin yet? Unfortunately I am not seeing a difference in my case. Outlook still hangs and becomes unresponsive if shared mailboxes are connected. I would appreciate if others could share their experiences as we are currently stuck on version 9.0.2046.0 due to these ongoing issues. To make things worse, we are now seeing this intrusive message everywhere (on version 9.0.2046.0) and there does not seem to be a way to hide it, assuming this information is correct. This is so confusing for all users. Why on earth is this displayed for business users.

As others have mentioned on this thread, version 9.1.2160.0 does not work well with Outlook and shared mailboxes. We have tested this for more than a month now. Outlook frequently hangs, becomes unresponsive and sometimes crashes. We had to uninstall and reinstall version 9.0.2046.0, which is nice and responsive in comparison.

I have upgraded from 9.0.2046.0 to 9.1.2060.0 and my Outlook is not as responsive as it used to be. Scanning of received/read/modified emails is enabled in my case. We use shared mailboxes with delegated access (I have 3 shared mailboxes open in Outlook). I have not done a lot of tests yet but I have noticed a difference between the two versions. I will deploy 9.1.2060.0 to a few test users and will report back if they are seeing the same.

I can now confirm that our endpoints did not automatically update to 9.1.2060.0. My colleagues ran a manual "check for updates" on all endpoints that received this update, thinking that this would still prepare version 9.0.2046.0. As we have learned, this has changed very recently and 9.1.2060.0 is now offered instead of 9.0.2046.0.

Thank you for clarifying. I don't understand this process to be honest. I don't understand why we are now getting 9.1.2060.0 (a brand new release). Up until recently, 9.0.2046.0 was offered for 8.1 endpoints, and I assumed this was because ESET deemed this version (9.0.2046.0) to be stable. There were more recent versions available (e.g. 9.1.2057) but none of these versions were offered via "check for updates" - only 9.0.2046.0 was offered. Our local Support advised to either wait for the scheduled daily module update to take place, which should then prepare 9.0.2046.0, or to manually "check for updates". This is exactly what we have done over the last few weeks in order to update our 8.1 endpoints. I would be surprised if my colleagues ran a manual "check for updates" on the endpoints that received 9.1.2060.0 today - but I will check. All we are trying to achieve is to get all endpoints to one consistent version (9.0.2046.0), preferably via auto-updates, so that we can avoid an immediate reboot. But this seems to be getting more and more challenging.

exactly, that's what I am trying to say. up until yesterday or the day before yesterday, a manual check for updates prepared 9.0.2046.0 (that is with the auto-updates setting enabled). Now we get 9.1.2060.0 all of the sudden, which surprised us. Is this expected behaviour?

We have numerous endpoints that are on 8.1.x. Some updated to 9.1.2060.0 today, before I could disable the auto-update setting. On a test PC I did a "Check for updates" and saw the below message in the event log. "An update to version 9.1.2060.0 is prepared and will be applied after computer restart." This only started today. For the last few weeks a "check for updates" updated them to 9.0.2046.0. This only happens on 8.1.x endpoints. Endpoints that are already on 9.x are not affected.

I see this version is already available as a auto/micro-update. We are still in the process of upgrading 8.x to 9.0.2046, just so that we can finally have the same version installed on all endpoints. 9.1.2060 is not even a day old and it is already being pushed out everywhere. @Marcos where is this documented? Nothing is mentioned here about this. This entire process is so frustrating.

Our local ESET Support responded and confirmed they made a mistake. 9.1.2046.0 was removed from the auto-updates list, not 9.0.2046.0. @Marcos, is there a public list somewhere that us admins can refer to in order to find out which ESET versions are currently offered via the auto-update option?

That's a good point. Surely they would have pulled it from the repo too if there were major issues. I'm not sure if I am getting accurate information from our local ESET Support to be honest. Do you immediately reboot your endpoints after you deploy 9.0.2046.0 via task, @FTL? As far as I know, this is one of the drawbacks of this type of deployment, i.e. that a reboot is required. This is why I wanted to look into the auto-update option instead.

Hi everyone We are making use of the auto-update feature in order to upgrade our endpoints from 8.x to 9.0.2046.0. This seems to work quite well. However, there were a few endpoints where it took days, sometimes weeks, before this update appeared, even though the same agent/proxy policies apply. I then opened a ticket with Support as I wanted to understand what was going on. Support informed me on the 19th of August that Head Office apparently removed the 9.0.2046.0 auto-update option. However, our endpoints still receive this update, even after I cleared the proxy cache. We have not had any issues with 9.0.2046.0 so I would like to continue deploying this to all our endpoints but after receiving Support's feedback I am no longer sure what is going on here. Does anyone have any further info on this? Are there any major issues in 9.0.2046.0 that one should be aware of? I have seen the forum posts regarding subsequent versions that caused problems but nothing regarding 9.0.2046.0. Also, please let me know where I could possibly find out if a release is available via auto-update or not and, more importantly, if it has been pulled? All I found was this post here. Is there an overview somewhere that lists most recent releases and clearly shows which of these releases is available via auto-update or not? Thank you.

For anyone else confused by all these options, this might help a bit.

Assuming v9 is in use on all endpoints. Why is there a need for this policy if auto-updates can be disabled here and be paused here? I think I don't quite understand the difference between these settings/options. I would appreciate if you could clarify @Marcos - thank you.

Support figured it out. This setting had to be changed to "never update". Additionally, we've already had the following settings.

I will open a support ticket.