PuterCare

Thanks, I will give that a try.

I have the HIPS rules enabled, but they are blocking some scripts from running. I have a script that auto-updates some applications: C:\Windows\system32\wscript.exe "C:\ProgramData\Winget-AutoUpdate\Invisible.vbs" "powershell.exe -NoProfile -ExecutionPolicy Bypass -File """C:\ProgramData\Winget-AutoUpdate\user-run.ps1"" When it is ran, it is blocked: 01/12/2023 11:01:36;C:\Windows\explorer.exe;Start new application;C:\Windows\system32\wscript.exe;Blocked;Deny script processes started by explorer; I'd rather not turn this rule off as in most instances, we do not want to let explorer start wscript etc. I have tried adding a rule but they seem to be so broad that I can allow one process to launch another, but I can't seem to be any more specific than that. Is there any way around this other than turning the rule off? Thanks

The user reported the issue returned this morning so I switched to pre-release, updated, and it fixed it so I guess it is a known Eset issue and your devs are working on it. Thanks

I will try that the next time it is reported, in this case I had to uninstall and reinstall. Is this a known issue with a pre-release fix? Another thing, I am unable to install EIS from winget, fails to match hash and also installing from the new app store in Intune fails but I am not sure why.

Strange one here, Eset Internet Security 16.2.15.0, Microsoft Edge (latest version) with Adobe PDF integration enabled. Reports from multiple separate customers, all with EIS in common, no such reports from EES customers. PDF opens in Edge and is presented correctly. When the user tries to save the open PDF, the normal save dialogue opens, when they type the filename, random characters are printed instead of what they are actually typing. These random characters are sequential in relation to the keyboard i.e. they could type "testing" and "qwertyu" will be printed, sometimes text will start from a different part of the keyboard. It is as if it is obfuscating what is typed to prevent a keylogger from being able to work. Text I type using my Teamviewer remote connection appears fine, it is only the local keyboard that is affected. Whilst the save box is open, text typed anywhere on the computer is incorrect, as soon as the save box is closed it works ok. I have found it hard to find info on this, I lost the reference but found that years ago similar behaviour was attributed to ESET so I removed ESET and it started working ok. I reinstalled and it continued to work ok. Does anyone know if this could be ESET related and a quicker fix? Thanks

I can confirm that pushing the update to 10.2.2058 from ESET Protect has fixed the issue, I see that EIS is also affected on v16.2.15 at least.

Interestingly enough, I just did a clean install of EES 10.1.2058 onto a VM using the standalone downloader on the eset site so I could edit the regkey and export for deployment, and the service is already in quotes - "C:\Program Files\ESET\ESET Security\efwd.exe" I will check what version my endpoints are using and see if this version has fixed it. I had deployed EES to two of these systems this week from ESET Protect using the agent. EDIT: The endpoints are on 10.1.2050, I am pushing an update now.

Thanks, is there an ETA for release? I imagine I will need to fix these manually as I have a lot of CE+ audits by year end.

I have just had some systems with Eset installed fail a Cyber Essentials Plus audit for this, was there any update? I can fix myself but ideally the software would have a quoted path in the first place so there is no need for manual remediation. Thanks

All sorted, I ran the removal tool, this time agent installed as did software.

I think I know why the task disappeared, in the endpoint details, task executions section, I deleted the execution not realising this deletes the task from the library rather than just the execution. Last issue remaining is why one endpoint will not deploy but now I can focus all my efforts into fixing that.

Thanks, that client was on my public WiFi, I moved it to my private LAN and now the agent has connected so I guess some of my filtering on the public network interfered with the agent connection. Do you know why my software install task disappears? All my existing tasks are present, but I add a new task, it appears but later disappears.

Update: I installed the same agent to a VM on the same LAN, agent connected fine and software install task pushed successfully. I had already tried the Eset removal tool on the system where the agent will not connect and then installed fresh but same issue.

I am having some trouble with a couple of new client devices when trying to connect them to an existing OU in Protect. I created a new agent script, using a valid ESET PROTECT certificate, install it on the endpoint but it will not connect. Screenshot below. I have another new endpoint on the same OU that has an agent that connects, but any task to push EES install fails. I tried to manually install EES as admin and that fails too "MSI.1923". Software install log attached. Does anyone have any ideas why this is happening? I rebooted the VM but it did not help. I can ping my hostname externally and see that 2222 is open, existing endpoints all seem to be connecting ok. I just downloaded another agent and installed on a VM and it the agent is connecting ok, all these devices are currently on the same LAN. One other thing I noticed which was strange, I set up a new software install task, but today that task is missing from the Protect server. software-install.log

I just removed the policies from the All group, added them individually to the OUs. Now on the OU I am working on they seem to have merged ok, so this issue seems to be when policies are assigned to the All group they will become exclusive.

In Eset Protect I have set up a default policy per OU (I have different client offices set up as different OUs), in this policy I would add firewall rules that are to apply to all devices within the OU such as opening TCP 3389 for RDP access over the LAN. I recently applied a firewall policy to the All group so it applies to all OUs (ransomware protection), since doing that it seems to have overwritten any firewall rules from the OU policies o nthe endpoints and I can't seem to get them back. On the policy applied to the All group, I set the merge to Append, on the OU policy I set it to Prepend. I would then expect the OU firewall rules to be at the top on the endpoint, and the All policy rules to be underneath. Am I misunderstanding something? I made this change on Friday morning and am having various offices contact me about firewall issues. Many thanks

I can ping the hostname ok, there is a firewall in front of the server but it allows port 2222 from any source, other agents are all connecting fine. I will raise a support ticket. Thanks

I have ran the live agent script on a clean install on macOS 13.0 using sudo bash, it installs ok but fails to connect to ESET PROTECT 10.0.2133.0. I have created a new agent installer but still I have issues. Here is the error from the status log: Last authentication 2023-May-31 08:49:06 Enrollment failed with error: failed to connect to all addresses (code: 14) for request Era.Common.Services.Authentication.RPCEnrollmentRequest (id: f0a86e5b-8ec6-4fe8-91eb-7dbc9c455dbd) on connection to 'host: "esmc.mydomain.com" port: 2222' [RequestId: f0a86e5b-8ec6-4fe8-91eb-7dbc9c455dbd] Last replication 2023-May-31 08:48:41 Error: Replication connection problem: Response for request of type DeviceSessionTokenRequest (request id: 21) was not received in time Task: CReplicationConsistencyTask Scenario: Automatic replication (REGULAR) Connection: esmc.mydomain.com:2222 Connection established: false Replication inconsistency detected: false Server busy state detected: false Realm change detected: false Realm uuid: 00000000-0000-0000-0000-000000000000 Sent logs: 0 Cached static objects: 0 Cached static object groups: 0 Static objects to save: 0 Static objects to delete: 0 Modified static objects: 0 All replication attempts: 1 Does anyone have any ideas where I am going wrong? I also found my agent install script failed to run from Intune automatically, never had an issue with this before but may be Ventura related. Thanks

I have two users who are reporting intermittent Livegrid servers cannot be reached errors, the messages disappear by themselves after a while but then come back. Been going on for maybe a week, I haven't had time to look into it properly yet. These are on different licences, different locations.

In my case, both users are on Windows 10. I am unable to get the build right now but I would suspect 22H2.

Edge Version 111.0.1661.51 (Official build) (64-bit) ESET Internet Security 16.0.26.0 Since yesterday, 2 of my users have reported that Microsoft Edge will not load any pages. I connected to check and observed the same, each browser has the green outline around it to show it is Eset protected, no pages including internal pages like edge://settings will load. The page is blank with "Untitled" title on the tab. I tried Edge repair and forcibly uninstalling Edge, reinstalling Edge but the same issue is present. I renamed the default Edge profile folder which worked for a few minutes then the issue returned. I then disabled Eset protected browser, restarted Edge and it works like normal now. The workaround is to permanently disable the protected browser feature of Eset, hopefully an update will fix this but thought I would report as I expect this is fairly widespread, most of my licenses are for Endpoint Security which is why I haven't seen more users with the problem. Thanks

I changed my detection rule from MSI to registry, compare version, greater than or equal to and then use the version of the agent I am deploying manually. I need to test it fixes the issue but now if the PROTECT server auto-updates the agent, then my detection rule should still apply.

I have found the regkey so will work on a custom detection rule now, in case it helps others: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ESET\RemoteAdministrator\Agent\CurrentVersion\Info\ProductVersion

I have been successfully deploying the Protect agent via Intune for a while now using the steps here: https://support.eset.com/en/kb7846-deploy-eset-management-agent-using-microsoft-intune-microsoft-endpoint-manager Since late last year, I have had users reporting a Windows toast notification to say the agent installation has failed. I believe the cause is that the agent auto-updates itself and that breaks the detection rule which uses the MSI product code from the version I deployed myself. Is there a regkey that stores the agent version info that I can use for my detection rule to say equal or greater than? Thanks

Oddly enough, the client had to go out so left the system idle, when they returned a few hours later the status says protected. I am not sure why it took time to get to that stage after following the guide, we had already tried restarting which had no effect.