davey

Marcos FYI - After re applying all my policies to how i want them ( without ANY proxies ) previously as per above, I notice that when i went to create an Agent installer, the code of that Agent installer configuations is set to RE APPLY a proxy and a specific IP address. Are proxies configured elsewhere in RA? am i Doomed to foreever re configure any new clients i now create from from the RA installers because it has the proxy configuration i dont want, that after each new installtion i have to re apply another policy to undo the config applied by the installer? Think there may be a bug here? I am obvioulsy aware of it now but is this similiar structure affecting thousands of other eset admins, and of course the re occuring support? Agent installer was ERAAgentInstaller.bat = line of code was 'set http_proxy_hostname=***.**.**.***' (All Policies I have switch OFF proxy, I have modified the batch file myself to how i want it but this installer config is not being pulled from current live policies ) Let me know if you need further data. Regards

OK, after Marcos checked the logs, looks like this was failing due to being denied pass through from a proxy server. Funny thing is, i don't pass these through a proxy server and trying to pass traffic through a printer for some amazing reason was not reaching eset I am not sure yet how policies pushed from the RA applying to clients were set in the first place, however moral of this story............check for proxy

Marcos Thanks, I have sent you three files: - eea_logs 1433 Full Diagnostic Activation fail.zip = All options as described and logs taken after an activation fail - eea_logs 1442 Diagnostic Informative fail.zip = Reversed with informative logging - eea_logs 1458 = Logs after MBAM uninstalled ( MBAM will only be indicitive to myself and will not be on all other clients that fail ) To reiterate, this error message only occurred once my license was renewed. License was successfully renewed and I did not have to apply anything in the Remote administrator, once the updated date was reflected in the remote administrator, the clients then gave the license expiry message. Regards

OK Client -> Setup -> Advanced Setup -> Tools -> Diagnostics -> Enable Network Protection Advanced Logging = Yes/NO I have processed a local client activation attempt and a remote administrator one, which can both be seen in the logs ( which i have sent directly to you outside of this public post) at 12:45 + Cheers

Has anyone Gone past the renewal date reported by the client? does the client still communicate with the server in the same fashion ( updates / signatures etc ) or does the client halt all updates because of its false belief its not licensed?

MichalJ Unfortunately, this issue is still present for my clients: - Actual client will display a license expiring message - Remote administrator displays an alert for the client showing 'license expires' I am running this from a product activation task in Remote administrator, selecting my current valid license which I can confirm is a year ahead and specifies the correct date next year, however running this on clients fails, no details, just 'Task failed' on RA and on the client log file specifies 'Activation was not successful: Could not reach the activation server' If i manually attempt to enter the license key ( has remained the same on renewal ), i select Activate product on the protection status warning page, select 'enter a license key', I also receive an Activation failed message as per screen shot, this however has an additional error code ECP.20009 Regards

Hi all, i renewed my license about a week ago and all is good in on the remote administrator specifying the next expiration date. However, I was expecting my clients to catch up, althoug, now i have all my users worrying their AV is going to expire, when in fact it wont, or will it since the client thinks it will and stop updating? Anyway I have tested applying an activation task from the remote administrator which then fails on the client with 'Activation was not successful, . Could not reach activation server' I have applied the same license on the product activation task ( the only one ) that's valid and in date on the server. I have also checked the client can reach https://edf.eset.com/edf I expect, yes i could apply a policy so clients hides the license information, however i think that is defeating the point Anything I am missing here? anyone come across this or is something going on at eset's end? ESET Remote Administrator (Server), Version 6.5 (6.5.522.0) current client I am testing product activations on 7.0.2073.1

MartinK Ok, I am now all up to all clients connecting on the new ERA I am not convinced it was certificate after retracing the instructions, I added another step https://support.eset.com/kb6492/ II. Apply the Agent Certificate in a new Agent Policy on your new ERA server, Server Two in this example. and added the new ERA server on this step as technically this step only specifies adding the agent certificate ( even though the screen shot show otherwise under step 6 ( servers to connect to ). I am not sure if this was missing in the instructions or i inadvertently adding something just to let you know in case the instructions need tweaking Dave

MartinK Thanks for the reply and the heads up on the status.html. Yes indeed the clients are still connecting to the old ERA and as i can see in the Last-error.html, the policy applying the new ERA server has correctly served its purposed, but, yes I have done something ridiculous with the certificates because of the error 'CReplicationManager: Replication (network) connection to 'host: "***********" port: ****' failed with: Receive: NodSslWriteEncryptedData: Incorrect/unknown certificate or key format.' I will retrace my steps on the https://support.eset.com/kb6490/ Thanks

Hi all I have migrated my ERA server (6.5.522.0) to another server. followed https://support.eset.com/kb6498/?locale=en_US&viewlocale=en_US and proceeding instructions and all good. However, my clients in the new server only communicated once with the new server ( with or without the old server era service off ) and fail to speak to it, presumably I am doing something stupid here with the certificates. If i switch the old ERA back on clients revert to that even though i can see the correct policy applying to the client to divert to the new server. I will most probably go through the whole process again, but if any big pointers, would be appreciated