Known issues and limitations

Security bulletins that were released before 2018 are not evaluated

Multiple instances cannot be in one namespace

Multiple instances of WebSphere Automation cannot be deployed in the same namespace. Multiple instances can be deployed in separate namespaces in the cluster.

Node agent CVEs are not in the CVE report

WebSphere Automation uses the usage metering feature within WebSphere Application Server to collect data about your servers so that their vulnerability status can be assessed. Usage metering does not run in node agents. For more information about usage metering, see the Overview page.

Unresolved security vulnerabilities and exposures might affect your node agents. Manually evaluate new security bulletins to see whether they apply to your node agents.

API shows version 9.0.5 for WebSphere Application Server traditional versions 9.0.5.0 to 9.0.5.3

After a WebSphere Application Server traditional server is registered with the usage metering service, you can view the server asset in the Swagger UI. For versions 9.0.5.0 through 9.0.5.3, the API has 9.0.5 for the version value. The version fix pack number (0, 1, 2, or 3) is missing.

"version": "9.0.5",

For versions after 9.0.5.3, the version value correctly shows the version fix pack number. For example, version 9.0.5.6 has the full version number with 6 for the fix pack number.

"version": "9.0.5.6",

WebSphere Application Server traditional uses the IBM Version, Release, Modification, Fix Pack (V.R.M.F) format for numbering versions.

WebSphere Application Server base servers might be incorrectly indicated as vulnerable

WebSphere Automation might incorrectly indicate that WebSphere Application Server base servers are vulnerable. Security bulletins that apply only to WebSphere Application Server ND servers are incorrectly determined to apply to WebSphere Application Server base servers. In these instances, the attempt to apply the interim fix (iFix) from the security bulletin to a base server fails. WebSphere Automation continues to show the security vulnerability as unresolved for that server.

It is possible to manually resolve the security vulnerability by using the REST API. The REST APIs are a technology preview in this release and are therefore unsupported. For more information, see Viewing the REST API.

WebSphere Application Server for z/OS specific vulnerabilities

Vulnerabilities that are exclusive to WebSphere Application Server for z/OS and IBM Java™ Development Kit for z/OS are not included in the set of vulnerabilities that are known to, or tracked by, WebSphere Automation. Vulnerabilities that are reported on the ibm.com/support pages which impact multiple editions, including WebSphere Application Server for z/OS, are tracked. Those vulnerabilities that are reported only through the IBM Z Security Portal are not included and users of that portal must continue to use it for those issues reported only through the portal.

Registered Windows 2022 servers appear as an older Windows version

When you register a Windows 2022 server with WebSphere Application Server 9.0.5.x, the getAssets JSON file returns an older Windows server version for the operatingSystem parameter. This error does not negatively impact WebSphere Automation operation. The issue is resolved in Java 8.0.7.5 (SR7 FP5), but the default Java version for WebSphere Application Server 9.0.5.x is 8.0.7.0.

The following example getAssets JSON file shows the operatingSystem: Windows Server version 2009 error:

{
  "id": "c7eea541-b685-3d9a-88d3-ea62f01e601f",
  "name": "server1@hostname.example.com",
  "type": "traditional",
  "edition": "nd",
  "productName": "WebSphere Application Server Network Deployment",
  "version": "9.0.5.10",
  "apars": [
    "PH37034",
    "PH42728",
    "PH42762"
  ],
  "hostName": "hostname.example.com",
  "cellName": "NonAdminCell01",
  "nodeName": "DefaultNode01",
  "serverName": "server1",
  "installDirectory": "/C:/wsauser/IBM/WAS",
  "profileDirectory": "/C:/wsauser/IBM/WAS/profiles/AppSrv01",
  "operatingSystem": "Windows Server version 2009",
  "operatingSystemVersion": "10.0",
  "jdkId": "3003f49f-d42a-3f7d-9bd1-a7edb1ac96a7",

Fixes cannot be installed for certain operating systems

WebSphere Automation cannot install fixes on WebSphere Application Server or WebSphere Application Server Liberty that are installed on z/OS or iSeries platforms.

Fixes cannot be installed on certain installations

It is not possible to install fixes on the following types of application server instances:

• Instances of WebSphere Application Server Liberty that are installed from archive. Fixes can only be applied to Liberty instances that are installed by using Installation Manager.
• Instances of WebSphere Application Server or WebSphere Application Server Liberty that are configured to use swinging profiles.

Fix management records might fail because status did not change during timeout periods

When an active fix management record (also know as an installation record) on a host exists, you cannot create another fix management record until the first one is completed or failed. If fix management records stay in the same status for a long time, a timeout monitor updates their status to failed.

The timeout monitor runs once an hour in each pod. The preset timeout periods are as follows.

If you have a fix management record that stays in the same status for a long time, create a new one after the timeout period ends.

Support for registering deployment managers requires WebSphere Application Server 9.0.5.14

If you are registering a WebSphere Application Server deployment manager, it must be version 9.0.5.14 or later. This requirement ensures that the usage metering feature properly reports the server type to WebSphere Automation. Support for WebSphere Application Server 8.5.5 is planned for a future release.

To enable registration for a deployment manager that you cannot upgrade to WebSphere Application Server 9.0.5.14, or for a WebSphere Application Server 8.5.5 deployment manager, contact IBM Support.

No iFix option for fixing vulnerabilities in a Java SDK runtime

In the Prepare fix dialog, no interim fixes (iFixes) are shown as options to fix vulnerabilities in a Java SDK runtime. You must select Fix Pack as the Fix type on the Choose global options page, and then choose a fix pack to install on the Choose fixes page.