cpetry

Yeah, I have three known network profiles named like this so I can look at the ESET Endpoint and know how it's identifying the known network -- All with catch-all subnets for the trusted addresses: DNS Suffix - domain.local Wireless SSID - domain.local Network Authentication - domain.local If the Network Authenticator had redundancy I'd just use that and ditch the others. I have a network of 1,650 endpoints so there's no way I want a client to randomly forget the known network / trusted zones. Since you did something similar I'm sure this works. If this VMs start picking up the known network I'll be happy. I just didn't want to list a known network for each DNS server. I have over 16 sites. I'd hate to maintain more than the three "known networks". Yeah, they need to fix this bug. Ridiculous...

Thanks, I'll give that a shot. I have a test VM building right now (Win7 VM). Do you know how long the authenticator can be down or unavailable before the clients don't associate the network with the known network? It would be nice if this network authenticator had a clustering feature. I wonder if I can setup a Windows cluster, and install it on both clustered VMs to provide redundancy? Then point the ERA policy network authentication "host" property to the name of the cluster. I'd hate for the authenticator to go down for any reason and then have my clients lose their known network / trusted zone config. I think for now, I'll have three known network setups for the same thing, using different identification types for the same network. One for my domain.local DNS suffix, one for my wireless SSID, and one that has the network authenticator setup with nothing specifying. So for the few/select systems where the DNS suffix isn't working, the authenticator should pickup for. No idea if that will work but right now I have a small test bed of 60 endpoints for ERA 6 with Endpoint Security 6. So three known networks for my network all with catch-all subnets for the trusted addresses: DNS Suffix - domain.local Wireless SSID - domain.local Network Authentication - domain.local

I opened a ticket about that app earlier. I only confirmed it would install on Windows 2012 R2. So I hope it works with ERA 6.X. So when you set that up did you remove the DNS suffix from the known network identification and just have the network authentication tab filled out? Edit: They would rather tell their customers they are crazy and leave bugs in play. If this product hasn't been debugged by the end of the year I'm going to find something that's less buggy and switch my 1,650+ endpoint network to an alternative. I can always buy metadefender and use ESET as an engine only via their API. I can still get ESETs detection without their BS.

I've uninstalled/reinstalled and removed/re-added the NIC multiple times. This is on a Windows 7 x64 VM. It wouldn't detect the known network I have setup using the DNS suffix on either the E1000 or the VMXNET3. I had to finally give up and install the regular Endpoint AV 6.3.X product. No known network = firewall blocking ping and everything else we need to run on this Win7 VM. Yes, I did verify policy was applying. I haven't had this issue on my physical workstations. The same policy has been working for all of our physical workstations running Windows 7/8/8.1 and 10.

Sorry for the multiple responses after my own.. I just want to document this for others. So the good news is the rules let you select if they are for the trusted zone only. They gave me three rules to use for WMI / svchost so RSOP would work. I'll edit this post tomorrow and share them so others can use them until they make an update to include them as default for the trusted zone. I know I can put my endpoints in learning mode and generate rules but I prefer not to do that. I have no idea what should be allowed on a endpoints installation. If they are infected and it's communicating, I don't need rules generated for a trojan horse. So yeah.. I'd rather create them manually with absolute certainty.

Okay, so uninstalling and reinstalling the Endpoint Security on the user's machine helped. The fan stopped going crazy all the time (it was often, not "during updates") and the RAM usage for ekern.exe went from 250MB to 150MB. We used rip and replace to originally get the newer Endpoint on her system. Uninstalling via ERA 6.3.X didn't work. I had to remove the password and get her to uninstall it manually.

I'm running the latest version of everything. Yes, policies that weren't the firewall rules were still there. My firewall rules were blanked out. After I imported the config from another client my firewall rules all came back. The built-in rules were all blown away and the rules in the config from ESET weren't in the list.

I'd like to install version 6. If ERA 6 and Endpoint 6 didn't have their own issues that clearly trump the issues of version 5. You're making an assumption that version 6 fixed all of those issues.

My point is they can waste time coding "checks" or they can do it right and code it so when you install or upgrade it does just that. What if it's a bug and the "tool" you want just comes back and says the upgrade will fail on everything (as it did for you...)?

Yes, I locally imported the config sent to me via ESET support. So that prevented the ERA from overwriting it I guess because that's exactly how it behaved. My firewall rules were blank for over an hour until I finally gave up and re-improted a config from a working client. I need to get ESET support to send me the rules in non config.xml format. I haven't heard back...

Well today alone I wasn't able to push my policies back to an endpoint. I really hate that. I figured it would be enforced but it didn't seem to be at all. I ended up having to get a co-worker to export his config so I could import it into my endpoint. I imported a config sent by ESET support for some firewall rules (you can't export and import *just* firewall rules, which is also unrealistic). I also couldn't uninstall ESET Endpoint Security from a users machine. So I had to pull the password from the endpoint via policy and then she was able to uninstall it so I could then push it again. Also, it doesn't seem you can download an MSI installer with the config like you could in ERA 5.X. I was able to give that to my service desk. Thankfully, ESET support gave me a year license for rip and replace so I can give that to my service desk for new deployments. I was having way too many issues "upgrading" clients from 5.X to 6.X. After finding this latest issue with the Endpoint Security firewall and RSOP I'm waiting to hear back from support on what actual firewall rules are needed so I can key those into my policy by hand. I would you could selectively export/import rules into the firewall. I'm honestly not sure why you guys are so shocked people don't like ERA 6.X. I mean one guy in another thread said "it's like they fired their best software developer" and it's funny he said that because I literally said the same thing to a co-worker not long ago while driving to lunch with them. So I'm not the only customer who feels this way. Edit: Also, I have to use ERA 5.X to even use that rip and replace because ERA 6.X doesn't support custom packages...

This Apache HTTP proxy works. I just needed two ESET Sales Engineers to spend 2+ hours on a WebEx meeting to get it working. At least it's working now. I can't believe how difficult it was to get it working. The KB article was missing some information. They had to piece together steps from two articles.

The product should work for it's customers. No one should be writing batch files or scripts to automate what ERA should be doing. It's also not like a batch file would work for installing/uninstalling/upgrading endpoints. I've had to boot into SAFE MODE more times than I can count to run ESETUninstaller.exe so I could cleanly remove the endpoint just so I could reinstall the endpoint.

I don't have a special configuration and or policy. I want to resend the policies that are currently supposed to be applied to the endpoint. I imported some botched config sent to me from ESET support that blew away my endpoints firewall rules. I figured, no problem, these settings are policy enforced, I can resend the policies or reboot and the ERA should reinforce/resend the policies I have. Well, no, that didn't happen, and I don't see a way in tasks or the GUI to reinforce/resend policies. So instead, I just had a co-worker export his endpoint configuration, which was received from the ERA to begin with, and I imported that into my endpoint. That worked...

I think that instead of checking to see if a client can be upgraded, it should just work. I don't even recall needing a checker tool for any other product like ERA. If I pushed a software install/uninstall or upgrade task, it should just work. They need to take a play from their rip and replace tool.

I'd imagine you'd use the same licensing information and just don't exceed your total seat count between dev/test and production. That's how I'm handling it between ERA 5.X and ERA 6.X. I'm not happy enough with ERA 6.X to migrate all of my endpoints yet. It's missing too many common sense features. So I'm having to run ERA systems in parallel. I have less than 5% of my clients on 6.X.

I can't get uninstall tasks to work in ERA 6.X, but hey, according to ESET it works and it's been tested. I suggest you call and bother their service desk. I plan on doing that for each bug/issue I find. If they didn't want their service desk overloaded they should have spent more time on QA.

I had to import a configuration made by ESET support to see what firewall rules they created for allowing RSOP. That blew away all of my firewall rules and left me with none. So I figured I'd just resend the policy. I hope it's because I don't know how to do it and not that it can't. I had to get a co-worker to export his endpoints configuration so I could import it back onto my endpoint.

It's a brand new M3800 and yes. Did I not say it wasn't doing this before when we were using ESET AV 5.X? It couldn't possibly be this new software.... No, we are stuffing fabric into the vents.

I thought you meant Windows Updates. We do apply ESET updates as they are available. I've uninstalled ESET Endpoint Security, rebooted the users system, and reinstalled. Let's see how that works out. Their EKERN.EXE was also using 250+ MB of RAM. I was told by support that this is unusual.

They were able to reproduce this issue - case #1431416. Right now the workaround is to create rules but that kind of sucks. If I poke holes in the firewall with rules won't those holes be on any network, trusted/home/work or public? I was hoping automatic mode with a known network / trusted zone config would allow everything. Also, that troubleshooting wizard for the firewall was not showing this as being blocked. That was the first thing I tried...

We don't apply updates everyday though. Just wanted to report that we've seen this issue as well. We weren't having this issue on ESET AV 5.X at all (not even during updates).

We are having this exact same issue since deploying ESET Endpoint Security 6.3.2016.0. We have a test user with a new Dell Latitude M3800 that keeps reporting loud fan noise from her system since installing ESET. We were running a newer version of the ESET AV before without this issue.

I'm having this exact issue with ESET Endpoint Security 6.3.2016.0. I even tried disabling the ESET firewall and it still blocks the Group Policy Results Wizard. It allows all other RPC requests - \\computername\C$ can be browsed, I can ping, I can RDP, I can access the remote registry. These systems are in my trusted zone as a known home/work network. I know it's ESET - I've been able to run the Group Policy Results Wizard on a workstation, then I push ESET, then I can't run the GPRW anymore. I've opened a ticket with ESET support.

It is Windows 2012 R2 and it only happens on about 25% of installs. I have 250+ servers. I think what's happening is no one is taking the time to tell ESET anything because the response they get is "it's been tested and it works for us..."