In my VM where I have a Robot connected via Unattended License, when I launch processes from Orchestrator, the process attempts to install the package, but always fails to download the package. I’ve gone back and forth with UiPath support to no avail, but recently I stumbled across the ability to start a troubleshooting session on the machine.
When starting the troubleshooting session, the UiPath Assistant now shows all the processes in our Orchestrator, and if I launch an unattended process off on that VM with the Troubleshooting Session active, it has zero issues downloading/installing the package and running the process.
My Robot account that is setup in Orchestrator has the Tenant level “Allow Automation User” role and within the folder is also has the “Automation User” roles as suggested by other support threads.
What is the Troubleshooting Session doing that is not enabled by default with the current setup I’ve got? When I open Studio on the machine to verify package feeds, the Orchestrator Host Feed is notably not present, but during the Troubleshooting Session that feed automatically populates into Studio. I also go from having the session status being “Robot Error” with the message “Communication Error with Robot Service. Please check Robot Service Status.” The Robot service is running, I’ve restarted the service and any related UiPath services multiple times, but nothing changes.
I do notice that when I enable the Troubleshooting Session on the machine, the EDR Protection is disabled. In my machines pane in Orchestrator, the EDR Status for our machines are all “N/A”, this was not a parameter on our old Orchestrator version, but it is now in 2023.10.15. We’ve been behind on Orchestrator versions but we’re updating rapidly in an effort to migrate to UiPath Cloud hosting soon, so resolving these issues would be ideal.
Let me know if you have any ideas on what to address or attempt with the VM/Orchestrator Settings.
Your own observation is the key — when the Troubleshooting Session starts, EDR protection is disabled, and everything works. That’s your culprit.
Add EDR exclusions for UiPath processes (UiPath.Service.Host.exe, UiRobot.exe, UiPath.Executor.exe, etc.)
Whitelist your Orchestrator URL and its NuGet feed endpoint from SSL inspection.
To confirm before involving your security team, manually disable EDR on the VM for a few minutes and run an unattended job. If it succeeds, you have your proof.
Hey, thanks for the quick response. In regards to point #3, what I’m assuming is the case is there is no EDR on the VM to begin with, at least to my knowledge. There is no csagent service running (from what I’ve found that should be the CrowdStrike EDR service name), so I would assume that the EDR is already technically disabled. Is there a way to not require the machine in Orchestrator to check for EDR restrictions? Or is there something else I should be looking for in order to manually disable the EDR on the VM?
Generally mainreason might be the ip restrictions or firewall blocks and the policies might be different and hence troubleshoot might be working..to veridy either disable or add urls to exception list
Alternately check what feeds are present ..below is the document which contains where to check config
