ARL

ARL Content Change: Microsoft OneDrive classification and product consolidation

Content Library : ARL

Severity: Level 1. Tier1 Product Classification update

Impacted Publisher/Product: Microsoft OneDrive and OneDrive for Business

Expected Implementation: ARL release scheduled 6th Nov 2026

SUMMARY OF CHANGE

In the upcoming ARL update, Microsoft OneDrive releases will be classified as Commercial instead of Freeware, and OneDrive for Business 2022 will be consolidated into OneDrive 22. Microsoft uses the same OneDrive sync client and version numbers across personal and business environments, so this change will provide more consistent recognition and reporting. Refer : Microsoft OneDrive Sync Release Notes

DETAILS OF CHANGE

·      Classification update: OneDrive applications currently classified as Freeware will be changed to Commercial for all the versions present in ARL.

·      Product consolidation: OneDrive for Business 2022 will be merged into OneDrive 22. Existing recognition data for OneDrive for Business 2022 will map to OneDrive 22 after the update.

·      Reason for change: This update will make OneDrive product recognition and reporting more consistent across customer environments.

·      Recognition handling: Installations currently recognized as OneDrive for Business 2022 will be reported as OneDrive 22 after the update.

Records retained without change: The following records will not change:-

• legacy and pre-release on-premises versions, including OneDrive for Business 2016, 2019, 3.0, and 2013 Preview
• OneDrive for Office 365 products and plans
• OneDrive Mobile versions 2 through 6 and
• OneDrive Online for the Microsoft 365 SaaS application.

The table below lists each affected ARL record and its planned change

CUSTOMER IMPACT

·      Classification and reporting: The affected OneDrive releases will appear as Commercial instead of Freeware after customers receive the updated content library.

·      Normalization and recognition: Installations currently recognized as OneDrive for Business 2022 will appear as OneDrive 22 after the consolidation.

·      Existing records: OneDrive for Business 2022 records will move to OneDrive 22, and affected OneDrive applications will change from Freeware to Commercial. Products listed under “Records retained without change” are not affected.

·      License and entitlement: This update affects product classification and recognition only. It does not change license entitlements.

RECOMMENDED CUSTOMER ACTION

No customer configuration changes are required. After receiving the updated content library, customers should review reports, filters, dashboards, and integrations that rely on the classification and the OneDrive for Business 2022 product name.

For questions or suggestions about the listed OneDrive changes, please raise a support case with us and reference this content change notification for review. Thank you!

Understanding Oracle Java Evidence Processing and Recognition in the ARL

Oracle Java recognition can be complex because a Java installation may generate multiple types of software evidence. The same device may report file evidence for Java executables, installer evidence for JDK or JRE packages, and evidence created by another Oracle product that includes an embedded Java runtime.

The Application Recognition Library, or ARL, evaluates the available evidence to identify the applicable Java product, version, publisher and commercial classification while reducing duplicate or false-positive recognition.

This article explains the main evidence-processing principles used for Oracle Java.

Types of Java evidence

1) File evidence

File evidence is collected from Java executable files and their associated metadata. The primary executable patterns considered for Oracle Java recognition are:

• java.exe
• javaw.exe

The ARL assesses attributes such as:

• File and product version
• Product name
• File description
• Company or publisher
• Installation path

The java.exe executable may be present in both JDK and JRE installations. Therefore, an executable alone may confirm the presence of Java without always proving whether the installation is a standalone JDK, a standalone JRE, or Java embedded within another product.

The FlexNet Inventory Agent can also collect detailed file metadata when Oracle Java scanning is enabled, including the installation path, product name, publisher, Java version and related properties.

 2) Installer evidence

Installer evidence may be generated by:

• Native Java installers
• MSI or package-manager installations
• FlexNet Inventory Agent Java inspection
• Oracle Universal Installer, or OUI
• Another software product containing an embedded Java runtime

Installer evidence reported with the raw evidence type Java is collected after the FlexNet Inventory Agent locates a Java executable and runs supported Java version commands. Consequently, this evidence normally has corresponding Java executable file evidence

How the ARL determines the Java product

Java Platform

When the available file metadata identifies Java or Java Platform but does not reliably distinguish JDK from JRE, the evidence may be associated with Java Platform.

This provides visibility that Java is present while avoiding an unsupported assertion that the executable represents a separate JDK or JRE installation.

 Java Development Kit

Evidence is evaluated for JDK recognition when reliable attributes identify terms such as:

• JDK
• Java Development Kit
• JDK-specific product metadata

Beginning with Oracle JDK 11, Oracle no longer offers separate JRE or Server JRE downloads. Runtime capabilities are provided as part of the JDK distribution

 Java Runtime Environment

Evidence may be associated with JRE when reliable metadata identifies:

• JRE
• Java Runtime Environment
• A supported JRE installer pattern

JRE-specific mapping is generally applicable to Java 10 and earlier, subject to the evidence containing sufficient product and publisher information.

Publisher validation

Java is also distributed or repackaged by vendors other than Oracle. To reduce incorrect attribution:

• Evidence is mapped to Oracle Java only when the available publisher or file metadata supports Oracle attribution.
• Evidence clearly identifying IBM, SAP, Red Hat, BellSoft or another Java distributor should not be automatically attributed to Oracle.
• Evidence without reliable publisher or company information may be ignored or left unrecognised when the vendor cannot be established with sufficient confidence.
• Version patterns known to be associated with repackaged Java distributions are reviewed separately rather than automatically mapped to Oracle.

The current ARL guidance records that Java evidence without publisher or company information is ignored, and that certain repackaged version patterns require special handling.

This validation is important because identical or similar Java executable names may be used across different Java distributions.

Handling Oracle Universal Installer (OUI) Evidence

Oracle Universal Installer (OUI) evidence may be generated when Java components are installed as part of other Oracle products. As a result, the presence of OUI evidence does not necessarily indicate that Oracle Java was installed as a standalone product.

Examples of Oracle Java-related OUI evidence patterns include:

• Oracle.JDK
• Oracle.JRE
• Oracle.JDK Enterprise
• Oracle.JRE Enterprise

For example, Oracle.JDK and Oracle.JRE with evidence type OUI have been identified as patterns that can originate from Oracle product installations rather than an independent Java installation. To reduce false-positive Oracle Java recognition, Oracle Java evidence with evidence type OUI will be ignored in ARL.

Why is OUI evidence ignored?

Ignoring Oracle Java OUI evidence helps:

• Reduce false-positive recognition of Oracle JDK and JRE.
• Avoid recognising Java as a standalone installation based solely on evidence generated by another Oracle product.
• Ensure Oracle Java recognition is based on stronger evidence associated with the actual Java installation.

 Evidence that may be ignored

Java evidence may be ignored when it does not provide sufficient confidence for reliable recognition. Examples include:

• Evidence with no publisher or company information.
• Files that cannot be validated as Java product evidence.
• Known repackaged or vendor-specific patterns that must not be attributed to Oracle.
• Generic Oracle component evidence that does not establish a standalone Java installation.
• OUI patterns known to be generated by another Oracle product.
• Supporting executables that do not independently prove installation of the Java product.

Ignoring evidence means that the record is not used to recognise an ARL application. It does not remove the raw inventory evidence collected from the device.

What customers may see

As Java recognition rules are refined, customers may observe:

• A Java application being associated with a more appropriate publisher.
• Evidence moving between public and commercial Java applications after build-level validation.
• Duplicate JDK or JRE recognition being suppressed by precedence.
• OUI-based false-positive recognition being removed.
• Previously unrecognised Java evidence becoming recognised after ARL enrichment.
• Evidence remaining unrecognised when the publisher or product cannot be determined reliably.

Changes in recognised installation counts do not necessarily mean that software was installed or removed. They may result from improvements to evidence mapping, classification or application precedence.

Recommended customer actions

Customers investigating an Oracle Java recognition result should review:

• Application Transparency to identify the evidence contributing to recognition.
• The file path, publisher, product name, file version and evidence type.
• Whether both file and installer evidence exist for the same installation.
• Whether the Java runtime is standalone or embedded within another product.
• The latest ARL version available in their environment.

If evidence appears to be incorrectly mapped, submit a Flexera Support case with:

• The recognised application name and Flexera application ID.
• Exported installer and file evidence.
• The relevant device inventory or NDI file.
• The Java installation path.
• Output from java -version or equivalent vendor information, where available.
• Details showing whether Java was installed independently or supplied with another product.

This information enables Flexera to distinguish a content-mapping issue from incomplete, stale or ambiguous inventory data.

Important note : ARL recognition provides software inventory and normalization information. It does not determine whether an organization requires an Oracle Java licence or establish its contractual obligations. Customers should assess recognized installations against their applicable Oracle agreements and obtain appropriate licensing guidance where necessary.

ARL Classification Update on IBM WebSphere Application Server Liberty and WebSphere Application Server Liberty Network Deployment

Overview

Flexera is updating the Application Recognition Library (ARL) classification for the following IBM offerings:

• WebSphere Application Server Liberty, also known as WebSphere Application Server (base) Liberty
• WebSphere Application Server Liberty Network Deployment

These offerings are currently classified in the ARL as Commercial products. Following this update, they will be classified as Components of their corresponding traditional WebSphere Application Server offerings. This change aligns the ARL classification with IBM’s documented product packaging and entitlement model.

Why Are We Making This Change?

IBM documentation states that WebSphere Application Server Liberty base is not available as a standalone product. Entitlement to it is obtained through WebSphere Application Server (traditional), which includes entitlement to both the traditional and Liberty base components. Vendor literature reference - [ibm.com], [ibm.com]

Similarly, WebSphere Application Server Network Deployment Liberty is not available as a standalone product. Entitlement to it is obtained through WebSphere Application Server Network Deployment (traditional), which includes entitlement to both the traditional and Liberty Network Deployment components. Vendor literature reference - [ibm.com]

Flexera is therefore updating these ARL classifications from Commercial to Component to more accurately represent IBM’s documented product structure.

What Is Changing?

Only the ARL classification is changing. Existing application metadata, evidence linking, and product relationships will be retained.

What Is Not Changing?

This is a classification update only. It will not change:

• Product and application recognition results
• Inventory collection
• Software discovery
• Existing installations or deployments
• Evidence linking
• Application metadata
• Existing product relationships

Systems that currently recognize these products will continue to recognize them after the update.

Customer Impact

After the update, customers will see the affected products classified as Component instead of Commercial in ARL.

Customers may observe the new classification in:

• Custom reports and dashboards
• ARL exports
• Integrations that consume ARL classification data
• Automated workflows that use Product Classification as a filter

Recommended Customer Action

Customers should review the update if they use the Classification attribute in either or similar options, like custom reports, dashboards, integrations, exports, or automated workflows etc.

Release Information

This change is scheduled to be included in the ARL release on September 21, 2026.

The attached file contains the list of affected products and applications included in this update.

If you have questions about this change or observe unexpected behavior after the release, please raise a Flexera Support case.