Will checked out licenses will prevent over usage? In other words, if a product only uses checked-out licenses you will ever exceed your license limit?
Checked-out licenses were never meant to prevent over usage, they were designed for two reasons:
1. A replacement for Node Locked licenses in the XM Licensing world.
a. You are a NON-SELECT customer and you are not entitled to pool licenses, therefore you must use a checked-out license as your node locked license.
2. You are a SELECT or ELS customer using a machine that must be disconnected from SELECTserver access for greater than 30 days.
a. With XM Licensing, workstations must connect to a SELECTserver and transmit usage logs at least once every 30 days.
b. If you don’t your product will deactivate, therefore checking out a license will prevent this action.
c. The result is that SELECTserver considers the checked-out license to be in use 24-hours a day until either the license expiration occurs or it is checked back in.
If this were a true statement, then yes, checked out licenses would prevent over usage. However, what happens is that certain applications automate the check out and check in of the licenses.
When the application starts up it will automatically check out the license, on close it releases the license and checks it back in.
Bentley has designed SELECTserver to work in an asynchronous, disconnected manor. There is no longer an instantaneous concurrency like the former “heartbeat” licensing design. A Checked-out license is just another way of reporting usage. As stated previously, the application is considered to be in use from the time the license is checked out to the time it is checked in.
Here is an example of how a checked-out license counts toward usage once it is checked back in.
*We will assume that the site only owns 1 license of a given product, and that the product being used has implemented the automatic check-out logic.
· License is checked out on 01/01/2014 at 08:00 AM with a duration of 2 days, expiring on 01/03/2014 at 08:00 AM.
· License is never checked in, and just expires on 01/03/2014 at 08:00 AM.
· Usage is recorded for the machine each hour between 01/01/2014 08:00 AM and 01/03/2014 08:00 AM.
· If another user attempts to start up, the checkout will fail and the application won’t start.
Scenario 1 is the perfect scenario as we’ve started and stopped on even calendar hours. SELECTserver counts concurrency on calendar hours 08:00:00 to 08:59:59 as one calendar hour 09:00:00 to 09:59:59 is another calendar hour. Peak usage is the number of unique machines using a product within the calendar hour.
** It doesn’t matter if their usages overlap or not, if they are within the same calendar hour they are in use at the same time.
· Machine A uses the application from 08:00 until 09:15
· Machine B uses the application from 09:30 until 10:15
· The hourly peak occurs in the 9:00 hour and is 2 because both machines used the product during that hour.
8:00
9:00
10:00
8:15
8:30
8:45
9:15
9:30
9:45
10:15
10:30
10:45
Machine A
Machine B
Hourly Usage
1
2
· Machine B uses the application from 09:30 until 09:45
· Machine C uses the application from 09:50 until 11:00
· Machine A uses the application from 10:00 until 11:00
· The hourly peak occurs in the 9:00 hour and is 3 because both machines used the product during that hour.
Machine C
3
The answer comes from the way SELECTserver handles a check in.
Check outs are always a multiple day event, check out at 08:00 AM today and it will expire at 08:00 AM tomorrow which encompasses 2 days. When a check out is checked in early, the portion for the day which doesn’t cover a 24 hour period is converted to a normal usage. This is done to simplify calculations within the Peak Processing process.
For example, if a check-out is started at 01/01/2014 08:00 AM with a duration of 2 days and then is checked in early on 01/02/2014 06:30 AM the portion of the day from 01/02/2014 00:00 to 06:30 AM will be converted to a normal usage.
When Peak Processing takes place it will look as if the usage came from a Pooled usage and not a Check-out.
There is currently no way to track that the usage originated from a check out, and the logic predates the Trusted Usage Report. It does, however, highlight the fact that check outs can’t prevent over usage and the reason why.
What is usage and how is it calculated?
http://communities.bentley.com/products/licensing/b/licensing_blog/archive/2010/05/27/what-is-usage-and-how-is-it-calculated.aspx
Understanding, monitoring and managing usage.
http://communities.bentley.com/products/licensing/b/licensing_blog/archive/2013/10/01/understanding-monitoring-and-managing-usage.aspx
Hello Brian,
The link at the bottom of this article "Understanding, monitoring and managing usage" may help, along with this article on Custom Activation Groups:
communities.bentley.com/.../6467.custom-activation-groups
If this does not help, the search bar at the top of the SELECTserver and Product Activation Community should bring you to some related discussions. Or, you can post on the Forum:
communities.bentley.com/.../275813
You can link back to this article in case some improvement can be made as a result of the discussion.
This statement "For more information regarding avoiding Quarterly Term Licensing this article.", from another FAQ on Checking out licenses, indicated that this article would help in avoiding QTL, but it does very little in that respect except to say that Check-Out Licenses are not the way to go. How can I enforce usage to stay within my number of licenses?