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!

Awesome. Thanks!

Is there an official release date planned for ESA 2.6 yet? Support wasn't able to give me an exact date but since it's close to the end of March I'd imagine it's any day now.

Fixed by pulling the config from a test appliance as you suggested. For anyone in the future who may run into this problem I edited the /etc/krb5.conf file as such: [libdefaults] default_realm = MYDOMAIN.LOCAL ticket_lifetime = 24h forwardable = yes [realms] MYDOMAIN.LOCAL = { kdc = myserver.mydomain.local } [domain_realm] .mydomain.local = mydomain.local Apparently you should NOT use the CentOS Webmin to edit kerberos settings as it adds a bunch of formatting that will break your active directory sync. Edit only from the terminal using vi or the "Configure domain" wizard in management mode. Also, my default gateway was removed at some point. I ran a bunch of CentOS updates from the Webmin. Do you think that could have broken it? Lastly my network interface is showing this : and this: The network seems to be running normally though, but I do not have this error on the test appliance I configured. Could this be the result of anohter CentOS update? Does ESET recommend not updating CentOS as a best practice? Thanks!

Also, when I run through "Configure domain" from the server console, after the "Check Kerberos configuration in /etc/krb5.conf" I get: Clearing Kerberos cache... kdestroy: Improper format of Kerberos configuration file while initializing krb5

Tried adding the admin_server line. Also tried deleting the old domain controller out of /etc/hosts. Wouldn't deploying a new one do the exact same thing as rejoining the domain? The ERA is successfully joined, and I can rejoin it with no problem and verify that it shows up in active directory. Maybe something is broken from the original configuration though. Might try a new one like you said just to see what that file says.

I'm using an ERA virtual appliance. Active Directory sync was successful when initially configuring ERA, and ERA is joined to the domain. I recently upgraded domain controllers and changed domain controller names. Now when trying to sync from ERA I get "Improper format of Kerberos configuration file while initializing Kerberos 5 library": I've rejoined the virtual appliance to the domain and verified that it's showing up in active directory I updated the KDC from the Webadmin as such: I updated ERA sync settings as such: I've browsed through my /etc/krb5.conf file but without knowing much about it I'm not sure what it should look like. It looks like this: [logging] default = FILE: kdc = FILE: admin_server = FILE: [libdefaults] default_realm = MYDOMAIN.local [realms] MYDOMAIN.local = { default_domain = kdc = myserver.mydomain.local: admin_server = : } [domain_realm] .mydomain.local = MYDOMAIN.local Any help is appreciated.

Thank you for all of that information. I'm configuring Remote Web Access though, not Remote Desktop Web Access. They're similar but two different web applications. I even accidentally selected RD Web Access during ESA configuration the first time and it returned an error that no such web application was installed. I'll try contacting support and see if they have an easy fix for me, or if I should just wait for the next release.

I've installed ESA and selected the RWA Application Protection. The ESA OTP page is not displayed when logging into RWA. In the ESA Management Console nothing appears under "Web Application Protection". I've restarted IIS, and uninstalled/reinstalled RWA protection in the ESA configuration. Is this just an incompatibility with Server 2016? The manual I have ends at 11.2.2 and goes to Chapter 12 "API". It's pretty short on information concerning configuring ESA with RWA.

I'm planning to begin using ESA for RWA two factor authentication (Anywhere Access on Svr16). I have three questions: Can ESA be installed on Server 2016 standard with the Essentials role? I don't see it in the list of supported OS but I'm wondering if there are known issues, or if the documentation just hasn't been updated. Can ESA be installed on a domain controller? I have a redundant backup DC that isn't doing much that I'd like to install it on. During the installation of ESA do I need to select both "Remote Desktop" and "Remote Web Access" or just "Remote Web Access"? I want two factor authentication on the initial RWA login page, so I'm guessing I only need the latter but I want to make sure.

Yep. Looks like it. I tried searching through all the forums for that error and somehow missed that thread. Thanks!