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 220.127.116.11 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 18.104.22.168.
Java SE 8
EPM 22.214.171.124 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 support.oracle.com 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 126.96.36.199
(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 188.8.131.52 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 184.108.40.206
(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 220.127.116.11 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 18.104.22.168
No references to EPM 11.2 in JAN2020CPU as mentioned earlier.
Essbase Suite 22.214.171.124
No references to Oracle Essbase/APS/EAS 126.96.36.199 in JAN2020CPU. There is a separate Oracle Inventory on your EPM 11.2 server(s) for Essbase Suite 188.8.131.52, 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 184.108.40.206 where Essbase Suite 220.127.116.11 is concerned:
|29260139||Essbase Studio Server 18.104.22.168.031|
|29260160||Essbase Admin Server 22.214.171.124.031|
|29749671||Analytic Provider Services 126.96.36.199.033|
|29749652||Essbase RTC 188.8.131.52.033|
|29749662||Essbase Server 184.108.40.206.033|
Oracle Data Integrator 220.127.116.11
ODI 18.104.22.168 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 22.214.171.124.190708 (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 126.96.36.199. 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 188.8.131.52 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 184.108.40.206 or 220.127.116.11 -- those use WebLogic 10.3.6. EPM 18.104.22.168 uses WebLogic 22.214.171.124.
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.
Great! :) It took about a pot and a half of coffee to write all this up and proof-read.Delete
We are on 126.96.36.199 with Weblogic on 10.3.6 . Will this patch upgrade the weblogic version to 188.8.131.52 PSU 191217.1425 ?ReplyDelete
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.Delete
Hi Manish, no you cannot apply the WebLogic 184.108.40.206 PSU on top of WebLogic 10.3.6. The WebLogic 220.127.116.11 PSU will use OPatch to replace files in WebLogic 18.104.22.168 only, and won't upgrade WebLogic from 10.3.6. OPatch will reject this PSU as "non applicable" for your system.Delete
I don't recommend trying to intermingle WebLogic 12.x.x.x with EPM 22.214.171.124. 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 126.96.36.199 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.
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.Delete
Hi Dave, can you check the patch number for Oracle HTTP Server 188.8.131.52 you listed in your post? It's not 25115951. I think it should be 30687404?ReplyDelete
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 184.108.40.206 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!!ReplyDelete
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?ReplyDelete