That’s excellent, that will really help me determine the cause, thanks for that I’ll let you know how it goes.
Hi Kartik,
We’re getting there!
I managed to get your script working on our server, it was super helpful because it returns a meaningful error.
If I try to use those settings in the account page it still doesn’t work
L Same error as before.
If I try to run your powershell script from the Octopus script console it also doesn’t work. But the script console will work if I add this to your script:
[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy(’’)
[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true
Is that proxy setting something I need to setup in Octopus somewhere?
Regards
Andrew
Hi Kartik,
Got the account connecting
J I found the proxy settings in Octopus and tentacle manager. I can now try to get an actual deployment
going
Hi Andrew,
Thanks so much for updating us with your progress. Nice work on getting it working!
Please do not hesitate to get in touch should anything come up.
Cheers!
Kartik
Hi Kartik,
I am now having trouble setting up my deployment targets
L
My account works and connects:
Now I need to setup the target to deploy to, I set it to my account, I know this works because it lists the available web apps
However when I view the deployment target I see this:
If I run a health check the log just says
Hi Andrew,
Sorry that you are facing this issue. I tried reproducing the steps to add an Azure Web App on my local instance and was able to get through the health check successfully. We will need some more information to investigate what is going on there. Can you please attach the full task log? Details on how to do this are available here https://octopus.com/docs/support/get-the-raw-output-from-a-task
Alternatively, you can send it to support@octopus.com. Only Octopus staff will be able to access it.
Cheers,
Kartik
Hi Andrew
We wanted to confirm if you have modified the default machine policy to use a custom script? If so, can you please send us the script? At the moment, the Azure targets only run the default machine policy. This is a known issue which can be found here: https://github.com/OctopusDeploy/Issues/issues/5341. The script might help us identify why the Azure target is running into trouble here.
Thanks,
Kartik
Hi Kartik,
I haven’t intentionally done this, the only scripts I’ve been running against azure was the one you sent me
Hi @andrew_w,
This is proving to be quite the mystery, made all the more awkward by our poor timezone overlap.
Good: At this point it sounds like you can set up and test your Azure Service Principal Account through your normal Octopus Server.
Bad: It sounds like Health Checks are failing, which is strange. The health check just checks the Azure Web App actually exists and can be accessed using the Service Principle. What is also strange is that there is no helpful logging nor error message, just an exit code of 1.
Zoom call?
The easiest way forward would be to set up a Zoom call where we can screenshare and get to the bottom of this more quickly, the problem being our time zone overlap again, and we may not be able to get this together until next week. Can you confirm some times which may work for you to do that call? I can join a call most nights of the week after 8PM AEST.
In the meantime
In the meantime there are still some things you can do to isolate what is going wrong:
- Upgrade to the latest release of Octopus Server. If you want to stay on the 2019.6 LTS, please install the latest patch of 2019.6.x. If you are happy to go onto the fast lane, upgrade to the latest possible version of Octopus Server. Learn about release lanes. I’m doubtful this will fix the problem, but it will make it much easier for me to support you moving forward.
- Install an instance of Octopus Server on your own computer and try doing the same thing which is failing on your “real” Octopus Server. This will help isolate the problem down to the environment or the software or the configuration. You can download the latest MSI and set up a trial of Octopus Server in just a few minutes as long as you have SQL Server (even express) accessible on/from your computer.
Hope that helps!
Mike
Hi Michael,
Thanks for getting back to me. I’ve booked another session with our network team to make sure they’re not blocking anything when I do the health check.
After that I’m definitely keen on the zoom call. Can we book in an evening later this week - Wednesday or Thursday?
Regards
Andrew
Hi Andrew,
Thanks for your patience on this.
I am a Continuous Delivery Architect based in the UK and only got back from Annual Leave today. If you have time, book in some time with me and we can jump in and get this working for you. You can book some time with me here.
Thanks
Derek
Hi @andrew_w,
Thanks for your time on the call today.
It looks like the proxy in place is blocking the health checks and these IP’s need to be whitelisted in your proxy configuration to allow for the health check to run successfully.
We’d love to hear how you got on.
Thanks
Derek
Hi Derek,
Thanks for your help. I got the Network team to completely whitelist the server and the error still occurs, they are certain this is not a proxy issue.
I tried the following:
Hi Derek,
I got it working!
My first trick – denying delete permission on the work folder showed me what the error was – no tools folder.
I found the nupkg file for Calamari.Cloud in the c:\programfiles\octopus folder, so I manually extracted it to the tools folder and added a Success.txt file.
Gave it another go and it works.
I then tried an actual deployment, similar problem, 2 more tools missing AzureCLI and AzureCmdlets, I manually extracted the nupkg files and it now deploys
up to Azure J
Any thoughts on what is causing this issue? Manually having to deploy the nuget packages is not a satisfactory solution, we’d need to do that whenever Calamari
or Azure versions are upgraded.
Regard
Andrew
Hi @andrew_w,
That’s great that you got this sort of working. 
Out of interest, what account is your Octopus windows service running under? Could you try running it under Local System or Administrator and check it has the correct permissions for Octopus to work. You can see the required permissions on https://octopus.com/docs/installation/permissions-for-the-octopus-windows-service.
Thanks
Derek
No response?
Hi @andrew_w,
Thanks for coming back to me.
Apologies, I responded a few days back asking what permissions your Octopus service user is running under. Did you not see this? If not, I am really sorry and I have posted it below for you. I think it may be running under an account that doesn’t have the required access.
Hi @andrew_w,
That’s great that you got this sort of working.
Out of interest, what account is your Octopus windows service running under? Could you try running it under Local System or Administrator and check it has the correct permissions for Octopus to work. You can see the required permissions on https://octopus.com/docs/installation/permissions-for-the-octopus-windows-service.
Thanks
Derek
Ah ok yes it probably got lost in my inbox 
I checked the link you sent, I don’t think the service account had full permission on d:\octopus
I tried removing the tools folder to see if it would then create it, but I still get the error. I’ve put the folder back and it’s all good.
I’m not sure if there is much more I can try in our dev server, I may need to give it a go on the production install.
Hi @andrew_w,
Would you be able to apply the permissions to the tools folder and give that a test? You will see a lot of issues if the permissions are not set correctly and I expect this is the issue.
Let me know how you get on.
Thanks
Derek