Microsoft’s SoftGrid product can do some amazing things to help application compatibility issues. That being said, while administering your SoftGrid environment, you will undoubtedly come across problems with specific applications. You may successfully stream your application on one PC and everything works fine. You may then stream your application to another PC and the same application bombs.
This was the case when I recently tried to stream Java 1.5 to a client that had Java 1.6 installed locally. In previous versions of Java, there was a setting in the Java applet in Control Panel that allowed this type of configuration to work. The newer version of Java, however, does not react quite like its predecessors.
What I found was that you could stream Java 1.5 (within Internet Explorer of course) and it would work fine until the local version of Java 1.6 is launched. The only way I could get the Java 1.5 virtual app to work again was to uninstall the local Java 1.6.
I determined that when Java 1.6 was launched, it must be laying down registry entries or files that the Java 1.5 is reading thereby causing a conflict.
What do you do in situations like this?
One of the most common tools, that can be used to track down the culprit of such problems, is Sysinternal’s Process Monitor. If you’ve never heard of it, it’s a great (not to mention FREE!) tool created by Mark Russinovich that combines the functionality of RegMon and FileMon.
In order to use Process Monitor (ProcMon) in the virtual environment, one must first modify the .osd file for the virtual application. For detailed instructions, see KB 939896.
Once you’ve created your log file, you can now begin hunting down the source of the problem.
When ProcMon logs are created, hundreds of thousands of entries are written in a matter of seconds. I captured data for less than 30 seconds and had over 100,000 entries. Thankfully, ProcMon makes it easy to weed out irrelevant data.
Since I deduced that Java 1.6 was creating something that was causing a problem, I first started my search by filtering my log file. The idea that Java would lay down registry keys, which would cause problems, seemed to make the most sense, so I began narrowing my results to registry keys.
I only wanted to show a specific operation: RegCreateKey. You can do that by simply right-clicking on a line that contains the operation in question, click ‘include’, and then click ‘Operation’.
Next, I filtered my results so that only the ‘iexplore.exe’ process was shown (use the same process as before, but choose ‘Process Name’ instead of ‘Operation’.
I had successfully shrunk my results from over 100,000 entries to only 612. Looking over my results more closely, I could see that most (over 500 of the 612) of the keys created were within the path: HKCU\Software\Classes\CLSID, so I focused my search there.
Looking closely at the ClassID’s I could see that the second, third and fourth portions of the ID look very similar to Java versions (ex. 0015-0000-0028 = Java 184.108.40.206).
Logically, this seemed a reasonable source of my problem, and I decided to test it.
I went through the following steps:
1) Launch the local Java 1.6 (In my case I went to www.javatester.org/version.html from the local Internet Explorer.)
2) Delete the registry (first export the key, so that it can be put back in place, of course).
3) Launch the virtual Java 1.5 (In my case I again went to www.javatester.org/version.html ,but this time from the virtualized shortcut to IE).
This did indeed fix my problem. I now had Java 1.6 running locally and Java 1.5 running in the virtual environment.
The Final Solution
Now that I knew what registry keys were causing the problem, I needed to make sure those keys did not exist whenever the virtual application is launched.
Here’s what I did:
I created a reg file (let’s call it CLSID.reg) with the following info:
Windows Registry Editor Version 5.00
I created a batch file (let’s call it JavaFix.bat) with the following info:
xcopy z:\JavaFix\CLSID.reg c:\ /D
regedit -S c:\CLSID.reg
I then placed both of those files in a shared directory that my client computer had already mapped(the z: drive in this case).
*Note – I also could have created a batch file to map the drive.
Now all I had to do was edit the DEPENDENCY section of the OSD file for Java 1.5 to look like this:
<SCRIPT TIMING=”PRE” EVENT=”LAUNCH” PROTECT=”FALSE” WAIT=”TRUE”>
Another problem solved with the help of Process Monitor and some good old fashioned determination!