Skip to Main Content
Product Area Application Workspace
Created by Joris Gerretsen
Created on Mar 12, 2026

Major feature request for retrieving remote client ip in AVD (with workaround explained)

Hi,

I'm reaching out with a feature request related to Azure Virtual Desktop (AVD) environments, specifically around client context detection.

Background

As you may already be aware, AVD no longer passes the remote client's IP address to the virtual session. To work around this, I've built a solution with the Recast PowerShell module where a script runs at user logon or session connect that:

  1. Reads the remote client hostname from HKCU:\Volatile Environment\CLIENTNAME

  2. Queries the Liquit database via PowerShell to retrieve the IP address associated with that client device

  3. Writes the result to a custom registry value (e.g., HKCU:\Volatile Environment\CLIENTIPVALUE)

This allows me to work with subnet-based filtering using Condition Sets. However, this approach has limitations — registry values are currently only usable in Condition Sets, not in Contexts.

How did I do it:

$clientName = (Get-ItemProperty 'HKCU:\Volatile Environment').CLIENTNAME # retrieves the remote client hostname from the user session

$device = Get-LiquitDevice -Name $clientName # queries the Liquit database for all device information based on the client hostname

$clientIP = $device.Network.IP.IPAddressToString # extracts the IP address of the client device from the Liquit device object

Set-ItemProperty -Path 'HKCU:\Volatile Environment' -Name 'CLIENTIPVALUE' -Value $clientIP # writes the resolved client IP address into the user's session registry

As you can see I archieved this relying on all the pieces that are already present in recast. Just not combined.

This workaround can be archieved using the recast powershell module in AVD and run uploaded script package in Recast.

Feature Request 1: Registry Values as a Source for Contexts

Please consider adding support for registry values as a data source when defining Contexts. Currently, registry-based filtering is limited to Condition Sets, which can be applied to packages but cannot drive context assignment. Enabling registry values in Contexts would significantly expand the flexibility of context-based targeting in virtual and remote desktop environments.

Feature Request 2: Remote Client IP Resolution via TSClientName in Contexts

When using the "Subnet" option within Contexts, please consider adding an additional mode: Remote Client (based on TSClientName).

The idea: instead of relying on the IP address passed by the default windows WTSQuerySessionInformation (which is readonly and cannot be modified) AVD session (which is no longer available), Recast would:

  1. Read the ClientName (remote client hostname) from the session

  2. Look up that hostname in the Recast device database

  3. Use the associated IP address to evaluate the subnet context

This would provide a native, reliable solution for subnet-based context detection in AVD — without requiring custom scripting or workarounds.

Prerequisite: This would naturally require that both the client device and the AVD environment are known/managed within Recast.

I believe these two additions would greatly improve context targeting capabilities for organizations using AVD. I'd be happy to discuss this further or provide additional technical details if helpful.

The removal of the remote client IP in AVD is a widely reported pain point affecting organizations globally. There is currently no native solution from Microsoft or any workspace management vendor to address this gap. By implementing this feature, Recast would be the first to offer an infrastructure-native resolution to a problem thousands of AVD deployments face today for printing and application distribution. This makes it not just a quality-of-life improvement for existing customers, but a concrete sales differentiator — giving your team a strong reason-to-choose Recast in every AVD deal where location-aware application delivery is a requirement.

Thank you for considering this request.

  • Attach files