LocknetSSmith

Just checking back. Unfortunately nothing we have tried has gotten this to work beyond initial install. I have even ripped out the entire ERAS system, rebooted the server, and reinstalled from complete scratch. The agents go out, the reset cloned agent task is ran, but nothing ever checks back in after the images are recomposed. If I delete machines from the Web Console and re-run the Sync Server task, I at least get back to the master image machines though. Gonna try Eset support once more. I've been escalated twice though, so I'm not sure where else to go!

For what it's worth, here is what I'm going to try today. Nothing we've tried will get these agents to show on all of the virtual machines during this, our brand new deployment, as far as adding the agent to the image. It always only shows on the master image workstation, and even when we run the Reset Cloned Agent task against that computer, and then try to push the image, nothing checks in. I have uninstalled everything as far as v6.x and had them remove the agent from the image, and redeployed the "agentless" image out to all systems. I'm going to redeploy the ESET RA Server with a clean slate. The only time I've gotten all of the individual VM's to check into the server was by running the Agent installation task against them while they were online (during the day). I'm going to do this again so I can at least get the agent out there and get all of their VM's checking in. Before the next recompose of the master images, going to try to run the reset cloned agent task against all the VM's, then have them recompose and re-deploy with their new image. With a little luck, they'll all check back in. If not, this customer will probably cancel their order with us! So here is hoping.

I have a customer that we deployed ERA v6.x to, which happily had everything running like a clock for about a week. Then their endpoints got new IP addresses from DHCP leases expiring (they set their DHCP leases to renew once per week), and everything stopped checking in. All tasks pushed to these machines now fail, and they remain disconnected from the ERAS as shown in the Web Console. I checked the customer's DHCP settings, and they do have the creation of new PTR records enabled when IPs change for the reverse DNS lookup zone. They also have DNS scavenging enabled. Is ERA v6.x not approved for environments using DHCP, or am I missing something/doing something wrong?

No takers huh?

I have recently completed a deployment to an org. which is 100% VDI and found out the hard way that using the Agent Deployment Server task is not the proper method to install the ERA Agents. I was directed by ESET Support to utilize the Reset Cloned Agent client task in a proper deployment scenario, but that has left me with questions. For the initial deployment, here is the process I've gathered from the information I was given: 1. Use the policy to increase the check-in interval of ERA Agents 2. Add the ERA Agent and ESET Client to the computer you are composing your image from 3. Allow the ERA Agent to check into the ERAS 4. Run the Reset Cloned Agent client task against the endpoint before it checks into the server again (hence the need to increase check in interval) 5. Image other computers using the prepared image. They should now all check in as unique workstations My first question - Is this an accurate process for the initial deployment? My second question - this organization recomposes their images on a bi-monthly basis to add Windows updates and third party patches to their images. For ongoing day to day administration, when you have all of your agents checking in, what is the process for recomposing images? I could be off base here, but it seems to me that if a person were to follow the steps above, they would end up with a whole slew of duplicates showing the Web Console, and the old ones would all have to be deleted whenever you recomposed images? Or is there a process for post-recompose which would avoid this? Also, just a suggestion - Perhaps a good KB would be helpful here, that is specific for VDI environments!

Description: Disabled Notifications, Alerts, GUI, integration to the context menu. No egui.exe will run. Suitable for management solely from ERA.

In the ERA v6, in Admin -> Policies, there is a pre-existing policy that comes with the ERA Web Console, so I'm assuming it was built by ESET. The title of the policy is Security Product for Windows - Visibility - Invisible Mode That is what I am referring to.

So, I'm waiting for a call back from this customer for permission to connect to one of these computers. Can anyone explain how Invisible Mode is supposed to work?

Maybe - I can look! I thought perhaps this was because of the invisible mode policy. I wasn't sure how it was supposed to work from the description and couldn't find a KB on it or anything in the user guide (that's not to say that there isn't anything, but maybe that I just missed it). I'll check the logs

Hoping for a quick response on this one! I have a managed service client who I deployed v6 ERA to. Everything has been working great, but they wanted to test the policy Security Product for Windows - Visibility - Invisible Mode as they want to truly make AV invisible to the end user (or as close to it as they can get). So they applied the policy to a group of about 20 computers, and restarted them. Now, the ekrn.exe process has stopped - that is to say, the computers came back from a reboot, and the ekrn.exe process didn't start. Is that how invisible mode works? Are these computers still protected? Or did something go wrong? Thanks~

Hey all - I'm trying to add a series of exclusions to a customer's ESET policy in our v5 ERAC (Unix Desktop v4 -> ESET Daemon -> Settings -> Exclusions). I must be putting them in with the wrong syntax, because they're not applying at the end-user's level. The customer is running ESET NOD32 AV version 4.1.97 These are the exclusions I need to add: Description Files and Folders to add as Exclusions Program Directory* /Applications/Jungle Disk Workgroup Cache Directory* /Library/Caches/jungledisk/wg-cache Settings File /Library/Preferences/junglediskworkgroup-settings.xml This is the way I tried to enter these exclusions: /Applications/Jungle Disk Workgroup::/Library/Caches/jungledisk/wg-cache::/Library/Preferences/junglediskworkgroup-settings.xml Any ideas?

To all involved. ESET Support provided the information below in regards to our hard lock issues. Since applying this hotfix, the users I had which were experiencing issues have not frozen up. It has been about two weeks. "We have information from our developers that this issue seems like the issue is MS bug, with hotfix available, but not automatically distributed via auto updates. hxxp://support.microsoft.com/kb/2664888" I should also advise that they also recommended that we install the most recent version release of Endpoint Security (version 6.1.2227), but we have not yet done that. As of Friday, May 8th, the latest version wasn't available on the products page in our RA Server. I'll be checking again today.

The new online help has some descriptions of what the categories mean: hxxp://help.eset.com/ Excerpt from hxxp://help.eset.com/ees/6/en-US/ Here are some examples of categories that users might not be familiar with: Miscellaneous – Usually private (local) IP addresses such as intranet, 192.168.0.0/16, etc. When you get a 403 or 404 error code, the website will also match this category. Not resolved – This category includes web pages that are not resolved because of an error when connecting to the Web control database engine. Not categorized – Unknown web pages that are not yet in the Web control database. Proxies – Web pages such as anonymizers, redirectors or public proxy servers can be used to obtain (anonymous) access to web pages that are usually prohibited by the Web control filter. File sharing – These web pages contain large amounts of data such as photos, videos or e-books. There is a risk that these sites contain potentially offensive material or adult content. NOTE: A subcategory can belong to any group. There are some subcategories that are not included in predefined groups (for example, Games). In order to match a desired subcategory using Web control filter, add it to your desired group.

Yeah this is an unfortunate thing, but I'm thinking it doesn't follow a machine type now too. Although the only users we have who are hard locking have Dells, I also have users with Dells who aren't hard locking. To me that points more towards an incompatibility with a chipset issue. I remember with v5 first launched, computers with a certain chipset would hardlock if you ran HIPS - they fixed it pretty fast if I recall

Dell Latitude E6540, and Latitude E5540

I just wanted to chime in that we also have a case open with Support for v6 Endpoint Security and Endpoint Antivirus hard locking three computers here. I've submitted gigs of logs to support, and they've sent them on to the Dev team. One thing of interest that I found is that the three users here that are hard locking use Dell computers. The rest of us running v6 have HP's. Not sure if that matters or not, but I thought I'd add to the conversation.

I've found that manipulating the "Scan On" settings can help with situations like this as well. Microsoft actually recommends disabling all Scan On events except the Scan on Execution setting for Terminal Server environments. Of course you have to balance security - where we have done this, we have scheduled scans running more often.

You have to use the activation key that came with your license information... I believe it shows up as the "License Key." If you don't have one, and still just have your EAV username and password, you can convert it to a v6 key on Eset's website.

Didn't realize that it was a Microsoft Bug. That's a load off =)

I'm just curious as to why the Document Protection module is still disabled with out of the box settings? Is it still problematic as with version 5? I know the other scanners do well in picking up the slack, I was just surprised to see this.

So I must have worded this badly, because this was WAY OFF base from what my intent was. But ok - case closed I guess. I was honestly just wondering what they would show up as in a snort log, not for the purpose of any corporate espionage, but more so for knowing what is eset when digging through said logs.

Not sure if this is the right place for this, but is there a way to open (export) the contents of the virus signatures in a program like Snort or Yara? Is there a specific format that Eset uses for their signatures where they could be recognized in an analysis?

Version 5. I haven't had much exposure to version 6 yet, but we've been using version 5 for about 2 years now.

Is there a way to confirm that your version 5 Eset endpoints have indeed downloaded and updated with the new features from v6 from the version 5 ERAC? I'm referring to the Advanced Memory Scanner, Botnet Protection, and Exploit Blocker specifically. We have almost 6k systems in our ERAS, so I won't be able to check them all, but felt if I could check a random machine for each network, and confirm, that it would be a step in the right direction.

I've found in my experience that Eset detects more than Malwarebytes. Where MBAM has a slight edge (and it's not consistent) is in zero-day attacks as that is where they spend the majority of their research time. But even when I've seen MBAM detect something that Eset didn't immediately see, I can still clean it with Eset using the ondemand scanner with advanced heuristics enabled (out of the box, advanced heuristics is not enabled for the Real Time Protection in Eset). MBAM tends to have more false positives as well. For example, it will often flag changes made via Group Policy in a domain environment as malware.