j-gray

Or, alternatively, is there a way to effectively point the agent installer script to our local ESET Bridge?

Strange scenario, but we're needing to install the agent on OS X devices without internet access. We typically use the ProtectAgentInstaller.sh remotely but it attempts to download the agent from ESET. Is there a way we can install the agent via terminal that does not require a download and can also include the required connection parameters?

In our on-prem instance, one of the server tasks (static group synchronization) had the ability to reconcile duplicate systems but we seem to have lost that functionality when we moved to the cloud (AD Scanner tool does not provide for this). Is there any method available to merge or otherwise reconcile duplicate systems?

No, I'm referring to the 'ESET Web&Email' component that gets installed (below). It's always there even though we have Web and Email protection disabled. And it frequently causes network connectivity issues, particularly on new installs and upgrades. When attempting to download info.meta on one of the affected machines, I copy/pasted the URL you provided above into a browser window and it failed. Because agent upgrades were failing, I tried manually running our installer sh script, however, it also points to the same ESET repository, so failed as well. Once I removed ESET AV, I could access the repsository. No idea why the ESET components would be blocking its own repository.

@Marcos I was able to sit at one of the affected workstations. Notable, I could browse to any site except for the repository site you specified above. It was blocked for some reason. I uninstalled ESET and was then able to browse to the ESET repository site. Even though we have Web and Email protection entirely disabled, it seems the ESET Web&Email vpn/proxy component continues to throw a wrench in the works. We have about 90 workstations that are not updating modules, likely due to the ESET proxy component. Which means we also can't upgrade the agent nor the antivirus. ...and all this is a bit odd since we're using the ESET Bridge, so my assumption is that they should be getting module updates and component upgrades from the Bridge and not directly from ESET repository.

@Marcos Thanks for the reply. Unfortunately, most systems are at remote sites so I can't directly test with a browser. I can tell you that curl returns the same results: Using the following command: curl repository.eset.com/V1/info.meta I get this result: curl: (7) Failed to connect to repository.eset.com port 80 after 38 ms: Couldn't connect to server

We have a handful of clients that throw this error when running the agent install/upgrade task. The error is always: Downloading installer image 'hxxp://repository.eset.com/v1/com/eset/apps/business/era/agent/v10/10.1.3268.0/agent_macosx_x86_64.dmg curl: (7) Failed to connect to repository.eset.com port 80 after 35 ms: Couldn't connect to server. The clients can ping internal and external DNS servers and can ping repository.eset.com and get replies. If I run curl and point to 443, I get a '400 bad request' error, "Plain HTTP request was sent to HTTPS port". So it appears it's making connection attempts as expected but for whatever reason cannot connect to port 80. Possibly the timeout is too short? Any other hints or suggestions? Seems to be a common occurence.

@OlafB Just a heads-up; we've been on-prem for some time, but when it came to renwal time (~30 days), ESET increased the price of the on-prem solution by 112%. With that little lead time and such a significant increase, we had no choice but to go (extremely grudgingly) to the Cloud. This was early October of this year.

For reference:

It looks like version 1.12.3296.0 released around four days ago. The updated EI Connector for clients is available already in the repository, but our EP Console still shows 1.12.3290.0 (Oct 16 2023 15:02:05). How do we know if/when the Cloud Console will be updated? Are we to expect issues if the clients are on a higher version than the server?

Does anyone here use the AD Scanner? I'm finding that it simply doesn't bring over any AD workstations that are unmanaged. Can anyone confirm? I have a case open with support, but it's been 5 weeks with nothing useful so far. We're still stuck with the issue where systems go into Lost & Found and never get sync'd back out unless or until we uninstall and reinstall the Sync tool.

Thanks for the reply. In this case these are OS X devices. They typically just stop communicating and we must uninstall/reinstall the EP agent. On OS X, the status.html page is not viewable remotely and if copied it provides no information. I was able to remotely generate the customer_info.tgz file and look at the trace.log file. It's essentially full of the following, repeating several times per second: 2023-10-18 06:29:26 Warning: CEES7MConnectorModule [Thread 0x700003827000]: Failed to execute ERALoginToLogd message to logd. 2023-10-18 06:29:26 Error: CEES7MConnectorModule [Thread 0x700003827000]: Initial connection to product failed. Daemon is probably not running 2023-10-18 06:29:36 Warning: CEES7MConnectorModule [Thread 0x700003827000]: Failed to execute ERALoginToLogd message to logd. And when I run the restart_agent.sh command from the device, I get: "Failed to restart ESET Management Agent".

We recently moved EI and EP to the cloud. However, I'm finding clients still stuck on the on-prem EI Server. They are not on either EP Server, neither cloud nor on-prem, so I'm assuming the EP agent got corrupted at some point, as we find from time to time. Is there any method where we can easily point these clients to the correct EI Cloud server? I'm guessing our only option at this point is to locate those random systems and uninstall the old EP agent and install the new one. This definitely is not ideal.

99% of our systems were not yet on Sonoma, yet many broke after the auto-upgrade from 7.3 to 7.4. So this issue was not specific to Sonoma but specific to the ESET 7.4 upgrade.

Any updates on 7.4?

Thanks. I've already got three cases open with support for different issues and it usually takes months. I was hoping for some community feedback in the event anyone else is experiencing this issue.

Since moving to the cloud, we have multiple OS X systems that seem to revert to hostname.local instead of FQDN in the EP Console. Under computer properties, FQDN is reflected correctly as hostname.domain. This is also reflected correctly under each system Details tab. However, the workstations still show as hostname.local in the console. We have several tasks scheduled to rename computers based on FQDN and this works for some, but not for most. The task is configured to run against 'All'. Any reason why they would revert to hostname.local and why the rename task doesn't work even when they have the correct FQDN in the EP Console?

In our case (recently migrated to the cloud), there was a global auto-update policy automatically applied to all systems. It cannot be edited: We have auto-updates disabled at the client policy as you do above. However the global policy was overriding this and caused them to auto-update anyway.

Against my better judgement, we ran with the default auto-update policy setting when we migrated to the cloud and then almost immediately got bitten by the OS X 7.4 catastrophe. So I'm back to manually managing the upgrade process. We just can't allow updates to proceed en-masse without sufficient testing first.

We're not seeing issues with updates on 7.4. Most, if not all are on today's (09/29) definitions currently.

Well.... it looks like now they've pulled 7.4 from the repository, so we can no longer fix the ones that are broken after the upgrade.

Just piling on here, as I'm encountering similar with the forced auto-upgrade from 7.3 to 7.4. After the upgrade the ESET icon indicates a reboot is recommended. After reboot, unable to launch the ESET GUI due to "Communication Error Occurred". EP Console shows 'Security Product Version' column with no value (blank). Individual clients in EP Console still reflect 7.3 and "Product is installed but not running". Can't verify on the individual clients, as the GUI won't load. So far, uninstall and reinstall seems to resolve the issue.

Poor phrasing on my part, then. Regardless, we had and used that functionality and now it's no longer available. Of course, nothing is impossible. With an on-prem proxy or bridge that caches all the installation files a task could be relayed from cloud to proxy or similar.

Serious bummer. Remote agent deployment in the EP Console was something we heavily relied on and I wasn't aware that functionality was removed from the cloud solution. Of course, the alternate deployment tools appear to be Windows-only solutions, so not much help there.

I installed and configure the ESET Bridge earlier today along with all required policies. I can see OS X client connections to the bridge, as well as cache folders created. However, when running the OS X agent install/upgrade task, clients are failing with error, "GetFile: Cannot connect to host 'repository.eset.com' [error code: 20003, previous: 20009]" It seems that OS X clients are not downloading from the local Bridge, but still going out to ESET for the required files. Is there a recommended method to troubleshoot this and determine why clients aren't getting product updates from the Bridge?