- Flexera Community
- FlexNet Manager
- FlexNet Manager Knowledge Base
- Automating the Management of Embedded Java instances
Automating the Management of Embedded Java instances
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.
Nicolas Rousseau 2022_11_14: Please note that the Embedded Java instance management has been implemented with ITAM / FlexNet Manager 2022R1 in March 2022. For more information please refer to the February SAM Best Practice Webinar: Java and Windows Server Optimization report
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 18.104.22.168% 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). A public resource for finding the Oracle applications that embed Java: https://www.oracle.com/technetwork/java/javase/terms/oaa.html
This document, is intended for SAM Managers and FNMS admins, describes how to extend FNMS to manage embedded files automation.
High level design of the solution
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)
Build the embedded folder list (Business Adapter Studio Import)
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
Creation of a Java Platform (Public) Embedded Freeware application
Creation of Java recognition reports
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”.
Step by step description of Java operations moving forward
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.
Addition of Unix File Evidences to the solution
Starting with FNMS 2021R2.5 (June 2021 for SaaS, July 2021 for on prem), the Unix agent collects 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.
form my point of view the topic
- Java SE 7:
- Java 7 Until (& incl.) update 80 => “PUBLIC”
would also apply.
I have one question in regards to the Unix File Evidences:
Do I understand correct that for correct recognition, the Agent >= 17 needs to be installed ?
We have deployed some 17.1 and newer, but it still does not show anything from Unix File Evidences.
What do you suggest to check ?
@gbauer - By default, the agent does not perform File Evidence scanning. You need to go to the Inventory Settings page in the User Interface and enable File Evidence Scanning by platform. This creates a Policy Update that is passed down to installed agents to so that they capture File Evidence during a scheduled inventory.
Just a quick feedback - if you have this custom reporting installed and want to upgrade FNMS the database migration scripts will fail because of several extra index.
I backed up the scripts to re-generate the indexes just in case and simply dropped them. (of course you could simply re-run these custom sql's in the attatched documentation)
FNMS DB migration to 2022r1 was fine after that for me:
- drop INDEX [IX_ImportedInstalledFileEvidence_ComplianceConnectionID_ExternalFileID] ON [dbo].[ImportedInstalledFileEvidence_MT]
- drop INDEX [IX_ImportedInstallerEvidenceMapping_CConnectionID_EInstallerID] ON [dbo].[ImportedInstallerEvidenceMapping_MT]
- drop INDEX [IX_ImportedInstallerEvidence_ComplianceConnectionID_ExternalInstallerID] ON [dbo].[ImportedInstallerEvidence_MT]
- drop INDEX [IX_ImportedInstallerEvidenceMapping_ComplianceConnectionID_ExternalInstallerID] ON [dbo].[ImportedInstallerEvidenceMapping_MT]
As I understand there are similar or same functionality now in FNMS 2022r1 anyway so this might be more in the way than helpful for people using 2022r1
@steffen - thanks for the note. You're spot on that custom indexes configured on tables in the database will cause future database migrations to fail.
I'm not entirely sure where you got those indexes from, but as far as I can tell they didn't come from this article. (At least the current version of this article - maybe there was an earlier version of the article that included them?)
Indixes are created inside the attatched word:
see "Managing Java Embedded Files Evidences In FNMS v2.docx" and look in second "View Code.docx" embedded file.
Hello @steffen ,
Indeed, a custom index on an out of the fox table will make the migration fail...
However, the indexes on the second view are created on a temp table (like in many other custom SQL reports).
CREATE INDEX ExternalID ON #JavaEvidences (ExternalID)CREATE INDEX ComplianceComputerID ON #JavaEvidences (ComplianceComputerID)CREATE INDEX ExternalFileID ON #JavaEvidences (ExternalFileID)
Are you seeing indexes created by the reports on the out of the bow ImportedXXX_MT tables?
sorry for any confusion:
Nicolas's scripts did not create these aditional Indexes - all green here 😉
However Flexera Support did do some perormance troubleshooting (Case #02518130) and looks like there is some clean ups missing in there!
Thanks any many greetings