This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Performance Assurance for Virtual Servers
TrueSight Capacity Optimization 11.x, 10.x BMC Performance Assurance for Virtual Servers
We are being asked to upgrade the Java version deployed on all machines in our environment. The BMC Performance Assurance (BPA), TrueSight Capacity Optimization (TSCO), and Perceiver products all ship with an embedded Java Runtime Environment (JRE). Can that embedded JRE be upgraded to the latest Java version within these products?
TrueSight Capacity Optimization (Gateway Server/Capacity Agent) 11.x, 10.x
BMC Capacity Optimization
BMC Performance Assurance
BMC Performance Perceiver
BMC Performance Assurance (BPA), BMC Performance Perceiver (Perceiver), and TrueSight Capacity Optimization (TSCO) all ship their own embedded Java Runtime Environment (JRE) install for installation, uninstall and patching of the product. So, the JRE version installed on the machine itself won't impact BPA, TSCO, or Perceiver products functionality. At the system level any JRE version can be installed or no JRE installed at all -- those products won't use the version installed and will continue to run their embedded version.
If the Java version is being upgraded in the environment what is the requirement? Is an existing embedded application java version going to be detected and replaced even for application specific JRE installations with a new JRE version? If so that would not be a tested or supported product configuration. But if all that is being done is that the JRE version at the OS level is being upgraded then that will have no impact on BPA, TSCO, or Perceiver because it is not using that installation of JRE and will continue to use its embedded JRE version (with different JRE versions being associated with different product versions).
The JRE installed by the BPA, TSCO, and Perceiver products is not visible at the system level (it isn't installed via the normal Java install process so it can't be uninstalled via the standard Add/Remove Programs on Linux). The only way it would be detected on the system is if a scan for java.exe binaries installed within the BPA, TSCO, or Perceiver installation directory was executed and checked the version of that java.exe binary at a file system level.
So, the expectation is that the replacement of any natively installed JRE package on the machine with a newer version will have no impact on BPA, TSCO, and Perceiver since that JRE isn't being used. But that doesn't mean those product will now be running under the new JRE version -- they will continue to run under the JRE version they were shipped with.
Q: I think my security team is going to detect and replace the embedded version of java shipped with 3rd party applications, not just the system level JRE installation. What impact will that have?
There really isn't a good technical way to replace an embedded JRE within a 3rd party product since it isn't a separate detectable and replaceable install. So it isn't clear how technically the security team would be planning on going in and replacing an embedded JRE from within a 3rd party product installation.
Almost no product that installs its own embedded JRE version will support having that version removed and replaced with a completely different version. In general a product must be QA tested and frequently have its code modified to work with a new version of the JRE.
The BPA console won't really be a major issue (since the JRE installed as part of BPA is only for the install/uninstall component and the BPAMaintenanceTool -- so if that part doesn't work it won't impact the product itself. For Perceiver the only version of the JRE that is known to work and is supported is the version of the JRE that is embedded by default within Perceiver. TSCO, until version 11.5.00, also only supports the embedded version of JRE that is shipped with the product.
Q: What is the purpose of the /[BPA Installation Directory]/BMCBPAInstallJVM JRE installation?
That directory is used for:
(A) The uninstall of the BPA/TSCO Agent product
(B) The BPAMaintenanceTool (BPAPatchTool)
So, if you aren't doing an uninstall and you aren't running the patch installer on the machine then it would be possible to remove that directory. The actual BPA agent functionality (collect and transfer data) doesn't rely on that BMCBPAInstallJVM directory and will function without it. The TSCO Gateway Server Manager functionality and other console functionality also does not rely on this directory and will function without it.
Technical Support has done some limited testing of the BPAMaintenanceTool.sh on Red Hat Enterprise Linux (RHEL) running an updated JRE version and it looked good. The BPA Maintenance Tool successfully loaded and it was still possible to apply the latest patch both via the GUI and via the silent install. So, it looks on the surface at least it would be possible to remove the /[BMCBPAInstallJVM] directory and replace it with a symbolic link to a central newer Java install on the machine [even in the scenario where the TSCO Agent was deployed using JRE version 7 and the java version has been upgraded to JRE version 8. This is true at least on RHEL -- although if it works there, one would expect it to work on other platforms since the code is the same.
Since the ability to patch the TSCO Gateway Server and Capacity Agent is important functionality it is recommended, if the directory must be removed, to replace it with a symbolic link that points to a valid JRE installation directory on the machine.
Q: Are there any TSCO Agent official product installation images available which include an embedded JRE version 8 rather than JRE version 7?
In general, the JRE version is updated with the most current JRE version available at the time that a new TSCO release is being packaged. But, there have been instances where for specific deployment requirements the TSCO Agent image has been refreshed with a newer version of the embedded JRE.
Request for Enhancement (RFE) QM002405247: 'Request quarterly updates be provided for embedded JRE associated with any TSCO components' is being used to track the request to remove or refresh the embedded Java Run Time (JRE) environment associated with the TSCO Agent and other TSCO components.
The TSCO Agent version 10.5.00 and 10.7.01 packages for Linux have already been rebuilt with a newer embedded JRE version and the packages available on the BMC EPD site have been replaced.
Here is the md5sum of the new TSCO Agent packages for Linux (updated April 2018):
New Image : af74fbee0d6138629e3e385e420bcb64 *TSCO_Agent_ver10.5.00_Linux_x86_x86-64.tar
New Image : 324eef5d583642707471a99b8e3f0e67 *TSCO_Agent_ver10.7.01_Linux_x86_x86-64.tar
Those installation images will deploy the Oracle JRE version 1.8.0_162 in the /[TSCO Agent Installation Directory]/BMCBPAInstallJVM directory rather than the older version.
Updated 9/11/2019 - TSCO 11.3.01 linux agent install has been updated and uploaded to:
The MD5 checksum for the file is:
MD5 hash of TSCO_Agent_ver11.3.01_Linux_x86_x86-64.tar:
Java version - Adopt OpenJDK latest patch
Java used "OpenJDK11_Linux64"
Open JDK version:
Openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28) OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Update 9/3/2019 - New TSCO 11.3.01 Windows agent:
MD5 hash of file TSCO_Agent_ver11.3.01_MSWindows.zip:
2b b2 f8 9b 5b 86 9b f7 d4 1d 3c 4f 53 18 3f 52
Contact Technical Support for additional information regarding which TSCO Agent versions and platforms are available and which JRE version they contain. Technical Support can request other packages (such as the Windows packages) to be rebuilt with the newest JRE version.
Q: Can the TSCO Agent/Gateway Server embedded BMCBPAInstallJVM directory just be removed?Yes, the /[TSCO Agent Installation Directory]/BMCBPAInstallJVM directory can be deleted from both the TSCO Agent and Gateway Server installation with no impact on normal product operation. The JRE is necessary when installing the latest TSCO Agent/Gateway Server Cumulative Hot Fix (CHF) so if it has been removed (and hasn't been replaced with a symbolic link pointing to another valid JRE version on the machine) it would be necessary to then include a JRE as part of the TSCO Agent/Gateway Server CHF deployment package. This should be a straight forward process if the deployment is being done via an automated process, such as a BMC Server Automation (Bladelogic) patch deployment. By setting the JAVA_HOME environment variable to the path of the desired JRE version before running the patch installer it will be able to find the custom JRE version on the machine rather than using the 'BMCBPAInstallJVM' JRE.
Q: How does this related to TSCO version 11.5.xx?The TSCO Agent version 11.5 package includes a new script based installer which does not include the 'BMCBPAInstallJVM' directory as it isn't required for the install, uninstall, or patch deployment for the TSCO 11.5 Agent.
The TSCO Gateway Server (both Windows and Linux) continue to use the java installer and thus continue to include the 'BMCBPAInstallJVM' directory (and that directory continues to be used by the patch installer on the TSCO Gateway Server in version 11.5.
- BMC Capacity Optimization
- BMC TrueSight Capacity Optimization
- BMC Performance Perceiver for Servers
- BMC Performance Assurance for Servers