I’m having some issues using the “Run an Azure Powershell Script”, which I’m pretty sure isn’t me - hoping someone can help me get around or understand the problem.
I’ve linked my azure account successfully, it validates and when not using the azure powershell script I can access the account without an issue. I understand the script should login for you and use the subscription you select.
If I just use a Write-Host command I get the following error. I know it was suggested to use the variable ‘OctopusDisableAzureCLI’, surely this just defeats the point of this script?
Note: I’m using Octopus Deploy in the cloud so don’t have access to the machine this is running from.
I get same error when trying to run Powershell in a “Deploy Azure Web App” step.
I just started using a Service Principal instead of certificate (Azure App Service deployments no longer working), and then the PowerShell scripts are failing with a similar error message as ryanwatson. It doesn’t matter if the script is an inline script in the step, or in Deploy.ps1. I even tried just having “#” as a script, and it failed.
I have the same issue with more than one Azure subscription, but not all(!). The same deploy step works fine on one subription, but not on another (just switching targets).
If I remove the Powershell script, the deployment works.
Think I’ve quite literally this second worked out the problem - I’m still verifying this in practice, but seems to be true thus far. It has to do with the way that azure now generates the keys, there are loads of special characters in them.
Will update if I sort a work around.
YES YES YES
Created a new key, and now it works!!!
Thank you! I spent a day on this
Just using a new key solved your problem?
I’ve generated probably 100 now - but they all have weird characters that require escaping. If I was to run this locally from a powershell script, I need to use the ` (backtick) to work around the problem, but then it requires me to hardcode the key.
How did you manage?
hmm, I must have been super lucky… Tomorrow I will test with my other failing deployments, that is using other Service Principals. It’s 10 PM for me.
Got one that worked in the end, completely ridiculous - but yeah, it needs one without characters it needs to escape, spent a couple hours generating and trying again.
Don’t use “App Registrations (Preview)”
Thanks for keeping active in this thread and it appears that you have found a great work-around here. If I understand correctly, I believe you may be able to explicitly set a key value of your choosing for your Service Principal Account / App registration via PowerShell.
One example is when creating a new Service Principal account in our Azure Docs we use the example:
$password = "correct horse battery staple"
In that case, the key in Octopus would be
correct horse battery staple. I hope this helps prevent anyone else from needing to cycle through many keys before finally getting one without special characters for the time being.
I hope to get back here with an update for this from within Octopus regarding how we could handle keys that have special characters