JDK-6929996 : Request for method to disable the next gen plugin for end user managed account on Windows
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u18,6u20
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows,windows_vista
  • CPU: generic
  • Submitted: 2010-02-25
  • Updated: 2011-12-03
  • Resolved: 2011-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u30 b08Fixed 7-poolResolved
Related Reports
Relates :  
JDK-6953625 - SSV Helper Add-on doesn't get registered on IE
Description
Customer would like to disable the next gen plug-in remotely for thousands of PCs and they say that this works when they do this via the Java Control Panel but fails when they try to do this through modification of a registry key.  The problem is seen both with Windows XP as well as Windows Vista.  It appears the customer has a legacy application which they need to also run on these systems using 5.0u22 and the application does not function properly when the next gen plug-in is enabled.  

They specify to load their legacy application using family clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA.

The customer has managed desktops, with user that have restricted policies that would
prevent them access to the Java Control Panel so customer must implement the setting change for them remotely during, nightly maintenance window. 

Since the next gen plugin can be disabled in the Java Control Panel, there should also be a supported way to disable it via installation, registry or other method for multiple managed user desktop accounts.

Please see comments section and attachments for the test results from the customer.
Comments
SUGGESTED FIX Test case: step 1: install any jre5 (for example 5u22) step 2: install jre6 containing a fix. step 3: as an administrator switch to an old Java plug-in running from a command line: ssvagent.exe -high -jpisetup -old or just simply uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel. step 4: log out from an admin account and log in as a regular (non admion) user step5: run (as a regular user) Java any applet using clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA as mentioned in "Description section" above Step 6: Verify if JavaConsole reports 5u22 for both JavaPlugin and JRE like below: Java Plug-in 1.5.0_22 Using JRE version 1.5.0_22 Java HotSpot(TM) Client VM before fix new Java plug-in of jre6 was still active so Java Console output was: Java Plug-in 1.6.0_18 Using JRE version 1.5.0_22-b03 Java HotSpot(TM) Client VM See attached customer files: app with plugin2 turned off (via reg change) Error.rtf app with plugin2 turned off(manually via JCP) success.rtf app with plugin2engaged (default) Error.rtf
12-01-2011
SUGGESTED FIX Incorrect registration of Browser Helper Objects called SSVHelper with IE (CR #6953625) has been fixed: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3896 SSVHelper object is responsible for a propagation of Java Plug-in settings from admin account to all regular (non admin) user accounts. If SSVHelper is registered with IE then the only thing admin needs to do in order to switch from a new Java Plug-in to an old Java Plug-in is to run from a command line: ssvagent.exe -high -jpisetup -old or uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel. In both cases changes will be propagated to non admin user accounts.
07-01-2011
WORK AROUND Attached is SSVHelper.cmd which customer needs to run from a command line after an installation process of JRE6 is completed. This script registers Browser Helper Objects called SSVHelper with IE. This object is responsible for a propagation of Java Plug-in settings from admin account to all regular (non admin) user accounts. In other words if SSVHelper is registered with IE then the only thing admin needs to do in order to switch from a new Java Plug-in to an old Java Plug-in is to run from a command line: ssvagent.exe -high -jpisetup -old or uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel. In both cases changes will be propagated to non admin user accounts. NOTE: SSVHelper.cmd needs to be executed only once after JRE6 installation is completed. All subsequent switching between new/old Java Plug-in do not require SSVHelper.cmd to be executed any more. To manually register SSVHelper object run SSVHelper.cmd when jre installation is completed. usage: SSVHelper.cmd [JRE_HOME_DIRECTORY] JRE_HOME_DIRECTORY is optional. If not specified then a default location of jre6 is assumed which is "C:\Program Files\Java\jre6" Example 1 (JRE installed in a default location): jre-6u22-windows-i586.exe SSVHelper.cmd Example 2 (JRE installed in a custom location): jre-6u22-windows-i586.exe /s INSTALLDIR=C:\myJava\jre SSVHelper.cmd C:\myJava\jre
08-12-2010
SUGGESTED FIX .
08-12-2010
EVALUATION See Suggested Fix section.
18-05-2010
SUGGESTED FIX ssvagent.exe -high -jpisetup -new does the registry change: [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.6.0_18] "UseNewJavaPlugin"=dword:00000000 which affects all users (accounts) registered on a machine. The rest of necessary registry changes ssvagent.exe does for a current user only. When a new user logs in the necessary registry modification get propagated to that user on IE startup by ssv.dll. The problem was that since jre6u12 IE doesn't load ssv.dll on a startup (see CR #6953625). So that's why ssvagent.exe didn't work correctly for a customer in a multiuser environment. As a workaround we gave the customer a set of registry to manually propagate to all users: [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.6.0_18] "UseNewJavaPlugin"=dword:00000000 [HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA}\InprocServer32] @="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll" "ThreadingModel"="Apartment" [HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBA}\InprocServer32] @="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll" "ThreadingModel"="Apartment" [HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBB}\InprocServer32] @="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll" "ThreadingModel"="Apartment" [HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBC}\InprocServer32] @="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll" "ThreadingModel"="Apartment" Note: Assume JRE 6 update release is installed in a regular location C:\\Program Files\\Java\\jre6 Above registry changes will make a Java applet which is requesting jre 5u22 to use also Java Plugin 5u22 (which is an old plugin). When CR #6953625 get fixed then ssvagent.exe -high -jpisetup -old will work correctly even in a multiuser environment without a need for manual registry modification as described above.
18-05-2010
SUGGESTED FIX There is a way to switch between old/new Java plugin from a command line. I tested it on jre 6u19 on windowsXP so far: Log in as an admin user. goto <jre_installation_directory>\bin In order to switch from new to old plugin: run ssvagent.exe -high -jpisetup -old In order to switch from old to new plugin: run ssvagent.exe -high -jpisetup -new
28-04-2010