License reservation best practices

Hi,

We have several customers experiencing issues with the licensing system. A couple of the known offenders:

  • Applications are fetching dev licenses instead of runtime

Latest was a flex customer where the Historian fetched a 500 tags / 24 hour license instead of the unlimited license.

Other cases the Historian is getting the dev license (big license) instead of the runtime (smaller license)

In both of these cases we are reserving these dev licenses to "DUMMY" machines. In some cases, we are creating separate license servers to host the dev licenses. Why can't the system give us the runtime licenses first like we would expect?

  • Reservations not working

We reserve a supervisory license for a client. The client says that no license is available. We remove the reservation, suddenly the license is available. Even though the reservation was for that specific client. In this case, reservations are simply not working.

We haven't really found a good workaround for this. We can only guess that doing some rebuild could work. Remove the device or something like that. But this would be a completely manual operation that is very cumbersome for larger installations.

Parents
  • Best and most reliable way to prevent the Historian from grabbing the dev license.... Reserve the Dev license Historian feature to a node name that does not exist.  I like to use "Dummy".  On newer versions of the licensing, you would also need to click the 3 dots item next to the part number, and do a partial reservation.  Only reserve the Historian feature, not the whole dev license. 

    Another option is to perform a checkout of the license you want it to use to the Historian.  This works well, but if (when) something goes wrong with the trusted storage files that are on the Historian and hold that checked out license, it will then go and try to get the dev license again. 

    My suggestion, leave it with just the reservations, and make sure the dev is reserved to some node name that will not matter.

  • Like Trond and others, I have repeatedly experienced similar issues to those described in this post. The suggested "Dummy"-node trick does not seem to be 100% reliable. Fundamentally, we should not need workarounds to ensure that the customer's licenses works as expected. This is not just an inconvenience, it introduces reliability risks for our clients' operations, potentially impacting their uptime.

    To fix the issue, I propose that AVEVA creates a dedicated Development license that only includes the System Platform IDE. For flex, this would mean a license which only contains the feature line; 'i-flexruntime|xy.z|w', if I am not mistaken.

    This simple solution should work, since there would be no incorrect licenses available for the License Server to grab. It would only take the licenses which the customer has paid for, plus the IDE license which is used by the SI during development.

    Thanks for your consideration!

Reply
  • Like Trond and others, I have repeatedly experienced similar issues to those described in this post. The suggested "Dummy"-node trick does not seem to be 100% reliable. Fundamentally, we should not need workarounds to ensure that the customer's licenses works as expected. This is not just an inconvenience, it introduces reliability risks for our clients' operations, potentially impacting their uptime.

    To fix the issue, I propose that AVEVA creates a dedicated Development license that only includes the System Platform IDE. For flex, this would mean a license which only contains the feature line; 'i-flexruntime|xy.z|w', if I am not mistaken.

    This simple solution should work, since there would be no incorrect licenses available for the License Server to grab. It would only take the licenses which the customer has paid for, plus the IDE license which is used by the SI during development.

    Thanks for your consideration!

Children
No Data