PuterCare

I have a user who has the latest version of Protect agent and EES installed, they upgraded to Ventura. I followed the steps in the guide but it doesn't help, I uninstalled and reinstalled but I have the same issue. Installer is not listed in full disk access, ESET Device Control is. I have tried removing that too but still it doesn't work. Any other ideas or is it just not working at the moment? Thanks

I just had a weird issue so thought I would post in case this helps anyone else. I am onboarding macOS devices using Intune, part of my onboarding process installs Rosetta and then the Eset agent, Eset Protect then takes over and auto-installs EES and activates. All works nice and smooth but Friday I had a call to say a Mac that was onboarded that week (running Monterey) has no internet access. I did some troubleshooting and saw that on the network prefs screen the Eset firewall was stuck starting and the Eset proxy was not connected. Eset was not running on the menu bar. I went through the steps to uninstall Eset but it said that Rosetta was not installed and a button to install it, clicked that but it failed as there is no internet. I fixed by manually removing Eset firewall and proxy from network prefs which allowed me to run the uninstaller, install Rosetta, uninstall Eset and I then pushed a fresh install from Protect which is working. I hope this was an obscure glitch rather than anything that's going to cause issues going forward. It looks like somehow Rosetta was damaged or removed after Eset was installed. I don't have logs as I had to get the user up and running asap. Seems related to this:

It's not a huge amount of work but were I not moving hypervisor platforms then I agree, it's more work than necessary for a software update. It may be that the software update would apply after a while but I was in urgent need, hopefully someone can confirm.

I just realised I could do a DB pull instead which is much easier and supports transferring to a newer server version. Wil leave the question here though as would be useful to know if a manual update can be applied inside the appliance or whether I need to download the updated appliance and do a DB pull each time.

Hi, I am trying to migrate my ESET PROTECT server from VMWare to Hyper-V on another host. I have set up the Hyper-V appliance and the server version is 9.0.2144.0 but on my VMWare appliance the server version is 9.0.2141.0. I have gone into the update task and 9.0.2141.0 is the latest version showing in the repo. The migration guide says the source and destination must be on the same version, does anyone know how I can upgrade my VMware appliance so the server version matches? Thanks

Thanks for the confirmation.

Ref: I am having the same issues as the above thread on EES 9.0.2032.6, does anyone know if this should be working by now? I fixed by disabling the scan on read option but am just concerned that my users might open a malicious eml file and not have the same level of protection as when the option is enabled. Thanks

Is this something you needed to do on the endpoint or something Eset have fixed? Thanks

Glad it's not just me. I reinstalled EES 6.11.1 on macOS 12.1 and so far I have not had any issues reported by the user so I was unable to collect logs whilst the issue occurred. In my experience it has only happened after a macOS upgrade with Eset installed already.

I've had issues reported a few times over the past 6 months and on each occasion removing Eset Endpoint Security fixed. One of my clients got a new M1 Macbook last week on macOS 12.0.1, I connected, installed the Eset agent (had to install Rosetta 2 first) and pushed EES 6.11.1. Everything seemed ok but shortly after the client installed the macOS 12.1 update and since then they lost internet unless they entered recovery mode. We tried going into network settings and adding a new internet connection but this did not help, we removed EES and the internet came back. 6.11.1 is supposed to be compatible with Monterey and there are no known issues listed, has anyone else experienced similar problems? Thanks

I have found a couple of other threads but they were incomplete. Is it possible to stop a client task before it runs (in the planned state) and after it has started to run? One scenario is if a client task has been scheduled and the client system is offline, it is added as a planned task but has not been sent to the agent yet. I want the ability to cancel this task so that when the system comes online it is not sent to the agent. I have some client tasks that have been "running" for over a month now and they never complete so I would like to stop them, is this possible? Thanks

@itman to the rescue once again, thanks a lot 🙂

Hi all, I recently added the default rules to protect against ransomware but now some legit connections to Sharepoint in powershell are being blocked. I have found the list of IPs to set up in the firewall to fix this (https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide) but some IPv6 formats are not accepted by Eset e.g. 2620:1ec:d::10/128. Is this as simple as /128 CIDR subnet is a single IP so I should just enter in 2620:1ec:d::10 and it will have the same effect? My IPv6 experience is poor.. Thanks

A bit of luck to be honest, I was looking through the event logs and nothing was of interest. I looked at the local Eset HIPS log to see if it happened at particular time intervals and it seemed random. I then went through scheduled task library looking at the action tab of each task hoping to find wscript.exe or a vbs file and I found this one. I then enabled history for the scheduled tasks, checked what the script did, checked the exe was clean and then ran the task manually which caused an alert to be sent and an entry was added to the HIPS log. I then searched the task name in Google to work out what it was for, looked in programs list and removed the Intel software and set the service to manual. I'd love to know if there was a more surefire way to diagnose these were the script not to be set up in task scheduler for example.

I've resolved this one now, in scheduled tasks I found "USER_ESRV_SVC_QUEENCREEK" which was set to run at logon. It would use wscipt.exe to run C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.vbs. That VBS file contained: Set objShell = CreateObject("WScript.Shell") objShell.Run("C:\WINDOWS\System32\cmd.exe /c ""C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.bat"""), 0 Set objShell = Nothing And task.bat just contained - "C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.exe" Unsure why it is such a messy way to run task.exe. Uploaded the exe to Virustotal and it was clear. Removed Intel Driver and Support Assistant and Intel Computing Improvement Program, set Energy Server Service queencreek service to manual. The scheduled task was removed when uninstalling the software.

Thanks for your time on this thread, I have disabled the powershell rule now. I have one remaining alert that only affects one Endpoint therefore it is possible this is a malicious process: Source application: C:\Windows\System32\wscript.exe Executed operation: Start new application Target: C:\WINDOWS\System32\cmd.exe I will see if I can find any clues in event viewer about this one.

It is possibly connected to a Lenovo service such as one that Lenovo System Update runs, these are all Thinkpads. When I run System Update manually I get a lot of blocked processes. Could be unrelated but that is one thing all these endpoints have in common. I am also now receiving a lot of alerts for Powershell running dismhost.exe, I assume this could be Windows updates. After it gets blocked once, it gets blocked again but on each occasion the target is a different folder in the temp dir i.e.: Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Executed operation: Start new application Target: C:\Windows\TEMP\876F365A CA98 4687 91F5 43B7FAE16537\dismhost.exe I also have wscript.exe trying to start cmd.exe. I am just concerned that some of these may be malicious processes, when I get time I will try to tweak with permissive rules or otherwise may just need to remove the policy.

It is possibly connected to a Lenovo service such as one that Lenovo System Update runs, these are all Thinkpads. When I run System Update manually I get a lot of blocked processes. Could be unrelated but that is one thing all these endpoints have in common.

I am unable to edit my last post, I added an allow policy for powershell to start conhost and now I can run powershell. Still not sure what was happening in the background to trigger this.

I have gone into event viewer, the event is in the Eset log at 08:00:15 so I have filtered the Application and System log to only show 07:59:30-08:00:20 but the only event shown has a source of "Security-SPP" and details "Offline downlevel migration succeeded.". Any ideas where else I can try to work out the source of this? I will set up the permissive rule anyway as I need access to Powershell.

Thanks, I will try that. I just tried to run powershell and it was blocked by Eset with the same message so looks like something is running powershell in the background and it will trigger the rule. Not sure what that might be, a safe Windows component perhaps.

Thanks for that info. Yesterday I tried to replicate the same issue on my system by rebooting and signing in but nothing happened, but this morning I have received the same message. I went into my Eset HIPS log and it is listed but doesn't have any more info than what was in the email alert from PROTECT. I browsed to the StartupInfo dir in that article but the latest date modified was yesterday. I can just disable the rule but I like to try and work out the cause first, just not sure how I can do that in this case. I can compare what services each system runs and what startup items there are and look for clues. If it triggered on every boot then would be easier as I could adjust my startup items to test.

I figured it was probably a false positive but my thought was if Eset recommend those policies then best keep them in place if possible so I was trying to work out the cause first to see if it was anything important. Are there logs I can view on the local machine? Thanks

I downloaded the recommended HIPS policy, uploaded to PROTECT and applied to one of my OUs. Since then I have received several of the same message from a few endpoints: Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Executed operation: Start new application Target: C:\Windows\System32\Conhost.exe Action taken: Blocked These are AzureAD joined laptops, the only agent on them is Eset and the only other unusual thing I can think of is an Outlook add-in that inserts email signatures. I enabled "Log all blocked operations" in the policy but after the next email notification was received I ran the log collector task on that endpoint but there was nothing listed in the Logs, Diagnostic, HIPS section of PROTECT. I spoke to the users and they did not see anything strange other than the Eset pop-up and had not ran anything themselves. One user said it happened as soon as they signed into the laptop. Is there a local HIPS log on the machine that I can view and work out what might be causing this? Thanks

Are these default rules or something that is documented but needs to be set up? I had a look in the help files and found the built-in policies in ESMC/PROTECT. Thanks