UiPath.settings not populating when connecting robot to Orchestrator


I’ve installed the UiPath Robot service on an Azure VM with the following command using the latest installer:
UiPathPlatform.msi ADDLOCAL=DesktopFeature,Robot,RegisterService,Packages,StartupLauncher /q

I then proceeded to enable High Density Robots as is the documentation and provisioned each robot in Orchestrator.

When I connect the Robot service to Orchestrator with the following command (replacing the variables with the actual values):
C:\Program File (x86)\UiPath\Studio\UiRobot.exe --connect -url {domain} -key {key}

the nuget and activities feed properties are not populated, in the UiPath.settings file, with the values from Orchestrator. When I perform the same commands on my local machine the nuget and activities feed properties are populated in my local settings as expected.

This is causing processes to fail when running on the robot as it cannot download the external dependencies. I can fix the problem manually by filling in the nuget and activities feed settings with the correct values but this isn’t ideal, especially as I’m trying to automate the provisioning of new robots.

Has anyone else had any experience of this or who could perhaps suggest anything to fix the issue?



Let me understand. When doing the same steps on the Azure VM, as on your local environment, the robot is not able to run any process from Orchestrator?

Correct. When a job is started in Orchestrator to run on the robot on the Azure VM it fails because it can’t fin the activities package. In my case specifically, it can’t find the Web.Activities package so it throws an exception when trying to make a HTTP request.

When I set the ActivitiesFeed setting to “{muOrchestratorUrl}/nuget/activities” this fixes the issue, but it should set that automatically when first connecting to Orchestrator.

Are you using 2018.1 (robot and orchestrator) ?

Orchestrator is version 2017.1
I’m not sure how to find the Robot version.

Check add remove programs-uipath

Robot version on the VM is 18.1.1
Robot version on local machine is 17.1

if robot is 18.1, its expected. uipath settings from programdata is no longer populated with that data.

Ok thanks. Have you got a link to the 18.1 documentation then as the documentation I’m looking at still references these settings?

Also how does the robot now know where to download dependencies from if not from these settings?

the settings are saved, just that we don`t displayed them in settings - its a security feature

Ok then. So back to my original issue, where it originally couldn’t download the activities package until I populated the setting manually, is there anyway to check if the setting has been updated successfully after connecting to Orchestrator?

give me some clear steps:

  • from where are you running a job? (orchestrator or robot tray? )
  • whats missing? the job package or the activities used in the job/workflow?
  • if you create a new workflow, in 18.1 studio, publish it to orchestrator then run it on the 18.1 robot, it will work?
  • The job is triggered to run from Orchestrator.
  • The job package is downloaded correctly on the VM to C:\ProgramData\UiPath\Projects
  • Without setting the ActivitiesFeed setting manually, when the process executes in throws the following exception (in this case the process has a dependency on the Web.Activities package):
    Execution error : System.Xaml.XamlObjectWriterException: Cannot create unknown type ‘{http://schemas.uipath.com/workflow/activities}HttpClient’
  • After setting the ActivitesFeed setting manually and restarting the Robot service I no longer get this error.

do you have that web activities package also locally, in Local feed?
i am thinking if there is a problem with your DNS - in settings, how do you write the activities feed? full name or IP?

Yes, the package does exist in the local feed at:
C:\Program Files (x86)\UiPath\Studio\Packages\UiPath.WebAPI.Activities.1.1.6479.13209.nupkg

When I set the activities feed setting myself I use the full name e.g.

and the robot was provisioned with the same full name (in robot tray), right?
can you clean event viewer before running the job and getting the error? there should be some error logs generated by the robot, i would like to see them

I’ve done some testing now but I can’t seem to be able to replicate my original issue.

I’ll mark this thread as solved but if it comes again I’ll reopen.


1 Like