Octopus Azure Deployment fails with cryptic error


running v1.6.3.1723.

I’ve set up something similar to what’s described here: http://help.octopusdeploy.com/discussions/questions/1763-update-webconfig-during-azure-deployment

The main difference being I am deploying a worker role and a web role at the same time. When deploy runs it successfully creates a new cspkg file (called My.Azure.cspkg) and deletes the original. The azure deployment step seems to figure this out saying it’s deploying the new file but then dies. The complete log is attached.

It starts to try to upload the file the blob storage and stops with:

2014-05-01 07:47:25 INFO [Azure Upload] Uploading package to Azure blob storage: C:\Octopus\Data\tmp\deployments-35620\My.Azure.cspkg
2014-05-01 07:47:25 DEBUG [Azure Upload] Connecting to Azure blob storage
2014-05-01 07:47:26 ERROR Microsoft.WindowsAzure.ServiceManagement.ServiceManagementClientException: “An exception occurred when calling the ServiceManagement API. HTTP Status Code: 400. Service Management Error Code: . Message: . Operation Tracking ID: .”
at Microsoft.WindowsAzure.ServiceManagement.ServiceManagementChannelProxy.GetRestFaultFromComEx(CommunicationException cex)

So its a pretty meaningless error message. 400 usually means bad request i think? Does 1.6 still work with Azure? I have installed the management certificate and checked all the settings in the azure step match.

tasks-114596.txt (18 KB)

Attaching my deploy scripts too. Also i tried deliberately making the service and storage name wrong and it made no difference. same error msg.

I also removed the management certificate and still got the exact same error msg.

PreDeploy.ps1 (1 KB)

Deploy.ps1 (620 Bytes)

Hi Sam,

Thanks, this is indeed a strange error as Octopus 1.6 should continue to work with Azure.

Can you try running a proxy like Fiddler to see the HTTP requests? The 400 error might contain more details about what’s going wrong:


Hi Paul,

I tried this again yesterday and I seem to have it working now. I am not sure exactly what the issue was. The only thing I think I changed was prefixing the paths defined in deploy.ps1 with “.”

So the 400 just went away.

Thanks for the follow-up, glad it is sorted out.