It looks like the workaround before was to ensure that a service principal was being used or to use a custom expression for account/web app. I’m using a service principal and specifying the resource group + app using variables scoped to environment.
Could you please confirm what version of Octopus you’re using?
Could you also confirm whether you’re using a non-standard/isolated Azure Environment (I.e. US Government, China or Germany), or is this just a standard Azure subscription?
We haven’t been able to reproduce this issue in the latest version of Octopus on a standard Azure subscription. We setup a PremiumV2.Small app service and set the step to legacy mode, substituting variables the same as your screenshot or using the dropdown values directly (as well as setting up a new Azure Target), but both approaches succeed with a premium app service.
If you’re using a Service Principal account (which is mandatory now), you shouldn’t need to resort to variable substitution. That was just a workaround for people stuck using Management Certificates.
Are you in a position where you can upgrade to latest? If not, once we know what version you’re using, we can try and reproduce and confirm whether this is a known issue with that particular version.
Yes, it’s just a standard subscription in US East. I’m thinking that it’s at least 2 years old now. Right now we’re on v2018.8.10, so I’ll get that updated and see what changes and report back.
I’m thinking that this may be something intermittent with Azure. I’m deploying two different web apps for this project. Same subscription, same resource group. Both were failing yesterday. Only 1 is failing today.
I wanted to follow up on this issue. We updated to 2018-10-1 LTS and are still seeing this error pop up. I went through and started to re-create the process step to deploy the web app and am seeing the error here as well now. This error popped up immediately after I attached the service principal to the process as part of the account and web app section.
Note that we are using the “legacy” mode as we have not yet switched to deployment targets for these older deployments.
We have tried to reproduce the error without success. The call that is failing is trying to retrieve a list of your Azure web apps. I’ve uploaded a Linqpad script here that does the failing call to help with debugging: http://share.linqpad.net/s3pndm.linq
Stack Overflow suggests that this error occurs when tooling is out of date. We tried running that Linqpad script using old versions of Microsoft.Azure.Management.Websites and it returned our web apps, including those with an SKU “PremiumV2”.
We explored some permissions combinations, thinking that maybe the service principal does not have access to the service plan. This always resulted in a clear access denied errors, it appears the service principal must have read access on the subscription for this call to work.
I have a few questions that I’m hoping will help troubleshoot the issue. Does it happen intermittently? You mentioned you have two web apps with the same subscription and resource group, are they both failing? Could you send the stack trace from the deployment when the error happened?
