- A license denial has three possible causes – a genuine shortage, a seat checked out and left idle, or a server that failed to hand anything out – and only one of them means buy.
- Licensing teams call the split true and false denials. Telling them apart takes two views of the same moment, not a bigger license pool.
- Mitta Oy’s denials came from a faulty license server and, in some cases, a missing server line or hostname in the license file, so the previous team had been buying licenses to fix a server fault.
Four denial emails before nine on a Monday: two geoscientists locked out of Petrel, a reservoir lead asking why there are no tNavigator seats, and a request that failed at 10:42 with nothing to say why. The log records a refusal. It does not record a reason, and the reason decides everything – whether the right response is a purchase order or a service ticket, and whether the money spent this year buys capacity or covers up a fault.
The licenses kept getting declined, so the team bought more. With no usage data, buying was the only lever they had.
The server was broken. Mitta Oy, a Finnish consultancy to the construction industry, found that out after replacing its license server and putting usage monitoring behind it. The denials were not coming from heavy demand. They were coming from a faulty server that could not hand out licenses, and in some cases from a missing server line or hostname in the license file. The company had been buying licenses to fix a server fault.
Different industry, same mistake, and on a petrotechnical estate that mistake costs a great deal more per seat. Five questions decide whether the tool you buy next can tell you which mistake you are making.
1. Is it a shortage, a held module, or a broken server?
A denial says a request failed at 10:42. It does not say why. There are three answers, they lead to three different actions, and only one of them is a purchase.
The industry shorthand for this is true and false denials. A true denial is a request that failed because the seat was genuinely gone. A false denial is a request that failed while the pool had something left to give – held idle, or never handed out at all. Almost every denial a licensing desk sees is filed as the first kind, because the log gives no way to tell.
| What the data shows | What it means | What to do |
|---|---|---|
| Denials, and every license genuinely in use | A real capacity shortage – a true denial | Buy |
| Denials, licenses checked out but sitting idle | The pool is fine. The pattern is not | Reclaim the idle time |
| Denials while licenses sit free | Not capacity at all – the server or the license file | Fix the infrastructure, do not buy |
The third row is the one you cannot see with a single view. Denial Reports tell you a request failed and who was blocked. The real-time License Monitor Portal tells you a seat was free at that moment. The mismatch between those two is the signal. Mitta runs on that live view rather than email alerts, because at their volume the dashboard is enough.
Then the fix, which is a server job and not a purchase. CLIMS gives you vendor daemon status, console output and debug logs in a browser instead of an RDP session per server, license file view and edit, semantic comparison to catch the line that went missing, and triad detection for a three-server high-availability set.
Once Mitta could see actual use, one application had been sized for 130 concurrent licenses against an observed peak of about 30 users, and right-sizing it alone was put at €30,000 to €40,000 a year. Their Autodesk count came down by as much as half with no effect on productivity. Thin pools make the diagnosis harder, not easier: two expensive licenses shared between four people means a single held seat is somebody’s denial. Marko Ukkola, then Mitta’s IT Director, recommends usage monitoring for exactly this reason – it helps, in his words, “in uncovering unstable license servers”.
Take the middle case, where the licenses are checked out and idle. Petrel makes it structural: seventy-plus individually licensable modules, a slow start-up, and a workforce that has been denied before, so people reserve what they might need rather than what they are about to use. Module hoarding is rational from the desk it happens at. Across engineering estates the idle share of checked-out time typically runs 20% to 40%, which is enough to change a purchase decision on its own.
Seeing that takes two kinds of measurement, and Open iT sells them as tiers. The first reads your license server logs: who was denied and when, which seats were checked out with nobody at the keyboard, and which borrowed licenses stayed out after the work stopped. It polls the license managers hourly and samples every five minutes. The second goes onto the machine itself and measures whether a checked-out seat is actually being worked in, which is what produces the Work Ratio Report: active time against total checkout time, for each application and each module.
Only the first case, a genuine shortage, ends in a purchase. It is also the one everybody assumes they are looking at.
2. Which of your license managers would it actually see?
FlexNet is the one that matters first, because it is what Petrel runs on. Eighty applications and seven server types is a normal petrotechnical estate, and the portfolio usually lives in a shared spreadsheet.
Open iT’s LicenseAnalyzer™ reads the manager that hands out the seat, which is how it reaches more than 6,000 applications across 90-plus managers: cover FlexNet and Petrel comes with it.
| What you get out | Which managers give it |
|---|---|
| Concurrent use, elapsed time, and a live view of who holds what | tNavigator, Petroleum Experts (PetEx), DUG Insight, Seequent, Itasca, Geoactive, Esri Cloud |
| Denials: who was refused, and when | FlexNet, and therefore Petrel, plus Encom, Fekete, Peloton and Zetaware |
| History only, from log files, with no live view | Zetaware |
| Handing an idle seat back to the pool automatically instead of just reporting it | FlexLM, LM-X, LUM and RLM |
| One console for start, stop, options files and expiry dates | 12 LMs CLIMS administers, PetEx and tNavigator among them |
3. Who does the work, before and after go-live?
Go-live is where tools become somebody’s side project. Training slips, nobody owns the reports, the dashboard is still on the roadmap a year later, and usage data goes back to being a request that takes days.
So ask any vendor what the first month looks like, and what arrives in writing at the end of each step. Ours runs in five.
- Kick-off and planning. Before anything is installed: hardware, software and network prerequisites checked against a readiness list, scope and timeline agreed with your stakeholders, minutes and actions written down. This is where you find out whether the footprint below is a problem for you, and you find out with us rather than after the purchase order.
- Technical setup and integration. Core Server and Analysis Server installed and configured, then connectivity and data collection verified, with an installation report. Clients deployed to the workstations you designate, configured to your requirements, client-server communication verified, summary supplied. The verification is the part that matters, because it is where you confirm that the numbers you are about to make decisions on are arriving.
- Training and knowledge transfer. Sessions for the people who will run it and the people who will read the reports, with manuals and guides, and attendance recorded so you know who has actually been trained. Four-day public courses exist separately if you want more depth: Engineering Software Reporting & Analysis on 1–4 September 2026 and Engineering Software Administration & Optimization on 8–11 September 2026, both online.
- Optimization and use case development. Where the reports get pointed at your questions rather than the ones in the demo – which report goes to Finance, which threshold is worth an alert, which ten applications get measured before the other seventy.
- Ongoing support and partnership. A completion report, documentation and named support contacts handed over, and the lessons learned written down. Then the part that runs for years.
What you would be running is ordinary. Windows Server 2016 or later, SQL Server with Analysis Services, IIS and .NET, a service account and an application pool, plus Core Client on the host machines with admin rights to install it. Not a cluster. It is the stack your Windows and SQL person already runs, which is the point, and v10.2 added full Azure SQL Server support, so it moves when the rest of IT moves.
For the years after that, the answer that matters is not a support tier. It is where the mapping lives.
Vendors rename and repackage features, and somebody has to keep the map between a license feature and the thing you bought – acute when one application carries seventy modules across commercial, third-party and in-house code. Open iT configures that mapping as part of maintenance and support and keeps it in SSAD, centrally, rather than re-coded in each customer’s environment. Nobody on your side maintains it.
Beyond that, work can sit with us instead of a headcount you do not have. Everything in this table is bought separately, as a package or item by item.
| Licensing work that can move to Open iT | What it covers |
|---|---|
| Ongoing installations and configurations, after the initial deployment | Managed services |
| The custom dashboard nobody had time to build | Custom reporting and dashboard development |
| Reading usage against contracts before a renewal | Vendor analysis and negotiation support |
| Noticing drift before it becomes an incident | Quarterly health checks |
| Day-to-day problems across time zones | Global technical support |
Reporting comes out through Excel, Power BI, Tableau and native SSRS, and LicensePlanner™ allocates cost by actual usage rather than headcount.
Support, in this situation, does not mean somebody answers the phone. It means the work never reaches the desk.
4. What happens to a session at 3am?
This is the well operations question, and it can end the conversation. The objection is rarely about losing work, since autosave handles that. It is about re-access: logging back in, picking modules again, loading data, rebuilding the view, at the moment a decision is waiting.
Scale decides the remedy. At Mitta the fix for a held seat is a phone call – you can see who has it and where, so you ask them to release it for a few hours. Across several hundred Petrel users in three time zones, a phone call is not a plan.
With Open iT you can reclaim an idle session four ways – log, standby, suspend, terminate – across four rule priority levels, with time-of-day and day-of-week conditions, so a 3am well operations window is excluded by rule rather than by trust. Suspend is the one that matters. The license goes back in the pool and the work stays on the screen, with a pre-built autosave script shipped for Petrel. Reopening Petrel costs an engineer 20 to 30 minutes, which is why suspend beats terminate.
Terminate exists. Whether it is ever switched on is your call, not ours.
5. What will your works council and security team need to hear?
The measurement that goes onto the machine is where this gets decided. To tell an idle session from an active one it puts lightweight collectors on the host machines, and those collectors measure CPU, I/O, keystrokes and mouse interaction. In most energy organizations that sentence has to survive a works council, an ethics policy, or both, and it should.
So the controls are built for that meeting rather than for a datasheet. Usernames can be anonymized, reversibly or irreversibly. Access is controlled by role, and separately at the OLAP cube’s own data level, so what a report shows depends on who opened it. Trend analysis that never names an individual is the normal way to run this, and it is the difference between a measurement programme that launches and one that stalls in review.
Three answers to a denial, and only one of them is buying. The data is what tells them apart. Support is what keeps that data arriving when the person who set it up is on leave.
Get Open iT
Ask for the split first: which of your license managers would be managed, which monitored, which historical only, which neither.
