Oracle Middleware Licensing

Analyzing Oracle Middleware with the LMS Collection Tool

A practical guide for SAM managers to interpret LMS script output for WebLogic Server, SOA Suite, BI Publisher, and other Fusion Middleware components — with step-by-step analysis, red flag identification, and compliance documentation best practices.

Practical GuideOracle MiddlewareFredrik FilipssonNovember 2025
🏠 Oracle Knowledge HubOracle Audit DefenseAnalyzing ORACLE Middleware with the LMS Collection ...
8+
Middleware Products Captured by LMS
4
WebLogic Editions (Basic → Suite)
0.5
Intel Core Factor for License Calculation
10
Min NUP Licenses Per Processor

📋 Executive Summary

Oracle's License Management Services (LMS) Collection Tool captures detailed information about Oracle Middleware usage — WebLogic Server domains, SOA Suite deployments, BI Publisher installations, and more. For SAM and IT asset managers, understanding this output is crucial for license compliance.

This guide provides a step-by-step approach to analyzing the LMS middleware data: what the scripts collect, how to interpret key output files, how to determine WebLogic editions from feature usage, how to distinguish restricted-use from full-use deployments, and how to cross-check findings against your license entitlements.

Read our complete guide to Oracle Fusion Middleware Licensing.

📚 This article is part of:
📖 Read our Oracle Audit Defense guide🏠 Back to Oracle Knowledge Hub

📑 Table of Contents

  1. Middleware Products Captured by LMS
  2. How the LMS Script Collects Middleware Data
  3. Key Output Files & What They Reveal
  4. Interpreting WebLogic WLST Output: Editions, Features & Domains
  5. Restricted-Use vs Full-Use Deployments
  6. Common Red Flags in Middleware LMS Output
  7. Cross-Checking Findings with License Entitlements
  8. Best Practices for Reviewing & Documenting LMS Output
  9. Frequently Asked Questions

1. 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:

ProductDescriptionLicense Implication
Oracle WebLogic ServerCore Java EE application server (Basic, Standard, Enterprise, Suite editions)Edition determines features allowed; clustering = Enterprise+
Oracle SOA SuiteService-Oriented Architecture platform — BPEL, Oracle Service Bus, BPMSeparate license required; runs on WebLogic Suite
Oracle Business IntelligenceOBIEE / Oracle Analytics Server, BI PublisherSeparate license; check if covered by bundled product
Oracle WebCenterPortal and content management middlewareSeparately licensable product
Oracle Forms & ReportsLegacy middleware for forms-based applicationsIncludes restricted-use WebLogic Basic
Oracle Internet Application Server (iAS)Legacy app server components (now realized through WebLogic)Often bundled with EBS; restricted-use terms
Oracle TuxedoMiddleware for COBOL/C/C++ applicationsSeparate license if present in environment
Java SEJava runtime usage on serversRequires subscription for commercial use since 2019
Expert Insight

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. If it's installed or configured, the script will find it.

2. How the LMS Script Collects Middleware Data

The LMS Collection Tool combines scripts and utilities to extract configuration and usage data from middleware installations. Understanding the collection mechanism helps you interpret the output more accurately.

⚙️ Script Execution

+

Oracle provides middleware LMS scripts (often in a ZIP file) to run on each relevant server. 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.

Key Point: The scripts are designed not to modify the environment — they are read-only and have minimal performance impact. Oracle often assures customers of this, though it's wise to run them in a maintenance window.

⚙️ WLST Scripts for WebLogic

+

The tool leverages the WebLogic Scripting Tool (WLST) — a Jython-based interface — to query WebLogic domain information. A WLST script (often run offline) reads each WebLogic domain's configuration to list the domain name, servers, clusters, deployments, and services.

Key Point: By automating WLST commands, the LMS script gathers application server domain configurations and deployments without requiring manual input. It captures a complete snapshot of your middleware setup.

⚙️ 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 file system paths)
config.xml (per domain) — Main configuration file containing servers, clusters, JMS, deployed applications
registry.xml — Oracle Universal Installer inventory listing all installed middleware products and components
• Product-specific configs if present (e.g., opmn.xml for Oracle HTTP Server, portalconfig.xml for WebCenter)

Key Point: The LMS script copies these files because they reveal which components and features are in use. For example, registry.xml shows if SOA Suite or WebCenter binaries are installed — even if not actively running.

⚙️ System & Process Scans

+

The script may also scan the file system and running processes to ensure it captures all instances:

File scans — Searches for known middleware installation directories and files (WebLogic install dirs, ORACLE_HOME paths, etc.)
Process scans — Checks running processes for Oracle middleware (e.g., Java processes running WebLogic). This differentiates between installed-but-unused software and actively running servers.

Key Point: The output files (often consolidated into a ZIP archive) may include raw text, CSV, or XML files with the collected data. All are packaged for analysis by Oracle's auditors — or by you, proactively.

3. Key Output Files & What They Reveal

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

Output FileWhat It ContainsLicense Implication
registry.xml
(Oracle Inventory)
Lists all Oracle Fusion Middleware components installed on the server — product names, internal codes, versionsReveals which products are installed. If SOA Suite or BI Publisher appears without a license, investigate immediately.
domain-registry.xmlLists all WebLogic domains registered with the WebLogic installation (with file system paths)Ensures no WebLogic domain is overlooked. Each domain path should have a corresponding config analysis.
config.xml
(per domain)
Core domain configuration: domain name, version, servers (Admin + Managed), clusters, JMS, data sources, security, deployed applicationsShows how WebLogic is being used — single server vs cluster, enterprise features enabled, Oracle apps deployed. Primary file for edition determination.
WLST Output ReportsPre-formatted text/CSV reports listing each domain, server instances, clustering status, JMS, version, and deployed appsSimplified analysis view. May show: "Domain ProdDomain has 1 AdminServer and 4 Managed Servers in cluster ProdCluster."
Other Config FilesSOA composite info, httpd.conf / opmn.xml (OHS), BI config files, FMW Control deployment dataConfirms active use of SOA Suite, OHS, BI Publisher, etc. — not just installation but actual deployment and configuration.
⚠️ Tip — Focus on License Implications

The LMS output is very detailed — it captures not only what is installed, but how it's configured and what's running. As a SAM manager, focus on the parts that have license implications: features and components in use, clustering status, deployed Oracle applications, and server counts.

Read Interpreting Oracle LMS Database Script Output.

4. Interpreting WebLogic WLST Output: Editions, Features & Domains

One of the most important tasks is determining which WebLogic edition is in use in each environment and which features are enabled. Oracle WebLogic Server has multiple editions (Basic, Standard, Enterprise, and Suite), and the LMS data indicates usage patterns. Oracle does not explicitly label "This is Standard Edition" in the config — you infer it from features.

Edition-Determining Feature Matrix

Feature / IndicatorStandardEnterpriseSuiteHow to Detect in LMS Output
Single-server domain (no cluster)No <cluster> entries in config.xml
Clustering enabled<cluster name="..."> in config.xml or Managed Servers with cluster references
Distributed JMS (across cluster)<distributed-topic> or <distributed-queue> spanning servers
Whole Server MigrationMigration configuration for migratable targets in domain config
Production Redeployment (versioned)Two versions of an app deployed for zero-downtime updates
Oracle CoherenceCoherence cluster configuration or Coherence library deployed in domain/inventory
Basic JMS (single server)JMS configured on single server — not a differentiator
Critical Alert — Clustering = Enterprise or Higher

If the domain config shows a cluster (multiple WebLogic instances clustered together), Enterprise Edition features are in use. WebLogic Standard Edition does not support clustering. If LMS shows clustering and your records show only Standard Edition licenses purchased, you have a compliance gap. This is the single most common middleware compliance issue.

Identifying Domain Purpose

Beyond edition detection, identify whether the WebLogic domain is hosting Oracle middleware suites or products:

🔍 SOA Suite Domain

+

A domain containing SOA Suite components will show deployments or services like soa-infra, BAM, or OracleServiceBus in the domain config or WLST output. This means Oracle SOA Suite is installed on top of WebLogic — a separate licensable product.

Action: If SOA Suite components appear, verify you have SOA Suite licenses for the corresponding processor count. SOA Suite also requires WebLogic Suite as the underlying platform.

🔍 BI Publisher / Analytics Domain

+

A BI domain might show deployments like analytics, BI_Publisher, or BI-specific JMS and data sources. This indicates Oracle BI is running on WebLogic.

Action: Clarify the source — BI Publisher may be included with certain products (e.g., EBS includes a restricted-use XML Publisher). If it's standalone, verify you have BI licenses.

🔍 Oracle Forms & Reports Domain

+

Identified by applications like formsapp or configurations for Forms. The Forms license includes a restricted-use WebLogic Basic.

Action: Ensure the WebLogic domain is used only for Forms/Reports. Any custom applications deployed alongside violate the restricted-use terms.

🔍 Enterprise Manager Domain

+

The OEM WebLogic domain is often named GCDomain and runs the EMGC (Enterprise Manager Grid Control) application. This includes a restricted-use WebLogic license.

Action: No separate WebLogic license is required as long as it's only used for OEM — even clustering OEM is permitted under that restricted license for high availability.

📋 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 domain is clustered — hence not Basic or Standard. Oracle would consider this an Enterprise Edition deployment. If your records show only WebLogic Standard licenses purchased, you have a compliance gap.

Conversely, a single-server domain with no cluster could fit Standard (assuming no other enterprise-only features are flagged).

🛡️ Facing an Oracle middleware audit? Our independent advisors specialize in LMS output analysis and audit defense.

Audit Defense →

5. 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.

Bundled ProductWebLogic License IncludedHow to Identify in LMSRestrictions
Oracle E-Business Suite (EBS)WebLogic Basic (via iAS EE license)Domain name like EBS_domain; EBS-specific applications deployedOnly for EBS components. No custom applications. No advanced features.
Oracle Enterprise Manager (OEM)Restricted-use WebLogicDomain named GCDomain; EMGC application deployedOnly for OEM console. Clustering for HA is permitted.
PeopleSoftRestricted WebLogic / TuxedoPeopleSoft-specific domain and applicationsOnly for PeopleSoft app server components.
Hyperion / EPMRestricted WebLogicHyperion services (Essbase, etc.) deployed on domainOnly for Hyperion — cannot be used beyond EPM.
OBIEE / OASRestricted WebLogic for BI systemBI-specific deployments and configurationsOnly for hosting the BI system.
Oracle Forms & ReportsWebLogic BasicForms-specific applications and configOnly for Forms/Reports. No custom Java apps.
Critical Alert — Restricted-Use Violations

Oracle's restricted license terms explicitly state that WebLogic Basic can only be used for running the components of the product it came with — not for any other purpose. Deploying a custom Java application on an EBS WebLogic domain, or running non-OEM apps on a GCDomain, violates the license and creates compliance exposure.

Expert Insight

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 compliance with its restrictions. If it's full-use, ensure you have the appropriate WebLogic edition licensed.

6. Common Red Flags in Middleware LMS Output

When reviewing LMS data, be on the lookout for these common compliance red flags. Oracle uses these scripts specifically to identify usage of Oracle software beyond what you have legally licensed — spotting them yourself lets you address issues proactively.

🚩 Enterprise Features on Standard License

Clustering, distributed JMS, Whole Server Migration, or production redeployment features detected — but only Standard Edition licensed. This is the most common and most expensive red flag.

🚩 Unlicensed Middleware Components

SOA Suite, Oracle Service Bus, BPM, or WebCenter components active in registry.xml or domain config without corresponding licenses. Even "installed but unused" binaries are a flag.

🚩 WebLogic Beyond Licensed Processors

WebLogic instances running on servers or cores beyond your licensed processor count. An extra environment spun up for testing without licenses creates exposure.

🚩 WebLogic Basic Used Beyond Scope

Non-EBS applications deployed on an EBS WebLogic domain, or any similar cross-usage of restricted-use WebLogic for custom applications.

🚩 Standalone BI Publisher Unaccounted For

BI Publisher running standalone on WebLogic without a clear license source. Verify whether it's included with another suite you own or requires a separate BI license.

🚩 Oracle Coherence Without Suite License

Coherence data grid deployed or configured in a WebLogic domain. Coherence is included only with WebLogic Suite — Enterprise Edition does not grant Coherence usage beyond basic internal cache.

🚩 Java SE Without Subscription

Oracle JDK on servers with no Java subscription. Since 2019, Oracle Java SE requires a commercial subscription. LMS often flags Java installations alongside middleware.

🚩 Features Enabled "for Testing"

Even if a feature was enabled unknowingly (an admin turned on clustering or SOA Suite for testing), the script records it and Oracle will consider it a licensing requirement. "We only tested it" is rarely accepted as a defense.

⚠️ Warning — Oracle's View

Oracle uses these scripts specifically to flush out usage beyond what you have legally licensed. Even if a feature was enabled unknowingly, the script records it. Your job is to catch these and either remediate or be prepared to defend them — before Oracle finds them first.

7. Cross-Checking Findings with License Entitlements

Once you've extracted key information from the LMS output, cross-check it against your organization's license entitlements (contracts, purchase records).

📋 Entitlement Reconciliation Process

  1. Inventory your entitlements — List Oracle middleware licenses you own: product name, edition, version, quantity (processors or NUP), and any restrictions. Include bundled/restricted-use rights from other Oracle products.
  2. Map LMS findings to products — Take each component from LMS data and map it. WebLogic domain with clustering → WebLogic Enterprise Edition. SOA Suite components → Oracle SOA Suite licenses. OHS installation → iAS license (or covered by EBS/WebLogic Suite).
  3. Identify gaps or surpluses — If usage exceeds entitlements (e.g., 8 cores in use but only 4 licensed), mark as compliance issue. If covered under a restricted license, note that and ensure restrictions are met.
  4. Validate counts and measurements — Cross-verify hardware details (CPUs, cores) with Oracle's licensing rules and core factors. For example, 16 Intel cores × 0.5 core factor = 8 processor licenses required.
  5. Document every assumption — If you assume a WebLogic domain is covered by a restricted license (like OEM or EBS), document the basis. This is critical if Oracle or an auditor questions it later.
Expert Insight

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 before Oracle finalizes an audit report. It's far better that you find these than that Oracle finds them first.

8. Best Practices for Reviewing & Documenting LMS Output

Handling LMS script output can be complex, but a methodical approach makes it manageable and provides defensible records.

📋 SAM Manager Best Practices

  1. Involve the right teams — Engage middleware administrators early. They can confirm whether a domain is exclusively for EBS, whether a cluster was used only for testing, etc. Also involve your Oracle licensing specialist or procurement team.
  2. Verify output internally before sharing with Oracle — Ensure the output is complete (all servers/domains included), no sensitive passwords are logged, and you can reproduce any findings. If something looks incorrect (e.g., a decommissioned domain still showing config), note it.
  3. Organize data for clarity — Create a spreadsheet listing each Middleware instance: Server – Domain – Product/Component – Version – Key Features (cluster Y/N) – License Required – License Owned. Group domains by product type and environment.
  4. Document findings and actions — Write a short note on each potential compliance issue. Example: "Found WebLogic cluster in DeptX — currently licensed as Standard Edition. Action: Investigate purchasing Enterprise licenses or removing the cluster."
  5. Cross-reference with contracts — Keep copies of relevant Oracle agreements and ordering documents on hand. Your ordering document might state "Includes restricted use WebLogic Basic for EBS only" — quote that if needed.
  6. Keep the output secure — LMS output contains detailed system info that could be sensitive. Treat as confidential. If sending to Oracle (as part of an audit response), record exactly what was sent.
  7. Learn from the data — Discover unused middleware installations (opportunity to uninstall and reduce risk), consolidation opportunities (fewer servers = fewer licenses), and historic configurations that need cleanup.
  8. Prepare explanations for Oracle — For any red-flag item, have an explanation or remediation ready. Example: "We configured a cluster for a one-time test, but it's not used in production — we have now disabled clustering." Accompany with evidence.
📋 Example — Organized Analysis Worksheet

A well-organized reconciliation spreadsheet might have these columns:

ServerDomain NameProduct/ComponentVersionClustered?Enterprise Features?Restricted-Use?License RequiredLicense OwnedGap/SurplusAction Required

This summary helps management — and Oracle, if needed — understand the situation at a glance. It also becomes your to-do list and evidence that you're proactively managing compliance.

Frequently Asked Questions

Does the LMS script modify anything on our servers?+
No. The LMS scripts are designed to be read-only — they read configurations and output data without modifying the environment. Oracle assures customers they have minimal performance impact, though it's wise to run them in a maintenance window as a precaution.
How do I determine if a WebLogic domain requires Standard or Enterprise licensing?+
Check the domain's config.xml for clustering, distributed JMS, Whole Server Migration, or production redeployment. Any of these features require Enterprise Edition or higher. If the domain has a single server with no clusters or enterprise-only features, it can run on Standard Edition. Note that Standard Edition is licensed per physical socket, while Enterprise is licensed per core (with core factor).
Is WebLogic bundled with EBS the same as a full WebLogic license?+
No. EBS includes a "restricted-use" WebLogic Basic license that can only be used for running EBS components. You cannot deploy custom applications on this WebLogic instance. If you need WebLogic for anything beyond EBS, you must purchase a separate full-use WebLogic license (Standard, Enterprise, or Suite) and deploy on a separate domain.
What if SOA Suite components are installed but not actively used?+
Oracle's position is typically that installed software requires licensing, regardless of active use. However, if you can demonstrate that SOA Suite binaries were installed but never configured, deployed, or used (no SOA composites, no services running), you may have a defensible position. The safest approach is to uninstall unused components before an audit. If they appear in LMS output, be prepared to explain and provide evidence.
Should we review LMS output internally before sharing with Oracle?+
Absolutely. Always review and verify LMS script outputs internally before sharing with Oracle. This ensures completeness, allows you to catch and remediate issues proactively, and lets you prepare explanations for any anomalies. You'll be in a much stronger negotiating position if you've already identified and addressed compliance gaps before Oracle raises them.

Related Oracle Middleware Articles

Oracle Advisory Services

📊

License Management

🛡️

Audit Defense

📝

Contract Negotiation

📅

Book a Meeting

📄 Download Our Oracle Licensing White Papers

In-depth guides on Oracle middleware licensing, audit defense, and compliance best practices.

View White Papers →

Need Help Analyzing Your Oracle Middleware Compliance?

Our team of former Oracle insiders can review your LMS output, identify compliance gaps, and build a defensible position — before Oracle does.

FF

Fredrik Filipsson

Co-Founder, Redress Compliance

Fredrik Filipsson brings 20+ years of enterprise software licensing expertise, including experience working directly for IBM, SAP, and Oracle. He has helped hundreds of organizations — including numerous Fortune 500 companies — optimize costs, avoid compliance risks, and secure favorable terms with major software vendors.

📚 Continue exploring:
📖 Read our Oracle Audit Defense guide🏠 Back to Oracle Knowledge Hub