Recently we had to change the windows proxy for one of our customers. With the new proxy everything seems to work fine. Processes run in the machines can connect to Orchestrator, take and update queue items, etc. But when trying to use the activity DownloadStorageFile we receive this error from the activity “An error occurred while sending the request”.
This activity was working before the proxy was changed. The “old” proxy had no restrictiones but for the new one Systems people had to create exceptions for all the URLs that are accessed from the machines. Any one know what URL or exception has to be added to the proxy configuration in order to make the activity to work?
We’ve checked the activity’s documentation but found nothing about this issue.
We’ve also tried to edit the UiPath.config files (the one in \Studio\ folder as well as the one in \Studio\Rules\net6.0\ folder) adding the new proxy to the section of those files but it didn’t work.
Storage Buckets need proxy exceptions for Azure Blob Storage because DownloadStorageFile uses the Storage Buckets service, not Orch, so your new proxy is blocking file downloads.
Can you verify this on your machine: https://<your_org>.blob.core.windows.net
It looks like the new proxy is blocking some required URLs for the DownloadStorageFile activity. To fix this:
Whitelist Orchestrator URLs: Ensure URLs like https://<orchestrator_url>/odata/ and any storage endpoints are allowed through the proxy.
Check Network Traffic: Use tools like Fiddler or Wireshark to identify which URL is being blocked.
Verify Proxy Settings: Double-check proxy settings in the UiPath.config files and in the Windows registry. Also, ensure the proxy is correctly configured on Orchestrator if needed.
TLS/SSL Issues: Ensure there are no SSL/TLS interception issues by the proxy and that certificates are correctly installed.
@MohammedShabbir thank you for your help. We asked our Customer’s networking team to open the access for *.blob.core.windows.net.
@Monali_Vekariya thank you as well for your help. As mentioned, we asked the networking team to grant access for all the URLs listed in the official documentation. We are waiting for them to update the configuration and, as soon as they tell us, we will repeat tests.
The fact is that we see the buckets in browser and that any other functionality of the robots is working. We have several processes running and accessing the orquestrator and queues with no issue. The problem seems to be only related with the downloadStorageFile activity
After configuring *.blob.core.windows.net as rule in the new proxy, the problem seems to be solved and the process can complete all the actions as required.