puff

Disabling SD allowed me to update the agent version. Thanks.

Will that allow me to kill the agent process? I'm almost 100% certain that the agent upgrade is failing because the agent process cannot be stopped. These are production servers so if there is a way to kill the process without rebooting that would be best, but I can try disabling SD and rebooting after hours if that's the only way.

Any update on this? I just need an ESET friendly way to manually kill the agent service so I can upgrade these servers. All the methods I've used so far are unsuccessful, as the agent service just restarts immediately. Attempting to set the service to disabled just gets me access denied messages.

My upgrades failed due to an extended power outage that required me to shut down all servers. I tried manually uninstalling the agent though from one guest server and it fails, as the agent service cannot be stopped So I think that may be the root of the problem. How can I force terminate the agent service?

I'll run another Components Upgrade and then upload the trace log. It might be a bit as it stays in a "running" status for quite a bit before it times out and shows failed.

I have several Hyper-V guests running Server 2016 Std that will not upgrade to Agent 7.0.577.0 . They are currently running version 7.0.553.0. I have tried upgrading via "Components Upgrade" from SMC and with a manual installer. The Hyper-V hosts (also Server 2016) and all other computers on my network have upgraded to 7.0.577.0 without a problem. Is there a known issue installing the latest agent on Hyper-V guests?

Hi Marcos, Thanks for the tip, but as stated I don't see those applications in the File Security for Windows Server policies: They're listed under "WEB AND EMAIL" in my Endpoint policy, but they're not listed under any of those categories in the File Security policy.

Since upgrading to ESMC and v7 my servers constantly display these two security risks. I don't want either feature turned on for servers and would like to just disable the notification. I've looked in the policy setting for my servers under User Interface>Application Statuses, but these two applications are not listed in the File Security for Windows Server policy. I do see the two application statuses in my Endpoint for Windows policy, but that policy is of course not applied to the servers. How can I disable these notifications?

I didn't even think about the domain rejoin in the context of the name change. I'll just join the new server as a different name and remove the old one when I decommission it. Thanks! You're always a big help.

I'm getting ready to deploy an ESMC VA for the purpose of upgrading my ERA 6.x VA. I have a few questions. Do I need to export all of my existing certificates and reinstall them on the new server? Or is this done automatically as part of the database pull? I want to give the new server a different domain name. I believe the certificates are just tied to the IP address (which I will be keeping the same), but will a name change break anything that I should be aware of? Do I need to remove the old server from the domain, and rejoin the new server to the domain as part of the upgrade process? Thanks!

Thank you. The same happened to our ERA Appliance after installing updates. This fixed it.

Agreed. I'm working remotely over the holidays and I don't have physical access to any of these affected desktops to try a safe boot force removal. I'm now worried that these PCs are going to be vulnerable. At this point I'd prefer to just roll back to 6.6.2064.0 and not worry about it, but I can't uninstall the client from any of the failed PCs.

Add me to the list of failed license activation. Of the 30 desktops I upgraded to 6.6.2068.0, ten of them are displaying: Trying to uninstall the product so I can perform a fresh install leads to the uninstaller freezing on "Preparing uninstallation". This needs more attention and a solution from ESET.

Got it. The new agent certificate, new server certificate, and new CA were all created during installation of the virtual appliance. That was a couple of months ago so I'd imagine all agents should have the required CA, but I'll start with a small group to test it and roll it out in sections until all the agents are updated, then change the server certificate last. Thanks for your help!

I recently migrated Remote Administrator to a virtual appliance and during the migration I changed the server certificate to match the old server's certificate (following this guide). Now I would like to update all of my agents to use the new client certificate that was created during the virtual appliance install. I know I can change the agent's certificate by applying a new policy. My question is do I update all the agent's certificates first and then change the server certificate or the other way around? I don't want to break the communication between my agents and the server by changing the certificates in the wrong order. Thanks!