Each quarter Oracle releases a Critical Patch Update (CPU) as a collection of patches for multiple security vulnerabilities across its products. To keep your system secure and stable, these patches should be installed as soon as practical, especially for Weblogic and Java as they are used extensively in many JD Edwards installations.
Since Weblogic runs on not only your JAS server but also potentially your AIS, BSSV, and fat clients; it’s a high-impact application and patching can affect multiple business and technical processes. The Syntax JDE Managed Services team applies Oracle CPUs to hundreds of servers each quarter and we have developed a few best practices for the Weblogic patching process.
Review the patches carefully
Know your release levels before you patch, so you ensure you are applying the correct patches. Also, be aware when patching is no longer provided for your current release and make sure you do your research before attempting a release change. MTRs are your friend!
Patch non-Production first
This seems like a no-brainer, but it’s an important step that some people bypass. Patches are designed to HELP, but sometimes they can break things or cause issues. It’s best to uncover those potential problems on your non-Production server rather than impacting your Production systems. Make sure you leave enough time between non-Production and Production application to find potential issues, and make sure your non-Production system is at least somewhat active during that period. Two weeks is a good rule of thumb.
Be prepared to rollback
A best practice for installing the patch for Weblogic is to create a backup of the Middleware folder in case you run into an issue with the install and need to restore. A quick and easy way on a Windows server is to use RoboCopy to do the backup. Here are a couple of useful commands that can be run from a command prompt:
- To make the backup:
Robocopy <from folder> <to folder> /E
Example: Robocopy x:oraclemiddleware z:Oracle_backupmiddleware /E
(the “/E” copies subdirectories and includes empty directories)
- To delete the backup:
Create a folder called “empty” on the root of a drive like z:empty and run: Robocopy z:empty <folder to delete> /mir
Example: Robocopy z:empty z:oracle_backupmiddleware /mir
(the “/MIR” switch mirrors a directory tree and is the same as using the /e /purge switches)
You can now delete both the backup folder and the empty folder.
The primary message here – planning is key. Successful patching plans have a strategy in place before the first patch is even downloaded. You can find the Oracle Critical Patch Update Advisory at https://www.oracle.com/security-alerts/ including information on how to subscribe to email notifications of CPU Advisories and Security Alerts. Or ask for a Syntax JDE Managed Services quote and let Syntax handle these quarterly updates for you!