ERP systems and other enterprise applications sometimes break when the software was written to work with a specific release of Java that is not the one user desktops are configured to use by default.
What are you supposed to do when that happens? Make users revert to a version of Java that may be obsolete or include known security vulnerabilities. Or upgrade to a new version of the application, solely to resolve that issue?
Fortunately, there is a better way. You can configure user desktops to run specific versions of Java for specific, trusted applications. For everything else, you can run the latest version of Java, or a specific version specified by corporate IT. You can also block client side execution of Java entirely for any application not specifically whitelisted.
If you're experiencing this issue, watch this short video (one of our Tech Talk series) for a closer look at how we can help you resolve the problem.
In fact, several of our clients have multiple applications that only work with certain Java versions on the client, and the same employees may need to access more than one of them. The strategy we recommend in most cases is to employ Java Deployment Rule Sets. Rule Sets have been a standard part of Java since 2013. With multiple versions of Java installed on the desktop, you can specify that applications available from a given URL - such as the web address of your ERP system - follow your rules for which Java version to load. For Java applications installed on the desktop, rather than downloaded as web applets, a hash signature can be used as an alternative to a URL.
Other possible solutions include using virtual desktops configured with the required Java version. For a company that makes extensive use of Citrix or similar platforms, that might be the best solution. But the Rule Sets option has the advantage of being a relatively simple, native Java fix for the problem.
Java Deployment Rule Sets work best in combination with a systems management platform that allows IT to install and update a digitally signed Java archive (JAR) file on each managed desktop. That file, named DeploymentRuleSet.jar, must be installed in a specific location that is hard coded -C:\Windows\Sun\Java\Deployment on Windows - and you need administrative access to each client computer to create that directory and install the file.
Creating these rules is relatively simple, based on an XML format for defining application locations and Java versions. For example, we can assist you in setting up a Rule Set enabling Java for web access to an ERP system and blocking Java execution for anything else.
Sure, getting the configuration right can be a hassle, but we're here to help. Compared with ripping out an enterprise system that took millions of dollars to license and implement, implementing Java Deployment Rule Sets is a pretty simple solution.
For more information on what Rimini Street Advanced Technical Services can offer, please contact Heather Young firstname.lastname@example.org.
What You Get
Review the breadth of complimentary Advanced Technology Services available to Rimini Street support clients.
Desmond Whitt, VP, Advanced Technical Services
Mr. Whitt has almost 30 years of experience developing, supporting and deploying systems in the enterprise software industry. As leader of technology support operations at Rimini Street, he drives new innovation to both customers and internal operations to ensure the best use of technology for business needs. He also holds the patent on Rimini Street's Smart Proxy product. Before joining Rimini Street, Mr. Whitt held leadership positions at several software companies and received PeopleSoft's Outstanding Contributor Award for personally leading installations for more than 30 customers. Mr. Whitt holds a Masters of Engineering in Electrical Engineering from the University of Louisville in Kentucky.