Monday, February 3, 2020

January 2020 Oracle Critical Patch Update affects EPM 11.2

So you've spun up your shiny new Hyperion / Oracle EPM  And now... it is time to patch!

I haven't come across a comprehensive patching guide for EPM 11.2 yet, so here's my attempt to create one.  This guide assumes you've patched EPM 11.1.x.x in the past and are familiar with Oracle's "OPatch" utility.

As usual, assume you will take an outage and shut down the EPM stack across all servers before patching (ONE environment at a time, please!!  "Gee Dave, what could possibly go wrong?")

Oracle's quarterly "Critical Patch Update" (CPU for short) was published in mid-January 2020 right on schedule.  As expected, there are impacts to EPM 11.2, even though EPM isn't mentioned by name.

For your reference, there's a link to Oracle's JAN2020CPU (as they call it) announcement:
Oracle JAN2020CPU Security Alert

In a nutshell, here's what is believed to apply to EPM

Java SE 8

EPM ships with Java SE 1.8 Update 181.  This is "old" as it apparently was published in the APR2019CPU, and Java has been updated every Quarter since then.  The version we should use as of January 2020 is Java SE 1.8 Update 241.

The patch # for Java SE 8 is 18143322 and you should hop into and bookmark that patch.  Oracle will re-use this patch # every time a new Java 8 patch is issued.  Make your patch search screen look like this so you can find it quickly:

This is not a "patch"; it is a full install.  You can install it on just one server's C: drive, deselect the "public JRE" option within the install wizard, and accept the other default prompts.  When finished, copy it to your D/E/F drive as appropriate to your various Hyperion servers and save it as \Oracle\Middleware\jdk8

Once you've finished this task, you can uninstall it via the Windows Control Panel from the C: drive on the one server you installed it to.

You will then face a decision that is worthy of a separate blog post:  Do you replace the content of \Oracle\Middleware\jdk1.8.0_181 or do you update the Windows Registry and various bat/cmd files to replace all references of jdk1.8.0_181 to jdk8?  Replacing the content of the jdk1.8.0_181 folder is the fastest and easiest solution by far... until somebody in IT notices and asks why a vulnerable version of Java is installed.

Before you decide right away, remember Java 8 will likely be updated by Oracle every 3 months.

Oracle WebLogic / Fusion Middleware

(For my friends on the functional non-infrastructure side, here's why you care):  Hyperion does not function without WebLogic / FMW running behind the scenes.  When you start up web services like EPM Foundation, Planning Web, HFM Web, EAS Server, etc., you are starting an "Oracle WebLogic Managed Server".  When WEbLogic / FMW has a security vulnerability, then you should consider your EPM system to be equally vulnerable.

The patch # for this is 30675853 and it is "WebLogic PSU 191217.1425".  This is a cumulative patch.

The very good news is we no longer need to use the BEA Smart Update (bsu.bat) utility!  In fact, that entire directory structure doesn't exist anymore.  We now use good ol' Oracle OPatch.

The "-oh" parameter you pass to \Oracle\Middleware\OPatch\opatch.bat is \Oracle\Middleware

In addition to updating Oracle WebLogic, it also updates some files within the \Oracle\Middleware\oracle_common directory hierarchy (Oracle ADF / JDeveloper and the like).

Oracle HTTP Server

(For my friends on the functional non-infrastructure side, here's why you care): OHS is the front-end proxy for EPM Workspace.  This is what listens to port 19000 / 19443.  As stated in the WebLogic section above, if OHS can be exploited then so too can your EPM system.

The patch # for this is 30687404 and it is "Oracle HTTP Server PSU 191219.2319" .  This is also a cumulative patch and you also use OPatch to apply it.
(Update: Credit to "RJ" in the comments below who pointed out I had pasted an incorrect patch ID #.  30687404 is the correct patch ID # to use as of this writing)

The "-oh" parameter you pass to \Oracle\Middleware\ohs\OPatch\opatch.bat is \Oracle\Middleware\ohs

Oracle EPM / Hyperion

No references to EPM 11.2 in JAN2020CPU as mentioned earlier.

Essbase Suite

No references to Oracle Essbase/APS/EAS in JAN2020CPU.  There is a separate Oracle Inventory on your EPM 11.2 server(s) for Essbase Suite, if installed, so you can still patch it if you want some of the newer Essbase-related bugfixes.

Here's what you have out of the box in EPM where Essbase Suite is concerned:

29260139 Essbase Studio Server
29260160 Essbase Admin Server 
29749671 Analytic Provider Services
29749652 Essbase RTC
29749662 Essbase Server

Oracle Data Integrator

ODI is referenced within JAN2020CPU, but I'd avoid it for now until more information is forthcoming.  If you want to take a look, the patch # is 29778645 for "ODI BUNDLE PATCH (CPU)".  This patch updates the ODI Studio thick client, which expects some minor tweaks to ODI's Master repository.

You can apply this patch if your ODI is standalone and is NOT the one bundled with FDMEE  This is because the patch wants you to run the Oracle Upgrade Assistant utility, which expects that the ODI Master and Work repositories were built through the Repository Creation Utility ("RCU") rather than by the EPM System Configuration tool when you ran the "Configure Database" step for FDMEE.

We will likely need to wait for an FDMEE patch, which I'd expect to include a new *.drv file that instructs FDMEE to update the ODI repository when FDMEE is restarted.

Clear As Mud???

One question I'm asked by customer IT departments from time to time:  "Do we really need to do this?"

Here's one way to answer IT's question.  Forward Oracle's JAN2020CPU advisory article, linked at the top of this blog entry.  Here's just one specific example from the article:

I highlighted in red some, but not all, of the important nuggets of information:
  • CVE#. IT can paste into their favorite Internet search engine to learn more.
  • Product.  Oracle WebLogic Server is the technology behind pretty much all of Hyperion's web services in 11.2, except for DRM.
  • Remote Exploit without Auth.  A "yes" means an attacker doesn't need a userID/password for the server or application in order to cause mischief.
  • Base Score.  This is on a scale of 1 to 10, with 10 being the most serious.
  • Supported Versions Affected.  I highlighted 10.3.6 for our friends who are still on EPM or -- those use WebLogic 10.3.6.  EPM uses WebLogic
Give this example to your IT counterpart, along with the link to Oracle's advisory article, and ask if IT is willing to live with the scores listed throughout the article.  (Again, the above is just 1 example, but there are many ranging from the low 4s to the high 8s and 9s).

Be mindful the JAN2020CPU advisory mentions everything Oracle; Oracle Database, MySQL, Java, Hyperion, Oracle Financials, etc.  This makes reading through the entire advisory a daunting task.  I advise doing so only after ingesting my caffeine than it took you to get all the way to this paragraph!

You can mitigate any panic by explaining the on-premises Oracle EPM system typically sits behind a corporate firewall and is not exposed to the public Internet. By applying these various patches, you are mitigating risk of a disgruntled employee wanting to cause mischief or steal data before their last day.


  1. Replies
    1. Great! :) It took about a pot and a half of coffee to write all this up and proof-read.

  2. We are on with Weblogic on 10.3.6 . Will this patch upgrade the weblogic version to PSU 191217.1425 ?

    1. For Weblogic 10.3.6 - the latest is JWEB patch which I recommend you DO NOT apply as this broke HSS. Might fire this one with an Oracle SR.

    2. Hi Manish, no you cannot apply the WebLogic PSU on top of WebLogic 10.3.6. The WebLogic PSU will use OPatch to replace files in WebLogic only, and won't upgrade WebLogic from 10.3.6. OPatch will reject this PSU as "non applicable" for your system.

      I don't recommend trying to intermingle WebLogic 12.x.x.x with EPM Oracle would only certify it as supported if they invest the time to test this particular configuration. Such testing wouldn't be trivial. I don't speak for Oracle, but I can't imagine this would happen before Extended Support expires for at the end of 2021.

      WebLogic 10.3.6 has its own JAN2020CPU patch, but it was issued late (Jan 31 instead of the same time as most of the other patches). Don't jump straight to PROD with that patch. Instead give yourself time to regression test it in DEV/TEST.

    3. If you apply patch 18561746 to the oracle common files, the WLS CPU for WLS 10.3.6 (JWEB) will work. It will also allow the Oct WLS CPU to work, as well.

  3. Hi Dave, can you check the patch number for Oracle HTTP Server you listed in your post? It's not 25115951. I think it should be 30687404?

  4. Hi RJ, you are correct and I had transposed the patch # wrong when I carried it over from my patch matrix spreadsheet. 30687404 is indeed the correct OHS patch to use. The one I had originally listed was from my patch spreadsheet that includes the pre-installed patched. I've corrected this blog entry accordingly. Thanks for the catch!!

  5. After applying the WL patch (30675853), I can no longer use LCM to export reports from Financial Reporting (EPMLCM-17000 error); curious to hear what your experience is?


Thank you very much for your interest in this blog! I hope you're finding it helpful.

Please keep comments relevant to the topic in the post, as this blog is not a free-for-all substitute for Oracle Support or traditional consulting. If you have many questions unrelated to the specific topic at hand, consider contacting me on LinkedIn ( so we may discuss the possibility of consulting.

Commenting on posts older than 90 days unfortunately goes into moderation, thanks to spammers who've been hitting this blog. Please have patience, and thanks for your understanding!

Comments including URLs linking back to gambling or other things unrelated to Oracle EPM will be deleted on sight. If you're an EPM consultant and are offering me constructive criticism or a tip, go ahead and DO link back to your blog or firm's website if you so desire.

Thanks again for reading!