XenApp – Design Consideration – Part 3

In the part 1, we discussed about how to manage user / application specific configuration data for successful implementation of any application in XenApp world. That was one of the important parameter to be considered.

In this article we will discuss about how to minimize XenApp’s memory and CPU usage for less important activities so that user can have their share of CPU and memory most of the time.

In the client – server architecture as shown in the below diagram:

  • Clients will be installed on XenApp
  • Servers will be installed on the application server machine [non-XenApp]
  • Many clients will share same XenApp
  • Many servers will be installed on common application server machines.

In the below diagram, All client are installed on same XenApp machine. Client 1 and Client 3 are sharing same application server machine where their servers are installed. Client 2 and Client 4 have dedicated application server machines where their servers are installed. Users will access their client from Web ICA.

image

Now since all the clients are installed on the same XenApp and if these clients are heavy in terms of processing, with many users accessing these clients, this could eat up the available memory and CPU of XenApp.

Also, sometimes, because of less experienced developers, when they create the objects in the application, they forgot to free the memory space occupied by the object by deleting them when they go out of their scope. Sometimes developer assumes that the underlying programming language will take care the garbage collection. In such cases when users will access these clients, the unhandled objects might eat up the available memory for no reasonable activity. It would lead to the request denial by XenApp.

Mission of every administrator is to make XenApp running and available for users each and every time. Following recommendations could be helpful in achieving the above mission:

  • Thin client and thick server: In the client server architecture, if we design the application in such a way that maximum processing should be done on the application server side and client should act like input and output interface with minimum processing, so with high end application server machine, we can make XenApp available to maximum users all the time.
  • Programming language best practices: Developers should be aware of all the best practices and recommendations of the programming language they are using. They should use those function/methods that consume less memory and CPU. If they have created any object, they should kill it once they will be out of scope.

In the traditional way of deployment outside XenApp, the above recommendation might not show the big benefits but in the environment where several clients are installed on the same XenApp and many users are accessing them at the same time, the above recommendations will make the difference.

XenApp – Design Consideration – Part 2

As we discussed in Part 1, if an application is storing user specific data in the application folder or on some other location on the client machine, this application will not behave as expected on XenApp.

To address this issue, we might have to revisit the application design for storing the user specific data to the user’s roaming profile. Sometimes it is not feasible to change the application quickly for such issues.

The workaround to address this issue is to write some script that will copy the user specific data from client machine to the user’s roaming profile and then the same script will launch the application for the user.

Below is the VBScript to do the same. This VBScript copies the user specific data from some temporary location to the user’s roaming profile location. Once it copies the file, it runs the application.

'##############################################################################
'#
'# Language      VBscript
'# 
'# Author        Mohd Aslam
'# Date          10.18.09
'# Description   A script that copied user specific configuration file 
'#              from application folder to the roaming profile.   
'##############################################################################

Dim objFSO, WshShell

set WshShell = WScript.CreateObject("WScript.Shell")
set objFSO = CreateObject("Scripting.FileSystemObject")

strDirectory = WshShell.ExpandEnvironmentStrings("%Homeshare%") 
               & "\Application Data"

if Not ObjFSO.FolderExists(strDirectory) Then

    Set objFolder = ObjFSO.CreateFolder(strDirectory)
    
End If

strDirectory = WshShell.ExpandEnvironmentStrings("%Homeshare%") 
               & "\Application Data\Notepad"

if Not ObjFSO.FolderExists(strDirectory) Then

    Set objFolder = ObjFSO.CreateFolder(strDirectory)
    
End If

Source = "C:\temp\Notepad\"
Destination = WshShell.ExpandEnvironmentStrings("%Homeshare%") 
              & "\Application Data\Notepad\"
Filename = "Notepad.xml"

'***************************************************************
'            Execute Procedures
'***************************************************************

On Error Resume Next

'First copy the file from application folder or some temp location 
'to the roaming profile.

If Not ObjFSO.FileExists(Destination & Filename) Then

ObjFSO.CopyFile Source & Filename, Destination & Filename

End If

' execute the application
Wshshell.Run "c:\Windows\notepad.exe"

In XenApp, we just need to publish this VBScript.

It can be published in XenApp as shown below:

image

Important point to be noted is that the application should have some way to know where the user’s specific data is stored on roaming profile. By this I mean, application should be configured to look for the user’s data from the roaming profile.

If application is hardcoded to look for the user’s data from some specific location only then application virtualization [application streaming/isolation] could be the only solution as there we can implement the redirection rules to point to the correct location. 

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.

User Profiles – Static and Roaming

Introduction:

Let us start this topic with a scenario…

User1 has just logged into his machine and he has changed his system settings like he added few favorites, changed his desktop background etc and after that he has logged off from his machine successfully. Next time when he will re-visit his machine, he will expect to get the same settings that he did the last time.

  1. How would it be possible for him to get his changes for subsequent logins??
  2. What if he wants to have same settings when he logged into any other machine on the same farm??

The answer is User Profiles.

User profile is the collection of personal data/information/user application data specific to the particular user. 

Whenever user did some changes related to his settings and then logs off from the machine, those changes get saved to his profile. When he logs back to his machine, all his previous settings get loaded back and applied from his profile.

Classification:

User profiles can be classified into:

  • Static Profiles – Answer of First question above
  • Roaming Profiles – Answer of Second question above

Static Profiles:

It is a user specific profile stored in the user’s local machine. Suppose user logs on to machine 1 and did some changes to his personal settings, these changes will get saved to the user’s static profile. In non-VISTA machines the location of the profile is [C:\Documents and Settings\[UserID]] and in VISTA machines the location is [C:\Users\[UserID]].

The architecture is shown below:

image

Advantage of Static Profile:

  • Since it is specific to specific machine and stored at the same machine, it is easy to implement it.
  • No extra space required for it.

Disadvantage of Static Profile:

  • As said above, this type of profile is stored on specific machine; users will not be able to see their personal settings/data on some other machine.
  • In case of failure, users will lose their profiles containing their personal data and settings.

Roaming Profiles

Unlike static profile where profiles are stored on the individual machines, in Roaming profiles technique, user’s profile is stored on network shared location on some server on same network/domain as shown below:

image

When user logs on to machine 1, whatever changes he did with his personal settings, those get saved to his local profile folder. When user logs off from the server those changes get copied to the roaming profile share from the local machine. Next time when user logs back in to the server, user’s profile get downloaded from roaming profile share and applied to his local profile location in his machine. This way user gets his profile irrespective of the machine where user has logged in. During logoff, the changes user did get copied back to the roaming shared location.

Advantages:

  • Automatic Resource Availability: Since the user data is saved on the central location, it is always available for user from any machine with in the same domain.
  • At the time of failure of any particular machine other then the roaming profile machine, user’s data will still be available. 
  • Central management of user’s data: As all the profiles are stored on the central location, it is easy to manage them. Administrator can enforce various rules/policies on them.

Disadvantages:

  • Network bandwidth bottle neck: During user’s login process, his profile gets downloaded from roaming profile server through network. This could slow down the login process, if user profile has large amount of data that could eat-up the network resource. This could be handled by:
    • Using caching of files: If most of the files are already cached, then no need to download it time and again. However if the data get changed then only it needs to be downloaded and uploaded. This way we can decrease the overall size of the user profile so less traffic to flow and hence less bandwidth required.
    • Using folder redirection: Bandwidth can also be saved by redirecting all the requests for the user profile to the folders in the roaming profile rather then downloading then at login time.
  • Single point of failure: As shown in the above diagram, User’s roaming profile share machine could be the single point of failure. If this machine fails because of any reason, all the user profiles will be lost. To mitigate this single point of failure, regular backup of the profiles is recommended.

Conclusion:

In a large farm, maintaining profiles at the central location is always recommended. With proper backup plan, caching strategy and folder redirection, above disadvantages can be addressed. After all, in this dynamic work environment like in XenApp where user can access his application from any machine, storing and managing users profile at central location could be the key to success.