Harborview library Blast sessions drop only on one thin-client model; other models and fat clients stay connected to the same catalog pool. Which logs should the operator collect first?
Select an answer to reveal the explanation.
Short Explanation
When only one thin-client model blinks off, start at that model's Horizon Client, not at a healthy desktop everyone else is already using. Endpoint-specific display drops are a client-log problem first.
Full Explanation
When Harborview library Blast sessions drop only on one thin-client model while other models and fat clients stay connected to the same catalog pool, the operator should collect Horizon Client logs on a representative thin client of the failing model first. The defect tracks the client platform, not the shared pool backend. Library branches often mix thin-client generations; isolating the failing model with Client logs prevents unnecessary pool rebuilds that would disrupt working devices. Horizon Agent logs from a random instant clone that other client models use successfully are unlikely to show the model-specific client failure. Intelligent Hub logs from a librarian's personal phone are unrelated to thin-client Blast stability. Workspace ONE Web logs from a library catalog kiosk browser address the Workspace ONE Web app, not the native thin-client Horizon Client path. Exam caveat: Model-specific client failures prioritize Client-side collection on the failing hardware before blaming a healthy multi-model pool. Operational check: Reproduce on a failing thin-client unit, gather Horizon Client logs for that model, and compare protocol and disconnect events against a working fat client in the same pool.