Azure DevOps integration

Hi there,
I need support with the Azure DevOps integration please.
I was able to install the Octopus service under our Azure subscription, now I would like to know what’s the best way to push artefacts to the Octopus server (self hosted)?
The connector works fine in Azure, I am able to browse the spaces, when I try using the Octo.dll (in my Azure pipeline), to push artefacts to my Octopus instance, I am getting a connectivity error.
I believe there are some IPs that need to be allowed from our side to the Octopus instance, but browsing the Microsoft pages, it looks like there are about 3500 IPs addresses dedicated to the Azure hosts.
I am probably looking this scenario from the wrong side of the table, I think there is something else I can do to avoid exposing our Octopus server to these 3500 IPs??

Thank you for your time.
Best Regards.

Hi Lucio,

Thanks for getting in touch! Great question, and a couple of potential options come to mind to avoid having to expose Octopus to these IPs.

Probably the easiest way around this would be to instead set up a repository in Azure to store the packages and set up an external feed in Octopus to point at it and pull packages from it.

Alternatively it might work to put an Azure agent on the Octopus server. That should theoretically prevent having to open IPs to push to Octopus.

Would one of those options help get this working as needed? Let me know what you think or if you have any further questions going forward. :slight_smile:

Best regards,


We do something similar, in the end we went for a self hosted Azure Build Agent as that allowed us to control the IP range, in fact we ended up having a secure VPN link and having them talk via private ip for added security.

Hi Marcus,

Thanks for getting in touch! I appreciate you outlining the solution in your case, and great to hear confirmation of it. :slight_smile:

Don’t hesitate to reach out if you have any questions or concerns moving forward!

Best regards,


Hello @Kenneth_Bates
thanks for your reply…
I have created an Azure feed and I can see the uploaded files (from our sel hosted Octopus instance).
Now I am creating the step (in Azure) to create a new-release (using octo.dll) and I am having again the same issues as before - no connection.
What’s the difference between configuring Octopus in Azure (Settings\pipeline\service connections - so I can see spaces and project - working), and the use of Octo.dll (NOT working)?
Aren’t they using both the REST API?

Have you got any solution on the above?

Thank you indeed.
Kind Regards.

Hi Lucio,

There shouldn’t really be any difference, as they are originating at the same source.
Are you able to attach the log where the error is appearing for us to review?


Hi @paul.calvert , thanks for your reply.
There is actually no log for the error because the connection from the azure machine and the Octopus instance is not established.
I am only seeing the following Azure pipeline error:

D:\a\1\s>dotnet “C:\hostedtoolcache\windows\octo\7.3.4\x64/octo.dll” create-release “–space=Spaces-82” “–project=Projects-241” “–releaseNumber=2019.9.0.11852” “–channel=Channels-1857” "–server=https://predeployments.*******.com/" “–apiKey=***” --enableServiceMessages “–deployTo=Environments-241” --progress

Octopus Deploy Command Line Tool, version 7.3.4

Detected automation environment: “AzureDevOps”

System.Exception: Unable to connect to the Octopus Deploy server. See the inner exception for details. —> System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.IO.IOException: The server returned an invalid or unrecognized response.

at System.Net.Http.HttpConnection.FillAsync()

at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean foldedHeadersAllowed)

at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)

— End of inner exception stack trace —

I can edit that integration, I can browse the spaces and the projects, but I can’t interact with it using the octo.dll
Any idea?
Thank you for your time.

Hi @Kenneth_Bates and @paul.calvert,
have you got any update on the above?

Thank you in advance.

Kind Regards,

Hi Lucio,

Thanks for keeping in touch, and my apologies about the delay in getting back to you on this one.

System.IO.IOException: The server returned an invalid or unrecognized response. seems to imply that something network related is interfering, probably a proxy. Is it possible that’s the cause of this issue in your environment? If it is, you could configure your proxy settings in the Octo.exe create-release command in Azure Devops, under the Additional arguments section. The create-release documentation page outlines all of the arguments, where the proxy specific ones are as follows.

--proxy=VALUE          [Optional] The URL of the proxy to use, e.g., ''.
--proxyUser=VALUE      [Optional] The username for the proxy.
--proxyPass=VALUE      [Optional] The password for the proxy. If both the username and password are omitted and proxyAddress is specified, the default credentials are used.

To continue troubleshooting from this point, you could use a network monitoring tool such as Wireshark during a release creation attempt to hopefully provide some more information on what could be going on.

I hope this helps, and I look forward to hearing back. :slight_smile:

Best regards,


Hello @Kenneth_Bates
Thanks for the reply.
Unfortunately there is no proxy in our network as far as I know.
I strongly believe that the issue is from where I am calling the API.

  • octo.dll or octo.exe is called from the Azure (build/pipeline) agents
  • the Octopus connector is configured in the main Azure configuration page

The connector call is working and I can browse Spaces or Projects, the Agent API call (octo.exe or .dll) instead, is not able to connect to the Octopus instance configured in the connector above, and the IT guys here says that the issue could be Azure changing the Agents pool IPs during time…

Am I the only one having the same issue?

Thank you for your time.

Hi Lucio,

Thanks for keeping in touch and letting me know the possibility that it could be Azure changing the pool IPs. This is actually the first and only report of behavior like this that I’ve seen at least. I’d be very interested to hear if your IT guys find anything relevant here. Using Wireshark to monitor the network might be a good followup step to hopefully narrow down where the issue could be.

Best regards,


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.