GDI

@Marcos Thanks for the information. I'm looking for "Date Created", not "Last Used". We have a cutoff date to turn "learning mode" off. When that date comes, we want to see when the last rule was created. If learning mode is still creating recent rules, then we need to evaluate if we've missed some rules before we switch to "automatic" mode. We are trying to avoid breaking stuff once the firewall goes fully live.

I'm not sure if this is the right forum. We use ESET Protect but this is regarding the firewall on ESET Servers. We are enabling the firewall in learning mode on a couple new servers and I have two questions: 1. I see there is a way to see when a rule that has been created by learning mode was last used. But, is there a way to tell when the rule was actually created? Before we switch from learning to automatic, we want to see if any new rules were recently created. 2. Say a server needs a reinstall, is the only way to restore the rules on the new server is by doing a config export on the old server and an import on the new server? Thanks!

Thanks for the info! Looks like it was probably my fault. I was testing some deployments and it looks like there was a previous GPO to disabled some of the features. I'm assuming it was a left over due to a conflict with our previous AV. All is good now!

We are noticing that Windows built in "App & Browser Control" seems to be turned off by upon a fresh Windows install. We've debated enabling it via GPO. But, my question is, do they (or should they) be enabled if ESET is installed? Or does ESET basically do the same that smartscreen for app & files and Edge would do? Is there any potential for conflicts if "App & Browser Control" is enable along with having ESET installed?

@Peter Randziak Is there any update for this? We are using Protect Cloud and this has been going on for at least 5 days. Should we be logging support tickets for this? I'm also seeing no indication of this issue at https://status.eset.com/.

@Marcos Disregard. I just noticed the post that @Peter Randziak acknowledges that this is a known issue.

@Marcos Is this a known service issue? We've been having the same issue the past several days.

Have I posted in the wrong forum for this question?

Disregard my last post. Looks to be a local problem.

Starting to see this again today. Anyone else?

We are adding some iOS devices to our Protect Cloud instance. From what I understand, there isn't an ESET "App" for iOS and adding it into ESET gives very basic MDM functionality, like locking, factory reset, and some policies. What is interesting, under Dashboard > Antivirus Detections > Last Scan, it shows the iOS devices as "Never Scanned". Is this right? I thought iOS devices don't have scanning functionality or have I missed something? If they don't have scanning functionality, is there a way to exclude them from the "Never Scanned" stats?

I'm seeing a few systems where rebooting makes the error go away. I'm assuming once it is fully resolved, a reboot won't be necessary and it'll clear itself out on the next check-in with the ESET servers. Correct?

Thank you for the info! Regarding the info I quoted above, I'm still a bit confused. I copied our current ESET installation to a test server and ran the all-in-one installer. Once the installer opened, it had an option to install ESET Bridge, so I went ahead and tried it out and it did in fact uninstall the Apache HTTP Proxy. I confirmed this because before I started the installer, we had a "ApachHttpProxy" service. After the all-in-one installer ran and I restarted the server, the "ApachHttpProxy" service was no longer there and the "ESET Bridge" service was installed.

Maybe I'm being dense, but I'm not quite understanding the migration instructions from Apache HTTP Proxy to ESET Bridge. We are using Protect On-Prem on Windows Server 2019. I've read the instructions at https://help.eset.com/ebe/1/en-US/migrate_from_http_proxy.html and have the following questions: 1. First, the warning says "Do not install ESET Bridge on the computer running Apache HTTP Proxy" then it says that if I run the all-in-one installer, it'll uninstall Apache HTTP proxy and install ESET Bridge. Seems like those instructions are contradictory. Should I run the all-in-one installer on the ESET protect server to replace Apache HTTP Proxy with ESET bridge? 2. Step 2 says to configure the ESET Bridge Policy, but the "Install ESET Bridge" instructions says it creates the default HTTP Proxy Usage policies. So, which one is it? Do I create new policies or does the ESET Bridge installation create the policies? Thanks!

We are still having this issue when there is an internet outage. We had one last night and several of our servers gave the error but could not be restarted since it was during business hours. I was able to get the logs of one server while the error was showing, then restarted it and the notification went away.

Ok, so at this point it sounds like we can release 9.1.2051.0 as the issue has been resolved in the module (obviously as long as all systems have picked up the 2011.5 configuration module)

For those of us who deploy via ESET Protect, and those of us who are little less experienced with ESET, does that mean we should expect a newer version (higher than 9.1.2051.0) to be available for deployment from ESET Protect at some point next week? We'd prefer to stay on 9.0.2046.0 and wait for a full release rather than install a pre-release.

Thanks for the response. Just as an update, we did revert back to 9.0.2046.0 and we had no shutdowns after the scan last night. Should I expect a response here in the form or on my support ticket?

Already done.

I just noticed, I made a very big mistake in the title of this thread. The workstations are shutting down, not rebooting. Is there a way to correct the title to not cause confusion?

If it helps at all, this is almost exactly the same issue:

Not that I'm aware of. If there was, it didn't report it. The ESET Protect console did not report anything for any of the workstations.

I did open a support ticket for this but posting to see if anyone else is experiencing the same issue. We manage all of our workstations with ESET Protect. We deployed 9.1.2051.0 yesterday. We have a policy setup to run a nightly scheduled scan with "No Action" after it's complete. We observed every single workstation reboot (during work hours) after the scan was complete. I was actually logged into a system when it happened. Every single workstation had an Event 1074 in the Windows event logs stating that C:\Program Files\ESET\ESET Security\ekrn.exe initiated a shutdown. I know we could probably just disable the nightly scan but can't due to compliance reasons. We downgraded to 9.0.2046.0 on all systems. But, anyone else experiencing this?

ESET Endpoint Security 9.0.2046.0 ESET Server Security 9.0.12013.0

Unfortunately, in our area, we have frequent internet outages. After the internet comes up, our ESET Protect console reports several (not all) systems will show a "The ESET Push Notification Service servers cannot be reached" alert. This will stay up until reboot. After reboot, all is fine. This issue happens on Windows 10 workstations and Server 2019 servers. Our ESET protect is hosted on Server 2019 and we do not use a proxy. The workstations isn't a big deal as we can reboot those during the day. But, some of the servers it happens on, we cannot reboot the servers until the weekend as they are critical. Is there a way I can remotely restart the ESET service on these systems, or do something that fixes the issue, without rebooting the systems?