Remote Agent Deployment fails

[bbraunstein 27]

I'm in the process of migrating/upgrading my current ESET v5.x to 6.x. I have the Server, Web Console, and Database successfully set up. I have been able to install the Agents and products locally on sandbox computers with no issues. This computer used to have ESET v5 installed, which I uninstalled, and locally installed the Agent + AV, so the settings are already preconfigured to accept incoming connections from an ESET server. My company is spread across three different countries, so Remote Installation is a must. 

 

The computer is running Windows 7. I'm trying to deploy ESET Endpoint Antivirus. My server is running on a CentOS 6.5 VM. For comparison, the old ERAC was on a Windows 2012 R2 VM. 

 

I was able to successfully deploy Agent and Product locally on this computer. I uninstalled everything and now I want to deploy remotely. I followed the documentation to get a more verbose log by changing the trace log value to 'Error' and generating a report.

 

The context of the report shows me this:

2015-01-28 17:53:52 Error: CRemoteInstallModule [Thread 7f49a41cc700]: Executing remote deployment of agent 3d1bbc18-1e40-4b3d-8cdf-597ffffb81a2 on 'chosenia.modusagency.com'

Windows network remote deployment failed.

- Verify that 'chosenia.modusagency.com' is responding to 'ping'.

- Verify that 'chosenia.modusagency.com' can be resolved with 'nslookup' if it is a DNS name.

- Verify that firewall is not blocking communication and file sharing between server and the target machine.

- Verify that "File and Print Sharing for Microsoft Networks" is enabled on the target machine.

- Verify that "Remote Procedure Call (RPC)" service is running on the target machine.

- Make sure that simple file sharing is turned off on the target machine.

- Activate sharing resource ADMIN$ on the target machine.

- Verify that 'modusagency\spicescan' has administrator rights or use local 'Administrator' account that is enabled on the target machine.

- Verify that 'modusagency\spicescan' password is not blank.

- Verify that you can remotely log on to the workstation from the server.

- Verify that from server machine you can access 'net use \\chosenia.modusagency.com\IPC$' from the Command Prompt.

- Change 'ESET Remote Administrator Server' service credentials from 'Network Service' to user with domain administrator permissions temporarily for deployment.

* Error details: std::exception

SSH remote deployment failed because CONNECTION CAN NOT BE ESTABLISHED to the target LINUX or MAC machine.

- Verify that 'chosenia.modusagency.com' is responding to 'ping'.

- Verify that SSH daemon is enabled on the target machine and is running on the port 22.

- Verify that firewall is not blocking SSH communication between server and the target machine.

* Error details: connect: Connection refuse

 

Now, even though all these settings were necessary for the initial install of ESET v5, I still went back and double checked each setting on the computer. All the settings are configured as the log suggest. Is there something else I am missing? Or is there 'kind of, sort of "support"' for remote deployment?

[anthonyh 15]

Just to be sure, has the CentOS machine been joined to the domain? 

[sdsnyr94 1]

I'm going to jump in here with the same problem. ERA 6 Server on CentOS VM (Appliance provided from ESET, ESXi), and the Server is on the domain. Attempting to deploy the agent gave the same errors as the OP.  I verified that the unit was on the domain. While looking at the logs, I noticed the timestamps were off... which made me think about the timezone... which turned out to be set incorrect.

 

Correcting the timezone fixed the deployment to some PC's but not others. On the others, I was getting a mount error(12): cannot allocate memory. These computers are 4 year old Dell's that only have 2Gb RAM, and apparently there is a Windows 7 glitch regarding cifs shares regarding memory.  To resolve that you need to do the following on each unit:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v "LargeSystemCache" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v "Size" /t REG_DWORD /d 3 /f

NET STOP LANMANSERVER /Y
NET START LANMANSERVER /Y

I got the above from : https://wiki.archlinux.org/index.php/Samba/Troubleshooting

 

I put this in a batch file that I could deploy with PDQDeploy when needed.

 

One request to Eset Development - Better error messages in the Web GUI, the only messages I have gotten are Task Failed with the Generic troubleshooting steps.

[Peter Randziak 1,130]

Hello,

 

can you please send me a private message with reference to this topic with the logs?

 

We will check it.

 

P.R.

[michalp 20]

The cryptic error line "* Error details: std::exception" will be fixed in next release, so it will be possible to determine exactly what is not working in this specific case.

[THECOM 0]

i have same problem, if i am deploy using ERA server 5 not problem, why in ERA server 6 problem like this.. 

hxxp://i58.tinypic.com/1zmdz7o.jpg

[bbraunstein 27]

If the client computer is NOT part of the domain, or the hostname cannot be resolved, I found that by changing the name of the client to its IP address allows the push to succeed.

 

In your case, on the Web Console, click on the client and then select Details... On the first column, "Name", change hsc-edy to the IP of the device. Then try another push. This is what resolved the deployment issues for Linux/Apple devices on my network that are not part of the domain and do not have A records. But I never tried this on Windows computers. You can try and see if this resolves for you.

[robscott27 0]

I have/had this same sort of issue with version 6 as well. Only my ERA server is on a Windows 2008 machine. All the clients that the remote agent is going to are WIndows 7 based machines. Two things I've noticed - whether they help or not, that'll be up to you:

 

1. The Windows firewall, if on, will block the install. Turning it off will *sometimes* allow it to install, but will still fail due to #2 below

2. We have a Barracuda Web Filter 610 installed which blocks web access if the user has not authenticated against Active Directory. If the client machine (and possibly the ERA server, I'm still testing this one out) does not have web access, the remote agent won't install. The error generated on the backend ends up being: Failed to synchronize package repository.

 

More often than not, the firewall is the cause - at least in my experiences with my machines. Not sure if that helps at all, but figured I'd contribute as I've experienced this sort of thing as well.

[jbossbarr 2]

This product is garbage - beta software with no KB, no help, no support, and no response from ESET.

We are decommissioning this pilot on 2 of our clients because of too many issues and super, super long hold times from ESET.

Use version 5 - DO NOT deploy this ERA version.