Solving Java issues on XenApp Servers (Part 1)

Recently I was troubleshooting an issue with Java on a provisioned server. The problem manifested by the user being asked to install Java when a particular UI interface was called that in turn invoked Java to display a Gannet table of appointments. As the user did not have elevated rights any attempt to install failed. Simply refusing to install also caused the function to fail. After much trial and error I determined that this was a result of two issues.

When a user connects to a Java app that user session, in normal conditions, it will try and determine if Java is installed. It does this by checking if it has a path to the \bin folder and if it has access to the cache folder. If either fails it will then attempt to install Java, however this is not possible for Citrix users normally as it will try to install on the hosting server.

What has to be done, to make Java applications work in Citrix, is to ensure that when a user connects they are able to satisfy the Java run-time requirements. To do this several changes need to be made on the hosting server so that both the run-time files are seen by the user session and that the cache is not in a location that requires privileged rights to access.

On the host XenApp server (provisioned or standard) the following needs to be done:

1. Make a note of the version(s) of Java currently installed. Download the offline installer(s) for those versions.
2. Log off all remote user sessions to ensure a clean uninstall.
3. Uninstall all Java versions currently installed on the server.
4.  Delete old file locations if any. These are often found in the following locations: C:\Program Files (x86)\Java\<version> or C:\Program Files\Java\<version>
5. Starting with the oldest (lowest numbered version) install using TS-Install or “change user” process. 
1.  If the version(s) of Java installed are pre version 6u20 you will need to make the ‘C:\Windows\Sun\Java\Deployment’ manually. This is important for supporting clients that have more current version installed locally. 
6. Once all versions are installed, you will need to change the default location for the Java cache folder. To do this:
1. Make a new folder: C:\JavaCache, make it R/W for “Everyone”. 
2. Create a file named ‘deployment.properties’ which should include the information of all Java versions installed as well as the location of the cache folder. Example:
3. Save the file, see step ‘f’ for location.
4. Create a file named ‘deployment.config’. This will have to be done for each version location and for use in ‘C:\Windows\Sun\Java\Deployment’
5. In each file you need to add the path for the properties file. This will depend on where the file is in relation to the version. Example:
6. Save file, see below for location.
7. Each of these files will need to be saved in the C:\Windows\Sun\Java\Deployment folder and C:\Program Files (x86)\Java\<version>\lib for each version.
7. Entry needs to be added in the servers PATH variable pointing to the /bin directory of each version. Example: C:\Program Files (x86)\Java\jre1.6.0_05\bin;C:\Program Files (x86)\Java\j2re1.4.2_19\bin
8. Navigate to the server configuration and access the User group rights. Ensure that either:
1. The Remote Users Group is included in the Users group or,
2. The User group includes the same user groups that are a part of the Remote Users Group.
9.  Close all. Proceed with the process of sealing the image if the server is provisioned.

What the above does is redirect the user session to a cache that doesn’t require elevated rights to access (such as the default). This along with the path changes allows the client to see that Java is installed and that the cache is available.

For verification, navigate to a Java app that is served from the configured XenApp server. Once opened access the Java Control Panel located in the System Tray, right click and select Open Control Panel. If properly operating you should be able to see the Java cache path properly configured.

If using roaming profiles you might need to reset (move or delete) the store profiles where ever they are stored.

In part two I will outline the other problem that showed up regarding Java interaction and an issue with XenApp configuration of SFTA.

Peace.