whitelistCMD

It's not working. I've confirmed there's no other policy that is overriding this, and forced the address list as well as web access protection. The endpoint definitely received the change I made as I can see it locally. I then tried to enter the domain name specifically, as I would enter it into web browser, and it's still not working. I'm not sure where the issue is? Any suggestions?

Thanks, Marcos. I'll go ahead and give this a try.

ERA OVA version: 6.5.417.0 Looking to block certain country domain extensions in web control. We're currently using ESET Web Control, but would like to start blocking certain country domain extensions. I tried a few configurations with wildcards, but I can't seem to get it to work. Is this even a possibility in Web Control, and if so, how and where should this be entered? I've been attempting this in a global block rule that I know is working, the user is definitely added to the rule, and I've been trying to enter the domain extension with a wildcard in the URL list attached to the rule. Examples (*.ru; *.ru*; *?.ru; .ru) <--Omit the ";". Thanks in advance.

I forgot to mention that both consoles are OVA's and both are running centos-release-7-4.1708.el7.centos.x86_64.

Hello, I recently installed new software package updates via Webmin to both of our ERA consoles this weekend, and I'm now unable to login to ERA with domain credentials. Error is showing on login page as "Login Failed" ( I tried multiple accounts, all of which have previously logged into ERA). Local Admin accounts for ERAs are working correctly. I rejoined domain and ran some tests to verify everything was working correctly (ERA versions are both 6.5.417.0). I rejoined the domain successfully, and then ran the following commands: wbinfo -p ##Ping was Successful## wbinfo -u ##User list was returned## wbinfo -g ##Groups list was returned## The domain controller showed the successful connection in the logs and at that point I stopped looking at this being the potential problem. However, in looking at the ERA server trace log, I'm getting the following error after each login attempt: ##2017-10-09 16:16:07 Error: ConsoleApiModule [Thread 7fcf28fe9700]: Untranslatable CInterModuleException: ConvertDomainUserSidToGroupsSids: 'wbinfo' failed with 1, stderr: ##failed to call wbcLookupUserSids: WBC_ERR_DOMAIN_NOT_FOUND ##Could not get user's domain groups for user SID X-X-X-XX-XXXXX.......... I installed the updates via "Webmin>Software Package Updates" and also "Webmin>Software Packages". After doing some research of different portions of the error, I'm fairly certain this involves the python package and that package was installed with "Webmin>Software Packages". Long story getting longer, I will end my post with these two questions: 1. Where do I even start in order to attempt to fix this? 2. In order to keep the CentOS 7 back-end of the ERA up-to-date, what is the recommended procedure for doing so? I've only ever used "Webmin>Software Package Updates" and this was the first time I happened to install what was under "Webmin>Software Packages", which I'm assuming that Python package is the cause of my issue. Thanks in advance for all the help. Hopefully this won't be too difficult to fix. Fingers crossed.

Thank you, Martin! This is very helpful information. I should have clarified the Upgrade Components and Software Install portion, but I will need to do it for both, so this is helpful either way. Thanks again for the help. I don't know exactly when I'll get to this, but when I do, I'll reply back here if I have any questions.

Hello, So we just finished deploying ESET across our entire infrastructure and I would like to know what the best way is to configure an auto deploy task for components upgrades on all of our endpoints and servers? What I would like to have happen is to set this up and have it kick-off over a weekend. My biggest concern is doing all machines at once. I would like for it to run slow, a couple machines at a time, for a duration of say something like 24-48 hours. Can this be done on a top level dynamic group and go through in alphabetical order or something? Any ideas or suggestions are much appreciated. Thanks in advance.

Mainly because of the lack of triggers, but also because we have a similar feature in ERA and would like to give it a try.

Is anyone aware of how to use the Run Command Client Task to run an executable as a domain administrator? I'm really only stuck on the credentials portion of this. If I run as a specific user, and I'm not in front of the machine I'm running the task on, what is required in the "command line to run" in order to supply my credentials? For example: RUNAS /user:domain\username filename.exe <-- How do I provide credentials? Thanks in advance.

I wanted to post my results in following your advice, I'm just finally getting a few minutes to do so now. It ended up being that the computer just needed a restart. As soon as I restarted the computer (I restarted to disable HIPS so that I could get into the directory where the file was), it came back up and I looked in the directory and there was no file there of the name stated above. So, the restart removed the file and I did not have to do it manually. As soon as I ran the upgrade task after that restart, it went right through and completed successfully. Thanks for all the help!!

So let me backtrack for a minute, and try to explain. I was confused at first, I will admit, because I was unaware that if you look in the About section on an Endpoint, that there's a seat name and a device name. Actually, could we do a private message instead? I'd like to share some screenshots to better explain, but would prefer to do that privately since there will be machine names in those. This may take me a bit to get to... possibly tomorrow, as I'm in meetings now the rest of the day

No, unfortunately not. I looked at that option as well, but wasn't sure because this is technically not cloned, even though it resembles such an issue. This is just a plain old physical machine that had a previous name that is now in use by another computer and the seat name on the renamed computer is conflicting with the device name of the computer that has acquired the previous name. I just fixed the issue now. Here's what I had to do: I logged into ELA with License Key and Password, Then I changed the seat name on both machines to match their current device names, and verified that the change occurred by looking at the Endpoint. I then checked the ERA to see what was going on, but no changes. Both machines were still checking in under one name. I then deleted both from ERA (unchecked the box to deactivate products), ran another AD sync, and when they appeared again they were both checking-in under their designated names as desired. Problem solved. Also, I appreciate that you guys are always very responsive on here and are always looking for feedback. I don't mind working out the kinks, because I can see how well this product performs its intended purpose. It's better at that than any other platform I've used. It's the trust that I have with ESET in all aspects that makes being patient well worth it. You guys have an awesome product, and with a few tweaks to administrative/troubleshooting issues, things will be much easier on all of us. Truly grateful for the work that all of you do. It's been nothing but forward progress. Thank you.

Hi Michal, So the ERA entries for the two machines do not match. I'm familiar with the rename computers task, as I've had that issue in the past as well. The device names are different, with one showing as agent and app installed, while the other is not. In reality though, they both have agent and app. So, that's not my issue, My issue is that one of the devices has an endpoint with the identical seat name to the other device name. So L26 seat name (L01) is the device name for L01, while L01's seat name is L01-1. The problem is, L26 is reporting as nothing installed, but is actually checking in as L01. Let me know if I need to clarify this further. I'm working on retrieving password now. I found the license key, but can't find the pw. If there's anything that can come from this, just please do all that you can to make the whole management process across the board, much easier. I often find that while this product is awesome at what it does, it's extremely difficult to use at times, It can consume several hours, if not days, to solve relatively minor problems with no clear direction on how to fix. Please build more robust remediation into the ERA for administrative issues such as something like this. Even removing application and agent are near disastrous from the ERA. If I can't have authoritative power over a policy that's applied to all machines at the top level and I'm unable to move machine group to get away from policy, then I waste an hour of my time digging up directions and completing the uninstall manually. Or trying to create an exact opposite of the policy hoping that it will stick throughout the uninstall process. Simplify and maintain, as they say. I should be able to do any and all from ERA with ease and simplicity while being able to find what I need relatively quickly.

Hello, I have recently found that this has become an issue for me. One of our support people has renamed a computer (we'll call it L26) from a previous name (we'll call L01). The problem is, ESET was installed before this name change, so it's seat name is L01 with a computer name of L26. Normally, this wouldn't be that much of an issue as we've renamed plenty of machines. However, the L01 name has been reissued to another machine. Because of this, the ERA thinks that L26 is L01. Let me put a simple construct up so you can see... Seat name will be first with Device name to follow... L01-1 > L01 L01 > L26 L26 now = L01 and the real/current L01 I've since logged into the the ELA portal, but I can't seem to edit anything with the machines. It's like the check boxes are missing next to the names. The only one that shows is up at the top. Is it possible to change the seat name from ELA? Should I be seeing check boxes next to the names? If neither of those are correct, what are my options here? L26 is currently showing in ERA as having nothing installed (even though it does). It's there because of Active Directory Sync, but the agent is replicating as L01. Please help. Thank you.

I'm currently having this same issue on one particular machine. The error I'm receiving is as follows: File already exists 'C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Data\upgrade.json'. Cannot continue with agent upgrade This is a remote machine of a higher executive, so I'd like to get this taken care of the right way. What options do I have? Thanks in advance.

Thank you, Martin. I appreciate you seeing this through with me and making sure I understood correctly. Hopefully this can be addressed in the future. And also the ability to fetch an Endpoints trace log from ERA would be very helpful as well. Thanks again. I appreciate your time.

Just to clarify, are you saying that the "Trace Log Verbosity" which I have set to "Warning" under Admin>Server Settings>Trace log verbosity does not impact which logs from Endpoints are sent when I have the "Export logs to syslog" option turned on? That may help answer some questions. If I turn on "Export logs to syslog" then all I'm going to get into SIEM is the predefined set of logs from Endpoints that are sent to ERA which I can find listed in the Threats Tab? If this is the case, I would like to request a clearer and more simplified logging option because how it is sent now is misleading. If turning on "export logs to syslog" which will send Endpoint logs to my SIEM, then I should see either A. All logs from Endpoint, or B. Have the option to choose which logs are sent from Endpoint with all the same options that are on the Endpoint. Also, Trace Log Verbosity should be grouped separately because its current placement is misleading. If I have the option to change Trace Log Verbosity for Server Trace Log, then please create separate section for Trace Log where I can easily define for both Server and Endpoints and then clearly state that this does not control Exporting of Endpoint feature logs.

Now I'm confused again. The logging to SIEM from ERA is currently working, I'm no longer concerned about getting logs to SIEM. I'm now trying to determine what logs will be sent to SIEM, and how to change which logs are sent based off of what trace log verbosity setting I choose? Does that make sense? What I would like to do is get the logs from the Endpoints to the SIEM, which is currently working, but which logs will be sent there? Can I change this based off of the Trace Log Verbosity setting? If so, which setting should I choose to get the most all encompassing logs sent there? I have it set to Warning currently, but what is "warning" comprised of in regards to the other levels of logging. Will "warning" include warning itself, plus information, plus trace, plus debug? Again, the whole goal of this is to get as many logs of all types sent to our SIEM, and obviously in doing that, I want to know what is covered by each verbosity setting? This really should be more of linear option, and not as variant. If I have Web Control feature enabled on an Endpoint and the Endpoint is logging all blocked URL's, sending them to ERA which I can generate a report off of, I should be able to pipe those logs then from the ERA to a SIEM, along with other logs. If I need to clarify any part of this, please say so. Thanks.

Hi Martin, We're basically on the same page, minus the trace log. I only looked in the Trace Log to see if there were errors pertaining to why I couldn't get syslog working, but it is now. More to come on that later. My ultimate goal in this is to get as many Endpoint logs into our SIEM as possible. If I were wanting to do that, which logging verbosity level should I be setting on the ERA? So, Error is least amount of logging and Debug and Trace are the most? Will Trace include error logs? I hope this is making sense? Another way to put it, is which level of logging is the most all encompassing level, and which other levels of logging does that level include? Also, is there currently a way to export Web Control logs to a SIEM? Thanks again for the help.

I think I've discovered the problem. I need to test some more to be certain. Can you please explain the log verbosity levels? Does "Warning" include Information, Debug, and trace? I'm trying to decide on a level, but there's no clear answer on which setting covers which. Some say "this, plus above" and then Warning Is "Ciritcal Error Messages and Warnings". That's not entirely clear to me. So does Warning include Error and Critical and then above? Information, Debug, and Trace? Is that included in Warning too?

I don't see any errors in the ERA trace log, but would be happy to send in a pm if you'd like. I've attached a picture of syslog config in ERA. Please see attached. Thanks.

Hello, I'm having issues getting the ERA to send syslog messages. There's nothing blocking the traffic in our network, so I've ruled that out. I followed the ERA admin guide for configuration in the ERA itself and have even tested different settings in the ERA syslog section to see if it would make an impact, but still no dice. I'm running ERA OVA 6.5 in vmware. I have the webmin interface enabled on the ERA. Does anyone know of anyway to validate within the webmin interface or through ssh to ERA, that the ERA is even sending syslog messages? Thanks in advance.

It was the password set on the agent. I quickly made a policy to sit over the top of first agent policy that force disabled the password. Then re-ran the batch on the server, and now the agent is checking into the new ERA. Thanks for all your help guys.

I just ran the batch like you said, and it's not rewriting the config. It's still connecting to old ERA. The parameters are set correctly in the batch. If I run the batch on a new machine with no Agent, it connects to the correct ERA.

Ok, I just ran the batch file with the new ERA configuration inside, and the first time updated the agent, just like you said. The second run did not change the config.I decided to wait and run a third time, but still no dice.The agent is still checking into the first ERA. Is it possible that since the agent is password protected, it won't rewrite the config unless I remove the password protection on the policy?