Jump to content

Re-Write Agent Config to Point to another ERA


Recommended Posts

Hello,

I may have a bit of a unique situation going on, and I'm not entirely sure how to address it properl?. Long story short, we have two different sites. Initially, when we switched to ESET from Kaspersky, I deployed agents out to both sites from ERA at first site. For audit reasons, it has been decided to split the two sites. I deployed a second ERA to the second site, configured everything and am now set to go over there, with a successful install on a new server already completed. I've since removed all the AD syncing, etc pertaining to the second site, from the first ERA. My question now is this: All the agents in the second site are 6.3.136.0 and I have 6.5 ERA deployed in second site; is it enough to run a components upgrade task from the second ERA on any of those servers from the second site in order to re-write the agent configuration and have the newly upgraded agent point to the second ERA at that second site? Let me know if I need to clarify anything. Thank you all in advance.

Link to comment
Share on other sites

  • Administrators

In order to point ERA Agent to another ERA Server on more computers, generate a new Live Agent installer to ensure that correct ERAS settings are used and current certificates are included and re-deploy it on the machines.

You can do it also manually but you'll need to install agent twice. First time to upgrade it to the latest version and second time to do a repair which will enable you to set up connection parameters and certificates.

Link to comment
Share on other sites

So if I create a Live agent (6.5.522.0) installer from new and second ERA (with correct certs and settings), then drop it on the desktop of a server with an agent (6.3.136.0) pointed to Old and First ERA, and then Run the live installer as Admin; the result would be a rewrite of the config and an upgrade to the agent? 

I'm not sure what you meant by manually? Is the scenario I just described above, considered manual?

Thanks for the help.

Link to comment
Share on other sites

  • Administrators

Yes, that's correct. Sorry for the confusion, by "manually" I meant running an agent msi installer. When running a Live agent installer (batch file), it will download the msi from the repository and use embedded ERA settings and certificates during installation.

Link to comment
Share on other sites

  • ESET Staff

Actually be warned, that if the version of ERA agent is not the same as the one installed, first attempt will perform only upgrade (keep the configuration kept) and then the second attempt will do the "repair" (adjustment of the configuration parameters to point it towards the new server).

Link to comment
Share on other sites

Ok, I just ran the batch file with the new ERA configuration inside, and the first time updated the agent, just like you said. The second run did not change the config.I decided to wait and run a third time, but still no dice.The agent is still checking into the first ERA. Is it possible that since the agent is password protected, it won't rewrite the config unless I remove the password protection on the policy?

 

Link to comment
Share on other sites

  • Administrators
Just now, whitelistCMD said:

Ok, I just ran the batch file with the new ERA configuration inside, and the first time updated the agent, just like you said. The second run did not change the config.I decided to wait and run a third time, but still no dice.The agent is still checking into the first ERA.

It's enough to run the batch file just once. When I said to run it twice, I meant the msi installer - first time it would upgrade to the latest version and the second time you would be able to run a repair and configure connection parameters and certificates. This is not needed with the batch file - connection parameters as well as certificates are set by the batch file.

You can view the batch file (Agent Live installer) and make sure that the connection parameters are correct.

Link to comment
Share on other sites

I just ran the batch like you said, and it's not rewriting the config. It's still connecting to old ERA. The parameters are set correctly in the batch. If I run the batch on a new machine with no Agent, it connects to the correct ERA.

Link to comment
Share on other sites

It was the password set on the agent. I quickly made a policy to sit over the top of first agent policy that force disabled the password. Then re-ran the batch on the server, and now the agent is checking into the new ERA. Thanks for all your help guys.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...