1) USD hosted within Citrix
This works fine and is supported on XenApp 7.6 at the time of this writing. I’m told by customers that it also works fine on XenDesktop but Microsoft does not specifically test that scenario and thus considers it unsupported at this time. For current up to date information, see the official documentation. The problem we often see here is that USD is more of a hybrid web/thick client application than it is a true thick client application. USD hosts the web applications in it’s UI so this means that moving USD to the Citrix server also means running your web applications from the Citrix server. If you already do this, then you aren’t likely to see any problem. Where we do see problems is when a company normally runs web applications from the client desktop and only thick clients from the server. When USD is moved to the server, it brings the web apps with them including all the memory and CPU requirements of those web applications, which can be significant. Usually the complaint is that it doesn’t scale or is using too much memory, which means they didn’t think through the ramifications to their server sizing, having all your web application run from the Citrix server. USD itself uses about 300mb of memory but the web applications can use significantly more. This problem is complicated by the fact that the standard web hosting method today is Internal WPF, which internalizes the browser memory into the USD process so if you look at the memory usage in USD, you actually see USD + IE memory for all hosted browsers. It is extremely important to understand the memory, CPU, and IE implications of running a hybrid application like USD from a Citrix server.
USD Caching is also a consideration on Citrix. USD Caching consists of storing a local copy of your configuration including hosted controls, action calls, etc so it doesn’t need to load all the records from CRM every time the application starts up. It has nothing to do with browser caching. This cache is stored in the \users\[myuser]\appdata\roaming\Microsoft\USD or %appdata%\Microsoft\USD folder. If you have Citrix wipe this folder on logout and you do not have it replicated on login, then your cache will be refreshed from CRM regardless of the ClientCacheVersionNumber setting in USD configuration. See https://technet.microsoft.com/en-us/library/dn646861.aspx for more information about USD caching.
2) USD Hosting a Citrix Application
The second scenario is running a single application in Citrix, inside a tab in USD. Citrix has two modes, desktop mode and streaming mode. Streaming mode is basically treating the application as the shell and removing the chrome from a Citrix standpoint but looks pretty cool to the users. This detail is important when implementing in USD however, since the method of hosting is identical between the two. Ultimately USD would use the Citrix ActiveX control underneath to load a Citrix ICA file that connects to the Citrix instance. This instance can either be the desktop or the streamed application. One important thing to realize is that the frame inside USD is fixed size or at least is controlled by the USD host rather than the remote application, so the nice feature of streaming where the frame matches the size of the application goes away. Normally you would maximize the application within the USD frame but if you don’t, you will see the background of the desktop, which might be a little strange to those familiar with application streaming.
The documentation for connecting to a Citrix session as a hosted app refers to an ICA file ( see CRM2016SDK/UII/Bin/UII/Cirtix%20Server%20Component/ReadMe.html). ICA files contain a static entry for the server the session will connect to, however, this doesn’t work too well for load balancing. How Citrix seems to have dealt with this is to generate the ICA file on the fly using the Citrix application portal. The user and perhaps the admin doesn’t even know the ICA file is still being created. The out of the box implementation in UII/CCA/USD does not support this on the fly generated ICA file however. You can either save one to disk or you can do something like I did in the attached hosted control code to capture the generated ICA and attach it to the ActiveX control, then start loading it. This code shows a browser and when the user clicks the application to launch, it captures the ICA file that Citrix generates, attaches it to the ActiveX control and starts the connection and hides the browser.
Combining #1 and #2
While it is possible to combine #1 and #2 here, often all applications are installed on all Citrix servers to help with scaling. If that is the case, you are usually better off hosting the native application in USD and run the entire thing in one Citrix session rather than having pieces running on different Citrix servers and having USD also hosted in a Citrix session. This is a lot easier to setup and troubleshoot as well.
How Citrix Integration Works in USD
Probably the most important thing to understand about how USD interacts with Citrix is that it doesn’t just display the session that the user sees. USD also establishes a special Citrix data communication tunnel called a Citrix Virtual Channel. Some registry entries are required on both ends for Citrix to allow this channel to be established. When an Action is called on the hosted control on the desktop, USD packages its contents and forwards it to the Citrix server via this Virtual channel over to a Stub that is running on the other side. Note that the UI Stream that the user actually sees is a separate stream and independent of the virtual channel logically.
The communication between the two applications is represented by the following diagram. All actions and exchange of data happens via the virtual channel with the special executable stub that must be installed on the Citrix server. It is possible to also load a custom adapter via the stub on the server for advanced application scenarios.
Running Unified Service Desk and all hosted applications on a Citrix server is straight forward and has some benefits, including eliminating the need to do a desktop install and the ability to support non-windows platforms on the desktop. On the other hand, it is important to understand that USD is not a typical thick client application but is instead a hybrid web/thick application. This means you must have your browser properly configured on the Citrix server as users will be viewing content with it through the USD frame. It also means that those web applications that use significant amounts of memory that you were previously use to consuming only client resources, are now going to consume resources on your servers when hosted in USD.
Hosting a Citrix application within USD can be complicated to setup but it provides a number of benefits when the hosted application is a traditional thick client application. With the attached hosted control (with perhaps some modifications for your scenario), you can also support the launching of applications via the Citrix portal and the auto generated connection information that it creates.