Node-locked Studio License question

I have a question regarding node-locked studio licenses.

In our Citrix-enabled world, we have a Citrix machine that has been imaged and assigned to a specific user. That user starts Studio and completes licensing, which activates that license.

Six months later, that user is replaced by a new user. Our company would now “re-image” the machine for the new user, meaning the Studio license information is cleared out/reset.

The NEW user now logs into that machine and needs to activate the node locked license for the machine again.

QUESTION: CAN HE DO SO? Will the license reactivate? Or will he/she get an error saying the license for that machine is already in use?

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.

are your machine ID’s constant because you are cloning VM’s ?

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

1 Like

Thanks @ClaytonM and everyone… I’ll give it a shot!

1 Like

Please update us when you get the answer…I am curious to know :blush:

But you can’t have two systems on the same network with the same mac address

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.

I hope I explained that better.


1 Like

We are rolling out Orchestrator Activation for Studio in 18.4 - (similar with attended bots licensing). Which means that you will be able to move the license between users at any time. Will this help?


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?

1 Like

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.

Ok. We’ll discuss about it.

Till then 2 short notes:

  1. I think Citrix use case is covered - we have introduced the Attended Floating Robot and we’ll do the same for Studio. Floating means that you don’t need to define the machine but only the user. -
  2. If we are going to introduce concurrent for Studio that we’ll work exclusively concurrent in the first phase at least. As of now you can not have both Named User and Concurrent under the same tenant.
1 Like

Thank you, @badita … very good conversation/information.