Nextgen plugin fails on Windows Server 2003 with multiple Administrator Users

The customer says this bug only appears on Windows Server 2003. It does not appear on Windows XP. However since are large customers are using Windows Server 2003, this is an important issue.

Scenario:

- Have an applet which is referenced using the OBJECT tag and using a family classid (clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA).

- Have a Windows Server 2003 client system with only Java 5.0 update 17 installed

- Have 2 users (both with administrator privileges) defined on the Windows Server 2003 system.

- For both users, the applet is started correctly when opening the html page.

- One of the 2 users installs Java 6.0 update 12.

- The administrator who performed the Java 6.0 installation can open the html page and the applet is started correctly.

- Login with the other administrator. When accessing the html page, the Java Plug-in is not started (red cross is shown).

- Disable the next generation Plug-in in the control panel. Now, the applet can be started correctly.

- Enable the next generation plug-in in the control panel (so revert to the original settings). Strangely, now the applet is started succesfully. This workaround however cannot be applied to our customers as users often cannot change the settings in the control panel.

This bug can be reproduced always. Note also that when using a specific java update version in the classid, the problem doesn't occur.

This issue no longer fails once the "enable third party extensions" option is turned on under Internet Explorer. The change we made is to the Internet Explorer options. From the IE Tools menu, select Internet Options and then the Advanced tab. Under the Browsing section, make sure "Enable third party browser extensions (requires restart)" is turned on. You need to restart IE to make the change effective.

Customer reported this is not viable solution for him for the following reasons:

1. When only Java 5.0 is installed, the applet starts up correctly (with the family classid for Java 5.0) even if "Enable third party browser extensions" is turned off. After installing Java 6.0, the applet doesn't start anymore. Why does the installation of Java 6.0 require the new setting? As it works with Java 5.0, the installation of Java 6.0 breaks a working environment.

2. The user who has installed Java 6.0 can perfectly run the Java applet (with the family classid for Java 5.0) even if the "Enable third party browser extensions" is turned off. During the whole scenario, this setting was not turned on for this user. Why is the setting required for one user and not for the other?

3. As mentioned in the original description of the problem, the applet starts correctly after having disabled the next generation plug-in and re-enabling it. This proves that the Internet Explorer setting "Enable third party browser extensions" is not required after all.

4. After having turned on "Enable third party browser extensions" as you suggested, the applet starts-up correctly. Then, after turning off "Enable third party browser extensions", the applet still starts up correctly. This confirms again that the applet can start without this Internet Explorer setting. It looks as if some initial configuration needs to be completed first.

Considering all the above, is it possible to have a fix in Java 6.0 which allows the usage of family classids for all Windows user without the need for a manual configuration change, just as it used to be in Java 5.0?

Having to change the configuration is not a valid workaround as it needs to be done for all Windows Users. Windows 2003 is often used as a terminal Server, where the users do not have access to these configuration settings, and often they cannot be changed because of security restrictions.