Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Posts Tagged ‘Java’

Failed Java Uninstalls

Posted by William Diaz on October 23, 2013


After moving to Java 7 several months ago, this issue started plaguing us. During normal troubleshooting of Java applet-website issues techs would try to uninstall our custom Java 7 package, only to encounter: “There was a problem starting C:\Program Files (x86)\Java\jre7\bin\\installer.dll. The specified module could not be found.”

image

Up until recently, the fix was to run the Microsoft FixIt Utility to Fix problems with Programs that can’t be installed or uninstalled. Afterwards, we would then need to remove the stubborn registry entries that left the Program and Features application list populated with the now removed application by running the uninstall again. With the recent expiration of Java 7 update 25 and confusion from tier 1 support, there were several updates being done to the new JRE. In order to maintain a consistent software environment, I asked to have those updated JREs put back to 7.25. This also required uninstalling 7.25 on so many workstations that my head was left spinning because the process had to be done manually and I was the “go-to” person for the Java crisis. More importantly, at some point we would need to eventually update to a new JRE and likely want to remove the old one but not have a way to automatically uninstall the previous client with the uninstall broken.

After some web research, I found that the issue was with one of the custom actions in the Java msi, UninstallJRE:

SNAGHTML1ec65f21

This should be changed to:

image

Thanks to Keith Jones. Found this gem here: http://lists.wpkg.org/pipermail/wpkg-users/2013-May/009394.html.

Advertisements

Posted in Uncategorized | Tagged: | 3 Comments »

Um, So We’ll Have to Lower Java Security Again?

Posted by William Diaz on October 21, 2013


So, last week with the expiration of Java 7 Update 25, Java LiveConnect stopped working on several web sites that our users frequent, forcing them to change the default Java security setting from High to Medium. For arguments sake you could update to Java 7 Update 45 and go back to using the High security setting. But then I saw some additional text on one of the common Java 7 security dialogs: “This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute…”

image

Assuming the applet is not updated by the next JRE expiration, user’s would then have to lower Java security again.

image

Posted in Uncategorized | Tagged: | Leave a Comment »

Java Headaches After Update Release

Posted by William Diaz on October 17, 2013


So Java just released JRE 7 Update 45. This is apparent when someone goes to run a Java applet and encounters the following prompt:”Your Java version is out of date…”

image

For the average home user, this is not a big deal. But in a corporate environment headaches ensue. Why? Because some users will blindly click on the Update button and be redirected to the Java download page for the latest release. The first problem is that our users are not going to have the administrative privileges to update their Java client. But the real problem is that once a user has done this, they will be redirected to the Java download page each and every time they need to run a Java applet. So the question was, how do we get the prompt back so the user can select the appropriate Later option and Do not ask again until the next update is available?

For starters, the property that controls this setting is located in a file called deployment.properties in %userprofile\AppData\LocalLow\Sun\Java\Deployment named deployment.expiration.decision.10.25.2=update:

Posted in Troubleshooting | Tagged: | Leave a Comment »

Java 7 Troubleshooting (disabled support for MD2)

Posted by William Diaz on September 4, 2013


Upon trying to connect to a vendors website application, a user was seeing an error pointing to a failed certificate validation:

image

With java logging enabled, the details were more specific:

com.citrix.sdk.jsse.CitrixSSLException: The certificate validation failed. 
    at com.citrix.sdk.jsse.SocketFactory.createSslSocket(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.citrix.client.io.net.ip.proxy.o.a(Unknown Source)
    at com.citrix.client.io.net.ip.z.a(Unknown Source)
    at com.citrix.client.io.net.ip.z.a(Unknown Source)
    at com.citrix.client.module.td.tcp.TCPTransportDriver.s(Unknown Source)
    at com.citrix.client.module.td.TransportDriver.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)

Looking at the certificate, I could see it was using the relatively old MD2 algorithm. While the user did not experience this issue previously, its worth noting we had just moved to Java 7 from 6. Likely JRE 7 has disabled support for MD2 because it is considered unsecure. Some quick research revealed this was the case. With the site outside of our control, a need existed for the user to be able to access the application. Instead of downgrading to Java 6, enabling MD2 support in Java 7 is a simple matter of editing the java.security file in C:\Program Files (x86)\Java\jre7\lib\security to comment out jdk.certpath.disabledAlgorithms=MD2 or simply remove the MD2 part:

SNAGHTML67b4bc0

Posted in Uncategorized | Tagged: | Leave a Comment »

Java 7 Domain Account Locks

Posted by William Diaz on August 16, 2013


We recently moved from Java 6 to Java 7, specifically JRE 7 Update 25. Immediately, we began get reports of user accounts getting locked after the affected users visited web sites hosting Java applets. For the most parts, the applets would run until the 5th attempt to load-refresh the applet and then the domain account would get locked. The initial look with Network Monitor showed that authenticated users were failing at the proxy level:

SNAGHTML151ef729

The spot-workaround was to create bypass rules for the individual sites to allow all users to pass without authentication, which was by no means a elegant since it was a reactionary approach  that waited for user’s to get locked across various offices and then report the problem to tier 1 and then escalate.

When the support issues began to settle down, I began to look more deeply into the problem. We took a non-production proxy and removed all the rules that were created over the previous days so that any Java applet would begin failing authentication (I used the Java Verify page as my test). I have to admit, network traffic and protocols are not my Zen, but as I began to look at various captures and figure may way around netmon, I saw the same theme each time, Kerberos authentication failing:

Read the rest of this entry »

Posted in Troubleshooting | Tagged: , | 1 Comment »