Functionality Revealed – Peeling Back the Onion
A longtime RLM customer discovers some hidden value.
Sometimes, it takes a customer to prod you into a new way of doing business to help you understand the full functionality that you've had all along.
The Story
This week I met with one of my customers who was using RLM Internet Activation to issue standalone, uncounted licenses for their desktop applications. Generally, each of their customers used only a handful of licenses, so their licensing process involved giving each customer an activation code that was valid for a small number of separate activations, according to the number they had ordered. Things were going great, except...
They told me that a few of their largest customers were worried that as their staff came and went and as new machines were added and others decommissioned, their activation count would become depleted too fast. They wondered if there might be a better way to handle licensing for such a dynamic user population. The answer was simple, sort of back to the future.
What they determined their customers really needed was a pool of licenses so that their users could come and go knowing that the total concurrent user count would not exceed the total number of licenses.
My customer asked me where they could get the RLM license server to support this alternate deployment model. I said, "You already have everything you need. It's part of the standard RLM kit." The customer then asked, "What do we have to change in our application to support floating licensing?" I told them that no source code changes would be required because all that has to change are the types of licenses they issue... a nice surprise for them.
More about Floating and Named User Licenses
Floating licenses are the most versatile of the license types. If floating licenses are available, anyone on the network with the application software product and access to the license server can get a license to run. This is tremendously powerful for software user organizations. But, there are times when software publishers (ISVs) want to sell the convenience of floating licenses while enforcing a more restricted named_user license model.
In the named_user model, the idea is to restrict license access to only users who are on a list.
Business Benefits of the Named User Model
The benefit of named_user licenses to the software user community is that their regular software users will not have to contend with other users for licenses. The licenses are in effect dedicated to the group of named users. These licenses may also be less expensive than floating licenses. The ISV, on the other hand, benefits because he can sell named_user licenses, perhaps at a lower cost, that better match the spirit of his license agreement. If he chooses, the ISV can still sell unrestricted floating licenses, but at a premium to the named_user type.
Names can be Dynamically Assigned
In Reprise Software's RLM, named_user licenses allow ISVs to require that user names be included on a list in order to use the licenses. The list can be assigned by the system administrator, or RLM can create the list "on the fly." The number of users in the list can be less than, equal to, or greater than the number of licenses available. Once a user is added to the list, he can be deleted, but once deleted, he must remain off the list for a minimum number of hours (24 hours by default). This prevents the manipulation of the system in an effort to defeat the named_user license policy.
If the number of named users is smaller than the number of licenses, then this small group will share the larger pool (assumes that it's feasible for a single user to consume more than one license at a time). If the number of named_users is greater than the number of licenses, then the larger pool of named_users will contend for the available licenses.
Managing the List
As was mentioned earlier, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered via the RLM web interface by the end-user administrator. If entered manually, either individual user names or GROUP names (as defined in the ISV server options file) can be used.
Named_user licenses utilize the INCLUDE functionality of the license server, and do not need a fully populated list of users before the licenses can be used. In fact, no users need to be specified since the license server will add users who do not appear on the list if the current list size is less than the number of allowed named users.ustomer discovers some hidden value.
How to License Server-based Software
Consider your options
The usual licensing strategy for server software is to lock it to a physical host. This provides some degree of protection from installing and running on multiple hosts, but it does not necessarily represent the optimal approach in terms of maximizing your revenue or customer satisfaction.
What's missing?
First, there's the notion of scaling. Do you really want to charge the same price for every site? You need some way to charge more when your software is used more. Perhaps you can sell multiple node locked servers to larger sites, or even charge relative to the number of cores on the machines, the rationale being that there is the potential to get more use from machines with more horsepower.
Float your server licenses
If you want your customers to have the flexibility of installing and using your server on many machines without having to license them separately, perhaps you should use a floating license manager that ensures that no more than a predetermined number of concurrent server copies can run at the same time. With floating licensing, you issue a license key with a count, and lock only the license server, not each user node.
Size matters
Another approach could be licensing by some other scaled metric: how many records can be maintained in the database, a count of named users, etc. Each of these metrics can be encoded into a license key, allowing the server software to know when it starts what level of service to enforce based on the license key scaling parameters. A single version of your software could then enforce the appropriate size limits on a site by site basis.
Using a license manager, such as RLM, could also give you even more control of how your software behaves within a virtual machine. You could even license by platform or by the site's timezone.
In any case, using a license manager gives you the freedom to change with your license policies.
Are you ready for Cloud Computing?
Traditional software licensing models are being challenged by new hardware and software deployment options. Gone are the days when users had to own their hardware infrastructure. Gone are the days of getting approval for the purchase of big ticket items like servers, and desktops, configuring them, and maintaining them to run their perpetually-licensed software in-house.
Cloud Computing - Opportunity?
Today, users can obtain "hardware on the fly" to run any operating system on arbitrarily large servers - "in the cloud." These virtual systems may persist indefinitely or disappear when no longer needed. The software on them may be used for only a short burst of time - just enough to get the job done - measured in days or even hours. Likewise, paying for "cloud-time" is easy, often paying with nothing more than a credit card.
The biggest industry players are driving the cloud movement. Folks like Amazon.com, Google, IBM, and Microsoft are leveraging their enormous investment in computing hardware and advanced virtualization software to build on-demand computing platforms. Corporate users, tired of paying to maintain in-house iron, are increasingly looking to reduce costs with cloud computing, while at the same time simplifying procurement, decreasing deployment delays, and adding unprecedented throughput potential.
Re-think Software Licensing Models
As a result, enterprise-class software vendors are thinking about new licensing models. Many vendors have already turned to subscription based models where customers pay for software monthly, or annually. But, with cloud computing, users may want to pay by the day, hour, or even minute. This puts new stresses on today's traditional pricing and licensing models on which software vendors' revenue streams depend. But, cloud computing could open untapped markets for some software vendors' products, especially those that carry a high per-seat cost, by allowing them to provide convenient access to their software on "big iron" at a much lower price point.
Perhaps software vendors need to move more rapidly toward "post-use-billing" models. Software applications could connect to a central server to collect usage information, either clock time, or a more precise measure of the amount of work (value) that was derived from a usage session.
Keeping up with the Pace of Change
Cloud computing is just the latest disruptive technology trend that is forcing independent software vendors to look for new ways to license their software products. Companies who use electronic license management are in the best position to keep pace with and take advantage of the ever-changing computing landscape.
Dynamic Named-User Licensing
Let your License Manager build user lists dynamically
Floating licenses are the most versatile of the license types. If floating licenses are available, anyone on the network with the application software product and access to the license server can get a license to run. This is tremendously powerful for software user organizations. But, there are times when software publishers (ISVs) want to sell the convenience of floating licenses while enforcing a more restricted named_user license model.
In the named_user model, the idea is to restrict license access to only users who are on a list.
Business Benefits
The benefit of named_user licenses to the software user community is that their regular software users will not have to contend with other users for licenses. The licenses are in effect dedicated to the group of named users. These licenses may also be less expensive than floating licenses. The ISV, on the other hand, benefits because he can sell named_user licenses, perhaps at a lower cost, that better match the spirit of his license agreement. If he chooses, the ISV can still sell unrestricted floating licenses, but at a premium to the named_user type.
Names can be Dynamically Assigned
In Reprise Software's RLM, named_user licenses allow ISVs to require that user names be included on a list in order to use the licenses. The list can be assigned by the system administrator, or RLM can create the list "on the fly." The number of users in the list can be less than, equal to, or greater than the number of licenses available. Once a user is added to the list, he can be deleted, but once deleted, he must remain off the list for a minimum number of hours (24 hours by default). This prevents the manipulation of the system in an effort to defeat the named_user license policy.
If the number of named users is smaller than the number of licenses, then this small group will share the larger pool (assumes that it's feasible for a single user to consume more than one license at a time). If the number of named_users is greater than the number of licenses, then the larger pool of named_users will contend for the available licenses.
The "How To"
To deploy a named_user licensing model, the ISV does not need to modify his RLM-enabled application at all; it's controlled in the license certificate itself. To create a named user license a named_user keyword is simply added to a standard floating license certificate, in one of the three following ways:
named_user - to require the same # of users as there are licenses
or
named_user=n - to require a maximum of n users to be named
or
named_user="n min_hours" - to require a maximum of n users to be named, and to specify the minimum number of hours before the deleted user name can be re-added back to the list.
Managing the List
As was mentioned earlier, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered via the RLM web interface by the end-user administrator. If entered manually, either individual user names or GROUP names (as defined in the ISV server options file) can be used.
Named_user licenses utilize the INCLUDE functionality of the license server, and do not need a fully populated list of users before the licenses can be used. In fact, no users need to be specified since the license server will add users who do not appear on the list if the current list size is less than the number of allowed named users.
The Licensing of Sub-licensed Tool Kits
How do ISVs license their products in library form?
Many independent software vendors (ISVs) who sell their products as complete applications also sell them as re-linkable libraries. Licensing the applications is pretty straightforward, but what about the libraries? How do ISVs tackle licensing of libraries?
Most of the companies that we've talked to who have libraries to license want to use a license manager to enforce their pricing models. They also want to have the flexibility to turn on and off certain features within the library. ISVs who ship software development toolkits (SDKs) that are designed to be incorporated by your customers into sub-licensed products usually do not want licenses to be required in the derivative applications. However, they may still want a way to enable each sub-licensee with a unique license key.
The Reprise License Manager (RLM) addresses licensing of SDKs by supporting a license "in-a-string" concept. This approach allows ISVs to sell licenses in the form of digitally signed text strings that are passed as parameters into their library's initialization routine. During initialization, the license is then passed as a parameter into RLM's initialization routine for validation. This means that only products that are built with a valid license string will successfully initialize the library. Often, ISVs will also include the customer's name or contract number in the license for identification purposes.
Since the initialized library has access to the contents of the key internally, the library can call RLM as it would normally to check out feature licenses, without the need for a separate disk based license file.
An important additional benefit of this approach is the simplification of back office administration, since the same methods and tools that you use to create licenses for your standard licensed applications can also be used for your licensed libraries.
Please feel free to contact us to discuss your situation further.
Expanding your Software Licensing Policies
RLM's Simple API makes executing tactical adjustments to pricing and licensing policies easy
In these tough economic times it is critical to have the flexibility to address complex licensing policies quickly and easily. In a previous article RLM's 'Policy is in the License' methodology was discussed, explaining how the RLM license policy is largely removed from your application. Since the license policy is defined in the license keys, a single binary can support many license policies.. Once RLM is implemented, you can address ever-changing business rules by simply varying the type of keys that you issue. RLM can support a wide range of licensing options and policies. Many of these policies have been covered in previous articles and are summarized here (with link to original article):
- Trial and Evaluation Licenses are implemented using a license with an expiration date, and possibly a "demo" flag, to make your product accessible to would-be buyers. Since eval/demo/trial licenses can also be easily turned into full, "purchased" licenses, a trial version of your product is the logical first step in a successful sales process. Well-designed eval/demo/trial licensing programs will reduce your cost of sales, increase customer satisfaction and productivity, all while expanding your reach into wider geographies and attracting new types of users.
- Floating and Node Locked Licenses can be implemented as needed and depend largely on how your software is intended to be used, shared or unshared. Floating licenses are free to "float" across the network to users who need them. The license manager controls access to these floating licenses via a central server that enforces the maximum license count that you have set for this site. Node-locked licenses, on the other hand, are usually uncounted, allowing an unlimited number of copies to run on a specified host.
- NAMED_USER, or USER_BASED Licenses are a class of floating licenses that must be assigned to user names so that they cannot be used as widely as unrestricted floating licenses. With a named_user license, the license server can construct the list of users automatically as license checkouts occur, or the list can be entered/modified via the RLM web interface by the end-user administrator. Gives you more pricing depth.
- Token Based Licenses are among the more-advanced features that provide a license model to your customers to enable license alternates. This is the case where you sell a single product that consists of many separately licensable components (product and sub-product model). If you sell product bundles at a special discounted price, then customers can purchase a combination of both the bundles and the components of the bundles in order to match their requirements. Token based licensing allows you to define product rights in terms of relative value between your products, or allow a user to consume a mix of your products up to a pre-determined level of value. This model also allows you to introduce new products into your customers easily since the new products consume the same licenses (tokens) that are already installed.
- WAN/Time Zone Licenses use time zones in the license file to increase your pricing options. Your biggest customers usually connect their geographically dispersed sites via a WAN. When they do that, they can potentially share your floating licenses across the globe. For a variety of reasons you may want your licenses to be used only within a particular time zone.
- Subscription based Licenses are supported using the start and expiration dates in the license file. Subscription licenses are priced so that they provide a lower initial cost in order to attract both new customers and those customers who are trying to preserve short term cash.
- Version based Licenses can be implemented to support versioning control by either version number or version release date. License requests beyond the version number or release date would be denied, presenting an opportunity to remind the customer that access to that version requires a new license obtained only via a support contract extension, again providing an avenue for maximizing ongoing revenue.
- Licensing on Virtual Machines is supported in RLM via a parameter in the license itself that controls whether it will or will not run under VM. Vendors can deliver both kinds of licenses to their customers - disabled and enabled - allowing them to, for example, issue short-term VM-capable licenses for testing and evaluation purposes, but disabling other licenses for long-term production deployment, or allow certain customers, but not all, to run their licenses on VMs.
The remainder of this article will briefly discuss a few other optional license fields. The following license keywords can be classified as 'vendor defined' options as they are not used by RLM to determine policy, but can be accessed by your application to further restrict usage rights or present information to the end-user:
- License Options field specification is used to encode options for the product. Do you have the need to restrict information access or usage within you application? Do you want to limit the number of database records that can be created or accessed, the number of accounts that can be open, the number of portals that can be accessed, etc.? This information can be entered into the 'Options' field and extracted by your application to further limit or define the applications internal processes.
- Contract field can be used to hold the customer's purchase information or software agreement number. This can be displayed to the end-user to validate a support contract, etc.
- Issuer field would be used to identify the organization which issued the license, such as a third party distributor etc.
- Customer field can be used to identify the customer of the software and can be displayed by your application to the end-user. This can be an added incentive to keep honest users honest. It is unlikely that Mega South-East Airlines would want to use a license that was issued to Main St. Bank.
Even though it is wise when starting out to keep the implementation relatively simple, it is very important to have options to address the changes due to market pressure, economic stress or customer feedback. RLM's licensing methodology gives you the flexibility to address the ever-changing business rules. Reprise Software's experts can help you plan your optimal approach. Please feel free to contact us to discuss.
Software License Entitlements
Deciding what rights to give to your software customers
For software vendors, the most valuable aspect of using a license manager is the freedom to define exactly how your customers buy and use your software products. You can match the attributes of your licenses to the precise needs of your customers and markets. Equally valuable is the ability to address unusual opportunity-specific requirements from your biggest and most important customers or new technology partners.
License managers, such as RLM from Reprise Software, isolate details of the licensing policy from the application code, giving you the freedom to define licensing on a customer by customer or even site by site basis. A single binary version of the product can support various licensing policies because all the variable elements of the licenses are stored in digitally signed files, not embedded in the product itself.
Assigning License Rights
How do I harness the power of the license manager? What rights should I give to my customers? Let's first look at basic elements of a license that you can control, then look later at some other important parameters that can further refine your licensing policies.
Expiration Dates
Probably the most basic of all is the ability to control the duration of the license. In some cases, you may want your licenses to be perpetual, with no expiration date. At other times, as in demo or trial modes, you may want your licenses to have a short duration, 30 days or so. Still other times, you may sell usage rights on a periodic basis, monthly or annually, requiring a new license to be issued upon renewal.
Remember that rights once given are difficult to revoke. So, setting a fixed expiration date gives you the opportunity to retire and/or replace licenses in the field more easily should your license policies require a radical overhaul in the future.
Version Numbers
Important users demand enhancements to your products to achieve increased productivity and improved business efficiency. Successful independent software vendors (ISVs) are constantly updating and upgrading their products. Importantly, software vendors often require that customers pay to play. Most vendors encourage their customers to pay an annual support and update charge to help fund this on-going development. In other words, only those customers who have paid support are allowed to use the latest release. Version numbers in their licenses give ISVs the control they need to enforce this policy.
Floating or Node-locked?
License managers can "lock" a license to a particular host, and they can control how many licensed copies are allowed to run concurrently. Floating licenses are free to "float" to users who need them. The license manager controls access to these floating licenses via a central server that enforces the maximum license count that you have set for this site. In a sense, floating licenses are locked to the license server, but can be used by anyone with access to that server. Floating licenses are perceived to have more value than other locked licenses because they can be shared, yielding more utility to the user community.
Node-locked licenses, on the other hand, are usually uncounted, allowing an unlimited number of copies to run on a specified host. Which you choose implement, floating or node-locked, depends largely on how your software is intended to be used, shared or unshared. Maximum flexibility calls for software licensing that can support both, ideally with one build of the licensed software product.
Further Entitlement Fine Tuning
After you've decided on your basic license entitlement strategies, you can further refine your policies to more precisely match your needs. Below is a list of optional parameters that can be controlled within the context of the basic license attributes above:
- License Sharing: allows a single floating license to satisfy the needs of a user regardless of the number of concurrent copies on his computer. Sharing is commonly used for development tools and other engineering and scientific applications that are multi-threaded.
- Disable on VM: virtual machines pose a security hole for ISVs because VMs can be cloned.
- License Hold time and Minimum Checkout time: some applications are designed to run for a very short time. Extending those times can help you keep your "per user" pricing low at large sites.
License Roaming: enables licenses to be temporarily reassigned to mobile devices for field work. - NAMED_USER, or USER_BASED Licenses: a class of floating licenses that must be assigned to user names so that they cannot be used as widely as unrestricted floating licenses. Gives you more pricing depth.
- Platform restrictions: enables platform-specific pricing models.
Time zone restrictions: enables geographically-based pricing models. Charge more for licenses used over a wider geography. - Overdrafts: captures revenue from users who temporarily need to exceed their license inventory.
It's always a good idea to build a solid consensus within your company about how your license entitlements should be defined before you begin to implement licensing. But, if you need to make some changes in your policy after you release your software, RLM's "policy in the license" will allow you to adapt without having to re-release your software. Perhaps, Reprise Software's experts can help you plan your optimal approach. Please feel free to contact us to discuss.
Enhance the effectiveness of Trial Software by using “Detached Demos”
Many software vendors like to offer no-charge function- and/or time-limited copies of their software to potential customers as trial, demo or eval versions. The idea is of course to give the potential customer an easy, low or no-cost way to get experience using their software.
If your software benefits from the use of license management, or you are considering moving to an enforced license management scheme, one aspect to consider is what the user experience will be for trial/eval/demo copies of your software.
Typically, for license managed software, a short-term (usually 30 days) license is provided upon request to a qualified evaluator. The product may run in full- or reduced-functionality mode, usually on any machine but only for 30 days, unless extended by the software vendor.
Determining when those 30 days start is important. While software vendors can certainly make available licenses that enable 30 day trials, what happens when your would-be customer is delayed in beginning their evaluation of your product? Yes, Virginia, this does happen.
What would be ideal would be to allow the evaluation/trial/demo version to start when the evaluator is ready, not when they request the eval. And again, while it's possible to use an activation system to accomplish the "start when I'm ready" functionality, that of course requires an Internet connection.
What happens if the evaluator is flying at 35,000 feet or otherwise not able to access the Internet?
An "install + N"-day, or "detached demo" evaluation model is the answer. Here, the same API calls inside the source code of your product that handle day-to-day floating, fixed, feature-based and/or time-limited licensing can also create a one-time license for your product to run for 'n' days from install.
The benefits to this approach are clear - when the evaluator is ready, so is your product. This type of trial experience leaves the user happier, requires less routine administration ("can you please send me a new eval key?") and should result in a higher rate of closing sales.
Be sure the license management technology you choose has this "detached demo" capability.
Licensing and Pricing Strategies for “Short Duration” Applications
Many valuable software tools that require floating licensing run for only a short time. These include various solvers, development and design tools, and other specialty software products that are designed to perform very specific tasks very quickly. Unlike typical interactive or desktop applications, these short-burst applications typically do not have a GUI of there own, but are often launched by other applications within a product suite.
The "Short Duration" Licensing Challenge
The licensing challenge is based on the fact that a floating license is a shared license. When a floating license is used it is unavailable until it is returned. But, short duration tools consume licenses for only a short time, so a single license could potentially be shared by a large number of users.
The "Short Duration" Pricing Challenge
The licensing challenge is really a pricing challenge. In other words, how do you set a price for a single floating license that is low enough for small sites to afford while at the same time scaling your pricing so that larger sites that use more of your software pay you more for that use? How do you prevent large sites from satisfying their requirements by licensing only a single floating copy of your software?
Node-Locking?
An outdated approach would be to revert to node-locked licenses tied to each workstation or user. Although this would solve the problem, the vendor and end customer would be inconvenienced by having to create, install and manage N licenses for N users. This is very inefficient.
Customers would prefer to "float" licenses to users who need them.
Extra Hold Time
One way to handle this problem is to implement an extra "hold time" on the floating license. This holds the license for an extra number of seconds after it is released, regardless of how long the license was actually used. So, for example, if the application uses the license for 20 seconds, upon termination of the program the license is "held" for an additional 300 seconds, say, for a total of 320 seconds. The effect is that the floating license can be shared by fewer users because it is "busy" for a longer period of time each time it is used. This encourages customers to order more licenses to satisfy their user population. But, some customers may object to the license being unavailable for such a long time.
Minimum Checkout Time
Another similar method is to enforce a "minimum" license checkout duration. Instead of extra time being added to the end of a licensing session as in the above example, a license would be held for at least a specified minimum amount of time. So, a license with the minimum checkout time set to 300 seconds would add 280 extra seconds to a license that was in use for only 20 seconds. Licenses used for more than 300 seconds would not be affected.
Both "extra hold time" and "minimum checkout time" should be specified in the license file, external to the application, so that the same executable can use either method without modification to the source code.
Post-use Billing
Since the ultimate goal is for the vendor to get paid an amount that is proportional to the value derived from the customer's use of the software, how about introducing a metered or pay-per-use approach? This approach is based on actual usage time. A post-use billing model would allow a customer to use as much or as little of the software as he wished, with no artificial licensing constraints. The vendor and customer would agree not on a "per copy" price, but on a "per hour" price. Periodically, say once a month, the user would submit a report generated from the license manager's transaction log file that would summarize usage time. The user could put his own constraints on the licenses so as not to exceed a certain budget, but both the customer and the vendor would be satisfied.
RLM can handle these approaches, so please contact Reprise Software to discuss your needs in more detail.
Licensing on Virtual Machines
Finding Ways to Tame Virtual Machines
Virtual Machines present Licensing Challenges
Virtual Machine (VM) software has been a major factor in increasing computer utilization and efficiency. VM software allows users to segment a computer into multiple "virtual" systems, each with its own copy of an operating system each acting fully independently from the others. For software vendors, this "machine replication" can be a problem, one that can make profits become "virtual" too.
Attack of the Clones
As the use of Virtual Machine (VM) software becomes more widespread, software vendors are realizing that by using VMs to replicate whole operating environments on a single host, users can also replicate (clone) the licensing system used to limit the number of licenses on that host. Since licenses are usually tied or "node-locked" to a host using the Ethernet hardware address, this means that users can also gain access to extra application licenses - in most cases exceeding the scope of their license agreement.
RLM on Virtual Machines
Software licensing vendors are beginning to help ISVs address this issue. For instance, starting in v5.0 of RLM, Reprise Software added the capability to disable node-locked licenses or license servers when running on virtual machines.
RLM detects VMs and disables license servers and other specially marked licenses. Disabling licenses on Virtual Machines is useful for node-locked, uncounted licenses in order to prevent these licenses from being used on multiple "cloned" systems within virtual machines.
By being able to disable licenses on VMs, software vendors can gain more control over how their software is used and priced. Software vendors can charge fair value for licenses that can run in a VM, matching the extra value and flexibility obtained in exchange for a potentially higher price. At the same time, some vendors might consider lowering the cost of licenses that are disabled on VM. This strategy is not unlike how some vendors use "time-zone-limited" licenses to reduce the cost of their basic license while charging higher fees for licenses that can span larger geographies.
Have it Your Way
Not all software vendors want to disable licenses under a VM. So, as with most RLM features, software vendors can turn this feature off, choosing not to limit licenses on VMs.
Importantly, since the license itself contains the parameter that controls whether it will or will not run under VM, vendors can deliver both kinds of licenses to their customers - disabled and non-disabled - allowing them to, for example, issue short-term VM-capable licenses for testing and evaluation purposes, but disabling other licenses for long-term production deployment.
Feel free to contact us via info@reprisesoftware.com should you wish to discuss details of the use of RLM on virtual machines.
Search the Blog
Recent Posts
- Activation of a Rehostable license fails with a -148 (NO_REHOST_TOP_DIR) error
- Reprise Software’s Recommended Software Installation Steps
- Failover License Servers – why can’t I have 3?
- Application cannot connect to license server
- My license server won’t start
RSS feed subscription