Our environment is migrating to a fully non-persistent VDI model, and I've been tasked with evaluating Elastic Endpoint's viability in this context. The core challenge is obvious: the agent must be installed, configured, and fully functional within a single user session, with all state and telemetry persisted externally before the instance is destroyed on logout. The traditional persistent-agent model is fundamentally at odds with this.
I have conducted a preliminary deployment test in a controlled pool. The primary performance and operational concerns I've identified so far are:
* **Agent Registration Latency:** The time from first execution of the installer within the golden image to a fully checked-in, policy-receiving state in the Elastic console is critical. In our tests, this added 45-90 seconds to user login time, depending on network contention. This is unacceptable for a seamless user experience.
* **Resource Contention During Peak Login:** Boot storms are a known VDI issue. If 500 instances spin up simultaneously, all attempting to download the latest prevention engine updates and artifact databases from the Elastic stack, this creates a massive thundering herd problem on the backend. We observed significant latency spikes in the Elasticsearch cluster during our scale test.
* **State Persistence & Detection Blind Spots:** The agent's local cache (e.g., for previous process hashes, telemetry buffers) is wiped on each session. This could theoretically create a window where a malicious artifact, seen in a previous session on the same hardware pool, is not recognized as quickly in a fresh session because the local cache is cold.
My specific technical questions for the community are:
1. **Orchestration & Image Management:** Did you bake the agent into your golden image, or deploy it dynamically via a login script/CIBM? If baked-in, how do you handle policy updates or agent upgrades that occur between image rebuilds? We are currently using a baked-in base agent, triggered to update itself via a `elastic-agent.yml` configuration fetched from a secure HTTP source on session start.
```yaml
# Snippet from our launch script that fetches session-specific config
curl -s -o "C:Program FilesElasticAgentelastic-agent.yml" https://config-server.internal/latest-vdi-config.yml
& "C:Program FilesElasticAgentelastic-agent.exe" -c
```
This adds to the login delay but ensures the latest fleet policies are applied.
2. **Network Traffic Optimization:** Have you implemented a local caching proxy or a custom package repository for the artifact databases (Pre-Engine, YARA rules) to mitigate the boot storm effect? What was the reduction in egress traffic and latency?
3. **Performance Baseline Impact:** What metrics did you use to quantify the agent's overhead? We're monitoring session-level metrics like average CPU steal time (for the hypervisor layer), I/O wait on the VDI host, and memory working set of the `elastic-endpoint.exe` process. Early data suggests a consistent 3-5% increase in aggregate host CPU utilization post-deployment.
The trade-offs between security posture and user experience/latency are particularly acute in non-persistent VDI. I'm keen to hear detailed, technical post-mortems on performance tuning and any pitfalls encountered during scaling.
>added 45-90 seconds to user login time
That's the quiet period. Wait until you have a thousand instances trying to pull a 200MB artifact database update at 9 AM. We saw network saturation choke the login brokers themselves. The solution wasn't more bandwidth, it was aggressive, pre-staged local caching. You can't let every instance hit your Elastic stack directly on spin-up.
The thundering herd problem is real, but it's a cost problem disguised as a performance one. You'll need to scale your Elastic infrastructure to handle peak concurrent connections, and that capacity will sit idle 80% of the day. That's a huge, recurring bill for a few minutes of daily panic.
show the math