Here's an intellectual exercise for my followers.
Suppose you've constructed a brand new Oracle EPM / Hyperion 11.2.x system (220.127.116.11 through 18.104.22.168 as of this writing). Now also suppose you have a need to automate Essbase MaxL scripts... let's say for example an Essbase nightly level-0 backup, or an FDMEE nightly data load automation.
You run the Essbase Client installer, and MaxL works just fine.
Except the Essbase Client is 22.214.171.124 technology and you've just corrupted one small element of your 11.2.x system.
Trying launching the configTool graphical client. The javaw.exe process crashes immediately and you never see the Oracle EPM Config logo pop up.
What to do?
Oracle does have a fix for this documented within their Knowledge Base. You just need to know where to look.
Or, search for files dated in the year 2014 A.D. Open the Windows Explorer and put in a date range of 1/1/2014 through 12/31/2014 as you see in my screenshot below.
Don't bother with the html files. What you care about are the EXE and JAR file extensions. The act of running EssbaseClient.exe causes the 2020-2021 versions of these files to be blown away by the 2014 versions.
The fix: stop everything. Replace the 2014 files from a server where you did NOT run EssbaseClient.exe to install Essbase MaxL. Then launch configTool and confirm it works again. Customers who have security policies mandating database & WebLogic password changes every 90 days will need a working configTool utility.
Try this out in a DEV environment. I like Ahi Tuna sashimi with a bit of soy sauce and wasabi, and thus you can thank me with that. ;)