VDI Access Policy

Imprivata VDI access policies and Scout Citrix configuration aren’t mutually exclusive. For the areas Imprivata covers, it acts as the primary source and Scout is the fallback, so the same resource doesn’t have to be configured twice.

Today this applies to VDI access policies only; other Imprivata computer-policy areas (Secure Walk Away, desktop and lock-screen behavior) aren’t combined with Scout this way yet.

A VDI access policy is configured on the Imprivata server (Computers / Computer policies / User policies → Virtual Desktops). It defines which Citrix desktops and published applications a user is entitled to, and whether they launch automatically. When the user signs in at the eLux device through Imprivata, the device reads their VDI access policy and starts those Citrix resources automatically with single sign-on, using the credentials already presented at Imprivata login — the user doesn’t re-enter anything.

This is where Imprivata and Scout meet: Citrix Configuration distinguishes between a private session (launched for the individual signed-in user) and a persistent session (a shared session under a common account). A VDI access policy changes how the private session behaves; the persistent session is left to Scout.

Configuring on the Imprivata Server

A VDI access policy is built from three layers. All three must align for a Citrix resource to auto-launch — if any layer omits it, the resource doesn’t start.

1. Computers > Virtual Desktops (inventory) — Defines the pool of Citrix stores and their published resources.
   • XenDesktop: Add each StoreFront server URL and enable Allow authentication from XenDesktop-enabled devices.
   • XenApp: Add each StoreFront server URL and list the exact published application/delivery-group name(s); enable Allow authentication from XenApp-enabled devices.
2. Computers > Computer policies > Virtual Desktops (per device) — Chooses how a computer uses the inventory.
   • XenDesktop: Enable Automate access to Citrix XenDesktop; choose the desktop-launch prompt behavior; set the When the device is locked option; select the available Citrix servers.
   • XenApp: Enable Automate access to Citrix XenApp and Enable Published Applications; set the When the device is locked option; select the available Citrix servers.
   • Assign the computer policy to the eLux device.
3. Users > User policies > Virtual Desktops (per user) — Defines what runs for the signed-in user; this is the master switch for VDI access automation.
   • Enable virtual desktop access automation — if disabled, no resources are injected and the Scout fallback applies.
   • XenDesktop: Enable Automate access to full VDI desktops and select which desktops/applications auto-start.
   • XenApp: Enable Automate access to applications or published desktops, choose the roaming option, and select which applications auto-start.
   • Under Authentication > Primary factors, select the login factors (for example Password and Proximity Card).
   • Assign the user policy to the user.

Configuring on the Scout Side

• Private session — No Scout changes are needed; the resource is left to the Imprivata VDI access policy.
• Persistent session (used with fast user switching — an always-on shared application, for example an EHR app) — Configure it in Scout as a persistent StoreFront application as usual. It keeps running across user switches, and the Imprivata resource for that store is dropped instead.

Precedence Between Imprivata and Scout

Precedence is decided per Citrix resource, matched on the same store (StoreFront URL) and the same published resource or delivery group:

Scout wins on persistent sessions because Citrix Workspace App can’t open one store under two identities at once, and an Imprivata VDI access policy can’t express a shared, common-user login — it always launches as the current signed-in user. A persistent session must therefore stay a Scout configuration.