Analyzing Oracle Middleware with the LMS Collection Tool – A Practical Guide

Analyzing Oracle Middleware with the LMS Collection Tool

Oracle’s License Management Services (LMS) Collection Tool is a script set that captures detailed information about Oracle software usage. For Software Asset Management (SAM) and IT asset managers, understanding the LMS output for Oracle Middleware components is crucial for license compliance.

This guide provides a step-by-step approach to analyzing Oracle Middleware data (WebLogic Server, SOA Suite, BI Publisher, etc.) gathered by the LMS tool, with tips on interpreting the results and ensuring compliance.

Overview of Oracle Middleware Products Captured by LMS

Oracle’s LMS scripts cover various product families, including Oracle Fusion Middleware. The middleware components typically inventoried by the LMS tool include​:

• Oracle WebLogic Server – The core Java EE application server (all editions: Basic, Standard, Enterprise, Suite).
• Oracle Internet Application Server (iAS) – Legacy application server components (often now realized through WebLogic).
• Oracle SOA Suite – Service-Oriented Architecture platform (BPEL engine, Oracle Service Bus, BPM, etc.).
• Oracle Business Intelligence – e.g. Oracle Business Intelligence Enterprise Edition or Oracle Analytics Server (which includes BI Publisher).
• Oracle WebCenter – Portal and content management middleware.
• Oracle Forms and Reports – Legacy middleware for forms applications.
• Oracle Tuxedo – Middleware for COBOL/C/C++ applications (if present in environment).
• Java SE – Java runtime usage on servers (to check if Java requires separate licensing).

These products fall under Oracle’s Fusion Middleware portfolio and are within the “radar” of LMS audits​. The LMS tool’s middleware module is tailored to gather data about application server domains and deployed components​, much like the database module gathers info on DB options.

How the Oracle LMS Script Collects Middleware Data

The LMS Collection Tool combines scripts and utilities to extract configuration and usage data from middleware installations.

Key points about how data is collected:

• Script Execution: Oracle provides the middleware LMS scripts (often in a ZIP) to run on each relevant server​. Typically, a master script (shell or batch) must be run with admin privileges on the server​. This master script calls product-specific subscripts for WebLogic and other components.
• WLST Scripts for WebLogic: The tool leverages the WebLogic Scripting Tool (WLST)—a Jython-based interface—to query WebLogic domain information. For example, a WLST script (often run offline) can read each WebLogic domain’s configuration to list the domain name, servers, clusters, deployments, and services​. By automating WLST commands, the LMS script gathers application server domain configurations and deployments without requiring manual input.
• Configuration File Parsing: In addition to WLST, the tool directly collects important config files from middleware homes:
  • domain-registry.xml – Lists all WebLogic domains registered on that installation (with their file system paths)​. This helps identify every domain that needs analysis.
  • config.xml (for each domain) – The main configuration file of a WebLogic domain, containing the setup of servers, clusters, JMS, deployed applications, etc.​. The LMS script copies this for each domain because it reveals the components and features used.
  • Oracle Inventory (registry.xml) – The Oracle Universal Installer inventory file from the Middleware home, listing all installed Oracle middleware products and components (by internal codes and versions). This shows, for example, if SOA Suite or WebCenter binaries are installed in that environment.
  • Other product-specific configs if present (e.g. opmn.xml for older Oracle HTTP Server/Forms installations, portalconfig.xml for WebCenter Portal, etc.)​.
• System and Process Scans: The script may scan the file system and running processes to ensure it captures all instances:
  • File Scans – It searches for known middleware installation directories and files to identify installations (for example, WebLogic installation directories, ORACLE_HOME paths, etc.)​.
  • Process Scans—It checks running processes for Oracle middleware (e.g., Java processes running WebLogic)​. This helps differentiate between installed but unused software and actively running servers.
• No Changes, Only Read-Only: The LMS scripts are designed not to modify the environment but to read configurations and output data. Oracle often assures customers that the scripts are read-only and have minimal performance impact​ (though it’s wise to run them in a maintenance window).
• Output Files: As the script runs, it produces output files (often consolidated into a zip archive). These may include raw text, CSV, or XML files with the collected data​. For example, a WebLogic WLST script might output a text report of the domain configuration, and the inventory data might be in XML. All these are usually packaged for analysis.

Example: For WebLogic, the LMS tool might run a WLST script that prints each domain’s name, version (e.g., WebLogic Server 12c 12.2.1.4), the number of servers and whether they’re in a cluster, JMS configuration, etc. Meanwhile, it also grabs the domain-registry.xml and config.xml files to ensure nothing is missed in the report​. In effect, Oracle gathers a complete snapshot of your middleware setup.

Key Output Files and What They Reveal

After running the LMS collection tool on middleware servers, you will have a set of output files. Understanding each file is the first step in analysis:

• Oracle Inventory (registry.xml or inventory.txt) – Installed Products: Lists the Oracle Fusion Middleware components installed on the server. For example, if SOA components were installed in that WebLogic home, it might show “WebLogic Server 12.2.1.4.0” and “Oracle SOA Suite 12.2.1.4.0”. Each installed feature appears as an entry (often with internal names) in this file. This tells you which Oracle middleware products are on that server, which is crucial for knowing what licenses might be required.
  • How to use it: Review this list against your licenses. Suppose you see a product like Oracle Service Bus or Oracle BI Publisher in the inventory but haven’t licensed it separately. In that case, that’s a flag to investigate (it could be unused binaries or a compliance gap).
• domain-registry.xml – Domain List: This XML file contains the locations of all WebLogic domains registered with the WebLogic installation​. This registry is updated whenever a new domain is created on a WebLogic install. The LMS output will include this file so you can identify every domain (by path and name) on the server.
  • How to use it: Ensure you account for each domain in your analysis. It ensures that no WebLogic domain is overlooked. You should find a corresponding config file or WLST output for each domain path in the LMS results.
• WebLogic Domain Config (config.xml) Domain Configuration: This is the core configuration file for each WebLogic domain, collected to reveal detailed settings. Key information config.xml includes:
  • Domain name and WebLogic version.Servers: AdminServer and Managed Servers defined.Clusters: If multiple servers are grouped in clusters.JMS: JMS servers and modules configuration.Data sources, JTA, Security realms: (all configured services).Deployed Applications: It may list J2EE applications or Oracle applications deployed.
  This file essentially shows how WebLogic is being used—single server vs. cluster, what Java EE features are configured, etc. Oracle LMS uses it to interpret what edition of WebLogic you’re effectively using based on the features enabled​.
  • How to use it: Open each domain’s config.xml (or the WLST-generated summary of it). Check for <cluster> entries (which indicate clustering), <jms-system-resource> for JMS, and any mention of specific Oracle apps (for instance, a deployed application named “soa-infra” indicates an SOA Suite domain). We will discuss interpreting these in the next section.
• WLST Output Reports – The LMS tool may sometimes provide a pre-formatted report (text/CSV) extracted via WLST. For example, an output file might list each WebLogic server instance with columns for “Domain – Server – Clustered (Y/N) – JMS Enabled – Version – Edition.” This is essentially the script’s parsed output to highlight important points (Oracle may or may not provide a nicely formatted output to the customer; sometimes it’s raw data that Oracle’s auditors parse themselves). If present, these reports can simplify analysis:
  • For instance, a WLST output might say: “Domain ProdDomain Has 1 AdminServer and 4 Managed Servers in cluster ProdCluster” – flagging a cluster deployment.
• Other Config Files – If other middleware components are present, their configs will appear:
  • SOA Suite: A SOA domain’s config or composite deployment information might be captured (e.g., a listing of SOA composites).
  • Oracle HTTP Server (OHS): httpd.conf or opmn.xml might be included, showing web server usage.
  • Oracle BI Publisher/Analytics: Configuration files indicating BI services or OBIEE deployment on WebLogic (like bi-config.xml) could appear if relevant.
  • Enterprise Manager (Fusion Middleware Control): If using FMW Control, its deployment might appear (though this is usually part of the WebLogic domain config for SOA/BI).

Tip: The LMS output is very detailed. It captures not only what is installed, but how it’s configured and even what’s running​. Be prepared for a lot of technical data. As a SAM manager, focus on the parts that have license implications – typically the features and components in use.

Read Interpreting Oracle LMS Database Script Output.

Interpreting WebLogic WLST Output: Editions, Features, and Domain Configurations

One of the most important tasks is determining which edition of WebLogic is being used in each environment and what features are enabled. Oracle WebLogic Server has multiple editions (Basic, Standard, Enterprise, and Suite), and the LMS data will indicate usage patterns.

Here’s how to interpret the output:

• WebLogic Edition (Standard vs Enterprise vs Suite): Oracle does not explicitly label “This is Standard Edition” in the config; rather, you infer it from features:
  • Clustering Enabled: Enterprise Edition features are in use if the domain config shows a cluster (multiple WebLogic instances in one domain clustered together). WebLogic Standard Edition does not support clustering​. For example, if config.xml has a <cluster name="..."> section or Managed Servers with <cluster> references, that domain is using clustering – a feature of Enterprise (or Suite) edition.​. In LMS output, Oracle would flag this. Cluster = require WebLogic Enterprise licensing.
  • Multiple Managed Servers (without cluster): If a domain has multiple managed servers but no defined cluster, technically, they aren’t clustered (which Standard Edition could allow as long as they’re independent). However, in practice, the production use of multiple servers often implies either clustering or other advanced features (like distributed deployments). Double-check if clustering is not obvious or if a load balancer is fronting independent servers. Standalone servers can be Standard, but any tight coupling (session replication, etc.) would be a cluster indicator.
  • High Availability Features: Look for signs of advanced HA features in the config, e.g., Whole Server Migration, Service Migration configurations, or JMS persistent storage on shared storage for migratable targets. These are Enterprise-only capabilities​ (Standard cannot do whole-server migration, etc.). LMS output might not explicitly name these, but it’s a clue if present in config files.
  • Oracle Coherence: If the domain or inventory shows Coherence (caching) configured – for example, Coherence cluster configuration or Coherence library deployed – note that Coherence is included only with WebLogic Suite (or licensed separately). Enterprise Edition does not automatically grant Coherence usage beyond the basic included cache for cluster operations. If you see Coherence clusters explicitly, that could imply use of WebLogic Suite features​ (or an add-on Coherence license).
  • JMS Configuration: Basic JMS is available in all editions, but JMS clustering (distributed destinations across a cluster) inherently requires a clustered WebLogic (Enterprise). Check the JMS configuration: if you see a <distributed-topic> or <distributed-queue> spanning servers, which confirms a cluster. If JMS is only configured on single servers, that alone is fine on Standard. However, if the output shows JMS running on multiple managed servers in concert, that again ties to clustering. The LMS script specifically looks for JMS clustering and other indicators of Enterprise features​.
• Domain Version and Type: The WebLogic version (10g, 11g, 12c, etc.) is usually in the inventory and domain config. All editions share the binary, so the version doesn’t determine the edition by itself – the usage of features matters. But note that if you have WebLogic Server Basic (the restricted version included with some products), it’s essentially WebLogic Server with certain features disabled by license (clustering, advanced JMS, etc. are not allowed on Basic)​. We’ll cover Basic vs full licenses in the next section.
• Features in Use: Besides clustering, scan the config or WLST report for other enterprise features:
  • JTA: Transaction Manager is standard, but Cross-Domain Transactions require Enterprise (rare, check if multiple domains are part of a transaction – not usually visible in config).
  • Security Providers: External authentication providers (LDAP, etc.) are allowed in all editions. Not a differentiator.
  • Deployment features: Production Redeployment (versioned deployment) might be noted if an application is deployed with versioning – this is an Enterprise feature. If you find evidence of versioned deployments in the domain (e.g., two versions of an app deployed for zero-downtime updates), that’s an Enterprise/Suite feature​docs.oracle.com.
  • Virtualization: If the environment uses Oracle VM with WebLogic and takes advantage of Oracle’s virtualization-specific features (like Oracle Virtual Assembly Builder, which is listed under Enterprise features​), that implies Enterprise. This might not appear in WebLogic config but could be gleaned from context (inventory or environment).
• Domain Purpose (Installed Suites): Identify if the WebLogic domain is hosting any Oracle middleware suites or products: For example, a domain containing SOA Suite components (you might see deployments or services like soa-infra, BAM, OracleServiceBus in the domain config or WLST output) indicates that the domain is a SOA Suite domain. This means that Oracle SOA Suite is installed on top of WebLogic – a separate licensable product.A domain for Oracle BI Publisher/Analytics might show deployments like analytics, BI_Publisher or something
  • similar, along with BI-specific JMS and data sources.An Oracle Forms & Reports domain might be identified by applications like formsapp or configurations for Forms.Oracle Enterprise Manager (Fusion Middleware Control) could appear if the domain was extended with FMW control (as is often the case for SOA/BI domains).
  How to interpret: If the LMS output reveals these components, it means those middleware products are in use (and not just installed). It’s important to correlate this with your SOA, OSB, BI licenses, etc.
• Edition Confirmation: Oracle’s LMS analysts will use the data to conclude the edition. For your internal analysis, you can decide:
  • If you see no clusters, no advanced features, and modest usage (single-server domains), it might align with WebLogic Standard Edition usage.
  • If you see clusters or enterprise-only features, usage aligns with WebLogic Enterprise Edition or Suite. In such cases, check if the inventory shows Coherence or iAS suite components (which would lean toward Suite). Otherwise, Enterprise is likely to need a license.
  • If the only WebLogic usage is associated with an Oracle application (like E-Business Suite or PeopleSoft domain), that might be running under a restricted “Basic” license bundled with that app – more on this next.

Example Interpretation: The LMS script output shows “Domain ProdDomain: WebLogic Server 12.2.1, 1 admin + 4 managed servers in cluster ProdCluster”. This tells us the WebLogic domain is clustered (hence not Basic or Standard – clustering “usually implies a higher edition or license requirement”​). Oracle would consider this an Enterprise Edition deployment. If our records show only WebLogic Standard licenses purchased, we have a compliance gap. Conversely, if it showed a single-server domain with no cluster, that could fit Standard (assuming no other flagged features).

Identifying Restricted-Use vs Full-Use Deployments

Oracle often bundles “restricted-use” WebLogic licenses with other products (Oracle Database, E-Business Suite, etc.). It’s critical to distinguish these from full-use WebLogic installations in the LMS findings:

• WebLogic Server Basic (restricted-use): WebLogic Basic is a license-constrained edition that comes free with certain Oracle products (it is not sold standalone)​. For instance:
  • Oracle E-Business Suite (EBS): EBS 12.2 uses WebLogic for its application tier. Oracle grants a restricted WebLogic license through the Oracle Internet Application Server Enterprise Edition (iAS EE) license that comes with EBS​miroconsulting.com. This WebLogic “Basic” can only be used within the EBS context – running the forms, reports, and other components of EBS​. It allows the core app server functionality needed by EBS, but if you deploy custom applications or use advanced features on this WebLogic, you violate the license.
    • Identification: The LMS output might reveal an EBS domain through naming conventions or deployments (for example, a domain name EBS_domain or the presence of EBS-specific applications). Oracle’s scripts can spot this because “WebLogic domain names and Java arguments” often indicate Oracle packaged apps​. If you identify a domain as the EBS domain, treat it as restricted-use WebLogic. Ensure that the domain is only used for EBS. No separate WebLogic license is required for it (it’s covered by EBS’s iAS EE license) – but also it can’t be used for anything else.
  • Oracle Database / Enterprise Manager: Oracle Enterprise Manager (OEM) Cloud Control uses WebLogic for its console. OEM comes with a restricted-use WebLogic license for that purpose​.
    • Identification: The OEM WebLogic domain is often named “GCDomain” and runs the EMGC (Enterprise Manager Grid Control) application. LMS output on a database server might show a domain with EMGC or OEM-related deployments. This does not require a separate WebLogic license as long as it’s only used for OEM (even clustering OEM is permitted under that restricted license for high availability​).
    • It could be this scenario if you find WebLogic on a server primarily for Oracle Enterprise Manager or database tooling.
  • Other Oracle Apps: PeopleSoft, JD Edwards, Hyperion, Oracle BI (OBIEE/OAS) – all of these either use WebLogic or are allowed under a restricted license for that application only. For example, OBIEE 12c includes a WebLogic to host the BI system; PeopleSoft includes a license to WebLogic (or Tuxedo) for the app server component. The LMS data might not explicitly label them as such, but you can classify them as restricted-use cases by recognizing the context (domain name, installed apps).
    • E.g. If LMS shows a WebLogic domain hosting Hyperion services (Essbase, etc.), note that WebLogic is bundled with Hyperion – ensure it’s not being used beyond Hyperion.
• Full-Use WebLogic: Any WebLogic installation not tied to one of the above Oracle products (i.e., it’s hosting custom applications or standalone middleware like SOA Suite) is a full-use deployment that requires its WebLogic license. If LMS output shows a WebLogic domain that isn’t clearly for EBS, OEM, or another Oracle app, assume it’s a full-use instance. You must then match it to either WebLogic Standard, Enterprise, or Suite licenses you own.
• Gray Areas: Sometimes, an environment might blur lines, e.g., deploying a custom app on the same WebLogic domain that runs an Oracle-provided application:
  • This is not allowed under restricted use. Oracle’s restricted license terms for WebLogic Basic explicitly state that it’s only for running the components of the product it came with, not for any other purpose​. If LMS output shows additional deployments on an EBS WebLogic domain (say, a custom Java application deployed alongside EBS), that’s a compliance problem—you would need a full WebLogic license for that usage. Companies should segregate such custom deployments into separate WebLogic instances with their own licenses.
  • Watch for any anomalies in domains that are supposed to be restricted. For example, an EBS WebLogic domain should normally only have EBS-related applications. If you see others, flag it.

Action: For each WebLogic domain identified, ask, “Is this domain solely used for an Oracle packaged product (with a restricted license), or is it a general purpose application server?”. Document this classification.

It will determine whether you need to account for a WebLogic license for that domain. (If it’s restricted-use, ensure you comply with its restrictions; if it’s full-use, ensure you have the appropriate WebLogic edition licensed.)

Common Red Flags in Middleware LMS Output

When reviewing the LMS data, be on the lookout for these common compliance red flags in Oracle Middleware environments:

• Enterprise-Only Features on a Standard License: If the output shows clustering, multiple managed servers in a cluster, or other Enterprise features, but you have only purchased WebLogic Standard Edition, this is a major red flag. For example, JMS distributed destinations across a cluster or enabled “Whole Server Migration” without Enterprise licensing. Oracle will flag this in an audit – WebLogic Enterprise Edition is required for clustering and advanced high-availability features​. Red Flag: “Domain X is clustered” with only Standard Edition entitlements. Remedy: You’d need to procure Enterprise licenses or reconfigure to a non-clustered architecture (the former is more typical).
• Unlicensed Oracle Middleware Components: The LMS tool can uncover installed or active components like SOA Suite, Oracle Service Bus, Oracle BPM, WebCenter, etc. If your organization has not licensed these, their presence is a compliance issue. For instance, if registry.xml our WLST output indicates SOA Suite is installed or running (perhaps the domain has soa-infra deployed), and if you never bought SOA Suite licenses, you have “shelfware” being used without entitlement. Oracle’s script will “identify any optional components in use (like Oracle SOA Suite, if installed)”​. Red Flag: Active use of SOA/BPM, OSB, etc., with no corresponding license. Remedy: Either remove/disable those components or acquire the proper licenses; at minimum, be ready to explain if they were installed but not used (and ensure they truly haven’t been used).
• Multiple Clusters or Scaling Beyond Licenses: If you have Enterprise Edition licenses but only for a certain number of cores, check if the environment has grown:
  • E.g., LMS shows two large clusters running, and your license count covers only one cluster’s worth of CPUs. Oracle licenses WebLogic by processor; multiple domains/clusters aren’t an issue per se if all processors are licensed. But if LMS data shows WebLogic running on servers that exceed your licensed processor counts (maybe an extra environment spun up without licenses), that’s a red flag. Red Flag: WebLogic instances on unlicensed servers or extra cores beyond purchased amounts. Remedy: Reconcile the server list with your license purchase records; ensure all CPUs running WebLogic (outside of restricted-use scenarios) are accounted for.
• Use of WebLogic “Basic” Beyond Scope: As discussed, WebLogic Basic (restricted) misuse is a red flag. For example, an EBS WebLogic domain hosting a custom application or an OEM WebLogic used to run another J2EE app. Oracle’s terms forbid using Basic for anything other than the bundled product​. Red Flag: Non-EBS applications deployed on an EBS WebLogic instance (or any similar cross-usage). Remedy: Migrate that custom app to its own properly licensed WebLogic domain or obtain the appropriate license and segregate it.
• Oracle BI Publisher/Analytics Usage: Oracle BI Publisher is often included in other products (EBS has a restricted-use BI Publisher called Oracle XML Publisher, etc.). If LMS shows a standalone BI Publisher installation (maybe on WebLogic) and you haven’t licensed Oracle BI, clarify its source. Sometimes BI Publisher comes with an Oracle Internet Application Server license or as part of BI Suite. Red Flag: BI Publisher standalone deployment unaccounted for. Remedy: Verify if BI Publisher came as part of another suite you own or if it requires a separate license.
• Java SE Usage: Not middleware per se, but LMS often notes Java versions on servers​. Since 2019, Oracle Java SE requires a subscription for commercial use (unless an Oracle product license covers it). If LMS output highlights Oracle Java installations without a Java license, note that as well. It might be outside your immediate middleware analysis, but it’s related (Oracle might use the middleware script to flag Java usage, too). Red Flag: Oracle JDK on servers with no Java subscription. Remedy: Include Java in your compliance review if applicable.

The mismatches between the LMS data and your entitlements create red flags. Oracle’s script is very thorough and will likely reveal any such mismatches​. Being able to spot them yourself allows you to address issues proactively.

Insight: Oracle uses these scripts specifically to flush out “usage of Oracle software beyond what you have legally licensed”​. Even if a feature was enabled unknowingly (say, an admin turned on SOA Suite or enabled a WebLogic cluster for testing), the script records it and Oracle will consider it a licensing requirement. Your job is to catch these and either remediate or be prepared to defend/resolve them.

Cross-Checking Findings with License Entitlements

Once you’ve extracted the key information from the LMS output, the next step is to cross-check it against your organization’s license entitlements (contracts, purchase records):

1. Inventory Your Entitlements: List out the Oracle middleware licenses you own. Include the product name, edition, version (if applicable), quantity (processors or Named User Plus, etc.), and any special restrictions. For example:
   • WebLogic Server Standard Edition – 4 processors.
   • Oracle SOA Suite – 2 processors.
   • Oracle Internet Application Server Enterprise Edition – licenses (for EBS use, which cover WebLogic Basic).
   • Any Oracle middleware suite bundles (WebLogic Suite, etc.).
2. Map LMS Findings to Products: Take each component from LMS data and map it:
   • For example, LMS shows WebLogic domain A using clustering, which translates to WebLogic Enterprise Edition usage. Do you have enough Enterprise licenses for domain A’s servers?
   • LMS shows SOA Suite components in domain B -> this maps to Oracle SOA Suite licenses. Do you own SOA Suite licenses (for that environment’s CPU count)?
   • LMS shows an OHS/WebTier installation -> maps to iAS (Oracle HTTP Server comes under iAS license). EBS’s iAS license might cover it if it’s EBS, otherwise it might require WebLogic Suite or separate HTTP Server license (depending on version).
3. Identify Gaps or Surpluses: For each mapping, determine compliance:
   • If usage exceeds entitlements (a gap), mark it as a compliance issue. For example, LMS shows 8 CPU cores of WebLogic Enterprise in use, but you have 4 cores licensed – gap of 4 cores.
   • If usage is within entitlements, mark it as compliant (but keep an eye on any conditions, like Named User minimums, etc.).
   • If something is covered under a different product’s restricted license, note that and ensure it truly stays within that allowed use. (E.g., “WebLogic domain X – covered by EBS license, restricted-use – no additional license needed.”)
4. Validate the Counts/Measurements: Oracle LMS outputs often include hardware details (number of CPUs, cores, etc.)​, which are used to calculate license needs. Cross-verify these with your knowledge of the server specs and Oracle’s licensing rules (core factors, etc.). Ensure that the count Oracle might do matches your understanding. For example, if a server has 16 cores of Intel, Oracle will apply a core factor of 0.5 = 8 licenses for Enterprise per server. Have you accounted for that in your entitlements?
5. Document Every Assumption: If you assume a WebLogic is covered by a restricted license (like OEM or EBS), document the basis (e.g., “Domain GCDomain on Server X is Oracle Enterprise Manager – per Oracle, included restricted WebLogic license​”). This is important in case Oracle or an auditor questions it – you can show you’ve not just ignored it but have a justification.

You create a clear picture of compliance by reconciling the LMS findings with entitlements. Often, this process will highlight areas that need action – either technical (disabling a feature) or procurement (purchasing additional licenses). It’s far better that you find these than that Oracle finds them first.

Remember: The LMS output is essentially Oracle’s view of your usage. Oracle expects you to have matching licenses for everything reported. Any discrepancy is where they will press during an audit. Doing this cross-check internally means you can address issues (or prepare explanations) before sending data to Oracle or at least before Oracle finalizes an audit report​.

Best Practices for Reviewing and Documenting LMS Output

Handling LMS script output can be complex, but a methodical approach will make it easier and provide defensible records.

Here are the best practices for SAM managers when analyzing Oracle Middleware LMS data:

• Involve the Right Teams: Engage your middleware administrators early. They can help interpret technical details (e.g., confirming if a certain domain is exclusively for EBS or if a cluster was only used for a test). Collaboration ensures you don’t misidentify something. Also, involve your Oracle licensing specialist or procurement team, which knows your contracts.
• Verify the Output Internally: Always review and verify LMS script outputs internally before sharing with Oracle​. This means:
  • Ensure the output is complete (all relevant servers/domains included).
  • Ensure that no sensitive passwords or data are inadvertently in the logs.
  • Validate that you can reproduce any findings (for instance, if LMS says a feature was used, have the admin confirm from their side).
  • If something looks incorrect or anomalous (e.g., an old domain that was decommissioned but has config still present), make a note of it and consider adding a clarification when reporting to Oracle.
• Organize Data for Clarity: The raw output can be overwhelming. Organize it into a more digestible format:
  • Create a spreadsheet or table listing each Middleware product instance. For example, each row could be: Server – Domain – Product/Component – Version – Key Features (cluster Y/N, etc.) – License Required – License Owned. This summary will help management (and Oracle, if needed) understand the situation at a glance.
  • Group domains by product type (all WebLogic domains together, all OHS installs together, etc.) and by environment (prod, test, etc.) if that matters for licensing (note: Oracle licenses don’t usually distinguish prod vs test except if you have specific agreements).
• Document Findings and Actions: Write a short note on each potential compliance issue you find. For example: “Found WebLogic cluster in DeptX – currently licensed as Standard Edition. Action: Investigate purchasing Enterprise licenses or removing cluster.” Or “SOA Suite components detected on Server Y – no license. Action: Confirm if used; if yes, it needs a license or uninstall if not needed.” This becomes your to-do list and evidence that you’re proactively managing compliance.
• Cross-Reference with Contracts: Keep copies of relevant Oracle agreements or ordering documents on hand and refer to them for any ambiguities. For instance, your Oracle ordering document might explicitly state something like “Includes restricted use WebLogic Basic for EBS only” – quote that if needed to justify not counting that installation against WebLogic licenses.
• Reconciling with Entitlements: As noted, reconcile and record that reconciliation​. This might be another tab in your spreadsheet: what you have vs. what you need if everything aligns, great. If not, decide on remediation (purchase or reconfigure) and document the plan.
• Keep the Output Secure: The LMS output contains detailed info about your systems that could be sensitive (for security or business reasons). Treat it as confidential. Share it internally on a need-to-know basis. If you send it to Oracle (as part of an audit response), do so through approved channels and record exactly what was sent.
• Learn from the Data: The LMS scripts essentially do an internal audit. Use this as a learning exercise:
  • You might discover unused middleware installations (e.g., an old WebLogic install still present on a server). That could be an opportunity to uninstall and reduce risk.
  • Or you find efficiency improvements—e.g., if you have WebLogic domains on several small servers but are licensed by processor, you might consolidate them to use fewer licenses.
  • Identify any historic usage that needs cleanup. Oracle LMS for databases, for example, can find if a feature was enabled in the past​. For middleware, usage data is more current config-based, but if something was left configured (like a cluster not in use), consider removing it to avoid confusion.
• Prepare Explanations for Oracle (if under audit): If you know Oracle will see these outputs, prepare your narrative. For any red-flag item, have an explanation or remediation ready. For instance, if an LMS result shows a cluster and you didn’t have Enterprise licenses, you might plan to tell Oracle, “Yes, we configured a cluster for a one-time test, but it’s not used in production – we have now disabled clustering.” Accompany that with evidence if possible. Oracle’s auditors can be strict, but showing that you’ve done your homework can sometimes lead to a more favorable discussion or at least demonstrate good faith.
• Future Tracking: Consider integrating this analysis into your regular SAM process. The LMS scripts could be run internally periodically (Oracle typically doesn’t allow their exact scripts to be used freely, but you can develop similar checks) to monitor middleware usage. This way, you won’t be caught off guard in the future.

Following these practices creates a solid record of actively managing your Oracle middleware licenses using the LMS data. In an audit scenario, this preparation is invaluable. It helps you correct issues and puts you in a stronger position to discuss and negotiate with Oracle if discrepancies arise.

Do you want to know more about our Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit