bbraunstein

Just a shot in the dark, but: your comments/posts are usually no more than 10 words long simply demand "how to xxx" do not provide any information on what environment you're working on what steps you've tried/achieved This is kind of off-putting. Try being more clear and descriptive with your issues and we'll be able to try and help you. Try starting from the Local Knowledgebase for your questions and then work your way up from there: https://forum.eset.com/topic/4469-latest-knowledgebase-articles-videos-for-era-6/

Yeah it was never 100% clear (at least before). Just push a new Software Install task with the same license and everything. The installer checks to see if there are any previous versions of ESET present and will uninstall the earlier version before installing the newest version.

So this a reach, but was there ever a resolution to this? I just had one of my client computers BSOD randomly. And then he proceeded to tell me that this happened a few times over the weekend as well. The STOP code was 0x19 but the first parameter is different, which indicates a slightly different cause of error. Also, this computer is running 6.1.2222.0 of ESET Endpoint Antivirus. Other than that, everything else Curious listed describes my scenario. If there was a resolution, maybe you can help me out?

That's what I figured. Thanks!

I know the Remote Administrator v6 server is unable to completely manage ESET v5 products, but what about Server Security for Linux/BSD/Solaris? If I have a policy for Linux and OS X Security Products, will the same policy successfully apply to Server Security version 4.0.10.0 ? Or would I need to manage and configure the settings for the Server Security product by hand? Thanks

What does the Event Viewer on the client workstation show?

If the client computer is NOT part of the domain, or the hostname cannot be resolved, I found that by changing the name of the client to its IP address allows the push to succeed. In your case, on the Web Console, click on the client and then select Details... On the first column, "Name", change hsc-edy to the IP of the device. Then try another push. This is what resolved the deployment issues for Linux/Apple devices on my network that are not part of the domain and do not have A records. But I never tried this on Windows computers. You can try and see if this resolves for you.

Don't worry, it's not your fault. We've all complained about this since December when they first released the "Beta" for North America. The logs are extremely unclear and just are not available through the Web Console. This is because the Agent neither receives or sends the logs of the clients, so if a task fails, you either: * Log into the client machine and read the logs locally or remotely * Bother the client every time the task fails and have them send you the logs * Log directly into the server and navigate to the Server logs to see if it gives anything helpful I personally find this as extremely inconvenient because how are we supposed to troubleshoot an issue when the task result is just, "Failed"? And the Web Console is supposed to serve as an interface between the user and the server, but what's the point of calling it an "interface" when you still need to access the server to view logs? I brought these points up numerous times so hopefully it will be implemented soon. For the time being, you'll need to continue troubleshooting the way you have been. It's the way we all have...

Hmm.. MSI error code 1619 means the installation package can't be opened. So it's definitely getting through the firewall and connecting to the computer. Does the Event Viewer logs give any more information?

I've PM'd you with my PLID details. Let me know how it goes.

Well, I'm glad things still worked out for you anyway!

Hmm.. I actually just noticed this with my clients as well. It happens sporadically but only affects one client at a time. Suddenly they just cut out, lose the license, stop updating and then prompt for reactivation. The only solution is to push a Product Activation task. I only have one license, with 64 of 80 seats activated. So it wouldn't make any sense for a 'some' license deactivation for me because if only the one license was deactivated, wouldn't all of the clients be affected at the same time? I hope this isn't a bug and I certainly hope it's not some ticking time bomb that's going to affect all of us at once since ESET replaced its QA team with us.

This "bug" has to do with directly connecting to the ESXi Console. The OVF template is for vCenter Servers only. So you will need to connect directly to a vCenter server using a vSphere Client. I had a similar issue when I was trying to upgrade. Really annoying how this wasn't made more obvious. Instead, I just mounted the .iso of installers and installed the components individually by hand. It wasn't easy... but eventually I got it up and running.

From the documentation: hxxp://help.eset.com/era/6/en-US/index.html?fs_agent_deploy_troubleshooting.htm

So if I'm understanding you correctly, I'd need to disable password-protection of the Settings completely, in order to allow modification from the client ?

My current Policy has Advanced Setup password protected on all my client endpoint products. After entering the credentials, the settings are still grayed out and not able to be modified. Is there way to enable editing of the Advanced Setup, while still password protecting the access? I'm using ERA v6, in case if it is not clear enough. Thanks !

Glad you managed to figure it out. I went through the exact process you did when I installed on my CentOS 6.5 server 3 months ago. If you have any other issues, a few other people and myself might be able to help you out.

It's (sort of) possible to manage ESET Endpoint v5 products with ERA v6, but only with limited functionality. I don't think ERA v5 has any ability to manage v6 products. The two products are so dramatically different that backwards compatibility was never really an option (One of the biggest complaints around here when ERA6 was first released). I'd recommend going full v6 or keep all your products at v5 until you're ready to upgrade.

Will this be fixed/added in a future release? I've mentioned this in other threads a few weeks ago. It seems kind of silly how the Web Console serves as a management interface to the server, but when I need to review log files, I have to SSH into my server. It kind of defeats the whole purpose of it being, you know, an interface.

Personally, I would really like to do away with the Unique task name for every single task I run, but this would definitely help out tremendously.

I'd like to be able to refine some of my results to only a specific domain or exclude certain computers from the list, preferably by it's computer name. Is this possible? For example, if I wanted to exclude all the computers whose name begins with the letter 'C', I choose the Directory Category "Computer . Computer name". And then there are filter modifiers, such as contains, equals, not equal, has prefix, has postfix, etc. If I wanted to include the computers whose names begin with the letter 'C', I could simply select the 'has prefix' modifier. But there is no way to EXCLUDE results. I've tried using common Regex symbols such as * and &, but nothing returns what I'm looking for. The whole thing is built on top of a MySQL database, so I would think I should be able to filter what I want.

jbc, There is no way to create a dynamic group that would specify between Desktops and Laptops. The icons you see listed can be a number of the following: Desktop Virtual Machine (Agentless) Mobile Server File Server Mail Server Gateway Server Collaboration Server There are also icons for the other ERA components such as the RDSensor, Proxy, and the Agent. At my company, the only laptops that we have are all Macbook Pros. If I wanted to create a STATIC group of only Laptops, I could make the filter as "Macbook Pro". How are the laptops connected in your company? Are they wired or wireless? If they're connected wirelessly, you could create a dynamic group assigned by IP address. That's how I have my three locations organized. Location1 == 192.168.1.0/24; Location2 == 192.168.50.0/24; Location3 == 192.168.70.0/24. Otherwise, there isn't a distinct category available to distinguish between laptop and desktop.

It always kind of irked me how the Web Console is supposed to be the interface between the Administrator and the Server, but whenever there is an error, we need to log into the server and look at the logs. Why not just make the logs accessible through the Web Console?

Hi, This did not resolve anything for me. The numbers and threat warnings still exist. I'd rather not mute threats, I agree with Jim, the concept of muting is merely an acknowledgement "I promise I will get back to it later." I shouldn't have to mute a problem if there really is a problem, especially if the problem no longer exists. If it truly does no longer exist, the status should be update to "cleaned/deleted" and removed.

Boy, does this line resonate with me. I actually like the new upgrade but it wasn't until after overcoming a LOT of hurdles. Sure, it was partly my fault for being a Linux Admin, things are never easy out of the box on Linux. I felt like the developers bragged about having a product that could function on Linux, but there was hardly any Linux support. Me and a select handful of other Linux users needed to work together to figure out out to build and troubleshoot errors. ESET shouldn't be pushing out updates and making posts like "ERA VERSION 6.X IS RELEASED!" and then not have any documentation published or even created for nearly a week afterwards (I'm looking at you, Global Release 6.1.128). My biggest complaint that really pissed me off is how misleading the North American December release of 6.1.336 was. Nowhere did any piece of documentation, warning, notification, or even ESET Dev say that the release was a beta/soft-release. As a paying customer, that was kind of a slap in the face that I was given an incomplete product. BUT, all that said, after figuring things out and steadily using the product for about a month, I like it. I don't blame the Moderators of the forum for anything, but I feel the Developers and QAs should have more collaboration before release, even if it means pushing the releases back one week.