Guide to License Denials

Introduction to License Denials

Engineering software is among the most expensive assets in any product development organization. Whether CAD, CAE, CFD, PLM, or EDA, these tools are mission-critical and are often licensed through floating, concurrent, or named-user models.

License denials are a critical aspect of managing engineering software licenses effectively. A denial occurs when an engineer attempts to access a shared license for a tool, but the license server denies the request, typically because all available licenses are in use. While the immediate response might be to purchase additional licenses, this is not always the optimal solution. Instead, organizations should consider several factors to make informed decisions:

Who is getting denied, and how often? Understanding which users face denials and the frequency of these occurrences provides insight into license demand.

What is the probability of denial? Assessing the likelihood of denials helps determine if the current license pool is adequate.

What is the difference between true and false denials? Differentiating between these types ensures accurate analysis of license shortages.

What alerts are useful for monitoring critical conditions? Alerts can notify administrators of denials or nearing capacity limits.

What reports can help analyze denials? Detailed reports provide data to optimize license usage.

This white paper explores these topics to help organizations manage their engineering software licenses efficiently using TeamEDA’s License Asset Manager and Usage Monitoring (LAMUM™) tool.

Understanding License Denials

License denials occur when a user requests a shared license, but the license server cannot fulfill the request, often because all licenses are checked out. In essence, a denial means an engineer cannot access a required software tool, which can delay project timelines and disrupt workflows.

True vs. False Denials

For example, consider an organization with four shared licenses for a specific tool, split evenly between two servers (Server A and Server B). If Server A’s licenses are fully utilized, a user requesting a license from Server A will be denied, even if Server B has an available license. This is recorded as a “false denial” because the user can immediately obtain a license from Server B. A “true denial,” however, occurs when no licenses are available across all servers.

False denials can skew usage data, so an effective denial reporting system must filter them out to focus on true denials, which indicate genuine license shortages. Denials can disrupt workflows, delay projects, and reduce productivity, making it essential to monitor and manage them effectively. LAMUM provides comprehensive oversight by tracking license usage, identifying denials, and alerting administrators to optimize license allocation.

Best Practices for License Management

To manage licenses effectively, prioritize the following tasks based on importance and ease of implementation:

Track inventory of shared license assets by product or bundle.

Maintain vendor information, including contacts.

Monitor license expiration dates.

Track license costs and purchase orders (POs).

Manage contracts and agreements.

Monitor feature checkouts for FLEXlm shared license managers.

Track both shared and standalone (node-locked) license assets.

Monitor executable usage for standalone licenses.

TeamEDA offers data-driven recommendations to address denials without always requiring additional license purchases.

To implement LAMUM, organizations should designate:

An IT person to install LAMUM, set up email alerts, and handle periodic upgrades (occasional task).

A License Asset Manager to track license inventory, contracts, POs, and vendor information (part-time role).

A License Administrator to manage license files, daemons, and create usage and denial reports (full-time role for organizations with over 1,000 users).

Types of Denials

Understanding the types of denials is crucial for effective license management.

Denials can be categorized as follows:

Capacity Reached (True Denial): Occurs when no licenses are available across all servers, indicating a genuine shortage.

Rules Violation: A user is denied access due to restrictions, such as not being authorized to use a license on a specific server.

Spurious Requests: Requests for non-existent features or licenses, which are invalid and should be filtered out.

Repetitious Denials: Repeated license requests from the same user, often caused by scripts that make frequent calls (e.g., every few seconds).

For FlexLM systems, denials are recorded in the Flex Debug Log with unique error codes, such as -4xxx for “Licensed number of users reached.” Filtering out non-essential error codes is critical to focus on true denials.

Key considerations include:

Frequency of true denials.

Speed of resolution.

Elimination of repetitious denials caused by automated scripts.

Cost of purchasing additional licenses versus optimizing existing ones.

LAMUM’s denial analysis tools help organizations detect and eliminate unnecessary denials, improving efficiency and reducing costs.

Denial Setup and Parsing

Accurate denial tracking requires proper setup of debug logs and parsing tools. Denial data is sourced from debug logs for license management systems like FlexLM and DSLS.

Below are the setup requirements and common issues:

FlexLM Setup

Debug Log: Ensure the Flex Debug Log is enabled for each tag and is set to read/write. Verify the log path is valid and at the end of the path string.

Denials Parser: Set up the Flex Denials Parser as outlined in the Flex Denial Parsing AppNote. If the log cannot be parsed, check permissions or firewall settings.

Log Rotation: Implement monthly or quarterly log rotation to manage file sizes. The first parse of a large log may take significant time, but subsequent parses are faster.

DSLS Setup

Debug Log: Enable the DSLS Debug Log for each tag and ensure it is read/write.

Denials Parser: Configure the DSLS Denials Parser per the DSLS Denial Parsing AppNote.

Log Path: Use an absolute path from the LAMUM server to the debug log. Use the “Test” button to validate the path.

Common Issues

Invalid Path: Ensure the debug log name is at the end of the path and accessible.

Permissions/Firewall: Verify that the LAMUM server can access the log file. If not, set up a cron job to copy the log to a local drive.

Large Log Files: For large files, schedule parsing at the end of the day using the “Parse Now” option and let it run overnight.

Parsing Frequency: Configure the time of day and frequency for parsing under Usage/Parsers.

Denial Reports

LAMUM provides various denial reports to analyze usage patterns:

Denials Overview: Summarizes denials with drill-down options for month, week, or day.

Denials by Tag/Feature: Filters denials by specific features or users over a specified period.

Denials Heatmap and Graph: Visualizes denial patterns to identify peak usage times.

Concurrency Graph: Helps assess acceptable denial probabilities (recommended at ~5%).

A 5% denial probability is generally acceptable, indicating efficient license utilization without excessive over-purchasing.

License Utilization Insights

Engineering software licenses are often underutilized. On a 24/7 basis, most licenses are used only 30% of the time, sitting idle for 70%, having more than half capacity of use in place. This presents opportunities to optimize license allocation and improve ROI.

Key questions to address include:

Are engineers holding licenses longer than necessary, leading to hoarding?

Which licenses are being hoarded, and by whom?

Are all purchased tools (CAD, CAE, EDA, PLM) fully utilized?

Can engineers be notified when a license becomes available to reduce wait times?

LAMUM’s usage monitoring dashboard provides real-time insights into license checkouts, heatmaps, and historical utilization data.

This enables organizations to:

Identify and address license hoarding.

Optimize usage patterns across a 24/7 period.

Ensure cost-effectiveness by owning licenses for approximately two-thirds of engineers, accounting for time spent in meetings, vacations, or travel.

LAMUM’s alerts, such as the Available License Alert, notify engineers when a license becomes available, reducing downtime and boosting productivity. By eliminating repetitive scripts and optimizing checkout schedules, organizations can save up to 25% on licensing costs while maintaining high accuracy in reporting.

Alerts for Effective License Management

LAMUM offers eight types of alerts to enhance license management and prevent disruptions:

Daemon-Down Alert: Notifies when the license server daemon (e.g., lmgrd) is down. Set by tag, select email recipients, and configure alert frequency.
Capacity Threshold Alert: Triggers when license usage reaches or nears capacity (e.g., 8 out of 10 licenses checked out). Set by tag/feature and specify recipients.
Expiration Alert (LAM/Renewal Date): Alerts 60 days before license expiration. Requires manual entry of expiry dates and email server setup.
License File Expiration Alert (UM): Reads expiration dates from port@host and alerts based on a warning period set by tag/user.
Long Checkout Alert: Targets licenses held longer than average (consult the “Averages” report). Sends warnings to users via Active Directory (AD)-connected email addresses.
Duplicate License Alert: Notifies when a user checks out the same license on multiple workstations, set for critical or limited licenses.
Available License Alert: Informs engineers when a license becomes available, reducing manual retries. Must be deleted after use to avoid repetitive alerts.
Denial Threshold Alert: Triggers when denials exceed a threshold (e.g., 8 denials per week). Requires Flex Denial Parser setup and specifies recipients and frequency.

Each alert requires proper configuration, including email addresses in user info, alert frequency, and AD integration for user notifications. Alerts for high-demand or expensive licenses help prevent hoarding and ensure optimal usage.

Routine Reporting for License Optimization

LAMUM provides routine reports (weekly, monthly, quarterly, yearly) to monitor license usage and denials. Reports can be delivered via email (requires mail server setup) or to designated folders on the LAMUM server.

Key report types include:

Graph Batch Reports: Generated from graphs using the “Create Batch Report” button.

Table Batch Reports: Created from the dropdown next to the Submit button.

Denial Reports: Include Denials Overview, Denials by Tag/Feature, Denials by Users, Heatmaps, and Graphs.

Report Delivery Schedule

Weekly: Last 7 days, delivered on Monday.

Monthly: Last 30 days, delivered on the 1st day of the month.

Quarterly: Last 90 days, delivered on the 1st day of the quarter.

Yearly: Last 365 days, delivered on January 1st.

Best Practices

Meet with management to select relevant reports, time periods, and delivery methods.

Use consistent, user-friendly report names (e.g., Feature/Tag, Time Period, Graph or Table).

Avoid special characters in report names, allowing spaces or hyphens.

Implement dashboards with current checkout status and heatmaps for key applications.

Set up Long Checkout Alerts to address hoarding.

Optimize license usage by eliminating repetitive scripts and analyzing 24/7 usage patterns.

Consider purchasing additional licenses only after data-driven analysis.

About TeamEDA, Inc.

TeamEDA, Inc., headquartered in Derry, NH, specializes in integrated software licensing management for engineering applications. LAMUM™, a best-in-class tool, combines License Asset Manager and Usage Monitoring to provide comprehensive oversight of engineering software assets. With years of specialist experience, TeamEDA delivers fast implementation, 100% accurate reporting, and significant cost savings. Learn more at teameda.com.