When a user launches an Autodesk application, the application requests a license key. The key either comes from the person’s desktop (a perpetual license today) or from a License server having multiple keys that can be shared across multiple users. By sharing keys, the usage rate of a license will be higher than for a key restricted to one desktop. The intent of this licensing approach is to balance the needs of customers to maximize user application access with a vendor’s desire to ensure payment for application usage. We’re going to cover the difficulties of getting the right Autodesk key from license server(s) in this post.
The central “character” in this post is Autodesk’s Cascading License file (CLF). CLFs resolve multiple needs:
- Making the customers' entitlements available to all users
- Listing all the entitlements such as individual or Suite Licenses
- Ensuring that keys match available enititlements
- Ensuing that the customer is not able to check out more keys than entitled
- Distributing the keys across multiple servers if the customer is distributed or needs back-up/fail-over, network security, etc.
The name Cascading License file is a bit of a misnomer. The file isn’t hierarchically structured, but it does release keys based on a hierarchy of license entitlement values.
License file debugging gets complicated for a couple of reasons: Individual applications are being packaged into Suites (but may still be grandfathered as individual applications), Suites have different monetary values, the same applications may be available in multiple Suites (and thus have different monetary values), the ACLF can be spread across multiple servers, and license keys can be re-associated after they are issued. Let’s tackle these issues one at a time.
Autodesk has re-packaged individual applications into Suites. Some of the same applications are available in multiple Suites. Suites may be priced differently, so that the same application may have a different value depending on the Suite it was licensed in. Some applications come in a “light” and “professional” version, with the “professional” version having more features and a higher price. Applications within Suites use the same Product Codes, meaning AutoCAD may have multiple Product Codes.
Customers may license multiple copies of Suites. They may also have perpetually licensed multiple copies of individual applications. When a user requests an application, the CLF will provide a license key to launch the application. This key may not be from the least expensive available license on the server, and the least expensive available key may in fact be on another server. Autodesk has created a method of searching though the distributed CLF to find the lowest cost available key, which is then swapped or “re-associated” for the license key initially issued. This process may take multiple seconds.
Users are associated with specific license servers. When a user requests a key, the user’s Autodesk application makes a request to the associated license server. If a key is available, the server issues it to the user. The lowest cost available key, however, may be on a different server. After the user’s application starts, the application will then “ping” the next license server to see if it has a lower cost key. If this is the case, the application will take the new key and swap it for the key on the user’s machine. The application will then release the original key back to its server. Each end user installation has a file that shows the initial as well as additional server identities for the license key association/re-association process to take place.
Autodesk applications may have “light” and “professional” versions that are licensed separately. A user may request a key for the “light” version. If the user later needs features from the “professional” version, and a key for that version is available, the user will get the “professional” application and key. The “light” key is then released. Although this association does not reflect a more difficult debugging process, users can be frustrated in needing the “professional” version and find it’s not available because the user who is using the “professional” version may no longer need the added features. The application doesn’t know its features are no longer needed, and can’t “downgrade” itself to release the key. That happens only when the user logs off. Customers may question whether the CLF algorithm is working correctly if users get license-denied notifications for “professional” versions even if the features aren’t being used (but the license key has been checked out).
The CLF contains the customer’s entitlements, and when a key is requested, the algorithms in the file try to find the lowest cost key for association. Think of an algorithm in which the least expensive key for an application is key number 1, and the most expensive key is N. Keys are “re-associated” starting at 1. When N is reached, the next user requesting a license receives a license-denied notification.
Debugging the CLF, or rather, verifying the algorithm will assign the lowest cost available key is problematic because if the algorithm “skips” a Suite or a server, the user is losing access to paid entitlements. Administrators or resellers debugging the CLF have had to rely on a collection of open source or homemade tools to read the server license file logs. These logs contain the information on which file was requested and where the license key was finally issued to determine if the algorithm worked successfully. Tracking the “re-association” process and ensuring keys are associated according to their value can be a painstaking and arduous task, especially as the number of licenses and servers increases. The process repeats itself every time the CLF changes due to additions or changes in licenses, or if the CLF contains errors.
Cetrus’ Process Meter™ delivers the information an administrator needs to easily and quickly perform CLF debugging. It records the license request from the user’s desktop, and reports on both the initial well as the “re-associated” key, including information on who the user is, their workstation, the application, the Product Code and server associated with the license keys. Process Meter doesn’t require deep technical skills to use, and because the reporting is web-based, administrators can remotely monitor and debug the CLF as licenses are added, or changed.
Click here for a free, no-charge, 30 day trial and see how easy it is to get license association information with Process Meter.