What is the solution to forcibly uninstalling the agent via fleet while offline, but the uninstallation is not clean and the logs are kept and the host cannot be contacted? Thanks
Hi,
I've attempted to reproduce your precise situation as reflected in the screenshots, but have not been able to. In the circumstances where the Agent has been unenrolled, Defend's attempt to send data are rejected and I'm unable to get it to reflect as more recently seen as your screenshot shows. If you happen to know the precise sequence of events that reproduced this condition, let me know.
Unfortunately if the Agent is unenrolled, there is no mechanism available through Fleet to uninstall any remaining components. If you're able to execute commands on the host independent of Fleet, perhaps using whatever mechanism was initially used to install the Agent on the host, then you should be able to fully uninstall Agent and Defend.
If you find the host still has C:\Program Files\Elastic\Agent\elastic-agent.exe, then you can uninstall that by executing, from an elevated Administrator command prompt, C:\Program Files\Elastic\Agent\elastic-agent.exe uninstall.
If you find the host no longer has the Agent at that path, but does have the Defend endpoint installed, you can independently uninstall that by copying C:\Program Files\Elastic\Endpoint\elastic-endpoint.exe to a temporary path and in then invoking that copy's uninstall option. For example:
If that doesn't resolve the situation, please let me know.
First of all thank you very much for your reply, the diagram shows that the agent has been uninstalled via fleet, but it seems that the Defend endpoint has not been uninstalled and there is still ongoing to log input. However the host owner cannot be contacted so it is not possible to uninstall locally, is there any way to uninstall via fleet or api?
The problem I'd been having attempting to reproduce your present circumstance is that when the Agent was force unenrolled, the API key was invalidated, and even with the Defend integration remaining on the host attempting to send new events, it'd log that Elasticsearch had rejected its invalidated API key. That meant that the host screen I'd been seeing wasn't reflecting further events or contact from the Defend integration as yours obviously was.
However, I had the idea to configure integrations to output to Logstash and then setup Logstash forward to Elasticsearch, and that indeed recreated the situation you're observing after I force unenrolled the Agent. So is that likely the configuration you were using? I just want to understand what configuration and steps have produced the present state.
Unfortunately, in that state, there is no way to uninstall Defend (or Agent or other beats if they also remain) via Fleet. With the control channel between the Agent and Fleet broken through unenrollment, you'll need to find another path to execute the uninstall commands on that host.
yes,was configured to export to Logstash and then set up Logstash to forward to Elasticsearch.
So why is it not possible to uninstall Defend together with the fleet uninstall agent?
[another path to execute the uninstall command on this host] This means that the uninstall needs to be done locally on the computer? What other way is there?
Or how do I need to change the configuration of the output to logstash to achieve this?
The option presented in Fleet is termed Unenroll and does not also uninstall Elastic Agent proper. Documentation regarding the uninstallation of the Elastic Agent proper can be found here, but currently always requires that a command be run on the host through a means independent of Fleet. A github issue exists where there is a conversation as to whether to change that behavior or add an additional option to fully uninstall Agent through Fleet, in case you'd like to share your opinions there.
There are a couple of nuances to be aware of though that might be relevant to this particular discussion. If a user elects to Unenroll an Agent that is still communicating to Fleet, but does not use the Force unenroll agent option...i.e. the box in the screenshot is not checked:
....then the Agent that remains on the host will be reconfigured to not have any integrations left configured and will uninstall integrations like Defend. Of course the API key used to send events directly to Elasticsearch is also invalidated through this unenroll action.
If however the box is checked to force an unenrollment, a circumstance intended for use if the host is no longer communicating with Fleet, then while the API key is similarly invalidated, the Agent's configuration will not be changed and integrations such as Defend will remain installed. In configurations where integrations like Defend had been sending data directly to Elasticsearch, the invalidation of the API key means that no new data will be able to be successfully sent.
In your circumstance though, since you had integrations configured to send to Logstash, the invalidation of the API key doesn't thwart that path and the remaining Defend integration remains able to submit data through Logstash.
As an Defend developer, I'm not able to confidently speak on whether there might be a way to reconfigure Logstash to meet your goals. I suppose if it were practical to rekey, or migrate to a new Logstash server, everything that you'd like to remain functional, the integrations on the orphaned host(s) would no longer be able to successfully communicate with your Logstash server.
This means that the uninstall needs to be done locally on the computer? What other way is there?
Unfortunately, that's correct. With the Agent no longer enrolled with Fleet, there is no way to trigger the uninstallation of Defend or other integrations. The only solution to fully uninstalling Agent from that host requires the ability to execute commands through some other means (locally, remote management tool, etc.)
Thank you very much for your reply. As shown in the figure, if you do not check the mandatory uninstall to uninstall the offline client, will the uninstall task be performed again when the client is online? Or do you need to send the uninstall task again when you are online?
If you do not check the Force unenroll agent box, then the unenrollment is queued and when the endpoint's Agent next connects it will pick that up and it will be configured to no longer have any integrations, which would trigger the uninstallation of Defend as mentioned above. However, Agent itself will remain on the box until removed by some other means.
I received some additional details from the Fleet team I can add. There is no timeout or eventual automatic forced unenrollment, it'd always be a manual step to force unenroll. So if you do the normal (box not checked) unenroll and the endpoint's Agent eventually connects again, even months later, it'll indeed pick up that unenrollment that had been pending for that time.
okay,thank you very much for your reply.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.