PSM Session Drops, Missing Recordings, and SSH Bypass
A hospital runs PSM on three Windows servers behind an F5 load balancer. About 500 clinicians use RDP to 200 application servers through PSM RemoteApp; 30 Unix administrators use PSM for SSH to 400 Linux hosts. Session recordings are stored in a PSMRecordings safe on a 2 TB volume. Users report RDP sessions dropping at exactly 10 minutes during peak hours, and audit found recordings missing for 12% of Unix sessions. Twelve Unix admins have a direct SSH path that bypasses PSM because a legacy jump host remains open. The PSM server CPU peaks at 95% and the recordings volume is 85% full. The F5 has no session affinity and the CISO asks for a plan before the next audit.
1. What is your diagnostic order for the 10-minute RDP drops and the missing Unix recordings? Distinguish PSM configuration from infrastructure causes.
Read the worked answer
Treat the 10-minute drop as a timeout chain, not a PSM bug. Check, in order: the platform connection component idle/session timeout, the PSM server maximum session duration, the F5 idle timeout, and the Windows RDP GPO idle/disconnect limits. If every user drops at exactly 10 minutes, the load balancer or a global timeout is more likely than per-user PSM policy. Also check session affinity; without it, a reconnect can land on another PSM server and appear as a drop. For missing Unix recordings, separate configuration from capacity: confirm Record session is enabled on the Unix platform, the PSM for SSH proxy is in the path, the PSMRecording service is healthy, and the recording safe has write permission and free space. The 12% gap plus 85% full volume and 95% CPU points to storage or overload, not a random audit failure. Correlate missing recordings with PSM server and time.
2. How would you close the direct SSH bypass without breaking scripts and automation?
Read the worked answer
Close the bypass with network enforcement, not a policy memo. On the Linux hosts, restrict SSH to the PSM for SSH proxy addresses and a separate automation subnet; remove the legacy jump host path or ACL it to the proxy. Inventory scripts and cron jobs first, because a blind block will break automation. Move interactive admins to PSM for SSH; move scripts to a dedicated service account authenticated through a credential provider or an allowed automation host. Keep a documented exception group with expiry and monitoring. Verify with packet captures and SSH logs that direct admin logins fail while PSM sessions succeed. This preserves automation and gives the CISO evidence that interactive access is recorded.
3. Given CPU at 95% and volume 85% full, what capacity and architecture changes would you recommend for three PSM servers and recording retention?
Read the worked answer
At 95% CPU and 85% full, the immediate risk is lost recordings, not just slow sessions. Add a fourth PSM server or rebalance existing sessions; use load balancer session affinity and health checks. Move recordings to scalable shared storage or object storage with retention tiering, and set a retention policy that matches audit requirements. Monitor recording volume, PSM CPU, and failed recording events. For SSH, use a PSM Gateway or dedicated PSM for SSH nodes so RDP and SSH workloads do not starve each other. Do not simply delete old recordings to free space; archive them with integrity checks. Capacity planning should be based on concurrent sessions and recording size per session, not server count.