For application compatibility, versions of the JRE (6.0 Update 31 and earlier) would register version specific Class IDs for versions of the JRE that were not installed and pointed them to the current version of the JRE. These are registered in the user’s registry under the HKCU\Software\Classes\CLSID key. Every time the user launches IE, the JRE would validate these keys exist and are set appropriately.

Newer versions of JRE 6.0 and 7.0 no longer register the previous JRE class IDs when launching IE. It only does this during the install process. This causes an issue for other user accounts on the PC. Corporate PCs typically have software installed with a different account than the one the user logs on with. Web applications that were developed for an earlier version of Java no longer function when this occurs. Its not a compatibility issue with the JRE itself, it just that IE cannot find the object being called in the HTML. This makes the guidance in the following support docs unusable. Unless of course, you happen to be the account that installed the JRE.

If you feel there is a defect in the JRE or its installation and you do not have a Support Contract with Oracle, you can report a bug on the following page:

http://bugs.sun.com/

However, be aware that bugs reported through the Oracle Support organization will get a higher priority than those reported outside of Support. Information about accessing Oracle Support or obtaining a Support contract can be found here:

My apologies in advance if this is not the correct forum to post this, but the comments here describe the exact issues we are experiencing with our SCCM deployments of JRE 1.6.0_37 and JRE 1.7.0_09, the latest releases as of 10/18/2012. Is Oracle any closer to resolving the issue with the CLSIDs not propogating properly to each users profile (HKEY_CURRENT_USER\Software\Classes\CLSID\)? We can, but would rather not have to, tweak the registry by adding the entries ourselves to make it work. All of the keys were propogated correctly, as reported, in versions prior to 1.6.0_32(33).

I found that this was reported here as well, and it mentions that Oracle has "isolated" the issue back in version 1.6.0_33, but it does not appear to be fixed in the latest releases. Unfortunately I can't access or find the documents they mention relating to work arounds.
https://blogs.oracle.com/stevenChan/entry/jre_1_6_0_33

I did open a support case with Oracle. Oracle did admit it was a known bug. Howerver, because I don't actually have a support agreement for Java and our other Oracle applications specifically require older versions of Java that are not impacted, the case was closed.

Thanks CJ, that's what I was looking for in hopes that a case had been opened with them. We are in the same situation...internal apps that no longer work properly and we don't have a support contract that I am aware of either. I'm on the software deployment side of the house, not the development side so getting the code changed in the apps is going to be a monumental task. Appears that submitting this as a 'bug' again will do no good since they are already aware of and admitted the issue. Hopefully Oracle will address this issue in an upcoming release.

In the meantime, I guess it's up to us to work some magic in getting the proper registry keys set.

In our testing, we found that having the "CAFE..." CLSIDs in HKLM and removing them completely from HKCU also seems to work. Problem is that an uninstall doesn't fully remove the keys from each HKCU (unless that user is the one that installs the software, which in our case all users are in least privileged mode, so they cannot install software) and since the keys from 1.6.0_37 aren't propagating to HKCU, the old ones remain and can cause an issue.

If you have an Oracle Java support agreement or an effected Oracle application, I would encourage you to open a case. Since its been an issue for a while, it seems it that its not getting a high enough priority.