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)