XenApp – Design Consideration – Part 1


Most of the traditional client – server applications are not designed by keeping citrix architecture in mind.  They are simply designed such that their client would be installed on the user’s workstation and application server on some application server machine. When such applications are installed and configured on the XenApp, sometimes they do not behave as expected.

Each application has some sort of configuration files like initialization files, config files to store application specific data like database connection strings. These configuration files could be of two types:

  • User specific configuration files: This is required to store user specific data like user settings.
  • Application specific configuration files: This is required to store application specific data like database connection string, reporting server names and URLs etc.

In the traditional approach of application deployment without Citrix framework as shown in the below diagram, since the application client is installed on User’s workstation so storing the above configuration files are not the big deal. Some applications are designed in such a way that they:

  • store the user specific files under the
    • application folder or
    • dedicated folder on user’s workstation or
    • user’s static profiles [C:\document and settings\[Username]\Application Data\…]
    • registry HKEY_LOCAL_MACHINE
  • store application specific data under the
    • installation/application folder

image

Since in the traditional approach, application client will be installed on user’s workstation, so storing information as described above has no issues as all users will run their own flavor of client.

Now under the Citrix/XenApp, the way application clients will be installed/access is far different from the traditional approach. In XenApp, the application clients will be installed/configured on the central XenApp machine and all the users will access it from the same central location. Now taking the above traditional model to the new XenApp world might not work. Let me explain how with a scenario:

There is an application client A. It is designed with the traditional approach without taking XenApp into consideration. This client is writing:

  • user specific data like user’s layout settings into its installed folder
  • user specific data like [MaxCount=30] into the HKEY_LOCAL_MACHINE

Now if this client A is to be installed on user’s workstation alone, it will work absolutely fine as it will not have any conflict with other user client instance.

Now suppose we need to deploy this client on XenApp. Many users will access this client in XenApp using Web ICA client. Suppose at the first time User A has accessed client in XenApp. He modified some of his layout settings and changed the MaxCount value in registry to 40 as per his requirement. These values will get saved to their respective locations as per the design. Now second time some other User B logged into the same client and he also changed some of his layout settings and changed the MaxCount value in registry to 50 as per his requirement. Now these changes will over-write the changes User A did before as they are stored on the same common location and so application might not behave as expected.

To make client A compatible to the XenApp so that it can behave properly we may have to:

  • revisit the design of the client or
  • use some scripting technique to resolve the above issue or
  • Application Isolation technique

Here in this article I will discuss about the design consideration. I will write separate articles on scripting and application isolation technique to resolve the above issue.

Let me now discuss the new architecture:

In the XenApp world, application client will be installed on central XenApp machine. This XenApp machine will support both the static and roaming profiles. User specific data will be stored in:

  • User’s roaming profile [recommended way]
  • HKEY_CURRENT_USER if it is a registry related data.

Application specific data will be stored in the application/installation folder as before.

The architecture is shown below:

image

Now let us revisit the above scenario with this new XenApp approach. As said above, suppose User A has changed some of his layout settings and registry value [MaxCount=30]. These values will get stored in the User’s roaming profile and HKEY_CURRENT_USER hive in registry respectively. Next time when User B logged into the same client, his changes will be store on his roaming profile and HKEY_CURRENT_USER hive that is separate for every user. Now when user A will revisit the client he will find all his changed settings as his settings were stored in his area where other user’s will not have any access. This way application will behave properly for all users.

This was one of the important design considerations for successful usage of XenApp technology. There are also other techniques that I will discuss in Part2 of this article.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s