Wouldn’t it make more sense to go for user linked licenses in this case rather than node-locked?
I think because the license is linked the Device ID which would change when the image is recreated (unless you can configure it to be the same somehow), the license wouldn’t reactivate. You could raise a ticket to get it reset however.
Actually, for our development group, the machine IDs are constant, which is why I thought node-locked would be the better option… so when user X leaves the department and is replaced by user Y, it’s my understanding from speaking with the Networking group that the machine’s image would be reset, but it would have the same machine number when it went to user Y.
My concern is that when user Y goes to re-license that machine number, will user Y get an error when he tries to activate the license telling him that the machine with that device ID is already activated? And if so, what would be the procedure to correct that?
The problem with named user licensing is, based on my understanding, the license STILL looks at the machine number in ADDITION TO the user ID… which actually makes this type of license considerably more restrictive in my mind. This didn’t seem to make sense to me at first, but then I realized that if the only requirement was user ID, that user could go to 1,000 different machines and activate as many licenses as he/she wanted.
I wish UiPath would just come up with a concurrent licensing scheme similar to their unattended robot licenses for all their products… then you could just install and activate Studio wherever you wanted, and your only requirement would be the number of users currently active.
Machine ID’s are usually constant because in IT, they use the Mac Address and a system that assigns a ID to that MAC addresss. In order for it to change they would have to change it in their system that keeps track of it.
Studio (and any application really) is installed for the entire machine and the license is stored displaying the Node for that license. I kind of agree that the User should not be associated with the node or license.
I don’t really know if an error occurs when you try to reinstall the license from a different user. To test it you would need to deactivate the license I guess which would defeat the purpose of the test. Maybe you can get it answered from Technical Support or if a license needs clearing, Here
Sorry, I can clarify.
Yeah the MAC address is unique like you said, so basically IT typically has a system that stores the MAC address of every machine when a new machine is deployed. Well each MAC address also has a set of settings associated with it, like the Computer Name, Admin user, Applications to install, and more. So, when they go to Reimage the machine, it references that system and Reimages it with that Computer name and settings. Therefore, the Computer Name will always be the same, unless they were to manually change it in the system to use another Computer Name.
So does this mean that starting with 18.4, we would be able to have a SINGLE LICENSE CODE installed on Orchestrator which would control ALL UiPath access ALL robots (production, test and developer)… plus Studio access as well? Because if the answer to that is YES, then YES, this would be great.
What would the Studio licensing options be? Concurrent user? Would we be able to install Studio on as many machines as we want, with licenses only being consumed when that user starts Studio?
YES… but in practice you should have multiple Orchestrators (1. production & 2. dev/test) so at least two codes for now.
Named User for sure. If one dev is leaving after 6 months you can allocate that license to another one. For Concurrent we’re still discussing when and if to enable it. Do you have developers working concurrent (in shifts?)
We have 2 types of developers right now: in house and consultant. The in-house developers could be considered named user, while I could easily see the consultants being concurrent, as some of them work locally, some are offshore in different time zones, and the individual consultants involved in a project may change during the life of the project.
Speaking personally, I would love to see a concurrent licensing scheme for Studio where Orchestrator controls how many users are logged in simultaneously. This would simplify licensing in Citrix environments, I would think. Granted, it means that any company wanting to activate concurrent licensing would likely have to accept the fact that Studio MUST connect to Orchestrator at log-on (to track the number of concurrent users)… but I would think companies wanting to implement concurrent licensing would find that an acceptable trade-off.