A great blog by the SoftGrid Team, incase you have not seen it here it is. Thanks Mike Ory
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 126.96.36.199).
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[-HKEY_CURRENT_USER\Software\Classes\CLSID]I created a batch file (let’s call it JavaFix.bat) with the following info:xcopy z:\JavaFix\CLSID.reg c:\ /Dregedit -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:
<DEPENDENCY><SCRIPT TIMING="PRE" EVENT="LAUNCH" PROTECT="FALSE" WAIT="TRUE"><HREF>"Z:\JavaFix\JavaFix.bat"</HREF></SCRIPT><CLIENTVERSION VERSION="188.8.131.52"/></DEPENDENCY>
Another problem solved with the help of Process Monitor and some good old fashioned determination!
Thank You for this very informative article. It sounds like it might be realted to a similar problem I am having streaming JRE 1.4.2_13 to some clients.
Users execute the virtual app that calls IE locally, loads a JRE virtually and calls a https 443 URL.
When some of the clients call the virtual app they get "Page cannot be displayed"..I login to help remotly using enterprise VNC (the VNC client listens on port 5900) and the virtual app works.
I close my remote VNC session to them and the page cannot be displayed.
I can load the JRE locally on the client and all functions fine.
Because the virtual app runs when VNC is active I have entertained the idea that SoftGrid uses a loopback that VNC Enterprise and SoftGrid might have in common??
I made sure that an exception was in the Windows firewall for TCP ports 80, 139, 443, 445, 554 and UDP port 137, 138.
Iv re-sequenced and still end up with the same problem???
The issue has dumfounded me and quite a few other technicians. Weve tried to isolate it to a user profile, network issue........
Any ideas on how to procede?
This is a much(!!) better solution, and does not involve editing things on the local machine:
Thank you for your post, it helps a lot.
I have got the same problem with java 1.6.0_10 installed locally and java 1.4.2_13 I want to stream.
I have to stream java 1.4.2_13 for a web app.
In my OSD file, I included these lines :
<SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="FALSE" WAIT="TRUE" TIMEOUT="">
<SCRIPTBODY>reg delete "HKCU\Software\Classes\CLSID" /f</SCRIPTBODY>
But it doesn't work, I have got a red cross.
My client APPV is 184.108.40.2065.
Have you got any ideas ?
I am trying to virtualize the version 1.4.2_06 with the locally installed JRE version of 1.6_20.
The OS i am using is Windows 7 64 Bit .
The problem i am facing is that jre 1.4 launches well in the user (testing it on the site "www.java.com/.../testvm.xml").
While this test is not succesful in the admin account.
Please suggest how to troubleshoot this problem
I did the successful sequence of JRE 1.4 with locally installed JRE 1.6.
I used the following approach :
1) take clean sequencing machine(NO JRE(ANY VERSION) INSTALLED)
2) install JRE 1.6 locally on sequencing machine
3) launch "App-V Sequencer"
4) Click "Begin Monitoring"
5) during monitoring open "appwiz.cpl" and uninstall JRE 1.6
6) run the command from cmd "shutdown -r -t 0" to complete uninstallation of JRE 1.6
7) App-V sequencer captures the restart. Just stop monitoring and start monitoring (to complete restart process)
8) Now install the JRE 1.4 (during monitoring)
9) After completion of intallation create shorcut pointing to "iexplorer.exe"
10) Stop monitoring and save the captured sequence.
Test the sequence package with www.javatester.org/version.html
Packge works fine in both user and admin without any conflict with local JRE installed.......