I seem to be having the same issue. I switched my Orchestrator CE settings to Tenant mode to enable the Upload button on the libraries tab. After reading through the forum, I’ve done the following:
My Studio version is 2019.4.4 CE
Completely Quit the Robot from the Tray and restarted it - the status shows Connected/Licensed
As a policy, I do not use blank spaces in any of my naming conventions - my tenant name has underscores in it
I’ve already upgraded all the packages to the latest versions
I have a simple, no frills, Vanilla application that simply opens a browser window. I use it as a test application when I set up an Orchestrator to make sure everything works. Now, it looks like this package isn’t even loading!
I was just reading over your other topics and thought I would move your 2nd post into it’s own topic to ensure it was seen by the community as the OP of the other topic was from 2018.
For the Orchestrator CE, as you found out you don’t have the option to upload libraries when configured for Host. In order to do so you need to switch to per tenant mode.
But in doing so you are looking at a different NuGet repository that is empty. You can see this in Studio by reviewing your Manage Packages > Settings. The Tenant source will change from
I’m not aware if there is a way to preload the tenant, so you may have to do this manually (Download from the host feed and re-upload in the tenant feed). I assume this is a restriction of cloud as you could make alternate configures for private.
Another potential option is to add alternate feeds into the configuration for Studio and Robot rather than fetching the additional libraries from Orchestrator.
I can upload my custom library to a the new feed. But my problem isn’t limited to just this. After I switched to Tenant mode, and later switched back to Host mode, none of my other RPA applications (that are as simple as opening a browser window) work when they are executed as a Job.
In summary, my Orchestrator instance is broken. How do I remedy this situation. I can still do without a custom library. But for the Orchestrator not to run as it should has now become a greater issue.
I would suggest reviewing your Studio and Robot Logs to see if it gives any indication. I personally do not use Cloud/CE Orchestator.
My best guess is being in host or tenant mode for the libraries there is a separation between NuGet repositories as well as file system permissions (on Orchestrator). My first thought would be to restart your Robot service as it will most likely be holding onto the wrong repository reference or has cached what is available in the repository that it could query whether it was empty/non-existent/had content in between you changing the Orchestrator setting.
UiPath Studio when opening a project will store this information in the .local folder. I’m not sure how long it takes to invalidate the cache, but you can simple delete it and re-open the project to regenerate it.
I imagine for a published package when ran on a Robot behaves similarly.
Yes. I have a package that I use as a standard check when I set up CE Orchestrator instances.
This package doesn’t even launch. Therefore, I can’t see what the possible reasons are.
I’ve already restarted the Robot service several times.
If you are willing to share screenshots (hiding sensitive info) of what you are seeing, might be able to offer other suggestion, but I am not able to replicate what you are describing other than the NuGet repositories being cached between switching.
Could always try reaching out to the Cloud Support folks to see if they have any suggestions.
I wish I could. I’ve been building several PoCs to demonstrate RPA to various teams in my organization using the Community Edition and if I remember correctly, I don’t think I qualify for a Cloud Support Ticket.
Let me investigate all the other pointers you’ve given me.
Here is the error. This is the only error I get at the Job Level when a package is run. It’s almost instantaneous and the Job exists with very little resistance. This Orchestrator is separate from the Studio and is on a different machine. Therefore, a package is explicitly uploaded after building it in the Studio environment.
One good things is that the PoC jobs scheduled prior to this happening are working fine. Nothing new deployed since this failure is working. I suspect the URLs in the last two lines of the error message hints at an issue.
UPDATE (GOOD News followed by BAD ! Please see screen shots below)
I was able to solve the earlier reported problem of getting the packages to load by doing the following:
Restart the Robot from the Tray
After the Robot restarted, hit the Disconnect button and save changes
Then open the Robot and then reconnect by submitting the machine key and URL - I verified that my machine key had not changed and therefore, this was not the reason for the reported problem
After this, the job that previously did not run ran as expected.
Also on a side note: A few weeks ago, there was an unscheduled notification from Uipath to restart our robots - which I did, and reported back into that forum thread. Therefore, not restarting the Robot was also not the reason for the reported problem.
The BAD News:
We did a clean restart of the box so that the Robot could reload during Startup
After that, all previously scheduled jobs that had run normally, and a new package that I uploaded to the Orchestrator got stuck in Pending status.
Despite the Robot being connected and Licensed, I’m getting a License related message from the Orchestrator. Please see screen grabs below. What changed on the Licensed model? And why would I not be able to run something on a perfectly valid free license?
Looks like this issue has been resolved as well . The cause was beyond my control. A few days ago, the IT team moved the VM from one Data Center to another. And the fact that it was moved from EST to Central time zone was lost in the game. I discovered it by accident last night when I worked an hour more because I was logged into the RDP and it was showing time an hour earlier, until I looked at my mobile device and realized this discrepancy!
I changed the Time zone setting in my Tenant, and that resulted in this problem in my Job triggers.
I had to open all the schedules and change their time zones from EST to Central and update them. Since then, the test job I scheduled to run every 5 minutes is working as intended.
Behavior of Timezone Mismatch:
Before the change, the Trigger schedules defined in EST were ahead of the Robot agent that was running on a machine set to the Central Time zone. Looks like the trigger schedules couldn’t reach down to the agent due to this time discrepancy.
Therefore, I could see the Jobs kicking off on the Orchestrator, but they would exit immediately without actually doing anything!
This possibly explains why, after a clean restart of the VM, I could execute the jobs manually from the Robot tray, but not as a Job from the Cloud Orchestrator.
Here below is the job track from a few minutes ago.
I will observe my jobs for another two days before I conclusively mark this fix as a solution.