EngineeringMechanical EngineeringLicensing
SOLIDWORKS Network Licence Administration
Once network licensing is in place, a small service on a server governs whether the entire engineering function can work. Out of the box it does almost nothing to manage that pool — every control is opt-in, and the difference between a default installation and a configured one is typically several effective seats.
- Group · Licensing
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 19 min
01 The Licence Manager as Production Infrastructure
Once network licensing is in place, a small service on a server governs whether the entire engineering function can work. It deserves the operational treatment that status implies, and it rarely receives it.
The licence manager is built on a widely used commercial licensing framework. That has a useful consequence: the control mechanisms are mature and well documented, and the administrative vocabulary — reservations, exclusions, timeouts, borrowing, report logging — carries across from other products using the same framework. A comprehensive administration guide for the underlying framework is installed alongside the service, and is the authoritative reference for the full keyword set.
Out of the box, the service does none of this. It holds a pool and issues entitlements on a first-come basis with generous idle handling. Every control described here is opt-in, and the difference between a default installation and a configured one is typically several effective seats.
Default installation paths, port numbers and the exact keyword set vary by release and by the version of the underlying licensing framework. Verify against the administration guide installed with your licence manager and the current vendor documentation before applying any configuration described here.
02 Server Placement & Network Access
Where it should live
- An always-on server. Co-hosting on an existing production server is fine; the service is lightweight. Hosting on a workstation is not, because it will be rebooted without reference to who is working.
- Inside change control. Any reboot, patch or firewall change affecting the host affects the whole engineering function. It should appear on the same change calendar as any other production service.
- Reachable by every client. Including remote sites, virtualised workstations and anyone connecting over a remote access link.
- Monitored. Service availability should be alerted on, not discovered by a queue of engineers.
Ports and firewall
Communication uses two ports: one for the licence manager itself and one for the vendor daemon that serves the specific product entitlements. Both must be open inbound on the server and outbound from clients. Clients address the server in a port-and-host form, so the port is part of the client configuration and not merely a firewall concern.
Blocked ports account for a disproportionate share of "no licence available" reports. The symptom is indistinguishable from an exhausted pool from the user's perspective, which sends the investigation in the wrong direction. Before examining pool utilisation, confirm the client can actually reach both ports on the server. A firewall policy change or a network segmentation project is frequently the underlying trigger, and neither will have been flagged to engineering.
Client configuration
Clients are pointed at the server in the deployment image, so the address is set once and applied uniformly. Where the licence server later moves or is renamed, existing clients need separate correction — updating the image alone does not reconfigure machines already installed. Plan a server move as a change affecting every client, not just the server.
03 The Options File
A plain text file that turns an undifferentiated pool into a managed resource. It does not exist by default; creating it is the single highest-value configuration action available.
How it is applied
Windows account names for every user, the group structure you intend to control by, and a list of every product served.
A plain text file created in any editor, using the framework's keyword syntax, one directive per line.
Saved with the expected name into the licences folder of the licence manager installation on the server.
Enable the options file in the server administration interface and reactivate so the service reads it.
Confirm reservations hold and exclusions bite by testing with an affected account, not by inspecting the file.
Keep the file under change control with a comment header recording who changed what and when.
Directives operate on the account name used to log on to Windows, not on a person's display name or email address. Building the file from a staff list rather than from account names produces directives that silently do nothing — the file loads without error and the rules simply never match. Verify by testing with an affected account before considering the change complete.
Control categories
| Category | Effect | Typical use |
|---|---|---|
| Grouping | Defines named collections of users or machines that other directives operate on | Establish groups by team or role before writing any rule; makes the file maintainable |
| Inclusion | Restricts a product so that only listed users or groups may use it | Confine a specialist product to the team entitled to it |
| Exclusion | Prevents listed users or groups from using a product | Stop occasional users drawing premium tiers needed by full-time designers |
| Reservation | Holds a stated number of entitlements exclusively for a user or group | Guarantee availability for a role that must never be blocked |
| Borrowing control | Permits or prevents borrowing, per product and per user or group | Prevent a borrowed entitlement leaving a small pool for weeks |
| Idle timeout | Returns an entitlement to the pool after a period of inactivity | The most effective single capacity control available |
| Limits | Caps the number of entitlements a user or group may hold | Prevent one team absorbing a shared pool |
| Report logging | Produces a usage log suitable for analysis | The evidence base for every sizing decision |
04 Idle Reclaim
The control with the largest effect on effective capacity, and the one most often left at its default.
By default an inactive session holds its entitlement for a substantial period — long enough that a machine left running over lunch, or an application left open overnight, continues to occupy the pool. The timeout is adjustable within a bounded range, and shortening it converts directly into availability.
The default idle handling commonly applies to the base entitlement and not to add-in products. That is precisely the wrong way round for capacity: add-in pools are usually smaller and add-in use is usually more intermittent. Set the timeout explicitly per product so it covers add-ins as well, and confirm by observing the log rather than assuming.
Choosing a value
- Too long and the control does nothing — sessions left open all day continue to hold entitlements.
- Too short and engineers are interrupted during genuine thinking time or while working in another application on the same task.
- A workable starting point is somewhere between thirty and sixty minutes for base entitlements, and shorter for premium add-ins where the pool is small and use is genuinely intermittent.
- Communicate it. An engineer whose session is reclaimed without warning will report it as a fault. Explain the behaviour, and note that unsaved work is prompted for before release.
After setting a timeout, look at the reclaim events in the usage log. A healthy configuration reclaims steadily through the day with few complaints. Frequent reclaims immediately followed by the same user reacquiring the entitlement means the value is too short for how that team actually works — adjust it rather than reverting the control entirely.
05 Borrowing Policy
Borrowing takes an entitlement off the network for a defined period so an engineer can work disconnected. It is genuinely useful and, left ungoverned, is the fastest way to exhaust a small pool.
A borrowed entitlement is removed from the pool for its full term, whether or not it is being used. It returns automatically at the end of the borrowing period, and can be returned early — but only from the same network connection used to borrow it, which catches out engineers who borrow on a wired connection and attempt to return over wireless.
Policy positions worth taking
Who may borrow
Restrict to roles with a genuine offline requirement — site engineers, field support, staff travelling. Everyone else works connected.
Why: unrestricted borrowing in a small pool is indistinguishable from losing entitlements.
For how long
Constrain the maximum term below the platform maximum. A few days covers most genuine offline needs.
Why: engineers habitually borrow for the maximum offered rather than the period they need.
Which products
Permit borrowing of base entitlements; restrict premium add-ins with small pools.
Why: a single borrowed analysis entitlement can block a team for a fortnight.
Borrowing is also the mitigation for a scheduled licence server outage. Where a server is being patched, moved or upgraded, having the affected users borrow beforehand keeps them working through the window. Build this into the change procedure for the licence host so it is a standard step rather than an improvisation.
06 Consumption Order
Where several product tiers are held, the order in which they are drawn determines whether premium entitlements remain available for the work that needs them.
The service draws from the pool according to a configurable order. Left unset, an engineer opening the application for basic detailing may be issued a premium tier simply because it was available, leaving the full-time designer who needs that tier without one. Setting the order so that lower tiers are consumed first resolves this without any change to entitlement counts.
The configuration is straightforward and worth reviewing whenever entitlements change — a new tier purchased and not added to the ordering will behave unpredictably. It should also be reviewed after any upgrade, because entitlements for multiple release years may be present simultaneously during a staged rollout.
Consumption ordering is set once and then forgotten, which means a newly purchased tier or a newly activated release sits outside the intended order. The symptom is intermittent and hard to attribute: some engineers occasionally draw the wrong tier and nobody can reproduce it on demand. Add an ordering review to the procedure for any entitlement change.
07 Upgrade & Reactivation
Upgraded first, and early
The licence manager must be at or above the version of every product it serves. Because an upgraded manager continues to serve earlier versions, it can be moved days or weeks ahead of the main upgrade with no effect on current users. This is the easiest task to remove from a critical upgrade window, and it should always be removed.
Where a data management server is in scope, note that its own version requirements extend to the licence manager. Confirm the required manager version for every product in the estate before scheduling.
Reactivation
Activation-based network entitlements need periodic reactivation, typically annually and again after any upgrade. Two operational points follow. The reactivation is performed on the server through the administration interface, so it needs server access and the recorded serial numbers. And the failure mode is total — the pool becomes unavailable to everyone at once — which makes it worth an explicit calendar entry with an owner rather than institutional memory.
| Event | Timing | Consequence if missed |
|---|---|---|
| Annual reactivation | Scheduled, ahead of expiry | Whole pool unavailable simultaneously |
| Upgrade ahead of products | Days to weeks before the product upgrade | Clients on the new release cannot draw entitlements |
| Reactivate after upgrade | Immediately after the manager upgrade | Pool appears empty despite a successful upgrade |
| Options file re-read | After any options file edit | Changes silently have no effect |
| Consumption order review | After any entitlement change | Intermittent issue of the wrong tier |
| Usage log review | Quarterly, and before any purchase | Sizing decisions made on assumption |
08 Troubleshooting
| Symptom | Check first | Then |
|---|---|---|
| No licence available, pool not full | Client can reach both ports on the server | Recent firewall or network segmentation change |
| Pool empty after an upgrade | Entitlements reactivated at the new version | Manager version is at or above every product served |
| Options file appears to do nothing | The file was referenced and the service reactivated | Directives use Windows account names, not display names |
| Reservations not holding | Group membership spelled correctly and account names valid | A later directive in the file overriding an earlier one |
| Engineer cannot return a borrowed entitlement | Same network connection as used to borrow | It returns automatically at the end of the term regardless |
| Wrong tier issued intermittently | Consumption order includes every tier held | Order reviewed after the most recent entitlement change |
| Add-in pool exhausted immediately each morning | Add-ins set to load at startup in the deployment image | Idle timeout applied to add-in products, not just base tiers |
09 Network Licence Administration Checklist
- Host is production-grade. Always-on server, inside change control, monitored for availability.
- Ports open and verified. Both ports confirmed reachable from a representative client, not merely configured.
- Options file exists. Created, referenced, and the service reactivated so it is actually read.
- Groups defined by account name. Directives use Windows account names and have been tested with an affected account.
- Idle timeout set. Applied explicitly to add-in products as well as base entitlements, with a value tuned from the log.
- Borrowing governed. Permitted roles, maximum term and eligible products all decided rather than left open.
- Consumption order configured. Every tier held appears in the order, reviewed after the last entitlement change.
- Report logging enabled. Usage log running and reviewed at least quarterly.
- Reactivation diarised. Owner and date recorded, with a reminder ahead of expiry.
- Upgrade sequence understood. Manager upgraded ahead of products, with reactivation immediately after.
- Options file under change control. Comment header recording who changed what and when.
- Borrowing built into outage procedure. Affected users borrow before any planned licence host outage.
10 Frequently Asked Questions
Is an options file worth the effort for a small pool?
Small pools benefit most, because a single entitlement held unnecessarily represents a larger proportion of capacity. In a pool of four, one engineer holding a premium add-in all day removes a quarter of it.
A minimal useful file is short: define two or three groups, set an idle timeout that covers add-ins, and enable report logging. That is perhaps thirty minutes of work and typically returns at least one effective seat immediately.
Engineers say the timeout interrupts their work. Should we remove it?
Adjust it rather than remove it. The usual cause is a value too short for genuine working patterns — an engineer reviewing drawings on paper, in a meeting about the model, or working in another application on the same task will appear idle.
Look at the reclaim events in the log. Frequent reclaims immediately followed by the same user reacquiring the entitlement indicate the value is wrong, not the control. Lengthen it for base entitlements while keeping it shorter for premium add-ins, and explain the behaviour to the team so a reclaim is recognised rather than reported as a fault.
Can we see who is holding a particular entitlement right now?
Yes. The server administration interface shows current usage including which accounts hold which products, and borrowed entitlements are listed with their return dates. This is the first place to look when someone reports being unable to start.
Use it diagnostically rather than punitively. The useful output is usually a pattern — a particular add-in consistently held all day, or a borrowed entitlement nobody remembers taking — which points at a configuration change rather than at an individual.
We need to move the licence server. What is involved?
Three things, and the third is the one that catches people out. The service is installed on the new host and the entitlements are transferred, which generally involves deactivating on the old server before activating on the new one. The options file and any configuration are carried across. And every client must be repointed at the new server address.
Updating the deployment image is not sufficient — it changes what new installations receive, not machines already installed. Plan a server move as a change affecting every workstation, and have affected users borrow beforehand so the transition window does not stop work.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.