XenApp : Legacy Audio

When user clicks the application icon in the Web ICA link, at the application startup, startup audio tone may came up. It may be desired or user may not want it. Some applications have built in functionality based on audio.

Audio can be enabled or disable either during the application publishing or through the policies.

During application publishing, it can be enabled or disabled using Advanced > Client options as shown below:

It can also be enabled or disabled using the farm policies as shown below:

Recommended way is to use farm policies as it would be the central place to maintain it.

Enabling or Disabling Audio can be evaluated based on the bandwidth and the application requirement. If we have high bandwidth, we can enable it but if we have limited or low bandwidth we can disable it or enable it with limited bandwidth assigned for it based on the application requirement. This can also be done using the policies [Bandwidth > Session Limits > Audio] as shown below:

Remember this could one of the important parameter to be evaluated for the efficient application delivery in XenApp.

XenApp: Error while connecting

As discussed in the article “XenApp – Design Consideration – Part3”, poor application design could eat up the XenApp resources. This could lead to request denial to the users who are trying to access their application in XenApp. They could receive the below error message when they will click the icon of their application in Web ICA link:

Reasons of the above error message:

1. Heavy Application Clients: In XenApp, many application clients are installed on the same machine. If they are heavy in terms of processing power, they could eat up the available resource [memory and CPU].
2. Poor programming: Sometimes because of lack of experience, programmers forgot to free up the memory consumed by the created objects at the time when they were going out of scope.
3. XenApp down: Sometimes because of above two reasons or any other reason, XenApp machine goes down. In such case, if a user will try to access their application, they will certainly receive the above error.

Resolution:

To resolve the above issue:

1. If XenApp is still up and running, try to see if memory or CPU is available, if they are not, try to free them. Find out which application is consuming the most. This will be required to study the application design to prevent such scenarios in future.
2. If we are not able to free up the resource, last option is to restart the XenApp machine.

Recommendations:

1. Load Evaluators: Proper load evaluators should be created and set for each application or servers.
2. XenApp restart schedule/plan: Restart schedule/plan should be in place. Regular restart can free up the system resources. Restart should be done at off hours as during that period, users will not be able to access their application.
3. Application design revisit: Based on the data on the application that is consuming most of the resources, they should be revisited to find out the reason why they are consuming most of the resources. If they really requires large memory and high processing power, they can be given dedicated XenApp. We can capture the information on the application load with many users accessing it at the same time by the use of any load testing tools like HP’s LoadRunner.
4. Application grouping: As discussed in the above point, if application requires large memory and high processing power, they can be given the dedicated XenApp. Many medium sized applications can be grouped/installed on the same XenApp. Proper grouping of application is extremely important for successful XenApp implementation. 

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.

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:

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

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:

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:

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:

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.

XenApp – Published application – Disabling/Hiding disabled application

In the software world, each software has to be upgraded to new versions to cater the ever changing requirements and user demands.

To make the software available to users, it should be installed and published in XenApp. Once published successfully for users for the first time and after that during several new releases of the same application, if there is no change in the application executable name, we don’t need to re-publish it, though it needs to be un-installed and re-installed/upgraded to the new version.

Now there could be two possibilities/scenarios administrator may encounter during the application upgradation:

1. Users already connected to the old version of application: Suppose when an administrator has planned to upgrade the application, during the same time, some user from other part of the globe is accessing the application to perform their daily job. In this case, administrator will not be able to upgrade the application as the application has already been locked by users.
2. During upgradation, users might try to connect to the application: It is also possible that users might try to access the application while the administrator is in the middle of application upgrade process. This could lead to access denied or some error message to the users that could create some quos in user community and end-up in many helpdesk calls.

To avoid the above scenarios, published application icon can be disabled. It can be disabled by right clicking the application icon in access management console and selecting the option “Disable application”. It can also be disabled by selecting the application properties and selecting the check box “Disable application” as shown in the below diagram. Now when user will try to click on the published icon, he will not be able to launch it. Now user might get irritated as he is able to see the application but not able to access it, so the recommended way is to select the checkbox “Hide disable application” along with the checkbox for “Disabled application”. This way users will not be able to see the published icon.

Once the upgradation is done successfully, the icons can be enabled by right clicking the application icon in access management console or by un-checking the check boxes for disabled and hide disabled application from the application properties screen.

With the above recommendation and proper upgradation/down time window, application can be upgraded without having issues to the users.

XenApp – Publishing ULRs

Sometimes users have not been granted admin rights to the workstation they are working on. The purpose is not to allow them to install anything on the workstation.

Few websites requires some plug-ins like java plug-in to be downloaded and installed on to the user’s workstation to work properly. In the absence of admin rights, Users can not install these plug-ins into their workstation and so they will not be able to work properly with the websites they require to work on.

One option to resolve this issue is for administrator to install the required plug-ins to the user’s workstation. This could be a problem as there may be many users working on different websites with different plug-ins. It would be difficult to manage those plug-ins in case of version upgrades.

Second option is that the XenApp administrator can run the required website on the XenApp for the first time to get all the required plug-ins downloaded and installed. Once the plug-ins will be installed successfully, administrator has to publish the required website from XenApp. To do so, Administrator needs to publish internet explorer executable with website url as its parameter as shown below for all the required users:

This will resolve the problem as all the processing will be done on XenApp and users do not have to have any rights to install the plug-ins.

Second option is recommended as it is easy to support and maintain all the plug-ins on some central XenApp machines but following points needs to be addressed before selecting this option:

1. Many websites required different versions of plug-ins and sometimes two same plug-in having different versions could have some compatibility issues and should not be installed together. In short, all the plug-ins needs to be analyzed for their compatibility before installing to the XenApp. Incompatible plug-ins should not be installed on the same XenApp.
2. As we are publishing the internet explorer executable for the users, we are giving them access to XenApp’s internet explorer and so they may use it to access any other website as well. This could lead to the security issue and could impact the XenApp and the network performance. For example, user can go to any site from the published iexplorer and can download anything or can ever watch the online videos. Since all the processing will be done on XenApp, this could eat-up the network bandwidth and XepApp CPU. To prohibit users to access any other website other then the one that is given as parameter to the published iexplorer, proper GPO’s (Global Policies) should be designed and applied for the users.

Cloud Computing From 60,000 Feet

Introduction:

“It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a ‘cloud’ somewhere. And that if you have the right kind of browser or the right kind of access, it doesn’t matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the cloud…”
– Dr. Eric Schmidt, Google CEO, August 2006

In my opinion…

“Clouds are always good. For farmers it brings the sign of hope and confidence, for Company CIOs and CTOs, it brings the sign of growth in terms of effort and money savings at the edge of the competitive environment…”

One question that every CIO and CTO wants to have answer of “How to reduce the resources like servers without reducing the overall computational power and the profitability.”

Cloud Computing could be the ultimate answer.

          

As a user, when we are accessing the data from any device, from any location, we have no idea how processing of information is going around in the cloud. It’s just like a black box. 

Virtualization is the heart of Cloud computing.

Cloud can be classified as two broad categories:

• Public Cloud
• Private Cloud

Public Cloud:

Public Cloud could be any cloud maintained somewhere outside the company’s firewall/boundaries on some public domain. It has virtual data centers maintained by the cloud providers.

Believe or not, “Anyone with a web-based email account or a profile on a social network is already taking advantage of public cloud computing, whether they know it or not.” 

Advantages:

• With this kind of model, information can be dynamically delivered on demand [subscription basis] and accessed from anywhere anytime. 
• Resources in the cloud can be shared between multiple users and so they can be utilized to the maximum extend.
• As cloud is outside companies boundaries, there is no way to know if anything is changed or upgraded because of some failure or unknown reason.
• Any company can buy the raw processing power and the storage capacity and thus they can avoid the headache of maintaining it. It is best for the small or medium sized organizations as they do not have to buy any physical hardware or expertise to maintain it.
• In terms of cost and usage, public cloud can be compared with the electricity usage. When you require it, switch on it, use it and pay for it. When you don’t, just switch off it and you do not have to pay for it. It’s called pay on demand.

Disadvantages:

• Without proper security model, Public cloud could be prone to the security breaches and could lead to the failure. This could be termed as cloud bursting. Also, many companies do not want to put their sensitive data or IPR [intellectual property rights] data or mission critical transactions on to the public cloud.
• Consumers will not have any control on the way, data could be stored/retrieved/accessed from the cloud.
• The cost of using public clouds for extended period of time can turn out to be more expensive than owning the infrastructure in-house.

Private Cloud:

Private Cloud is confined to the company’s boundaries and is accessed from the outside world via firewall. Though with this kind of model, information can be dynamically delivered on demand but it can only be accessed by the authorized users from anywhere anytime with proper security boundaries via a firewall.

Advantages:

• Without any fear, companies can put their mission critical transactions and data in their private data centers. This is the key advantage of Private cloud that they are more secure as IT department will have more control over the data and the way it can be accessed.

Disadvantages:

• Due to the cost of hardware, data center space, technical expertise to know how to create and maintain it, it is not recommended for small or medium sized organizations.
• Companies following this approach of private cloud are missing the benefits of the infinite processing power, infinite capacity, flexibility and Pay on demand offered by the public cloud.

Conclusion:

As I have explained above that both Private and Public cloud has advantages and disadvantages so just using/adapting any one might not give the full benefits of the cloud computing. Using the mixture of both could be the good idea.

Public cloud can be used for non – sensitive data like it can host QA environment or the storage of less sensitive data. With proper security boundaries like with VPN, even some important data like email server can be hosted on the public cloud.

Private cloud can be used to host the sensitive data that requires high amount of security.

Reference:

White Paper: “A Cloud Guide For HPC
Top Drivers, Barriers, Use Cases, and Vendor Requirements for Private and Public HPC Cloud Computing” by Mr. Ashar Baig
www.univaud.com

XenApp – Display memory – Dual Monitors

In the real world, many users are using Dual monitors to have big/extended display facilities. In such a scenario, if the users are working on graphics intensive applications like CADS, they might experience problems with dual display like:

• they might not be able to extend / take the application screen to the other monitor in dual monitor system
• they might be able to move but the image of the application screen might not get refreshed and user will feel like their display got freezed.

The most probable reason of the above issue is the lack of proper display memory allocation in XenApp environment.

To get rid of the above issue, XenApp administrator has to increase the display memory value to some higher value like 8192 KB [it is maximum value]. This could be done on server level or on the farm level as shown below:

The recommended way is to implement it on the farm and on servers select the option to use the farm settings. This way we can control it from the top level.