Jump to content

serious communication-errors while trying to move clients from old ESMC-Server to new Protect-Server


Recommended Posts

The old admin is away forever 😞 and me has to try a migration-attempt, but still not successful. 😥

- sorry for bad english and sorry for much text, I'm trying to solve this since 2 days (and yes, I read much here, but cant get the information that helps) -

f.i. I read this (but does not help):

https://help.eset.com/era_install/65/en-US/clean_installation_different_ip.html
https://help.eset.com/esmc_admin/70/en-US/fs_agent_connection_troubleshooting.html
https://help.eset.com/esmc_admin/72/en-US/certificates_certificate_era.html

Actual configuration (all Windows Server and Windows Clients):
- ESMC Server 7.2.1278.00
- all clients (Eset-Mgmt Agent: 7.2.xxx and Eset-AV: 8.0.xxx) are working well

New configuraion:
Because the old server is old :-) I installed 1 additonal new server:
- ESET Protect 8.1.1223.00

Idea:
To tell all clients, that they have to connect to the new server, with as less impact as possible 
(ideally no install of new client components, only to give the information regarding the new server, f.i. via policies)

New server is installed and runs well (as soon I can see).

Now I'm trying to move an existing test-client from old server to the new server.
First I removed all policys from the client on the old server (may be this was the first error).
May be I also triggered "stop administatration of this client", I made much things during last 2 days 🙂

The new server found the test-client via Rogue Detection (I think) and it is shown as unwanted device in the Protect-Console.
I was able to move the test-client then to the "lost-found" group but its totally grey with no further informations.
So, the communication between test-client and new server seems to be distorted. 😞

1.Idea: May be a certification-problem?
I exported all possible certifcates from old server and imported into new server and tried to build a new peer-agent-certificate, but does not work. (I read later, that serverbased install of agent is only with the certificate possible, that the server himself generates during its installation).
The idea of this attempt was, that the client can may be still communicate with old server and get a new policy, that describes, what his new server is ...

2. idead: May be a proxy-problem?
The status.html shows, that the test-client wants to use a proxy for replication.
But this proxy is not configured for ESET, its only a dumb proxy for internet-surfing and the Eset-AV can use it to download updates.
So I dont want, that the client-replication (agent) tries to connect the server via proxy)
And I dont know from which source the test-client knows of this proxy. May be read from some browser-configruation on this machine ...

So, may be I have a problem with certificates and proxy, but first I want to get rid of the proxy.
Because I'm sure, that the client-agent should no use a proxy.

I made a new policy on the new server, with empty proxy entries (and overwrite option), but I dont think, that the client proccesse the new rule, because the replicaton-connection is still distorted.
I made also new policy for the test-client on old server, with no proxy too, but gave also the IP for connection to new server. No real effect 😞

So the test-client is to be seen on new server in grey, but they dont talk with eachother 😞 
Or may be, the server talks to client, but the client dont talks back on the correct way.

Then I tried to deploy a newer agent version on the test-client via serverbased install.
And yes, the test-client has now installed the agent version: 8.1.1223.00 (all other clients still have 7.2.1266)
But this seems to be a oneway too. The client installs the agent but did not find a way back to communicate with his new server.
May be because he tries it still via the proxy, but the proxy does not know how to handle this (and should not handle this)

Could someone help me, to get rid of the proxy within the client-agent?

attached: a pic of the status.html on test-client  (behind the blue color occurs everytime the new server, so this part is correct)

1430338053_2021-09-1717_06_10-Statuslog.thumb.png.35218d7d8882b95235ab24e6c7076c58.png

Link to comment
Share on other sites

  • ESET Staff

So I will provide just short summary, what was most probably the easies solution to do:

  1. Install new EP Server, with new certificates generate automatically during deployment
  2. Interchange public certificate parts of CA certificates. I.e. export all CA certificates from old server and import them into new EP server, and vice versa = export CA certificates from new EP server and import them to old ESMC server. This will ensure, that both servers will trust AGENTs using both old and new AGENT certificate.
  3. Move (= export/import) policies from ESMC to EP server, especially those that has to be there to ensure full security, exclusions, etc. Just be aware that policie for AGENT should be migrated carefully, and those configuration certificates and hostnames for connectivity should be ideally skipped or adapted to new environment.
  4. Create new configuration for AGENTs in old ESMC, where you set new hostname of EP server, or ideally you can set both servers, as an alternative hostnames, where new server should be first one to be considered as an priority. Please double check that hostname of new EP server you enter into configuration is signed in EP's serverificate, especially in case certificate with wildcard "*" was not used. This can be verified in EP console, in "server settings".
  5. Assign such policy to testing device -> you should see it connecting to new EP server.

Once migration is done, you could possibly re-configure AGENTs via policy to start using new certificate, which would enable you to get rid of original certificates after some time.

And regarding your specific problem, there is an error "Agent to agent communication is not supported" which indicated that your EP server is probably using wrong certificate - any chance you changed certificate in "Server settings" of your newly deployed EP to a way that certificate supposed to be used only by AGENTs was used?

Link to comment
Share on other sites

After

  • I didn't get any feedback for days
  • I tried everything I could think of
  • my mood got worse and worse,

I decided to complete reinstall the EP server.
Lo and behold, it works!
The only difference I can remember that I made during this installation, was that I restarted the EP server after importing the old certificates AND licenses.
https://help.eset.com/era_admin/65/en-US/set_new_era_server_certificate.html recommends a direct restart.

But here https://help.eset.com/era_install/65/en-US/clean_installation_different_ip.html you can see the text: "Do not stop the ERA Server service until step 6."
Maybe that made the difference? I dont know.

 

In any case, it would be great if ESET-developers can work on more meaningful error messages.
The suspected proxy-entries doesn't seem to be a problem either, because it is regitered now in both: "HTTP proxy used for replication" and "HTTP proxy used for ESET services" and it is running. 😲
So what exactly do these expressions mean?
"Replication":      is it agent <-> server communication? (therefore my intention to get rid off the proxy-entry, because all (EP-Server + Clients) are within 1 LAN)
"ESET services":     is it ESET AV Client <-> Internet (f.i. ESET Repository Servers) communication?

and the string in logfile "Agent to agent communication is not supported" is very confusing too.
Is there a hidden agent on the server that wants to talk to Client-Agent vice-versa? Then this sentence make sense.
Ohterwise I was really confused, that my (Client-)Agent tried to talk to another (Client-)Agent ...

Client works mit new server.png

Link to comment
Share on other sites

  • ESET Staff
18 hours ago, AlexGermany said:

The suspected proxy-entries doesn't seem to be a problem either, because it is regitered now in both: "HTTP proxy used for replication" and "HTTP proxy used for ESET services" and it is running. 😲

So what exactly do these expressions mean?
"Replication":      is it agent <-> server communication? (therefore my intention to get rid off the proxy-entry, because all (EP-Server + Clients) are within 1 LAN)
"ESET services":     is it ESET AV Client <-> Internet (f.i. ESET Repository Servers) communication?

Yes, those settings are there to have possibility to use different proxy settings for AGENT-to-PROTECT communication, and all other communication, especially to the internet (= i.e. ESET servers), but generally it is for all HTTP/HTTPs traffic.
Probably all communication has some sort of fallback mechanisms, which might explain why it works even when proxy is not configured correctly, just to prevent mistakes that would cut-off control of the network just because of wrong configuration.
 

18 hours ago, AlexGermany said:

and the string in logfile "Agent to agent communication is not supported" is very confusing too.

Is there a hidden agent on the server that wants to talk to Client-Agent vice-versa? Then this sentence make sense.
Ohterwise I was really confused, that my (Client-)Agent tried to talk to another (Client-)Agent ...

As I mentioned in previous comment, when AGENT is connecting to PROTECT, it validates remote certificate and check whether this certificate is supposed to be used by PROTECT Server or by AGENT - and in this case it seems that AGENT-type of certificate was used for PROTECT Server service - so my best guess is that wrong certificate was selected when PROTECT settings were modified in one of the steps.
This whole check is actually security precaution, so that AGENT's certificate are not misused.

Link to comment
Share on other sites

  • 1 month later...

Some weeks everything run fine. Thx for the hints here.


But now I have the situation, that a new Agent-version exist (9.0.xxx)
Newly installed computers get the new version, if I start a server task with type "Agenten-Bereitstellung", may be translated as "Agent-Provisioning".
But the existing computers have still old Agent-version (8.1.xxx)

From my point of view, Agent-Provisioning is not the same as Agent-Update.
So I think I have to create a new task for Agent-Update, to update the old agents ont the existing computers.
Must it be a Server-Task again (like Agent-Provisioning).
Or can I use a Client-Task now for Agent-Updating (which template?)?

I'm asking her in the thread, because its due to naming-conventions by ESET still sometimes unclear, when to use a server-task and when a client-task. (btw. Why do I need this differentiation?)
I thought, that Agent-Provisioning should be a Client-Task too, because the goal is "Install an Agent on a Client".
But during install of ESET-Protect, I found only in the Server-Tasks a suitable Task-template for Agent-Provisioning *confusing*

Link to comment
Share on other sites

  • ESET Staff

So there are multiple alternatives:

  1. technically it is indeed client task, called "Components upgrade task" (might slightly differ in specific locations or version of the console). In this task you specifies version of your PROTECT server, and once it is executed on client machine, it will upgrade AGENT (and possibly other components) to version compatible with selected PROTECT Server version.
  2. It is on background the same, but you can use one-click mechanisms as offered in dashboard: just click on AGENT's column and update action will be offered: image.png
  3. Last alternative is to wait for auto-upgrade of AGENTs to be executed. This will work only for AGENTs 8.1+ and it cannot be disabled in configuration policies. As an results, AGENT should be upgrade to latest compatible version after some time (few weeks after PROTECT 9.0 upgrade), i.e. it is distributed in a time to not have serious impact on network and to not risk immediate upgrade.
     
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...