my on-premise Enterprise ORCH was upgraded to 2018.4.5. To take advantage of the centralised licensing management from the host, I uploaded the license file to the “host” tenant. From here I have distributed the licensens to the other tenants (including my own PROD tenant). This works perfectly!
Now I update my robot clients. These are located on VDIs and work nicely. However, after upgrading to 4.5 I find that the licensing is inconsistent and blocks my execution.
In ORCH I assign an UNATTENDED license to each of my 2 robots (a third robot still runs 2018.4.3). Since I have 4 licenses, there is 1 spare. ORCH reports OK. Upon logging in to the 2 robots they alle report correct version + “licensed” in both the Robot Panel and in mouse-over on the process bar.
However, when I try to execute a process, which used to run perfectly on the robots, I now get a message “You need to be registered”. I get this error both when starting a process from ORCH (both manually + scheduled) and locally on the robot from the Robot Panel.
This has happened before: Sometimes after an update of the OS or after every 3rd boot or so, I get a licensing problem. Normally I solve this by assigning the robot in question a different license, e.g. NonProduction, and then back to Unattended. This used to work every time. But not this time.
When I remote connect to my robot and on ORCH change the license type for that robot, I can see it happening right away - so the connection there. As soon as I change the license the robot shows the change. Back and forth.
Both on ORCH and locally the logs state “Licence error: You need to be registered” + stack dump. Sometimes a manual request on the local robot (whilst logged in) I get “Action not possible. Valid license is required!”.
I have enough licenses according to ORCH, and the robot clients all report “2018.4.5, licensed”. Still the licensing does not validate.
I refreshed the ORCH License File from regUtil and uploaded it to the host tenant. No effect. I removed the license form the host and deployed it to my “real” tenant. No effect.
Interestingly though, my third (2018.4.3) robot has no problem at all…
Is it a bug in the 4.5-client maybe?