I’ve been testing Delinea’s Privilege Manager (formerly Thycotic) in our hybrid environment, and I’ve hit a consistent snag. About 15% of our Windows Server 2016/2019 VMs (mix of AWS EC2 and on-prem) are not appearing in the console inventory, even though the agents appear installed and running. The servers are domain-joined, have outbound HTTPS access, and aren’t blocked by host firewall rules we can see.
Has anyone else run into this? I’m trying to correlate the missing servers, but so far the only common thread is they are all in AWS us-west-2, while our other regions seem fine. I’ve checked the typical suspects:
* Agent service status is “Running”
* No obvious errors in the local agent logs (`C:Program FilesThycoticAgentlog`)
* The Delinea server shows successful heartbeats for some, but not all, of the missing servers
* No patterns on instance type (t3.medium, m5.large) or subnet
I did find one interesting bit in a debug log on one missing server. It seems to fail silently during the initial registration handshake.
```xml
2023-10-26T11:22:34
Agent.Core
Error
Registration handshake failed: The underlying connection was closed
```
My current theory is something with the TLS negotiation between the agent and the Delinea server, maybe due to a specific Windows update or a cipher mismatch. I’m also wondering if there’s a timeout or thread limit on the Delinea side that’s being hit in certain conditions.
Before I open a support ticket, I wanted to see if the community has seen this and has a checklist I might have missed. Specifically:
* Any known issues with certain Windows Server cumulative updates?
* Could AWS Security Groups or NACLs be blocking something even if the agent service runs? (We allowed the Delinea server FQDN and IP)
* Is there a Delinea server log location that’s more verbose for tracking registration attempts?
That connection closed error during registration is a solid clue. I've seen similar issues where the agent's TLS negotiation fails against the central server, especially if there's a proxy or load balancer in the middle that's terminating TLS prematurely.
Since it's region-specific (us-west-2), have you checked if those subnets might be hitting a different egress path? Maybe a WAF or proxy policy in that region is stripping headers or enforcing a specific TLS version the agent doesn't support. Could you run a quick test from one of the missing servers using something like `Test-NetConnection` to your Delinea server on the correct port, and see if the TLS handshake completes?
APIs > promises
That connection closed error is a classic one, and your region-specific clue is huge. Since it's us-west-2, you're right to suspect the network path.
I'd check the TLS version/cipher mismatch first. Those agents can be picky. Try forcing a specific TLS version (like 1.2) in the agent config on one of the problem servers, or see if your AWS NACLs/Security Groups in that region are allowing the full cipher suite. A proxy doing "inspect and re-encrypt" could definitely cause this handshake to fail silently.
Also, double-check the server's system time. I've seen agents fail registration because the clock was off by just enough to break the certificate validity check.
Always testing.