j-gray
-
Posts
620 -
Joined
-
Last visited
-
Days Won
5
Posts posted by j-gray
-
-
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?
-
13 minutes ago, Marcos said:
By proxy you mean ESET Bridge?
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.
-
10 hours ago, Marcos said:
Downloading info.meta in a browser or using wget or curl must work or there is a problem with a firewall or proxy blocking the download as ewong wrote.
@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.
-
22 minutes ago, Marcos said:
Users of other vendors have also experienced network issues after upgrading macOS to Sonoma. Similar issues occurred after upgrading to Ventura and Apple addressed them later in a hotfix.
Before upgrading to Sonoma ESET Endpoint should be either upgraded to v7.4 or v7.4 should be installed from scratch after the upgrade.
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?
-
6 hours ago, karlmikaeloskar said:
Can you confirm what your update settings were? I think my mistake was that I was letting EEA update itself.
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.
-
On 9/28/2023 at 6:36 AM, avielc said:
This is causing all the dev machines running Ubuntu to be automatically updated to 10.1.8.0 and then receive a task to automatically downgrade back as there are rules\dynamic folder-tasks in place to make sure everyone are on a certain version.
WIthout me knowing about it, this will throw them into that loop.
Also, if the version is broken, I won't know about it until I hear the devs scream in agony that things aren't working for them. - I can't have that.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.
-
16 hours ago, e-rally said:
On the machines that are updated to 7.4.1100.0 they are now failing to get updates.
This may be a side effect of the version being pulled?
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.
-
7 hours ago, Marcos said:
It wasn't removed. It has never been there. Endpoints in a company are behind a firewall and not accessible from the Internet so pushing an installation from the cloud would be impossible.
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?
Install agent via terminal without Internet connectivity?
in ESET Endpoint Products for macOS
Posted
Or, alternatively, is there a way to effectively point the agent installer script to our local ESET Bridge?