Citrix VDI And Remote Desktop Where The Evidence Actually Resides (1)

Frequently asked questions

The employee only ever used a company laptop. Why isn't imaging it enough?

Because in these estates the laptop is deliberately kept empty: work happens on hosts, files live in profile stores and application servers, and the end point holds a client and a connection history. Image it for the corroborating trace and the landing zone, but direct the substantive requests at the session layer: container, hosts, brokers, identity logs. The architecture was designed so the laptop could be lost without losing anything; treat its evidential emptiness as the design working, not the trail ending.

The desktop rebuilds itself every night. Has the evidence been destroyed?

The desktop's local state, yes: nightly, by design, since long before the dispute: which is why no adverse inference attaches to routine non-persistence. The evidence was externalised as it was created: profile container, redirected folders, application servers, logs: and those survive on their own schedules. The urgent act is stopping the schedules (snapshots, logs, and the specific desktop's revert if a recent session matters), not mourning the desktop.

Can these environments show us exactly what the user saw on screen?

Only where session recording was deployed: some regulated functions and third-party-access setups record screens or keystrokes, retained per policy and worth request in g by name. Otherwise screen content is reconstructed inferentially: the application's own records of what was open, the profile's browser and recents trail, redirected-drive artefacts, and occasional client cache fragments. The honest framing is activity evidence rather than footage: usually sufficient, and claimed as nothing more.

How do we prove which person was behind a session, rather than which account?

The four links, with this estate's rich middle: broker logs bind account, time, end point identifier and address; the identity provider adds authentication method and device familiarity; the endpoint's own artefacts place a machine and often a person; and pattern evidence (habitual hours, devices, geographies) frames anomalies. Example 2 is the caution: the logbook is excellent at identifying sessions and neutral about who typed: the report keeps those separate and builds the human layer explicitly.

Work happened through published apps, not a desktop. What changes?

The desktop layer thins to almost nothing and the weight shifts: brokers still log every app launch (which app, when, from where); profiles still capture the app's user-side traces; and the substantive evidence concentrates in the application's own backend: the DMS, the finance system, the database: reached through this series' application and database guides. The request list changes shape; the follow-the-session principle does not.

Our opponent runs Citrix and says session data "is not retained". How do we test that?

Decompose it in correspondence: retention of what, where, since when: broker logs, gateway logs, the monitoring database (whose default reach is months, not days), identity-provider sign-ins (often a year or more), profile-store snapshots, host backups, SIEM forwarding. Blanket non-retention across all of those is an unusual estate and, if genuinely configured, was a choice with a date: which is itself disclosable. The §11 request names the layers individually precisely so that "not retained" has to be said, or not, about each. cflab. u k · e-disc ove r y. u k ©2026 Computer Forensics Lab Ltd ·cflab.uk ·e-discovery.uk ·info@cflab.uk ·+44 (0)20 7164 6915 Page 15 of 17