In almost every current XenDesktop/XenApp project for a specific period some applications are not available on the new platform, which are required by a group of users. A decision could be to let those workers do their work on the current/old platform. However most organizations don’t want that because the users don’t have access to new technologies of versions of other applications. In most cased the customer is looking for a way to offer access to those applications within the new platform. In this article I described the possible access methods to those applications running on a legacy environment, followed by the technical options to provide the access (including the advantages and disadvantages).
Desktop versus Published Applications
The first decision that should be made is the way the users get access to those applications running in the legacy Citrix environment. We can define two possibilities:
- Access via a Published Desktop
Many migration projects are providing the “Old” Desktop within the “New” Desktop which is the primary work location of the users. The advantage of this methodology is that only one icon needs to be provided to the user in the new environment. Also it’s clear to the end-user that the application is running in the legacy environment, which explains easily that the look and feel is different (especially from Presentation Server 4.5 running on Windows 2003 environments). Also for the service desk it’s easier to determine if the incident refers to the new or legacy environment. A disadvantage is that the user starts a Desktop within a Desktop. Because of that there the application interface is shown in a smaller screen as both taskbars are using a portion of the screen. Also the many used functionality ALT+TAB is not available in the legacy Desktop. The Desktop is seen as an application in the new Desktop. Last but not least it can be a political disadvantage; the users still knows that the old environment is in use (while there was promised that the old environment was shut down on moment X).
- Access via Published Applications
The second methodology to provide access to applications that are not available within the new environment is using Published Applications. From an end-user perspective the application is started seamless, so it looks like it’s running within the new desktop. Obviously the advantage is the fact that the application interface can be shown fully on the screen. Also users can switch between the application in legacy environment and the application in the new environment using ALT+TAB. However the interface will still look a bit different, which can raise questions at the end-user. If Published Applications are not used yet in the legacy environment, those should be created in this phase. Although it’s a pretty simple process, obviously this need to be done via the regular (change) process, which can be time intensive before the approval is provided and/or the creation process is finished. Also all Published Applications should be configured in exact the same way to use session sharing.
Ways to offer the acces
Besides the decision to use a Desktop or Published Applications also a decision should be made how the users can access the “Old” Desktop or the Published Applications from the new environment. The following options are available:
- ICA file(s)
Still an often applied option is the usage of the so called ICA file. In a ICA file all information is stored to set-up a connection to the old environment including starting a Desktop or Published Application. A ICA file needs to be created for each Published Application, so this can be labor intensive if this should be done for many applications. Also ICA files are obsolete; Citrix does not support those officially anymore. Because of that new features and technologies cannot be used when using ICA files. Last but not least ICA files contains specific server information, which can cause that the files need to be changes if the infrastructure changes. In the case of a temporary solution however, probably not much will change anymore regarding the old environment.
- Citrix Web Interface/StoreFront
Another option is using the current Web Interface (WI), StoreFront (SF) or set-up an additional WI or SF site on the new StoreFront server(s). The user opens within the New Desktop a browser and types the URL (possible via shortcut in the Start Menu, Desktop or similar) and chooses the Desktop and/or Published Application(s) he would like to use. By default Citrix Web Interface does not support Single SignOn (SSON), however there are modifications available (provided by the community) if this is a requirement. StoreFront support SSON by default. From an administrative prospective this is the easiest solution, in many cases the already existing components can be used. From an end-user perspective this options is laborious. When user need to access such applications sporadically it can be acceptable, however when frequently accessed user will not accept this solution.
- Citrix PNAgent/Legacy Support
The last possible option is using the PNAgent. With the PNAgent the Citrix Receiver (aka ICA Client) will be configured pointing to a Web Interface Services site or the Legacy support component within StoreFront. When the user has logged on, shortcuts of the Desktop and/or Published Application(s) are added to the Start Menu. Users can start the desktop/applications easily and transparent from the Start Menu where also the applications running in the new desktop can be found. Unfortunate the PNAgent functionality is end of life. With XenApp/XenDesktop 7.x Receiver 4.x is the standard receiver version, which lacks the real PNAgent functionality. It offers a kind of StoreFront look and feel application; the users need to subscribe to an application first (and then they will receive a shortcut in the Start Menu).
In StoreFront 2.6 there is an option called Disable User Subscription, unfortunate this does not work for the local Receiver (at the moment).
The latest available Receiver that offers PNAgent functionality is Citrix Receiver 3.4 Enterprise (Legacy PNAgent). Happily this version is support on all current operating systems, even Windows 2012 R2. So the decision can be made to use this client on the new platform, as long you are accessing legacy environments this won’t be a big issue and you do not encounter bugs that are solved in the Receiver 4.x release.
What to choose?
Maybe you are already expecting this answer, but it depends. The question you should ask it depends on what.
First let’s discuss about the decision to offer the Old Desktop or Published Applications. It depends here how often users need to have access to the applications in the legacy environment and the amount of applications that are required running in the old environment. In the case it are just a few applications that are used frequently I would advise using Published Applications. In the case it are many applications I prefer using a Desktop access. I will advise also a desktop connection if the applications are only used sporadically (for references only for example). But at the end the customer should decide what fits best within the organization.
The way the access is being offered is also depend of many factors. First the way the users have access the legacy environment before this project; secondly the available infrastructure components. When the decision is made to use a Published Desktop I still see many organizations using an ICA file. Although I really dislike ICA files, for this purpose it’s an easy, quick and workable solution. Also I have used the PNAgent functionality in the past, just like offering the icon via a modified Web Interface with an auto start modification.
For Published Applications the PNAgent functionality is ideal, however this is really end of life. But for a temporary solution it’s still acceptable for me, because the end-users are helped a lot with this functionality when using Published Applications. If you also would have silos at the end of the project I would suggest using Citrix StoreFront of the Citrix Receiver 4.x Legacy support functionality. At the end this is the same style like the old Program Neighborhood, we loved for so many years and complained a lot when it disappeared ( and now it’s back it looks like we don’t like that type interface anymore).