Automating the Management of Embedded Java instances
Description - Flexera Employee Solution
- Owner: Nicolas Rousseau
- Owner Email Address: email@example.com
- Solution Type: Custom Inventory Import & Custom SQL Reports
- Flexera Product & Version: FNMS 2016+
- Environment: On Prem Only
- Development Effort (Days): 3
- Implementation Effort (Days): 0.1
SOLUTIONS ARE PROVIDED ON AN "AS IS" BASIS. NEITHER FLEXERA NOR ITS SUPPLIERS MAKE ANY WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, TITLE, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. LICENSEE MAY HAVE OTHER STATUTORY RIGHTS. HOWEVER, TO THE FULL EXTENT PERMITTED BY LAW, THE DURATION OF STATUTORILY REQUIRED WARRANTIES, IF ANY, WILL BE LIMITED TO THE SHORTER OF (I) THE STATUTORILY REQUIRED PERIOD OR (II) THIRTY (30) DAYS FROM LICENSEE’S ACCEPTANCE OF THE AGREEMENT.
This solution allows to automatically remove embedded instances of Java from the Java Platform recognition.
The code of the solution is in the attached file. Full description below.
Java has a rule that manage differently builds:
- Java SE 5:
- Java 5 Until (& incl.) update 22 => “PUBLIC”
- Java 5 update 23 & up => “RESTRICTED”
- Java 5 (all update) where build >30 => “RESTRICTED”
- Java SE 6:
- Java 6 Until (& incl.) update 45 => “PUBLIC”
- Java 6 update 51 & up => “RESTRICTED”
- Java 6 (all update) where build >30 => “RESTRICTED”
- Java SE 7:
- Java 7 Until (& incl.) update 80 => “PUBLIC”
- Java 7 update 85 & up => “RESTRICTED”
- Java 7 (all update) where build >30 => “RESTRICTED”
- Java SE 8:
- Java 8 Until (& incl.) update 202 => “PUBLIC”
- Java 8 update 211 & up=> “Restricted” (License change – 16/04/2019)
- Java 8 (all update) where build >30 => “RESTRICTED”
- Java SE 9 / 10
- Java 9 & 10 => Public
- Java 11
- Java 11 Until (&incl.) update 2 => Public
- Java 11 update 3 => “RESTRICTED”
- Java 12 and more => “Restricted” (Licensing modification – 16/04/2019)
To adapt to this constraint, Java recognition has been modified in FNMS FNMS ARL in April 2021 to match this build level management.
- The java commercial and non-commercial products have been normalized back to major version level (for instance Java Platform 8 Standard
- Evidences have been linked according to their build level to applications (for instance: Java.exe 188.8.131.52% linked to Java Platform 8 Standard
Additional changes need to be applied in the Unix agents (planned to be released in June 2021) to collect the build version when it is returned by the “java -version” command and create a file evidence associated with a folder that will be useful to make the described solution efficient on Windows and Unix.
Another challenge with Java is that you may have multiple instances of Java on a computer, some being licensed, others being exempted (because embedded versions of Java).
This document, is intended for SAM Managers and FNMS admins, describes how to extend FNMS to manage embedded files automation.
The principal is the following: at import time (FileEvidence.xml writer), the inventory import checks if the raw evidences match, for their name (Unix evidences) or name + folder (Windows) with the list of “embedded evidences” imported from an Excel file.
If an exact match happens, the importer will add on the fly the “MatchARLEvidencesName” (column 3) value as a prefix to the raw evidence name. For instance, Java.exe in the C:\Program Files (x86)\Common Files\Oracle\Java\javapath path will become: JavaEmebeddedJava.exe and will no longer be recognized as “Java Platform”.
Components / steps of the solution
- Import the embedded files / folders reference data
- Modify the import logic of the FileEvidence.xml writer to automatically flag the raw evidences to have a different special recognition
- Create a Java Platform Embedded Edition Application (Freeware)
- This freeware application will have no version, will be linked to all embedded evidences (with a possibility to match the raw evidences names) and will allow to track all embedded Java instances that have been removed from the java Platform recognition
- Create 2 Java transparency reports
- One for the list of embedded folders and the reason for exclusions (just reads the result of the Excel import)
- One for the Java recognized applications (along with raw evidences and exclusion reason (for embedded)
Create the embedded list Excel file
You need to create an Excel file that exactly matches the template below.
Note that the Unix files contain their path in their name. The “reason” will allow to justify the evidences that will be set as “embedded” in the Java evidences with their path transparency report.
You can use wildcard (“%”) for defining the folder path.
Also note that Unix evidences reported as file evidences are not (yet) used for recognition. This is something coming with the FNMS 2020R2.5 agent (June for SaaS, July for on prem). With this new version of the agent, the Java -version command results will be stored as file evidences with a path that will be in Java instance path.
Import the Excel file into a Physical table with the Business Adapter
The Business Adapter Studio has the ability to create physical tables (see below) when importing data. The approach for importing the embedded folder reference data is to run the Business Adapter Studio XML embedded below. This Business Adapter import does not contain any data mapping, it just has the “Use Physiscal Table” box checked… to create the “ECMImport_ExcludeFolderFiles” table. Everytime the Business Adapter Studio runs, it drops the previous table and recreates it. Moving forward, you will need to extend the list of exempted files and folder and re-import the full list.
To import the refreshed version of the embedded files, pick up the refreshed Excel file (you can archive the previous one) and import the data by clicking on “Tool/Import”.
The importer creates a ECMImport_ExludedFileFolders table that is used by the inventory import customization and the Embedded Java Paths (NR) report.
As a result of a new import, the ECMImport_ExludedFileFolders table will be refreshed and will expose more “embedded files & Paths” to the file evidence recognition process, extended to exclude these evidences.
Modify the FileEvidence import writer
The Inventory import located on
.\ProgramData\Flexera Software\Compliance\Import Procedure\CustomInventory\Writer\FileEvidences.xml
needs to be customized to apply the following logic: Any raw evidences that matches the list of “embedded” folders will be renamed on the fly “EmbeddedXXX”, which will avoid any Java Product recognition but will keep the evidence visible.
An additional logic is added in the “FileEvidenceSetUp” to manage the embedded files: creation of new “EmbeddedJava.exe” importedFileEvidences, relink of the ImportedInstalledFileEvidences to these embedded ImportedFileEvidences. The customization is from line 7 to 64.
Customized FileEvidences.xml writer file has to be placed on: .\ProgramData\Flexera Software\Compliance\Import Procedure\CustomInventory\Writer\FileEvidences.xml.
The customizations are documented and comments in the SQL code.
-- *** Nicolas Rousseau: START OF CUSTOMIZATION ***
-- *** Nicolas Rousseau: END OF CUSTOMIZATION ***
The FileEvidences.xml file below is suited for FNMS 2020R1. Make sure you report the added section to the out of the box version if you are not in FNMS 2020R1
Make sure you have the out of the box “Importer.xml” file placed on .\ProgramData\Flexera Software\Compliance\Import Procedure\CustomInventory. It contains the sequence writers procedures for the inventory imports.
Make also sure that writer.config (that maps the xml files to the procedures) is place in .\ProgramData\Flexera Software\Compliance\Import Procedure\CustomInventory\Writer
This application has no version, a new edition… and will be linked to any “JavaEmbeded% “file evidence. It will allow to identify where these embedded versions have been re-directed
2 reports are created:
- The Embedded Java Paths (NR) report gives the list of path and file names that will trigger the evidence to be excluded. It is a flat view for the imported file evidences and paths and the reason for embedded status.
- The Java.exe Files With Their Path (NR) report gives the flat list of java.exe or JavaEmbeddedJava.exe files, along with the applications that have been recognized and the list of “embedded paths”.
The following steps will need to be performed before each reconciliation work.
- Refresh the embedded path in FNMS
- Make sure that all Java evidences are recognized
- Check that 100% of the installed servers are allocated to the Java Server License. BE CAREFUL NOT TO ALLOCATE AND EXEMPT AS IT CAUSES ISSUES.
- Check that 100% of the installed Desktops are allocated to the desktop licenses.
Starting with FNMS 2021R2.5 (June 2021 for SaaS, July 2021 for on prem), the Unix agent will collect the Java -version command result as file evidences, that will include, when available, the Update and Build versions of Java.
A challenge will be that Java products will be recognized through installer evidences (that will not contain path and will be the unique evidence collected by prior versions of the agent) AND file evidences.
Once the deployment of the latest version of the agent will be confirmed, you will need to ignore the Installer Evidences to remove them from the recognition process. Make sure you select evidences that are consistent (for instance: source = Flexera, assigned = Yes) The ARL recognition will then go through the file evidences only... and the embedded files automation will apply to Unix too.