While Installing Receiver, Users May Encounter an Error: “Setup Cannot Continue Because This Version of Receiver is Incompatible With a Previously-installed Version”

Install the latest supported version of Citrix Receiver.

All versions of Receiver for Windows after version 4.4 can upgrade from any older version of Receiver without the need of using the clean up utility.

Receiver cleanup utility is not required and not recommended while upgrading to the Receiver for Windows 4.4, or later.

Related:

'Unexpected Error, Contact Citrix Support Error ID: XDDS:DFB94D9B' – Unable to Update Machine Catalogs -Citrix Cloud

In Citrix Cloud, after updating an image, users are unable to update the machines. Users get a popup noting ‘Unexpected Error, Contact Citrix Support’. The error details note Error ID: XDDS:DFB94D9B.

  • Azure Hosting Connection
  • Test Connection test failed
  • No App Registration in Azure related to Citrix App

Related:

Supported Databases for Virtual Apps and Desktops (XenApp & XenDesktop) AND Provisioning (Provisioning Services)

Citrix is committed to ensuring that our products function with the latest Microsoft SQL databases. Citrix supplies reasonable efforts to ensure compatibility with upcoming database releases. New versions of supported databases released after our products have been released, must work. However, Citrix recommends creating a test environment to ensure there are no unforeseen issues related to changes made to the new version or update of the third-party product. Individuals wishing to use the new release with current Citrix products must perform their own testing before using the platform. Citrix does not support any BETA versions of third-party products.

Note:

  • This document will be updated periodically as new information becomes available.
  • The Cumulative Updates for SQL versions are not called out explicitly. They are an extension of the product and supported.

What has changed from the last release of the matrix

  • Updated support for Virtual Apps and Desktops 7 1912 LTSR
Supported Databases Virtual Apps and Desktops (XenApp/XenDesktop) 7.15 LTSR / 1909 / 1912 LTSR XenApp/XenDesktop 7.6 LTSR Provisioning Services 7.15 LTSR / 1909 / 1912 LTSR Provisioning Services 7.6 LTSR XenApp 6.5 HRP07
SQL 2017
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes (1) Yes (1) Yes
SQL 2016 SP1, SP2
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes (1) Yes (1) Yes
SQL 2014 SP1, SP2, SP3
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes Yes Yes
SQL 2012 SP1, SP2, SP3, SP4
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes Yes Yes
SQL 2012
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes (2) Yes (2) Yes Yes Yes
SQL 2008 R2 SP2, SP3
x86 Yes Yes Yes Yes Yes
x64 Yes Yes Yes Yes Yes
Express Yes Yes Yes Yes Yes

  1. PVS 7.7 onwards Always ON is supported. PVS 7.11 introduced Multi-subnet Failover
  2. Known issue using SQL 2012 and above with XenDesktop, Refer to article ‘CTX132438 – Unable to Create New XenDesktop Site Using SQL 2012 Server’

Note:

  • The x86 and x64 versions of SQL (version 2012 and later) have been validated with Always On, Clustered, Standalone and Mirrored modes.
  • The Express edition has been validated only as Standalone.

Related:

Installation of Citrix Receiver LTSR may fail with the MUI message: 'Multilingual User Interface Language pack has stopped working'.

For all the LTSR Citrix Receiver stops and MUI pops up a message: “Multilingual User Interface Language pack has stopped working” and do not continue the installation.


Inspecting the CTXReceiverInstallLogs-yyymmdd-hhmmss, the installation ends suddenly during TrolleyExpress-yyymmdd-hhmmss.log

Below is a snip from the same machine that fails with .NET 3.5 enabled on the left and succeeds with .NET 3.5 disabled on the right. The stage ‘Collect environment info succeeded’ is not reached in the example on the left.


NOTE WELL: in other machines with healthy .NET 3.5 Framework enabled, Receiver installation is successful.

Related:

Error: “The licenses required by this edition of Citrix XenApp are not present on the license server”

Users are unable to access the applications, and the error “An error occurred while making the requested connection” is provided.

The event viewer displays the following error, which indicates a licensing issue:

Source: MetaFrame

EventID: 9014

Description: The licenses required by this edition of Citrix Presentation Server are not present on the license server LicenseServerName.

XenApp 6.5 introduces a new feature to server role called License Model, which is found in the XenApp Server Role Manager console under license configuration. You can choose from the following three types of models:

  • XenApp

  • XenDesktop concurrent system

  • XenDesktop user/device

Note: The setting to modify the License model is also possible by modifying the policies.

Related:

CVE-2014-4700 – Vulnerability in Citrix XenDesktop could result in unauthorized access to another user’s desktop

Description of Problem

A vulnerability has been identified in Citrix XenDesktop that could result in a user gaining unauthorized interactive access to another user’s desktop.

This vulnerability affects a specific, non-default configuration of Citrix XenDesktop 7 (all versions up to and including 7.5), Citrix XenDesktop 5 (up to and including Rollup 5.6.300 for Citrix XenDesktop 5.6 FP1) and Citrix XenDesktop 4 (all versions).

This vulnerability only affects Citrix XenDesktop deployments that use pooled random desktop groups and where the broker configuration setting ShutdownDesktopsAfterUse is set to disabled. Configurations that only use assigned desktop groups, including RemotePC access scenarios and user-dedicated desktops, are not affected by this issue.

This vulnerability has been assigned the following CVE number:

    • CVE-2014-4700: Vulnerability in Citrix XenDesktop versions 7.x, 5.x and 4.x could result in unauthorized access to another user’s desktop.

Mitigating Factors

The configuration setting ShutdownDesktopsAfterUse is enabled by default in configurations that use pooled desktops groups to reset the disk image and clean the desktop. For more details, please see the following Citrix Knowledgebase article:

https://support.citrix.com/article/CTX127842

What Customers Should Do

Updates to Citrix XenDesktop have been released to address this issue. Citrix strongly recommends that affected customers apply these updates as soon as possible.

The hotfixes for Citrix XenDesktop 7.1 and 7.5 can be downloaded from the following locations:

CTX140362 – Hotfix XD710ICAWSWX86005 – For VDA Core Services 7.1/7.5 for Windows Desktop OS (32-bit) – English

CTX140363 – Hotfix XD710ICAWSWX64005 – For VDA Core Services 7.1/7.5 for Windows Desktop OS (64-bit) – English

A VDA Rollup for Citrix XenDesktop 5.6 FP1 can be downloaded from the following location:

CTX138550 – Hotfix Rollup XD560VDAWX86400 (Version 5.6.400) – For Citrix XenDesktop Virtual Desktop Agent Core Services x86 – English

CTX138551 – Hotfix Rollup XD560VDAWX64400 (Version 5.6.400) – For Citrix XenDesktop Virtual Desktop Agent Core Services x64 – English

What Citrix Is Doing

Citrix is notifying customers and channel partners about this potential security issue. This article is also available from the Citrix Knowledge Center at http://support.citrix.com/.

Obtaining Support on This Issue

If you require technical assistance with this issue, please contact Citrix Technical Support. Contact details for Citrix Technical Support are available at http://www.citrix.com/site/ss/supportContacts.asp.

Reporting Security Vulnerabilities to Citrix

Citrix welcomes input regarding the security of its products and considers any and all potential vulnerabilities seriously. For guidance on how to report security-related issues to Citrix, please see the following document: CTX081743 – Reporting Security Issues to Citrix

Related:

Citrix Workspace App Launcher is unable to launch applications automatically with Apple Safari 12

SERVER SIDE CHANGES

For StoreFront deployments, modify web.config under the Receiver for Web (RfWeb) site (typically C:inetpubwwwrootCitrixStoreWeb) to activate the Citrix Receiver Launcher / Citrix Workspace App Launcher for Safari 12 and later.

1. Open web.config using your preferred text editor and locate the line : <protocolHandler enabled=”true” platforms=”(Macintosh|Windows NT).*((Firefox/((5[2-9]|[6789][0-9])|ddd))|(Chrome/((4[2-9]|[56789][0-9])|ddd)))” skipDoubleHopCheckWhenDisabled=”false” />

2. The value of the platforms attribute is a regular expression specifying the browsers that Citrix Receiver Launcher is used for client detection and HDX launches. Change the regular expression to:

“(Macintosh|Windows NT).*((Firefox/((5[2-9]|[6789][0-9])|ddd))|(Chrome/((4[2-9]|[56789][0-9])|ddd)))|Macintosh.*Version/(1[2-9]|[2-9][0-9]).*Safari/

3. This will add Safari 12 and later to the list of browsers that Citrix Receiver Launcher will be used.

CLIENT SIDE CHANGES


On a Mac Station running Safari 12 perform the following actions:

  • Launch Safari 12 Browser and select Safari from the Menu on top > go to Preferences and select it

User-added image

  • In preferences > Select Advanced tab > check Checkbox “Show Develop Menu in Menu Bar” (Located at the very bottom). This option will enable the Develop tab in Safari top menu

User-added image

  • Close the preferences window by selecting the red circle on the top left corner
  • Go back to Safari Menu and select > Clear History

User-added image


User-added image

  • Then go to Safari Menu and select the Develop Tab > Empty Caches

User-added image

  • Close All safari windows after this. Make sure no Safari Windows are left open.
  • Test using Safari 12 and browse to Storefront’s receiver for website URL.

CLIENT DETECTION BEHAVIOR ON SAFARI 12

  • Go to https://StorefrontURL/Citrix/StoreNameWeb
  • The first thing a user should see when testing going internally to Storefront’s Website is to detect Receiver/Workspace App. Please select “Detect Receiver/Workspace App”. Image below shows test using receiver.

User-added image

  • The following window prompt will appear “Do you want to allow this page to open Citrix Receiver Launcher?” please select “Allow”

User-added image

  • Once “Allow” is selected, no Manual interaction will be required by user. Site will automatically load to go to either “Logon Page when using explicit authentication” or it would “take you to your Apps enumeration” if SSO (Single Sign On) is enabled.
  • Once user is logged in, when trying to launch an application or desktop the following prompt will show for user to select “Allow”

User-added image

ADDITIONAL CONSIDERATIONS

  • When users are connecting internally and Storefront server is using an Internal SSL cert. Mac stations must have the CA Root and or Intermediate Certificate added to their Keychain Store in the Mac. Additionally, SSL certIFICATE must be set to Always trust / Allow. See example below:

User-added image


Note: You should clear browser cache and history before the changes mentioned in this article can take effect.

Related:

Receiver for HTML5 – Unable to Launch Apps Using HTTPS URL

When Receiver for HTML5 is hosted on a https site (default and recommended), non SSL/TLS websocket connections are prohibited by browsers.

In explaining the technical reason behind this it is important to understand the following two principles:

1. As opposed to existing as a separate process, Citrix Receiver for HTML5 operates within the frame and process space of the browser itself. As such the browser has the ability to enforce certain security parameters.

2. Additionally, when any Receiver (or Workspace App for newer versions) makes a connection to a VDA for either a published desktop or app, the underlying connection is made to the VDA and not the Storefront server as any kind of intermediate proxy.


This second point is less obvious in the case of Citrix Receiver for HTML5 because the published desktop or app displays within the browser frame and “appears” to be connected via the Storefront server. Despite this appearance though, the underlying TCP/UDP connection is still between the client and the VDA. If the Storefront base URL is SSL enabled (where it begins with https as is best practice) and the VDA is not SSL enabled (which it is not by default) the browser in this case will prevent the connection due to what it sees as an underlying inconsistency. The inconsistency is that while the URL shown in the browser frame is prefixed with https, the actual underlying connection is not https even though it is not obvious to the user.

There are two solutions for this.

Solution 1 is to enable SSL on the VDA using one of these guides:

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/secure/tls.html#configure-tls-on-a-vda-using-the-powershell-script

https://www.citrix.com/blogs/2014/12/11/how-to-secure-ica-connections-in-xenapp-and-xendesktop-7-6-using-ssl/

This will ensure that the connection path is SSL enabled between the internal client and the VDA.

Solution 2 is to have your connections from the clients first go through a Netscaler Gateway. Netscaler Gateway will proxy the connections and perform a SSL handshake between the client and the Netscaler. In this scenario there is no inconsistency and connections via HTML5 Receiver will succeed.

Related: