"packs" : Dynamic licensing

Hi,

I want to wish you all and especially the easymorph team a happy new year with all the best. I also want to tell you the 4.6 version is amazing. The associative filtering feature is so nice and we so much expected the custom SQL filter !

About dynamic licensing we would like to know more about it, it’s also very interesting. How can we create pack of licenses ? How is it associated to server, it’s on your side or on our side ? Is it possible to change the server association (if you have multiple servers with one active/one passive).

Thank you, Romain! I'll pass it along to our team. From all of us, best wishes to you and good health in 2021!

License packs are added to license keys by us. A license pack is associated with a particular Server and the Server obtains the ability to assign licenses to Desktop users. Note that Dynamic license is a replacement for Professional license. For instance, 10 Professional licenses are removed from a license key and replaced with one pack for 10 Dynamic licenses added to the key. This gives our customers the ability to assign and transfer licenses between users without sending requests to our technical support. It also means that Desktop users no longer require a license key. When the renewal day comes, only an renewed license key should be applied on Server. No need to replace license keys by every Desktop user, as it was previously.

Not sure I understand your question correctly, but I'll try to answer. A pack of Dynamic licenses is linked to only one Server. However, in a license key, there can be multiple Server licenses and multiple packs of Dynamic licenses linked to one Server each. Moving a pack of licenses to another Server can be done via our technical support, if needed.

EasyMorph Desktop obtains a Dynamic license from the Server in the currently configured Server Link. If Desktop switches to another Server Link, then it can obtain a Dynamic license from the new Server given that the new Server also has Dynamic licenses available.

In our case we have one active easymorph server and if it fails, we have a second one which is called “passive” in this case (kind of safety server). If the active fails, the second one is activated so that easymorph remains usable up for the users.

The problem is that if we switch server because first is failing (imagine a problem of hardware on the machine), then users will have to request licenses from a differente package. It means I think that for each server, there must be an associated package. But as our “passive” server (safety server if you prefer) is not used until there’s a failure, it means the pack of licenses associated to that unused server will never be used, and of course that’s not something a company would want :slight_smile:

I understand we can contact you to switch association maybe but the switch must be fast in case of failure, of course we can not call you each time we switch. Do you see the point ?

We can add an equivalent pack of Dynamic licenses to your cold backup Server, but the problem is that Dynamic licenses can only be assigned manually at this point. Which means that if you assign a license to a user on the prod server, you would have to create exactly the same assignment on the cold backup Server to make it work seamlessly in case of switch.

Alternatively, when switching to cold backup, the license assignment table can be copied from the failed Server, if it’s still physically accessible. However, it may not be the case depending on failure type, so I wouldn’t go this route.

Automatic license assigned to users will be available in a later version and will resolve this problem.

Your first suggestion, I mean add en equivalent pack to our cold backup server seems fine. I mean I understand the users will have to request a license again but that’s not a big constraint as it’s just clicking on a button. It is not required that the switch is instant and totally transparent. Our users can understand there was a failure and it had impact.

Ok so it’s nice, we would have a solution.