One of the criteria that is often overlooked when building or buying software is the capability for users to customize the application without having to request a change by the vendor. OpenLM recognises that, while they have done their best to provide all the features one would need for license management, most customers will have special license requirements that pertain to a particular software product, either on a temporary or a permanent basis. In order to cater for this need, OpenLM offers the “Custom Commands” feature. We recommend that you discuss this feature with your development or support team to see if this product will work for you.
For instance, custom commands enable the user improve their license management by:-
- displaying custom commands in addition to standard OpenLM or vendor commands, for instance a warning that the software version is going to be decommissioned at the end of the month
- configuring license availability by setting conditions for prioritizing or excluding classes of users when the need arises (e.g. at peak periods)
- Launching a short program, script or process to run automatically when a certain condition is met. N.B. There is a time limit of 2 minutes within which the called routine or process must start.
These are only some of the opportunities available when using custom commands, many of which can be executed from the core system. For full functionality, you need the App Manager extension. Custom commands are free to use, all you need to do is email firstname.lastname@example.org to get a return email with the license link. This process guards against any potential misuse, because this is a very powerful feature.
Figure 1: Terms and conditions for using Custom Commands
(There are detailed instructions on how to set up OpenLM for using the custom commands on the OpenLM website in our knowledgebase. We have just described the basics briefly below, to illustrate that it is not a complex process).
Once you have the license installed, you need to restart the OpenLM Server to install the Custom Commands for use. You then need to check that the OpenLM Agent is configured and that the OpenLM Software Locker is running on the workstations. You may not need this functionality if you are not planning to customize your Agent Procedures, but it also does not affect your setup if it is set up for future use.
There are three routes for adding a custom command to the OpenLM core system, depending on the type of customization you want:-
- Use Agent Procedures to perform an action such as suspending one or more workstations or running a script that will affect workstations.
- Use Alert Management for posting customized messages to workstations or running a program when a specific condition is met.
- Use the App Manager extension to run a custom script when a business rule created via the App Manager is activated.
To get a better idea of how powerful this feature is, we have included an example using the Agent Procedures option.
An Example Using Agent Procedures
There are three steps to setting up an agent procedure, starting with a log-in to EasyAdmin.
- Define Custom Agent Procedures
- Define Unmanaged Processes
- Configure Unmanaged Processes to Enable Custom Procedures
Define Custom Agent Procedures
From the EasyAdmin screen, select “Agent Procedures”.
Figure 2: The EasyAdmin Administration Screen – with Agent Procedures selected.
This will open the screen below. If this is the first time you are adding a procedure, it will say “No Results found”. Select the “Add” button at the top of the screen.
Figure 3: Top of Agent Procedures administration screen
This will open the following screen:-
Figure 4: The Agent Procedure Editor, with drop-down list for Action Type
The Name field is a unique identifier for the agent procedure. We suggest you set up a naming convention that will help you to identify what the affected software is and what the procedure does, so that it is easy to identify from the Agent Procedures List.
Then add an action. Some of the fields, such as “Action Type” have a drop-down list, as shown above.
Script Info must contain the full path to the script (if a script is part of the procedure) in Windows Shell scripting, e.g. <path>\[filename].exe (or <path>\[filename].bat for a batch file).
The script can either run immediately or must wait until the previous command is successfully completed. To ensure that it runs immediately, prefix the path with an “@”sign, e.g. @<path>\[filename].exe. Without this prefix, it will wait for completion of the previous task.
The Execute Condition defaults to “NoWait”. You can override this to one of the other options, “WaitComplete” or “WaitSuccess”. If there is an error condition with the WaitSuccess option, the procedure will terminate.
Run At defines whether the procedure runs as an on-line interactive procedure (select “Application”) or whether it runs in background (or silent mode, select “Service”).
The “Active” field will indicate whether the procedure is active or not.
Figure 5: A simple procedure to kill any instance of NotePad with no wait.
The example above is very basic, but is a useful case of what can be implemented.
If you need to include a script for your procedure, you will have to define and configure an unmanaged process.
Define Unmanaged Processes
In case you were wondering what an unmanaged process is, it refers to a feature from a software product that OpenLM does not officially support. Following demand from customers, with Release 2.0, we added functionality to include other software products, or “unmanaged licenses” to their administrative portfolio.
What is an Unmanaged Process?
Here are 3 definitions:-
- Unmanaged software is software from a vendor that has a license manager that is outside the scope of OpenLM’s extensive list of supported vendors. This is usually because the software is not engineering software, which is the focus of OpenLM’s license management, but is commonly used at our customers. A typical example would be Adobe Acrobat.
- An unmanaged license applies to a software license for unmanaged software.
- An unmanaged process refers to a process that supports a feature from unmanaged software. Every software feature from any product runs as a process.
Although OpenLM does not manage the process, you can discover the process name by opening the Process List in OpenLM to get the name. Here is a description of how this is done.
Configure Unmanaged Processes to Enable Custom Procedures
We are not going into the detail of how to do this, but illustrate how much control you can have over software that is unmanaged, in the screen below. To learn more about how this is done, please visit here or see our full explanation here.
The example is a procedure to monitor Adobe Photoshop licenses that are idle, without human intervention, based on the elapsed idle time. The procedure name “messageAdobe” is the procedure name that will appear in the Agent Procedure List.
Figure 6: Example of an Unmanaged Process for Adobe Photoshop.
Although this is a very brief run through of the capabilities of Custom commands, there is enough information to show how easy it is to tailor your software license usage, even for licenses that are not managed. You can have customized control over all of your software tools without any intervention from your in-house developers or the software vendor.
With so many capabilities available, we have illustrated only one example. We invite you to visit our page and download the detailed PDF for a more comprehensive idea of how custom commands can make your license management easier. The link to this page can be found here.