- What's new
- System requirements
- Technical overview
Install and configure
Prepare to install
- Microsoft Azure Resource Manager virtualization environments
- Microsoft System Center Virtual Machine Manager virtualization environments
- XenServer virtualization environments
- Microsoft System Center Configuration Manager environments
- VMware virtualization environments
- Nutanix virtualization environments
- Microsoft Azure virtualization environments
- Install core components
- Install VDAs
- Install using the command line
- Install VDAs using scripts
- Create a Site
- Create machine catalogs
- Manage machine catalogs
- Create Delivery Groups
- Manage Delivery Groups
- Create Application Groups
- Manage Application Groups
- Remote PC Access
- XenApp Secure Browser
- Publish content
- Server VDI
- Personal vDisk
- Remove components
- Prepare to install
- Upgrade and migrate
- Security considerations and best practices
- Integrate XenApp and XenDesktop with NetScaler Gateway
- Delegated Administration
- Smart cards
- Transport Layer Security (TLS)
- Federated Authentication Service
- General content redirection
- Work with policies
- Policy templates
- Create policies
- Compare, prioritize, model, and troubleshoot policies
- Default policy settings
Policy settings reference
- ICA policy settings
- Load management policy settings
- Profile management policy settings
- Receiver policy settings
- Virtual Delivery Agent policy settings
- Virtual IP policy settings
- Configure COM Port and LPT Port Redirection settings using the registry
- Connector for Configuration Manager 2012 policy settings
- Advanced configuration
- Monitor deployments
- Alerts and notifications
- Delegated Administration and Director
- Secure Director deployment
- Configure permissions for VDAs earlier than XenDesktop 7
- Configure network analysis
- Troubleshoot user issues
- Troubleshoot applications
- Troubleshoot machines
- Feature compatibility matrix
- Data granularity and retention
- Configure PIV smart card authentication
- Application probing
- SDKs and APIs
Thinwire is the Citrix default display remoting technology used in XenApp and XenDesktop.
Display remoting technology allows graphics generated on one machine to be transmitted, typically across a network, to another machine for display.
A successful display remoting solution should provide a highly interactive user experience that is similar to that of a local PC. Thinwire achieves this by using a range of complex and efficient image analysis and compression techniques. Thinwire maximizes server scalability and consumes less bandwidth than other display remoting technologies.
Because of this balance, Thinwire meets most general business use cases and is used as the default display remoting technology in XenApp and XenDesktop.
Thinwire should be used for delivering typical desktop workloads, for example, desktops, office productivity or browser-based applications. Thinwire is also recommended for multi-monitor, high resolution or high DPI scenarios, and for workloads with a mixture of video and non-video content.
Framehawk should be used for mobile workers on broadband wireless connections where packet loss can be intermittently high.
In its default configuration, Thinwire can deliver 3D or highly interactive graphics. However, we recommend enabling HDX 3D Pro mode using the Citrix policy Optimize for 3D graphics workload for such scenarios when GPUs are present. The 3D Pro mode uses the GPU for hardware acceleration and configures Thinwire using optimal settings for graphics. This provides a more fluid experience for 3D professional graphics. For more information, see HDX 3D Pro and GPU acceleration for Windows Desktop OS.
- Thinwire has been optimized for modern operating systems, including Windows Server 2012 R2, Windows Server 2016, Windows 7, and Windows 10. For Windows Server 2008 R2, legacy graphics mode is recommended. Use the built-in Citrix policy templates, High Server Scalability-Legacy OS and Optimized for WAN-Legacy OS to deliver the Citrix recommended combinations of policy settings for these use cases.
We do not support legacy graphics mode in this release. It is included for backward compatibility when using XenApp 7.15 LTSR, XenDesktop 7.15 LTSR, and previous VDA releases with Windows 7 and Windows 2008 R2.
- The policy setting which drives the behavior of Thinwire, Use video codec for compression, is available on VDA versions in XenApp and XenDesktop 7.6 FP3 and later. The Use video codec when preferred option is the default setting on VDA versions XenApp and XenDesktop 7.9 and later.
- All Citrix Receivers support Thinwire. Some Citrix Receivers may however support features of Thinwire that others do not, for example, 8 or 16-bit graphics for reduced bandwidth usage. Support for such features are automatically negotiated by Citrix Receiver.
- Thinwire will use more server resources (CPU, memory) in multi-monitor and high-resolution scenarios. It is possible to tune the amount of resources Thinwire uses, however, bandwidth usage may increase as a result.
- In low bandwidth or high latency scenarios, you may consider enabling 8 or 16-bit graphics to improve interactivity, however visual quality will be affected, especially at 8-bit color depth.
Thinwire is the default display remoting technology.
The following Graphics policy setting sets the default and provides alternatives for different use cases:
Use video codec for compression
- Use video codec when preferred. This is the default setting. No additional configuration is required. Keeping this setting as the default ensures that Thinwire is selected for all Citrix connections, and is optimized for scalability, bandwidth, and superior image quality for typical desktop workloads.
- Other options in this policy setting will continue to use Thinwire in combination with other technologies for different use cases. For example:
- For actively changing regions. The adaptive display technology in Thinwire identifies moving images (video, 3D in motion) and uses H.264 or H.265 only in the part of the screen where the image is moving.
- For the entire screen. Delivers Thinwire with full-screen H.264 or H.265 to optimize for improved user experience and bandwidth, especially in cases with heavy use of 3D graphics.
A number of other policy settings, including the following Visual display policy settings can be used to fine tune the performance of display remoting technology and are all supported by Thinwire:
To get the Citrix recommended combinations of policy settings for different business use cases, use the built in Citrix Policy templates. The High Server Scalability and Very High Definition User Experience templates both use Thinwire with the optimum combinations of policy settings for your organization’s priorities and your users’ expectations.
You can monitor the use and performance of Thinwire from Citrix Director. The HDX virtual channel details view contains useful information for troubleshooting and monitoring Thinwire in any session. To view Thinwire-related metrics:
In Director, search for a user, machine or endpoint, open an active session and click Details. Or, you can select Filters > Sessions > All Sessions, open an active session and click Details.
Scroll down to the HDX panel.
Select Graphics - Thinwire.
In XenApp and XenDesktop 7.16 and earlier, there are three Thinwire bitmap encoding modes used for server OS and desktop OS VDA graphics remoting:
- Full screen H.264
- Thinwire Plus
- Thinwire Plus with selective H.264
Legacy GDI remoting uses the XPDM remoting driver and not a Thinwire bitmap encoder.
In a typical desktop session, most of the imagery is simple graphics or text regions. When any of the three bitmap encoding modes listed are used, Thinwire selects these areas for lossless encoding using the 2DRLE codec. At the Citrix Receiver client side, these elements are decoded using the Citrix Receiver-side 2DRLE decoder for session display.
Lossless compression codec (MDRLE)
In XenApp and XenDesktop 7.17, we’ve added a higher compression ratio MDRLE encoder that consumes less bandwidth in typical desktop sessions than the 2DRLE codec.
Lower bandwidth usually means improved session interactivity (especially on shared or constrained links) and reduced costs. For example, the expected bandwidth consumption when using the MDRLE codec is approximately 10–15% less compared with XenApp and XenDesktop 7.15 LTSR for typical Office-like workloads.
Configuration isn’t required for the MDRLE codec. If Citrix Receiver supports MDRLE decoding, the VDA uses the VDA MDRLE encoding and the Citrix Receiver MDRLE decoding. If Citrix Receiver doesn’t support MDRLE decoding, the VDA automatically falls back to 2DRLE encoding.
- XenApp and XenDesktop minimum version 7.17 VDAs
- Receiver for Windows minimum version 4.11
Session interactivity can degrade on low bandwidth or high latency links. For example, on a link with bandwidth < 2 Mbps or latency > 200 ms, scrolling on a web page can become slow, unresponsive, or bursty. Keyboard and mouse operations can lag behind graphics updates. Through version 7.17, you might use policy settings to reduce bandwidth consumption by configuring the session to Low visual quality, or set a lower color depth (16 or 8-bit graphics). However, you needed to know that a user was on a weak connection. HDX Thinwire could not dynamically adjust static imagery quality, based on network conditions. In 7.18, by default, HDX Thinwire switches to a progressive update mode when available bandwidth falls below 2 Mbps, or network latency exceeds 200ms. In this mode:
- All static images are heavily compressed.
- Text quality is reduced.
Transient imagery (video) is still managed with adaptive display or Selective H.264.
How progressive mode is used
By default, progressive mode is on standby for the Visual Quality policy settings: High, Medium (default), and Low.
Progressive mode is forced off (not used) when:
- Visual Quality = Always Lossless or Build to Lossless
- Preferred Colour Depth for Simple Graphics = 8-bit
- Use Video Codec = For the entire screen (when full-screen H.264 is desired)
When progressive mode is on standby, by default it is enabled when either of the following conditions occurs:
- Available bandwidth drops below 2 Mbps
- Network latency increases to above 200ms
After a mode switch occurs, a minimum of 10s is spent in that mode, even if the adverse network conditions are momentary.
Changing progressive mode behavior
You can change the progressive mode state with the following registry key:
0 = Always off (do not use in any circumstances)
1 = Automatic (toggle based on network conditions; this is the default)
2 = Always on
When in automatic mode (1), you can use the following registry key to change the thresholds at which progressive mode is toggled:
Value: <threshold in Kbps> (default = 2048) Example: 4096 = toggle progressive mode on if bandwidth falls below 4 Mbps
Value: <threshold in ms> (default = 200) Example: 100 = toggle progressive mode on if network latency drops below 100ms.