By optimizing your environment you gain the best performance from Citrix Receiver and provide the best user experience. You can improve and optimize performance by:

Mapping user devices

Citrix Receiver supports client device mapping for connections to XenApp and XenDesktop servers. Client device mapping enables a remote application running on the server to access devices attached to the local user device. The applications and system resources appear to the user at the user device as if they are running locally. Ensure that client device mapping is supported on the server before using these features.

Note: The Security-Enhanced Linux (SELinux) security model can affect the operation of the Client Drive Mapping and USB Redirection features (on both XenApp and XenDesktop). If you require either or both of these features, disable SELinux before configuring them on the server.

Mapping client drives

Client drive mapping allows drive letters on the XenApp or XenDesktop server to be redirected to directories that exist on the local user device. For example, drive H in a Citrix user session can be mapped to a directory on the local user device running Receiver.

Client drive mapping can make any directory mounted on the local user device, including a CD-ROM, DVD, or a USB memory stick, available to the user during a session, provided the local user has permission to access it. When a server is configured to allow client drive mapping, users can access their locally stored files, work with them during their session, and then save them again either on a local drive or on a drive on the server.

Two types of drive mapping are available:

  • Static client drive mapping enables administrators to map any part of a user device’s file system to a specified drive letter on the server at logon. For example, it can be used to map all or part of a user’s home directory or /tmp, and the mount points of hardware devices such as CD-ROMs, DVDs, or USB memory sticks.
  • Dynamic client drive mapping monitors the directories in which hardware devices such as CD-ROMs, DVDs, and USB memory sticks are typically mounted on the user device. And any new ones that appear during a session are automatically mapped to the next available drive letter on the server.

When Citrix Receiver connects to XenApp or XenDesktop, client drive mappings are reestablished unless client device mapping is disabled. You can use policies to give you more control over how client device mapping is applied. For more information, see the XenApp and XenDesktop documentation.

Users can map drives using the Preferences dialog box.

Note: By default, enabling static client drive mapping also enables dynamic client drive mapping. To disable the latter but enable the former, set DynamicCDM to False in wfclient.ini.

Mapping client printers

Citrix Receiver supports printing to network printers and printers that are attached locally to user devices. By default, unless you create policies to change it, XenApp lets users:

  • Print to all printing devices accessible from the user device
  • Add printers

These settings, however, might not be the optimum in all environments. For example, the default setting that allows users to print to all printers accessible from the user device is the easiest to administer initially. But the default setting might create slower logon times in some environments. In this situation, you might want to limit the list of printers configured on the user device.

Likewise, your organization’s security policies might require that you prevent users from mapping local printing ports. To do so, on the server configure the ICA policy Auto connect client COM ports setting to Disabled.

To limit the list of printers configured on the user device

  1. Open the configuration file, wfclient.ini, in one of the following:

    • $HOME/.ICAClient directory to limit the printers for a single user
    • $ICAROOT/config directory to limit the printers for all Receiver users. All users in this case are those users who first use the selfservice program after the change.
  2. In the [WFClient] section of the file type:


    Where printer1, printer2, and so on, are the names of the chosen printers. Separate printer name entries by a colon (:).

  3. Save and close the file.

Mapping client printers on XenApp for Windows

The Citrix Receiver for Linux supports the Citrix PS Universal Printer Driver. So, usually no local configuration is required for users to print to network printers or printers that are attached locally to user devices. You might, however, manually map client printers on XenApp for Windows if, for example, the user device’s printing software does not support the universal printer driver.

To map a local printer on a server

  1. From Citrix Receiver, start a server connection and log on to a computer running XenApp.

  2. On the Start menu, choose Settings > Printers.

  3. On the File menu, choose Add Printer.

    The Add Printer wizard appears.

  4. Use the wizard to add a network printer from the Client Network, Client domain. Usually this is a standard printer name, similar to those created by native Remote Desktop Services, such as “HP LaserJet 4 from client name in session 3.”

    For more information about adding printers, see your Windows operating system documentation.

Mapping client printers on XenApp for UNIX

In a UNIX environment, printer drivers defined by Citrix Receiver are ignored. The printing system on the user device must be able to handle the print format generated by the application.

Before users can print to a client printer from Citrix XenApp for UNIX, printing must be enabled by the administrator. For more information, see the XenApp for UNIX section in the XenApp and XenDesktop documentation.

Mapping client audio

Client audio mapping enables applications executing on the XenApp server or XenDesktop to play sounds through a sound device installed on the user device. You can set audio quality on a per-connection basis on the server and users can set it on the user device. If the user device and server audio quality settings are different, the lower setting is used.

Client audio mapping can cause excessive load on servers and the network. The higher the audio quality, the more bandwidth is required to transfer the audio data. Higher quality audio also uses more server CPU to process.

You configure client audio mapping using policies. For more information, see the XenApp and XenDesktop documentation.

Note: Client audio mapping is not supported when connecting to Citrix XenApp for UNIX.

To set a non-default audio device

The default audio device is typically the default ALSA device configured for your system. Use the following procedure to specify a different device:

  1. Choose and open a configuration file according to which users you want your changes to affect. See Customize Receiver using configuration files for information about how updates to particular configuration files affect different users.
  2. Add the following option, creating the section if necessary:


AudioDevice = <device>

Where device information is located in the ALSA configuration file on your operating system.

Note: The location of this information is not standard across all Linux operating systems. Citrix recommends consulting your operating system documentation for more details about locating this information.

Configuring USB support

USB support enables users to interact with a wide range of USB devices when connected to a virtual desktop. Users can plug USB devices into their computers and the devices are redirected to their virtual desktop. USB devices available for remoting include flash drives, smartphones, PDAs, printers, scanners, MP3 players, security devices, and tablets.

USB redirection requires either XenApp 7.6 (or later) or XenDesktop. XenApp does not support USB redirection of mass storage devices and requires special configuration to support audio devices. See XenApp 7.6 documentation for details.

Isochronous features in USB devices such as webcams, microphones, speakers, and headsets are supported in typical low latency/high speed LAN environments. But usually the standard audio or webcam redirection are more suitable.

The following types of device are supported directly in a XenDesktop session, and so do not use USB support:

  • Keyboards
  • Mice
  • Smart cards
  • Headsets
  • Webcams

Note: Specialist USB devices (for example, Bloomberg keyboards and 3D mice) can be configured to use USB support. For information on configuring policy rules for other specialist USB devices, see CTX 119722.

By default, certain types of USB devices are not supported for remoting through XenDesktop. For example, a user might have a NIC attached to the system board by internal USB. Remoting this would not be appropriate. The following types of USB device are not supported by default for use in a XenDesktop session:

  • Bluetooth dongles
  • Integrated NICs
  • USB hubs

To update the default list of USB devices available for remoting, edit the usb.conf file, located in $ICAROOT/. For more information, see the Update the list of USB devices available for remoting section.

To allow the remoting of USB devices to virtual desktops, enable the USB policy rule. For more information, see the XenApp and XenDesktop documentation.

How USB support works

When a user plugs in a USB device, it is checked against the USB policy, and, if allowed, redirected to the virtual desktop. If the device is denied by the default policy, it is available only to the local desktop.

For desktops accessed through desktop appliance mode, when a user plugs in a USB device, that device is automatically redirected to the virtual desktop. The virtual desktop is responsible for controlling the USB device and displaying it in the user interface.

The session window must have focus when the user plugs in the USB device for redirection to occur, unless desktop appliance mode is in use.

Mass storage devices

If a user disconnects from a virtual desktop when a USB mass storage device is still plugged in to the local desktop, that device is not redirected to the virtual desktop when the user reconnects. To ensure that the mass storage device is redirected to the virtual desktop, the user must remove and reinsert the device after reconnecting.

Note: If you insert a mass storage device into a Linux workstation that has been configured to deny remote support for USB mass storage devices, the device will not be accepted by the Receiver software. And a separate Linux file browser might open. Therefore, Citrix recommends that you pre-configure user devices with the Browse removable media when inserted setting cleared by default. On Debian-based devices, do this using the Debian menu bar by selecting Desktop > Preferences > Removable Drives and Media. And on the Storage tab, under Removable Storage, clear the Browse removable media when inserted check box.

Note: If the Client USB device redirection server policy is turned on, mass storage devices are always directed as USB devices even if client drive mapping is turned on.


By default, optimum webcam performance is provided by HDX RealTime Webcam Video Compression. In some circumstances, however, you may require users to connect webcams using USB support. To do this, you must disable HDX RealTime Webcam Video Compression. For more information, see Video Conferencing with HDX RealTime Webcam Video Compression.

USB classes allowed by default

The following classes of USB device are allowed by the default USB policy rules:

  • Audio (Class 01)

    Includes microphones, speakers, headsets, and MIDI controllers.

  • Physical Interface (Class 05)

    These devices are similar to HIDs, but generally provide real-time input or feedback and include force feedback joysticks, motion platforms, and force feedback exoskeletons.

  • Still Imaging (Class 06)

    Includes digital cameras and scanners. Digital cameras often support the still imaging class which uses the Picture Transfer Protocol (PTP) or Media Transfer Protocol (MTP) to transfer images to a computer or other peripheral. Cameras might also appear as mass storage devices. And it might be possible to configure a camera to use either class, through setup menus provided by the camera itself.

    If a camera appears as a mass storage device, client drive mapping is used, and USB support is not required.

  • Printers (Class 07)

    In general most printers are included in this class, although some use vendor-specific protocols (class ff). Multi-function printers might have an internal hub or be composite devices. In both cases, the printing element generally uses the Printers class and the scanning or fax element uses another class; for example, Still Imaging.

    Printers normally work appropriately without USB support.

  • Mass Storage (Class 08)

    The most common mass storage devices are USB flash drives; others include USB-attached hard drives, CD/DVD drives, and SD/MMC card readers. There is a wide variety of devices having internal storage which also presents a mass storage interface; these include media players, digital cameras, and mobile phones. Known subclasses include:

  • 01 Limited flash devices
  • 02 Typically CD/DVD devices (ATAPI/MMC-2)
  • 03 Typically tape devices (QIC-157)
  • 04 Typically floppy disk drives (UFI)
  • 05 Typically floppy disk drives (SFF-8070i)
  • 06 Most mass storage devices use this variant of SCSI

    Mass storage devices can often be accessed through client drive mapping, and so USB support is not required.

    Important: Some viruses are known to propagate actively using all types of mass storage. Consider carefully whether or not there is a business need to permit the use of mass storage devices, either through client drive mapping, or USB support. To reduce this risk, the server might be configured to prevent files being executed through client drive mapping.

  • Content Security (Class 0d)

    Content security devices enforce content protection, typically for licensing or digital rights management. This class includes dongles.

  • Personal Healthcare (Class 0f)

    These devices include personal healthcare devices such as blood pressure sensors, heart rate monitors, pedometers, pill monitors, and spirometers.

  • Application and Vendor Specific (Classes fe and ff)

    Many devices use vendor specific protocols or protocols not standardized by the USB consortium, and these usually appear as vendor-specific (class ff).

USB device classes denied by default

The following classes of USB device are denied by the default USB policy rules:

  • Communications and CDC Control (Classes 02 and 0a)

    Includes modems, ISDN adapters, network adapters, and some telephones and fax machines.

    The default USB policy does not allow these devices, because one of them might be providing the connection to the virtual desktop itself.

  • Human Interface Devices (Class 03)

    Includes a wide variety of both input and output devices. Typical Human Interface Devices (HIDs) are keyboards, mice, pointing devices, graphic tablets, sensors, game controllers, buttons, and control functions.

    Subclass 01 is known as the boot interface class and is used for keyboards and mice.

    The default USB policy does not allow USB keyboards (class 03, subclass 01, protocol 1), or USB mice (class 03, subclass 01, protocol 2). This is because most keyboards and mice are handled appropriately without USB support. And it is normally necessary to use these devices locally as well remotely when connecting to a virtual desktop.

  • USB Hubs (Class 09)

    USB Hubs allow extra devices to be connected to the local computer. It is not necessary to access these devices remotely.

  • Smart card (Class 0b)

    Smart card readers include contactless and contact smart card readers, and also USB tokens with an embedded smart card equivalent chip.

    Smart card readers are accessed using smart card remoting and do not require USB support.

  • Video (Class 0e)

    The video class covers devices that are used to manipulate video or video-related material, such as webcams, digital camcorders, analog video converters, some television tuners, and some digital cameras that support video streaming.

    By default, optimum webcam performance is provided by HDX RealTime Webcam Video Compression.

  • Wireless Controllers (Class e0)

    Includes a wide variety of wireless controllers, such as ultra wide band controllers and Bluetooth.

    Some of these devices might be providing critical network access, or connecting critical peripherals such as Bluetooth keyboards or mice.

    The default USB policy does not allow these devices. However, there might be particular devices it is appropriate to provide access to using USB support.

Updating the list of USB devices available for remoting

You can update the range of USB devices available for remoting to desktops by editing the list of default rules contained in the usb.conf file on the user device in $ICAROOT/.

You update the list by adding new policy rules to allow or deny USB devices not included in the default range. Rules created by an administrator in this way control which devices are offered to the server. The rules on the server control which of these to be accepted.

The default policy configuration for disallowed devices is:

DENY: class=09 # Hub devices

DENY: class=03 subclass=01 # HID Boot device (keyboards and mice)

DENY: class=0b # Smartcard

DENY: class=e0 # Wireless Controllers

DENY: class=02 # Communications and CDC Control

DENY: class=03 # UVC (webcam)

DENY: class=0a # CDC Data

ALLOW: # Ultimate fallback: allow everything else

Creating USB policy rules

Tip: When creating policy rules, see the USB Class Codes, available from the USB web site at http://www.usb.org/. Policy rules in usb.conf on the user device take the format {ALLOW:|DENY:} followed by a set of expressions based on values for the following tags:

Tag Description
VID Vendor ID from the device descriptor
REL Release ID from the device descriptor
PID Product ID from the device descriptor
Class Class from either the device descriptor or an interface descriptor
SubClass SubClass from either the device descriptor or an interface descriptor
Prot Protocol from either the device descriptor or an interface descriptor

When creating policy rules, be aware of the following:

  • Rules are case-insensitive.
  • Rules might have an optional comment at the end, introduced by “#.” A delimiter is not required and the comment is ignored for matching purposes.
  • Blank and pure comment lines are ignored.
  • Whitespace used as a separator is ignored, but cannot appear in the middle of a number or identifier. For example, Deny: Class=08 SubClass=05 is a valid rule; Deny: Class=0 8 Sub Class=05 is not.
  • Tags must use the matching operator “=.” For example, VID=1230.


The following example shows a section of the usb.conf file on the user device. For these rules to be implemented, the same set of rules must exist on the server.

ALLOW: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive

DENY: Class=08 SubClass=05 # Mass Storage Devices

DENY: Class=0D # All Security Devices

Configure start-up modes

Using desktop appliance mode, you can change how a virtual desktop handles previously attached USB devices. In the WfClient section in the file $ICAROOT/config/module.ini on each user device, set DesktopApplianceMode = Boolean as follows.

TRUE Any USB devices that are already plugged in start-up provided the device is not disallowed with a Deny rule in the USB policies on either the server (registry entry) or the user device (policy rules configuration file).
FALSE No USB devices start up.

Bloomberg keyboard redirection

The Bloomberg keyboard redirection can be performed through generic USB redirection.

To configure the Bloomberg v4 keyboard through Generic USB Redirection on the client side:

As a prerequisite, the policy should be enabled in Domain Delivery Controller (DDC).

  1. Find the vid and pid of the Bloomberg keyboard. For example, in Debian and Ubuntu run the following command:


  2. Go to $ICAROOT and edit the usb.conf file.

  3. Add the following entry in the usb.conf file to allow the Bloomberg keyboard for USB redirection, and then save the file.

    ALLOW: vid=1188 pid=9545

  4. Restart the ctxusbd daemon on the client. For example, in Debian and Ubuntu run the following command:

    systemctl restart ctxusbd

  5. Launch a client session. Make sure the session has focus while plugging in the Bloomberg v4 keyboard for redirection.

Improving performance over low-bandwidth connections

Citrix recommends that you use the latest version of XenApp or XenDesktop on the server and Receiver on the user device.

If you are using a low-bandwidth connection, you can change your Receiver configuration and the way you use Receiver to improve performance.

  • Configure your Receiver connection - Configuring your Receiver connections can reduce the bandwidth that ICA requires and improve performance
  • Change how Receiver is used - Changing the way Receiver is used can also reduce the bandwidth required for a high-performance connection
  • Enable UDP audio - This feature can maintain consistent latency on congested networks in Voice-over-IP (VoIP) connections
  • Use the latest versions of XenApp and Receiver for Linux - Citrix continually enhances and improves performance with each release, and many performance features require the latest Receiver and server software

Configuring connections

On devices with limited processing power or where limited bandwidth is available, there is a trade-off between performance and functionality. Users and administrators can choose an acceptable mixture of rich functionality and interactive performance. Making one or more of these changes, often on the server not the user device, can reduce the bandwidth that a connection requires and can improve performance:

  • Enable SpeedScreen Latency Reduction - SpeedScreen Latency Reduction improves performance over high latency connections by providing instant feedback to the user in response to typed data or mouse clicks. Use SpeedScreen Latency Reduction Manager to enable this feature on the server. By default, in Receiver, this is disabled for keyboard and only enabled for the mouse on high latency connections. See the Citrix Receiver for Linux OEM’s Reference Guide.
  • Enable data compression - Data compression reduces the amount of data transferred across the connection. This requires more processor resources to compress and decompress the data, but it can increase performance over low-bandwidth connections. Use Citrix Audio Quality and Image Compression policy settings to enable this feature.
  • Reduce the window size - Change the window size to the minimum that is comfortable. On the XenApp Services site set the Session Options.
  • Reduce the number of colors - Reduce the number of colors to 256. On the XenApp and XenDesktop Site, set the Session Options.
  • Reduce sound quality - If audio mapping is enabled, reduce the sound quality to the minimum setting using the Citrix Audio quality policy setting.

Enabling UDP audio

UDP audio can improve the quality of phone calls made over the Internet. It uses User Datagram Protocol (UDP) instead of Transmission Control Protocol (TCP).

Note the following:

  • UDP audio is not available in encrypted sessions (that is, those using TLS or ICA Encryption). In such sessions, audio transmission uses TCP.
  • The ICA channel priority can affect UDP audio.
  1. Set the following options in the ClientAudio section of module.ini:
    • Set EnableUDPAudio to True. By default, this is set to False, which disables UDP audio.
    • Specify the minimum and maximum port numbers for UDP audio traffic using UDPAudioPortLow and UDPAudioPortHigh respectively. By default, ports 16500 - 16509 are used.
  2. Set client and server audio settings as follows so that the resultant audio is of a medium quality (that is, not high or low).
    Audio quality on client Audio quality on client Audio quality on client
    High Medium Low
Audio quality on server High High Medium Low
Audio quality on server Medium Medium Medium Low
Audio quality on server Low Low Low Low

Changing how Receiver is used

ICA technology is highly optimized and typically does not have high CPU and bandwidth requirements. However, if you are using a very low-bandwidth connection, consider the following to preserve performance:

  • Avoid accessing large files using client drive mapping. When you access a large file with client drive mapping, the file is transferred over the server connection. On slow connections, this might take a long time.
  • Avoid printing large documents on local printers. When you print a document on a local printer, the print file is transferred over the server connection. On slow connections, this might take a long time.
  • Avoid playing multimedia content. Playing multimedia content uses many bandwidth and can cause reduced performance.

Improving multimedia performance

The Receiver includes a broad set of technologies that provide a high-definition user experience for today’s media-rich user environments. These improve the user experience when connecting to hosted applications and desktops, as follows:

  • HDX MediaStream Windows Media Redirection
  • HDX MediaStream Flash Redirection
  • HDX RealTime Webcam Video Compression
  • H.264 support

Configuring HDX Mediastream Windows Media Redirection

HDX Mediastream Windows Media Redirection overcomes the need for the high bandwidths required to provide multimedia capture and playback on virtual Windows desktops accessed from Linux user devices. Windows Media Redirection provides a mechanism for playing the media run-time files on the user device rather than on the server, thereby reducing the bandwidth requirements for playing multimedia files.

Windows Media Redirection improves the performance of Windows Media player and compatible players running on virtual Windows desktops. A wide range of file formats are supported, including:

  • Advanced Systems Format (ASF)
  • Motion Picture Experts Group (MPEG)
  • Audio-Video Interleaved (AVI)
  • MPEG Audio Layer-3 (MP3)
  • WAV sound files

Citrix Receiver includes a text-based translation table, MediaStreamingConfig.tbl, for translating Windows-specific media format GUIDs into MIME types GStreamer can use. You can update the translation table to do the following:

  • Add previously unknown or unsupported media filters/file formats to the translation table
  • Block problematic GUIDs to force fall-back to server-side rendering.
  • Add more parameters to existing MIME strings to allow for troubleshooting of problematic formats by changing a stream’s GStreamer parameters
  • Manage and deploy custom configurations depending on the media file types supported by GStreamer on a user device.

With client-side fetching, you can also allow the user device to stream media directly from URLs of the form http://, <mms://>, or <rtsp://> rather than streaming the media through a Citrix server. The server is responsible for directing the user device to the media, and for sending control commands (including Play, Pause, Stop, Volume, Seek). But the server does not handle any media data. This feature requires advanced multimedia GStreamer libraries on the device.

To implement HDX MediaStream Windows Media Redirection

  1. Install GStreamer 0.10, an open-source multimedia framework, on each user device that requires it. Typically, you install GStreamer before you install Citrix Receiver to allow the installation process to configure Citrix Receiver to use it.

    Most Linux distributions include GStreamer. Alternatively, you can download GStreamer from http://gstreamer.freedesktop.org.

  2. To enable client-side fetching, install the required GStreamer protocol source plugins for the file types that users play on the device. You can verify that a plug-in is installed and operational using the gst-launch utility. If gst-launch can play the URL, the required plug-in is operational. For example, run gst-launch-0.10 playbin2 uri=http://example-source/file.wmv and check that the video plays correctly.

  3. When installing Citrix Receiver on the device, select the GStreamer option if you are using the tarball script (this is done automatically for the .deb and .rpm packages).

Note about the client-side fetching feature:

  • By default, this feature is enabled. You can disable it using the SpeedScreenMMACSFEnabled option in the Multimedia section of All-Regions.ini. With this option set to False, Windows Media Redirection is used for media processing.
  • By default, all MediaStream features use the GStreamer playbin2 protocol. You can revert to the earlier playbin protocol for all MediaStream features except Client-Side Fetching, which continues to use playbin2, using the SpeedScreenMMAEnablePlaybin2 option in the Multimedia section of All-Regions.ini.
  • Receiver does not recognize playlist files or stream configuration information files such as .asx or .nsc files. If possible, users must specify a standard URL that does not reference these file types. Use gst-launch to verify that a given URL is valid.

Note about GStreamer 1.0:

  • By default, GStreamer 0.10 is used for HDX MediaStream Windows media redirection. GStreamer 1.0 is used only when GStreamer 0.10 is not available.
  • If you want to use GStreamer 1.0, follow the instructions below:
  1. Find the install directory of the GStreamer plug-ins. Depending on your distribution, the OS architecture, and the way you install GStreamer, the installation location of the plug-ins varies. The typical installation path is /usr/lib/x86_64-linux-gnu/gstreamer-1.0 or $HOME/ .local/share/gstreamer-1.0.
  2. Find the install directory of Citrix Receiver for Linux. The default directory for privileged (root) user installations is /opt/Citrix/ICAClient. The default directory for non-privileged user installations is $HOME/ICAClient/platform (where platform can be linuxx64, for example). For more information, see Install and set up.
  3. Install libgstflatstm1.0.so by making a symbolic link in the GStreamer plug-ins directory: ln -sf $ICACLIENT_DIR/util/libgstflatstm1.0.so $GST_PLUGINS_PATH/libgstflatstm1.0.so. This step might require elevated permissions, with sudo, for example.
  4. Use gst_play1.0 as the player: ln -sf $ICACLIENT_DIR/util/gst_play1.0 $ICACLIENT_DIR/util/gst_play. This step might require elevated permissions, with sudo, for example.
  • If you want to use GStreamer 1.0 in HDX RealTime Webcam Video Compression, use gst_read1.0 as the reader: ln -sf $ICACLIENT_DIR/util/gst_read1.0 $ICACLIENT_DIR/util/gst_read.

Configuring HDX MediaStream Flash Redirection

HDX MediaStream Flash Redirection enables Adobe Flash content to play locally on user devices, providing users with high definition audio and video playback, without increasing bandwidth requirements.

  1. Ensure that your user device meets the feature requirements. For more information, see System requirements.

  2. Add the following parameters to the [WFClient] section of wfclient.ini (for all connections made by a specific user) or the [Client Engine\Application Launching] section of All_Regions.ini (for all users of your environment):
    • **HDXFlashUseFlashRemoting=Ask Never Always**

      Enables HDX Mediastream for Flash on the user device. By default, this is set to Never and users are presented with a dialog box asking them if they want to optimize Flash content when connecting to webpages containing that content.

    • **HDXFlashEnableServerSideContentFetching=Disabled Enabled**

      Enables or disables server-side content fetching for Receiver. By default this is set to Disabled.

    • **HDXFlashUseServerHttpCookie=Disabled Enabled**

      Enables or disables HTTP cookie redirection. By default, this is set to Disabled.

    • **HDXFlashEnableClientSideCaching=Disabled Enabled**

      Enables or disables client-side caching for web content fetched by Receiver. By default, this is set to Enabled.

    • HDXFlashClientCacheSize= [25-250]

      Defines the size of the client-side cache, in MB. This can be any size between 25 MB and 250 MB. When the size limit is reached, existing content in the cache is deleted to allow storage of new content. By default, this is set to 100.

    • **HDXFlashServerSideContentCacheType=Persistent Temporary NoCaching**

      Defines the type of caching used by Receiver for content fetched using server-side content fetching. By default, this is set to Persistent.

      Note: This parameter is required only if HDXFlashEnableServerSideContentFetching is set to Enabled.

  3. Flash redirection is disabled by default. In /config/module.ini change FlashV2=Off to FlashV2=On to enable the feature.

Configure HDX RealTime webcam video compression

HDX RealTime provides a webcam video compression option to improve bandwidth efficiency during video conferencing, ensuring users experience optimal performance when using applications such as GoToMeeting with HD Faces, Skype for Business.

  1. Ensure that your user device meets the feature requirements.
  2. Ensure that the Multimedia virtual channel is enabled. To do this, open the module.ini configuration file, located in the $ICAROOT/config directory, and check that MultiMedia in the [ICA3.0] section is set to “On.”
  3. Enable audio input by clicking Use my microphone and webcam on the Mic & Webcam page of the Preferences dialog.

Disable HDX RealTime webcam video compression

By default, optimum webcam performance is provided by HDX RealTime Webcam Video Compression. In some circumstances, however, you might require users to connect webcams using USB support. To do this, you must do the following:

  • Disable HDX RealTime Webcam Video Compression
  • Enable USB support for webcams
  1. Add the following parameter to the [WFClient] section of the appropriate .ini file:


    For more information, see Customize Receiver using configuration files.

  2. Open the usb.conf file, typically located at $ICAROOT/usb.conf.

  3. Remove or comment out the following line:

    DENY: class=0e # UVC (default via HDX RealTime Webcam Video Compression)

  4. Save and close the file.

Configuring H.264 support

Receiver supports the display of H.264 graphics, including HDX 3D Pro graphics, that are served by XenDesktop 7. This support uses the deep compression codec feature, which is enabled by default. The feature provides better performance of rich and professional graphics applications on WAN networks compared with the existing JPEG codec.

Follow the instructions in this topic to disable the feature (and process graphics using the JPEG codec instead). You can also disable text tracking while still enabling deep compression codec support. This helps to reduce CPU costs while processing graphics that include complex images but relatively small amounts of text or non-critical text.

Important: To configure this feature, do not use any lossless setting in the XenDesktop Visual quality policy. If you do, H.264 encoding is disabled on the server and does not work in Receiver.

To disable deep compression codec support:

In wfclient.ini, set H264Enabled to False. This also disables text tracking.

To disable text tracking only

With deep compression codec support enabled, in wfclient.ini set TextTrackingEnabled to False.

Optimizing the performance of screen tiles

You can improve the way that JPEG-encoded screen tiles are processed using the direct-to-screen bitmap decoding, batch tile decoding, and deferred XSync features.

  1. Ensure that your JPEG library supports these features.

  2. In the Thinwire3.0 section of wfclient.ini, set DirectDecode and BatchDecode to True.

    Note: Enabling batch tile decoding also enables deferred XSync.

Enabling logging

To enable logging for Citrix Receiver for Linux:

  1. Download the Citrix Receiver for Linux and install it on your Linux machine, setting the ICAROOT environment variable to the installation location.
  2. For the Citrix Receiver for Linux, debug.ini is present in the configuration folder of ICAROOT. Create a symlink of this file at the $ICAROOT path by typing > ln -s config/debug.ini debug.ini from the command line.
  3. Edit the debug.ini at $ICAROOT and add the required trace parameters under the [wfica] section.
  4. Edit the $ICAROOT/config/module.ini file to add SyslogThreshold=7 at the end of the [WFClient] section. Doing so generates logs of all levels. To log only errors, set the SyslogThreshold to 3.
  5. To get syslog traces, edit the syslog configuration file. Go to the /etc/rsyslog.conf file (or syslog.conf, depending on your Linux distribution) and make the following changes:

    To enable local logging from all facilities, ensure that the $ModLoad imuxsock.so line is uncommented at the beginning of the file.

    The next two changes in the configuration file are necessary for remote logging, but not required for local logging to syslog.

    Server-side configuration: Uncomment the following lines in the rsyslog.conf file of the syslog server:

    $ModLoad imtcp

    $InputTCPServerRun 10514

    Client-side configuration: Add the following line by replacing localhost with the IP of the remote server: *.* @@localhost:10514

  6. Save your changes and then restart the syslog service by typing >sudo service rsyslog restart from the command line.
  7. All syslog logs are saved at /var/log. To view or edit logs in this folder, you need sudo access. The logs are going to the user-all-drivers_proxy22.log file. You can configure the path and name of the log file by editing the following line under the RULES section in the rsyslog.cong file –

    user.*      -/var/log/logfile_name.log

    You can edit the RULES section in the syslog configuration file. If the RULES section is not present in your syslog configuration file , you can add the RULES section from the sample rsyslog.conf file into your system syslog configuration file.

    Note: Every time you edit the rsyslog.conf file, you must restart the syslog service.

  8. Launch the Receiver process (./selfservice at $ICAROOT) and after the session ends, you can find the log file at /var/log. By default, the logs are appended to the log file on subsequent launches. To track traces for each launch, edit the configuration file before each launch to change the logfile and restart the rsyslog service.


To enable tracing, change the following parameters in the $ICAROOT/debug.ini file:

  • Connection Center Logging: under [conncenter] section, change “traceClasses” to “+TC_NCS”
  • Graphics (Thinwire) Logging: under [wfica] section, change “traceClasses” to “+TC_TW”
  • EUEM Logging: under [wfica] section, change “traceClasses” to “+TC_CLIB”

To disable tracing, change “traceClasses” entries to null.

For Example:


traceFlags =

traceClasses =

traceFeatures =

traceFile = clb.log.$$

traceBufferSize = 65536

Configuring multi-monitor layout persistence

This feature retains the session monitor layout information across endpoints. The session appears at the same monitor(s) as configured.


This feature requires the following:

  • StoreFront v3.15 or later.
  • If .ICAClient is already present in the home folder of the current user:

    Delete All_Regions.ini file


    To retain AllRegions.ini file, add the following lines at the end of the [Client Engine\Application Launching] section:






If the .ICAClient folder is not present, it indicates a fresh install of the receiver. In that case the default setting for the feature is retained.

Examples of use cases

  • Launch a session on any monitor in windowed mode and save the setting. When you relaunch the session, it appears in the same mode, on the same monitor, and in the same position.
  • Launch a session on any monitor in full-screen mode and save the setting. When you relaunch the session, it appears in full-screen mode on the same monitor.
  • Stretch and span a session in windowed mode across multiple monitors and then switch to full-screen mode. The session continues in full-screen across all monitors. When you relaunch the session, it appears in full-screen mode, spanning across all monitors.


The layout is overwritten with every save, and the layout is saved only on the active StoreFront.

If you launch multiple desktop sessions from the same StoreFront on different monitors, saving the layout in one session saves the layout information of all the sessions.

Configuring the save layout feature

To enable the save layout feature:

  1. Install the StoreFront 3.15 or later version (equal or greater than v3.15.0.12) on a compatible Delivery Controller (DDC).
  2. Download the build of Citrix Receiver for Linux 13.10 from the Downloads page and then install it on your Linux machine.
  3. Set the ICAROOT environment variable to the install location.
  4. Check whether the All_Regions.ini file is present in the .ICAClient folder. If so, delete it.
  5. In the $ICAROOT/config/All_Regions.ini file, look for the field – SaveMultiMonitorPref. By default, the value of this field is “true” (meaning this feature is turned on). To toggle off this feature, set this field to false. If you make any changes to the value of SaveMultiMonitorPref, you must delete the All_Regions.ini file present in the .ICAClient folder to prevent value mismatches and a possible profile lockdown. Set or unset the SaveMultiMonitorPref flag before launching sessions.
  6. Launch a new desktop session.
  7. Click Save Layout on the desktop viewer toolbar to save the current session layout. A notification appears at the bottom right of the screen, indicating success. When you click Save layout, the icon greys out. This indicates that saving is in progress. When the layout is saved the icon appears normal. However, if the icon is grayed out for a long time, see Knowledge Center article CTX235895 for troubleshooting information.
  8. Disconnect or log off the session. Relaunch the session. The session appears in the same mode, on the same monitor, and in the same position.

Limitations and unsupported scenarios

  • Saving a layout for windowed mode session spanning across multiple monitors is not supported due to limitations with the Linux Display manager.
  • Saving session information across monitors with varied resolution is not supported in this release and might result in unpredictable behavior.
  • Customers deployments with multiple storefront

Using Citrix Virtual desktops on dual monitor

  1. Select the desktop viewer and click the down arrow.
  2. Select Window.
  3. Drag the Citrix Virtual Desktops screen between the two monitors. Ensure that about half the screen is present in each monitor.
  4. From the Citrix Virtual Desktop toolbar, select Full-screen.

    The screen extends to both the monitors.