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:image

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.


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.


  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.