Shadow denials

The Shadow License Capping Report provides a detailed view of all license capping events where application usage was restricted based on defined shadow license policies. It tracks each instance of capping with user, system, and application-level details, enabling accurate monitoring and validation of license enforcement behavior. It captures, analyzes, and visualizes shadow license capping events to ensure transparency, compliance, and optimized license utilization.

In the OpenLM Platform this report is the Shadow Denials sheet of the System Monitoring dashboard: open Reporting Dashboard, select System Monitoring, then Shadow Denials.

The Shadow Denials sheet: KPIs for total capping events, successful sessions, and denial rate, followed by top impacted vendors and applications, capping distribution by consumption policy type, time-based trends, denial rate per user, workstation distribution, and the event-level detail table.

KPIs

• Total Capping Events: Total number of shadow denial events recorded.
• Total Successful Sessions: Total number of sessions that were not denied.
• Denial Rate (%): Calculated as (Capping Events / Total Checkout Attempts) x 100, where Total Checkout Attempts = Successful Sessions + Denials.

Visualizations

• Top Impact Analysis: Displays the top impacted vendors and applications based on the number of capping events. This helps identify which software or providers are most affected by license restrictions and may require optimization or policy adjustments.

• Capping Distribution Charts: Visualizes how capping events are distributed across different consumption policy types (such as Process, Workstation, and User at Workstation). This helps identify where enforcement is most frequently applied.

• Time-Series Analysis: Shows the trend of capping events over time, allowing users to detect spikes, recurring patterns, or anomalies in license enforcement behavior across selected periods.

• Denial Rate per User Chart: Represents the percentage of denied sessions for each user, helping identify users who are most impacted by license capping. This is useful for troubleshooting access issues and improving user experience.

• User & Workstation Charts: Provide a comparative view of capping events across users and workstations. These charts help pinpoint specific users or machines that frequently encounter license restrictions.

• Detailed Capping Table: Displays granular, event-level data including user, workstation, application, vendor, policy type, and denial status. This table supports deep analysis, auditing, and validation of individual capping events.

Values displayed:

• Username: The user account for which the license capping was enforced.

• Workstation: The machine or host from which the application was accessed.

• IP Address: The IP address of the workstation at the time of the capping event.

• Capping Timestamp: The exact date and time when the capping action occurred.

• Application Name: The application that triggered the capping event.

• Vendor Name: The software vendor associated with the application.

• Tracking Type: The method used to detect usage (Process, File, or Directory).

• Consumption Policy Type: The level at which the cap was applied (Process, Workstation, or User at Workstation).

• Shadow License Policy: The policy or rule responsible for enforcing the cap.

• Denial Status: Indicates whether the session was denied due to capping.

• Limit: The configured threshold for license usage under the applied policy.

• Filters:

• Date: Users can select a specific time range to analyze capping events.

• User: Users can select specific users to track individual capping behavior.

• Workstation: Users can select any workstation from this filter.

• Application Name: Users can select any application name from this filter.

• Vendor: Users can select any vendor from this filter.

• Tracking Type: Users can filter by usage detection method (Process, File, Directory).

• Consumption Policy Type: Users can filter by how the capping policy is applied.

• Denial Status: Users can filter to view true and false denials.

Interpreting this report

• A shadow denial is OpenLM enforcing your policy - not a license server refusing a license. The Denial Rate is capping events against total checkout attempts, so it measures how often your own limits bind. A rising rate means demand is pressing against a configured cap, not exhaustion of a vendor pool.
• Denial Rate at 0% with a healthy session count means the policies are not binding at current demand - headroom, not malfunction (the default 14-day window often shows exactly this; the history appears when you widen the Date filter).
• Capping distribution by Consumption Policy Type shows where enforcement bites (per process, per workstation, or per user-at-workstation) - if 1 policy type produces nearly all events, that is the limit to revisit first.
• The per-user denial-rate chart separates broad pressure (many users capped occasionally) from a few users hitting limits constantly - the second pattern is a policy-fit conversation with those users, not a capacity problem.

note

Capping events accumulate slowly. Over the default Last 14 days this report often shows zero capping events against a healthy count of successful sessions. Widen the Date filter to see the history. This screenshot uses a 20-year window, which is where the 1,737 capping events and the 1.6% denial rate come from.