The client changed the IP of the ESET server and lost the connection of 2800 computers

[Mauricio Osorio 2]

The client made an arbitrary IP change without changing the routing of the agents and now cannot return the old IP.
Is it possible to carry out a solution that allows the change of the IP in the agents in a massive way?
It should be noted that the agents were password protected and when performing a GPO installation the addressing does not change, apparently for this reason.
How can I help this client?

[Marcos 5,273]

I assume the agent was set up to connect to an IP address instead of hostname. If it's not possible to change the IP address back and then continue as per https://help.eset.com/protect_install/90/en-US/migrated_database_same_ip.html, then the only way to re-establish connection will be by re-deploying the agent using the new server address and certificates.

[Mauricio Osorio 2]

According to the client it is not possible to return to the previous IP. It is a public health entity and they are blind and at risk, any way to install the agent massively with the new connection data?

[Marcos 5,273]

There are several ways how to deploy agent, please refer to https://support.eset.com/en/kb7655.

[Mauricio Osorio 2]

When trying any remote installation task it fails, as I mentioned above, this is possibly because the agent is password protected:

Could I send the installer with this password somehow?

[tmuster2k 22]

Do you know what version of the ESET Management agent were you on? 

[Marcos 5,273]

Please follow the instructions for re-deploying agent over an existing password protected agent in https://support.eset.com/en/kb6745.

[tmuster2k 22]

in my testing, it appears that if you are already on the latest version of the agent that you cannot do install over the top and the task will fail if deploying. If you run locally with agent .exe file locally it will give error "Latest version is already installed". I don't remember this with previous versions like with 8.x but maybe something has changed. The only option appears to run script to remove orphaned agents and then do fresh deploy. 

[Marcos 5,273]

It's possible to repair agent locally and change settings so if you re-deploy it via GPO, ESET Remote deployment tool, etc. using the live agent installer with new server settings, it should work.

[MartinK 384]

6 hours ago, Mauricio Osorio said:

Could I send the installer with this password somehow?

In case you are using GPO deployment method, i.e. distribution AGENT installer with configuration in install_config.ini file, simplest would be to modify install_config.ini by adding PASSWORD=... as visible in referenced KB6745. I guess you already modified this configuration file with new IP address or hostname.

Also note that if AGENTs are configured to connect IP address or new hostname, certificate of ESEET PROTECT Server service has to be adapted for this if it was not previously (especially in case certificate is not using wildcard host which is not default). Otherwise AGENTs will be rejecting connection as they will consider it as an unsecure. IF this is the case, you will have to follow one of the migration scenarios - most probably this one: https://help.eset.com/protect_install/80/en-US/?migrated_database_same_ip.html. In the most optimistic scenario, creation and application of new ESET PROTECT Server certificate with proper configuration should resolve this - especially in case the same certificate authority will be used to create new certificate.

[Sameer 2]

Create a "Deploy Agent first (Agent script installer)" - under Agent Configuration select the working agent policy that uses the correct EP Certificate and IP / Hostname (preferred for such scenario) and using GPO deploy the .bat to your endpoint - this script will uninstall and then reinstall the agent.

[Mauricio Osorio 2]

On 1/18/2023 at 4:34 PM, MartinK said:

In case you are using GPO deployment method, i.e. distribution AGENT installer with configuration in install_config.ini file, simplest would be to modify install_config.ini by adding PASSWORD=... as visible in referenced KB6745. I guess you already modified this configuration file with new IP address or hostname.

Also note that if AGENTs are configured to connect IP address or new hostname, certificate of ESEET PROTECT Server service has to be adapted for this if it was not previously (especially in case certificate is not using wildcard host which is not default). Otherwise AGENTs will be rejecting connection as they will consider it as an unsecure. IF this is the case, you will have to follow one of the migration scenarios - most probably this one: https://help.eset.com/protect_install/80/en-US/?migrated_database_same_ip.html. In the most optimistic scenario, creation and application of new ESET PROTECT Server certificate with proper configuration should resolve this - especially in case the same certificate authority will be used to create new certificate.

We are trying to implement the solution you give us. I will be informing you of the result.

Thanks.

BTW: local support says there is no solution other than manual deployment.

[Mauricio Osorio 2]

Thanks for your instructions. We have managed to get a .bat file to replace the agent and direct the computers to the new IP address, but when sending it by Windows domain we have no positive results.