Assessing Applications for XenApp Compatibility - Citrix eDocs

Assessing Applications for XenApp Compatibility - Citrix eDocs

Assessing Applications for XenApp Compatibility

Ensure applications are compatible with the server operating system and are multiuser compatible. Application compatibility drives the application delivery method (for example, accessed from the server, streamed to server, or streamed to client desktops).

Evaluate whether or not applications are compatible with multiuser environments and, if so, the application server’s scalability. Before testing applications for compatibility, investigate how the application works with Terminal Services or XenApp. Terminal Services-compliant and Windows Logo certified applications experience few, if any, issues compared with noncompliant applications.

Initial application compatibility testing typically involves publishing the application so that is installed and hosted on a server in a test farm and having multiple test users connect to it. Applications that function correctly should be tested for conflicts with other applications you want to install on the server and, then, scalability.

Applications that do not function correctly might not have been designed for multiuser, multiapplication environments. Applications not designed for these environments can conflict with other applications or have scalability or performance issues. Registry settings, attempts to share files or DLLs, requirements for the exclusive use of files or DLLs, or other functionality within an application can make it incompatible. You can resolve some application issues through streaming, using features like Virtual IP, or siloing the application.

After testing, if these solutions do not work, you might need to find and fix the root cause of the problem. To identify root applications issues, consider using tools like the Microsoft Application Compatibility Toolkit (ACT) or Microsoft’s Windows Sysinternals. Examples of common issues include:

• .INI files that contain hard-coded file path names, database connection settings, and read/write file locking configurations that need to be reconfigured to prevent file conflicts.
• Custom applications developed with hard-coded paths in the registry.
• Applications that use the computer name or IP address for identification purposes. Because a server can run multiple instances of the application, all instances could use the same IP address or computer name, which can cause the application to fail.

When you find any of these hard-coded settings or other conflicts, document the setting in your farm design document. After you find resolutions to these issues, design your farm and test your design by creating a pilot test farm.