@danielstocker Thank you so much for bringing this to our attention. I have this assigned to the service lead to be investigated further and will make an update when we have greater clarity.

@Mike-Ubezzi-MSFT @mike-urnun-msft

Thanks for looking into this.

Do you need any more information to progress this?

@danielstocker can you provide more background about what was your original issue which leads to this discovery? I am not sure to properly understand the implication to set it improperly (what you mentioned as an unintentional swap)

Hi @ggirard07,

No problem. Let me summarise.
This came up initially because our documentation states that WEBSITE_CONTENTSHARE is required. (see here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

If we export a Functions template from the Marketplace (export template on the last page) we get WEBSITE_CONTENTSHARE as a standard app setting. If we use this, then the following situation can happen.

1) We deploy an ARM template and get an empty function with two slots
2) We deploy to the staging slot
3) We swap to make the content available in production
4) UNINTENDED SWAP as the ARM template is redeployed and app settings are reapplied (this even happens during an incremental ARM deployment as the appsettings resource always overwrites and resets the WEBSITE_CONTENTSHARE setting)
5) Deployment routine now deploys the new code to the staging slot and our production slot is empty rather than containing the previous version. Our production function is "unintentionally" down

The customer in this particular case then pointed to this article https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

This suggests that the setting should be set as a slot setting to fix the behaviour. While this does fix the behaviour in my tests, it seems wrong, because it should not work.

Below is a table of what happened in my tests. (after making it a slot setting)

My (and the customer's) perception is that the slots should not swap at all anymore, but as described in the article, it still works anyway.

I raised this internally as well and people found inconsistent behaviour when changing app settings. (Hence why this is highlighted in my testing grid) For a colleague testing it, updating the app settings, made the slot settings re-apply thus again causing an unintended swap.

This then finally (sorry about the lengthy response) led me to raise the support case where the outcome was "just do not set the setting at all".
My personal tests showed that this does fix the issue, but there is no guidance in the documentation to confirm this, hence why I raised this item.

Hope this helps.
Let me know if anything is unclear.

@danielstocker definitively an important information, especially to understand how the slots and swapping are working for Functions vs a traditional webapp with webjobs.
Also this is not explained either in the slots documentation despite 'WEBSITE_CONTENTSHARE' playing a critical role here. There is only a single screenshot at step 4 representing it, where those values are truncated to make things even more clear...

Hi @ggirard07 and thanks for reading through my diatribe. So what's the way forward from here? :)

@ggirard07 @ggailey777 @mike-urnun-msft

Is more information required to create some documentation clarity around this behaviour? I'm working with a customer who is considering stopping to use function slots because they are unsure about the official guidance around this scenario.

Thanks for your help

@danielstocker Just so that I am clear on what you think will address the documentation issues related to this:

• Remove the WEBSITE_CONTENTSHARE deployment setting from here.
• Add a note in the reference article that WEBSITE_CONTENTSHARE should only be set by the runtime.

Do you think that would be sufficient?

cc. @mattchenderson

Hi @ggailey777
Yes I think that'd be a good solution

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

If it isn't applied then the runtime will generate one for you, i think.

I deployed an ARM with a Consumption-plan and a Function App with a section _Microsoft.Web/sites/config_ named appsettings and the following properties

• FUNCTIONS_EXTENSION_VERSION : "~2",
• FUNCTIONS_WORKER_RUNTIME : "dotnet",
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [storage connectionstring]
• WEBSITE_NODE_DEFAULT_VERSION: 6.5.0

The deployment returned the following error:

      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

After I _also_ removed parameter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, the deployment went without any errors. So, there seems to be some required relation between those two settings.
Although successful, this deployment made me wander if and where function (packages) are physically deployed (and if this case is valid in the first place).

We have been seeing the exact behavior @tjgalama has described and are also wondering where the file shares with the function packages are stored.

Our function apps also include a timer triggered function, so we specify the AzureWebJobsStorage setting as suggested: we would have guessed/hoped the runtime would have used that same connection string for the (now implicit) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, but that isn't the case: in the storage account we specify there, we do see the azure-webjobs-hosts and azure-webjobs-secrets blob containers, but no file shares are present.

I have checked in Kudu for clues and it looks like all the files that needs to be there are in the file system (wherever that is, checked on app-name.scm.azurewebsites.net/api/vfs/), but no reference to either settings (WEBSITE_CONTENTSHARE or WEBSITE_CONTENTAZUREFILECONNECTIONSTRING) is to be seen in the environment tab (appname.scm.azurewebsites.net/Env.cshtml).

Maybe important to mention, our apps are set up with WEBSITE_ENABLE_SYNC_UPDATE_SITE=True and WEBSITE_RUN_FROM_PACKAGE=1.
The apps seem to work, but we would really like some clarity on this point, as we are porting a core business service to Azure Functions and want to figure this one out before rolling out to production.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

We have noticed this same issue over the past few days and need guidance on how to proceed. We have also been following the approach of setting the WEBSITE_CONTENTSHARE as a slot setting to get around the unintentional swap issue but now can't deploy due to this error. I have tried retroactively removing both this and the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING settings to move towards what appears to be the recommended approach of not using either, but these deployments would also fail.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

Remove it and let the runtime pick a name. Thid is how I do it.

@jeffhollan can you give us some clarity please

This says that WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING are _required_: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create-a-function-app

Commenters here think they are _not_ required; ARM thinks they are required?; Azure support thinks that WEBSITE_CONTENTSHARE breaks slot scenarios.

We ended up checking the code of the Azure functions host and it looks like, when running from package, the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting is not used.
We verified it by removing from our ARM template both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE and obtaining good results: our function apps don't have those two settings at all (not even assigned by the runtime) and they don't use file shares in any storage account (at least that we can see).

So one thing to keep in mind is that the filesystem for a webapp/function app looks something like this:

|-data
|-LogFiles
|-site
  |-deployments
  |-tools
  |-wwwroot

When you use run from package, that only replaces the wwwroot folder in this tree. Everything else is provided by the main file system. If you make a consumption or elastic premium function app without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING then the main filesystem is not available outside of the scale unit the function app was created in. This is not a supported/recommended configuration. It means that your function app may not scale beyond the limits of the scale unit it was created in, or if it does, you won't be able to trust that the filesystem state outside of wwwroot stays consistent.

The most recent guidance I've seen from the dev that owns how WEBSITE_CONTENTSHARE interacts with slots is the following:

• WEBSITE_CONTENTSHARE should NOT be a slot setting. An API change that blocks this is rolling out at time of writing.
• At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

Following from my comment above.. I also discovered that the system currently has some inconsistent behavior regarding generating WEBSITE_CONTENTSHARE so that you don't even need to specify it initially. Some of you have been saying that you haven't needed to specify it, while others are getting an error saying its required. As far as I can tell, this behavior works correctly for consumption (i.e. an ARM template for consumption does not need this setting initally) but the same is not true for elastic premium. That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

@paulbatum

• At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

You do realize this kind of break the purpose of an ARM template, right?

That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

What is the final expected configuration here?
Can we get an announcement on Azure/app-service-announcements with proper configuration and official timeline once all this is actually deployed?

Hi, not sure if there's been any development on this. I am still struggling to use ARM templates with WEBSITE_CONTENTSHARE flag. @paulbatum how can I omit a configuration from the ARM template? I had to completely disable the step in order to get it working.

@gustavobmichel Sorry, I dont understand your question. The ARM template is JSON, you edit it as required. It appears as part of the appsettings section, e.g:

          "appSettings": [
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },

Hi @paulbatum, thanks for coming back to me. I thought you mentioned about programatically omitting the settings from JSON template, so that was my question.

As others stated I also thought these two settings were required, so I removed the two from my ARM template.

To test this feature with zero-downtime I created a simple test with the bare mininum infrastructure to test it. I removed all the resources from my resource group and ran the ARM template as part of the release pipeline to create the resources without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE and WEBSITE_RUN_FROM_PACKAGE.

I ran a couple of tests and it is still all working ok using the consumption plan. I'll do some tests this week with the premium tier.

I have also added this configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 as per this link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot-swaps

I have attached my test ARM template for reference.
azuredeploy.txt

Hi @paulbatum, thanks for coming back to me. I thought you mentioned about programatically omitting the settings from JSON template, so that was my question.

As others stated I also thought these two settings were required, so I removed the two from my ARM template.

To test this feature with zero-downtime I created a simple test with the bare mininum infrastructure to test it. I removed all the resources from my resource group and ran the ARM template as part of the release pipeline to create the resources without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE and WEBSITE_RUN_FROM_PACKAGE.

I ran a couple of tests and it is still all working ok using the consumption plan. I'll do some tests this week with the premium tier.

I have also added this configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 as per this link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot-swaps

I have attached my test ARM template for reference.
azuredeploy.txt

Leaving out WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, how does your function know where to get the app code from?

If it helps, we have settled on:

• setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING to the storage account we want the code running from
• not specifying WEBSITE_CONTENTSHARE at all in the arm template (allow it to be auto generated for both slots)
• WEBSITE_RUN_FROM_PACKAGE = 1

I did a lot of testing around these and this seemed like the best configuration to avoid triggering unintentional swaps and knowing where the code was sitting, etc. Also doesn't require managing these settings outside of the ARM template, which I didn't like the idea of (feels like there's not a lot of point to using ARM templates at that point).

The deployment does also seem to work without specifying a WEBSITE_CONTENTAZUREFILECONNECTIONSTRING value at all, but as mentioned we couldn't find out where the code was sitting and the MS support guy handling my ticket seemed to suggest this was a bug and shouldn't be allowed by the platform.

If it helps, we have settled on:

• setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING to the storage account we want the code running from
• not specifying WEBSITE_CONTENTSHARE at all in the arm template (allow it to be auto generated for both slots)
• WEBSITE_RUN_FROM_PACKAGE = 1

I did a lot of testing around these and this seemed like the best configuration to avoid triggering unintentional swaps and knowing where the code was sitting, etc. Also doesn't require managing these settings outside of the ARM template, which I didn't like the idea of (feels like there's not a lot of point to using ARM templates at that point).

The deployment does also seem to work without specifying a WEBSITE_CONTENTAZUREFILECONNECTIONSTRING value at all, but as mentioned we couldn't find out where the code was sitting and the MS support guy handling my ticket seemed to suggest this was a bug and shouldn't be allowed by the platform.

This is exactly what I have found out as well. Thanks for confirming.

My function is having issues with accessing the storage after adding WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_RUN_FROM_PACKAGE. Did you guys add these two configs to both functionapp and slot?

The exact error is: Azure Functions Runtime is unreachable.

That is after I do the first deployment and then I attempt to deploy a new version.

I added my yml file as well.
yml file.txt
deploy.txt

I also updated my ARM template.

My function is having issues with accessing the storage after adding WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_RUN_FROM_PACKAGE. Did you guys add these two configs to both functionapp and slot?

The exact error is: Azure Functions Runtime is unreachable.

That is after I do the first deployment and then I attempt to deploy a new version.

I added my yml file as well.
yml file.txt
deploy.txt

I also updated my ARM template.

I have it on both. Actually I have nothing in my production slot and swap everything in from staging. I have seen this when defining a WEBSITE_CONTENTSHARE or not pointing to the correct storage account where code reside with WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. You need to not point anything anywhere with WEBSITE_CONTENTSHARE. I actually think I saw that error you refer to becsuse of adding a WEBSITE_CONTENTSHARE to environment variables. Make sure you don't have it defined.

Hi @mslot, I think the problem was on my deployment. I was setting it to zipDeploy because I read on this thread https://stackoverflow.com/a/56205917 about setting it on Azure DevOps. After I changed it to standard deployment, everything seems to be working. Thanks for your help.

That behavior is getting fixed, but it will probably take 1-2 months to make its way out.

Any update on this issue? Is the Consumption and Premium behavior now aligned? Can we omit WEBSITE_CONTENTSHARE from the initial ARM deployment and subsequent deployments? How does this affect staging slots? Any updated docs to link to or guidance?

We have essentially settled on the same approach as @thomaswilkin and @mslot but just through experimentation and trial-and-error. Still not even sure how the runtime knows where to find our files since WEBSITE_CONTENTSHARE is not set.

Hi. Not sure how can you guys do it but it seems like I can't deploy with
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING without WEBSITE_CONTENTSHARE. Even through the portal, it gave me an error while trying to set the config;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

On the overview page of the function app I also see this warning message: Storage is not configured, Function scaling will be limited. Click to learn more. I'm running on a premium plan. Any updates or official guideline on how should we config our function apps?

For the Premium plan (not 100% sure about Consumption plan), here is the matrix of what works/doesn't work:

• if you deploy a new resource:
  
  
  
  • if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
  
  
  • if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it fails with Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • if you supply both values, it works
  
  
• if you deploy to an existing resource
  
  
  
  • if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
  
  
  • if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it succeeds (and appears to work fine afterwards) even though WEBSITE_CONTENTSHARE is supposed to be required
  
  
  • if you supply both values, it 'works' in that the ARM part does not fail, but it causes the multiple-restart issue and the MS guidance above is to not set WEBSITE_CONTENTSHARE on the updates
  
  

So there does not appear to be a way to have a single ARM template that works for both scenarios at the moment.

I also see this warning message: Storage is not configured, Function scaling will be limited. Click to learn more . Havent had website WEBSITE_CONTENTAZUREFILECONNECTIONSTRING or WEBSITE_CONTENTSHARE. Just as Korkiak mention, any updated or official guideline?

We've recently started seeing the message "Storage is not configured, Function scaling will be limited. Click to learn more" in the Azure Portal for existing Azure Functions that were deployed four weeks ago. We have never used WEBSITE_CONTENTAZUREFILECONNECTIONSTRING nor WEBSITE_CONTENTSHARE and that have worked fine until now.

@paulbatum Seems like this issue is getting more activity over the last few days since the 'Storage is not configured, Function scaling will be limited' message started showing up in the portal. Any new guidance on the correct way to configure all of this?

I have just encounted the 'WEBSITE_CONTENTSHARE' cannot be a slot setting error as mention above when deploying a new Function App for the first time in serveral months using a template that has worked fine before.
The template has 'WEBSITE_CONTENTSHARE' as a slot setting and defined in both the Function App and deployment slot appsettings as per the following article that has also be mention above:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
Reading this thread removed this as a slot setting and tried various combinations of setting 'WEBSITE_CONTENTSHARE' and I'm not getting the same behaviour as others. I can can deploy with no errors as below:

• Specify 'WEBSITE_CONTENTSHARE' for both Function App & Deployment Slot
• Specify 'WEBSITE_CONTENTSHARE' for Function App only

If I do not specifiy 'WEBSITE_CONTENTSHARE' at all in the template I get the "Required parameter WEBSITE_CONTENTSHARE is missing" error.

So please can we have an update on what the actual settings should be as I can't deploy to production with this current behaviour.

Hey everyone, sorry for all the confusion here. We were trying to be smart by having the Azure Portal tell you when you may run into scaling issues with your configuration, but we goofed up the logic and so now people may be seeing the warning incorrectly. We're working on a fix but in the meantime here's how to validate if you may run into scaling issues with your app or not:

If you're running on elastic premium or consumption, then you must meet one of the following criteria:

1. You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined

or

1. If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

We should have a fix for this out by next week sometime.

Thanks @ehamai - for # 2 when you say 'set to something other than empty, 0, or 1' - is that correct? arent 0 and 1 opposites? (We have ours set to 1 and we assumed that meant yes/true (do run from package) as documented here: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package)

Hi Elliott, many thanks for the extremely swift reply.

So just to clarify:
When deploying from an ARM template to the Consumption plan and using a deployment slot but No zip/package

• I should define both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE on both the Production and Staging slot.

• I should NOT define WEBSITE_CONTENTSHARE as a deployment slot setting on either slot.

Best regards

Owain

From: Elliott Hamai notifications@github.com
Sent: 22 June 2020 17:31
To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com
Cc: Owain Winterbone (ITCS - Staff) O.Winterbone@uea.ac.uk; Manual manual@noreply.github.com
Subject: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE should not be used accroding to support (#36458)

Warning: This email is from outside the UEA system. Do not click on links or attachments unless you expect them from the sender and know the content is safe.

Hey everyone, sorry for all the confusion here. We were trying to be smart by having the Azure Portal tell you when you may run into scaling issues with your configuration, but we goofed up the logic and so now people may be seeing the warning incorrectly. We're working on a fix but in the meantime here's how to validate if you may run into scaling issues with your app or not:

If you're running on elastic premium or consumption, then you must meet one of the following criteria:

1. You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined

or

1. If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cecd3322262374fb9ffb608d816c9ad12%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284402737046987&sdata=woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cecd3322262374fb9ffb608d816c9ad12%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284402737056941&sdata=StHshC6EtV6A%2BLi3g7x0xfNx56POAYnwjMWihEf%2BCYM%3D&reserved=0.

@briandunnington - Yeah sorry it's confusing.

• 0 means disabled
• 1 means run from a local zip but for that to work properly, you need to also have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined by the first statement.

@OwainWin - Sorry I'm confused by your question. You asked if you should and should not include WEBSITE_CONTENTSHARE.

I believe you should have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined on both the production and staging slot.

Thanks @ehamai - so back to the original question of this thread: what is the guidance for setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in an ARM template that works for initial and subsequent deployments? For the Premium plan (not 100% sure about Consumption plan but believe it is the same), here is the matrix of what works/doesn't work:

• if you deploy a new resource:
  
  
  
  • if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
  
  
  • if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it fails with Required parameter WEBSITE_CONTENTSHARE is missing
  
  
  • if you supply both values, it works
  
  
• if you deploy to an existing resource
  
  
  
  • if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
  
  
  • if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it succeeds (and appears to work fine afterwards) even though WEBSITE_CONTENTSHARE is supposed to be required
  
  
  • if you supply both values, it 'works' in that the ARM part does not fail, but it causes the multiple-restart issue and the MS guidance above is to not set WEBSITE_CONTENTSHARE on the updates
  
  

So there does not appear to be a way to have a single ARM template that works for both scenarios at the moment.

Hi Elliott

What I meant to say for the second point was that the WEBSITE_CONTENTSHARE should be define as an application setting but it should not be made a Deployment slot setting.
So it should not have the tick as below:

[cid:[email protected]]

From: Elliott Hamai notifications@github.com
Sent: 22 June 2020 18:38
To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com
Cc: Owain Winterbone (ITCS - Staff) O.Winterbone@uea.ac.uk; Mention mention@noreply.github.com
Subject: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE should not be used accroding to support (#36458)

Warning: This email is from outside the UEA system. Do not click on links or attachments unless you expect them from the sender and know the content is safe.

@OwainWinhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665654874&sdata=x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw%3D&reserved=0 - Sorry I'm confused by your question. You asked if you should and should not include WEBSITE_CONTENTSHARE.

I believe you should have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined on both the production and staging slot.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&sdata=ctK99d4qO2YuIN%2F07lwuHC0wNut%2Fx8LjgLd7v55rTAM%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PEPPJE7NN6RO5D4SSLRX6JGNANCNFSM4IJGDPBQ&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&sdata=wXaMW%2Fx%2B5RXDtrfiQgHeZYtpc%2BhLyI9w6f9ut9NTFjM%3D&reserved=0.

@paulbatum

• At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

You do realize this kind of break the purpose of an ARM template, right?

That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

What is the final expected configuration here?
Can we get an announcement on Azure/app-service-announcements with proper configuration and official timeline once all this is actually deployed?

This is a big blocker for us. We need to be able to use the same ARM template to deploy to a new resource group that we would use to deploy to an existing resource group. We specifically run our ARM templates in Complete mode to help provide a little more context.

Right now, our ARM template looks sort of like this:

{
  "apiVersion": "2016-08-01",
  "type": "Microsoft.Web/sites",
  "name": "[variables('functionAppName')]",
  "location": "[variables('defaultLocation')]",
  "kind": "functionapp",
  "properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  },
  "resources": [
    {
      "name": "slotconfignames",
      "type": "config",
      "apiVersion": "2016-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "appSettingNames": [
          "SomeSlotSpecificSetting"
        ]
      }
    },
    {
      "name": "staging",
      "type": "slots",
      "apiVersion": "2016-08-01",
      "location": "[variables('defaultLocation')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "AzureWebJobsStorage",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "AzureWebJobsDashboard",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "SomeSetting__Foo",
              "value": "[parameters('someSettings').foo]"
            },
            {
              "name": "SomeSetting__Bar",
              "value": "[parameters('someSettings').bar]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "dotnet"
            },
            {
              "name": "SomeSlotSpecificSetting",
              "value": "abc 123"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ],
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName'))]",
    "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  ]
}

Take note of the following details: We are specifying our configuration _on the staging slot_, not the production slot. What this allows us to do is deploy new settings (and updates to existing ones) to the staging slot first. So, our DevOps pipeline does this:

• Step 1) Deploy ARM template to resource group
• Step 2) Deploy functions app to staging slot
• Step 3) Run some smoke tests against the staging slot
• Step 4) Swap the staging and production slots

The problem, though, is that because WEBSITE_CONTENTSHARE is being set inside the ARM template, the production slot and the staging slot are immediately taking the new version of the application right after Step 2 (before a swap even occurs). I believe this is what people are talking about when they say "unintended swap operation".

We _DO NOT_ want to set production slot settings in our ARM template, and we _DO NOT_ want any of the production slot settings to be removed as a result of our ARM template running. The way that deploying ARM template in Complete mode works is that if we specify any settings for the production slot, then all the settings that are not explicitly specified are removed automatically.

I hope this all makes sense. We are currently attempting to remove WEBSITE_CONTENTSHARE from our ARM template, in hopes that the runtime will generate the value in all scenarios and no longer lead to "unintended swaps".

Hi all, I am the primary developer for deployment slots and I will address your concerns regarding setting WEBSITE_CONTENTSHARE, and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:

Here is the official guidance:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: This should always be set as it tells app service that you are using azure files for content storage.

WEBSITE_CONTENTSHARE:

• This can now be omitted completely from you ARM templates for Consumption sku functions which will auto-generate the field and avoid unintended swaps. This means you can use the same template for creation and updates thereafter.

• Unfortunately, we found that this auto-generation of WEBSITE_CONTENTSHARE was overlooked for Elastic Premium ski so the issue of having to include it during creation and omit it during updates still stands. The fix for this is currently rolling out and has reached half our fleet. It should be completely rolled out in the next 2 weeks and after than the guidance will be the same for both skus and WEBSITE_CONTENTSHARE can be omitted completely.

Hope that addresses some of your concerns!

@shubDhond Thank you so much. Can we get an official update on the documentation?

@shubDhond for windows consumption plans if I provide only WEBSITE_CONTENTAZUREFILECONNECTIONSTRING I get an error via arm template deployment saying WEBSITE_CONTENTSHARE is missing.
I dont need to use slots. If omitt both the deployment goes through but bu I get the warning "storage is not configured.function scalling will be limited".

Whats the guidance on consumption plans w.r.t those two parameters I am using .net core windows consumption plan ?

Ditto! I also get this error. When will this be fixed?

I have the same issue on consumption and elastic plan, it's causing us a lot of issues with automated deployments.

I have had some success with omitting WEBSITE_CONTENTSHARE for Premium when deploying settings directly in the Microsoft.Web/sites properties (siteConfig, appSettings), but not when specifying the settings as a separate resource using Microsoft.Web/sites/config with "type": "config".

@shubDhond This issue is definitely not fixed. On the Windows Consumption plan if you deploy a template with only the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and without the WEBSITE_CONTENTSHARE you will get the error "WEBSITE_CONTENTSHARE is missing".

Trying to use the App Service deployment tasks in Azure DevOps and setting only the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING will also produce a HTTP 400 Error.

Automation of Azure Function apps on the consumption plan is currently totally broken.

Having the same issue as @clawrenceks

We are also experiencing the same issue as @clawrenceks.
We also cannot set only WEBSITE_CONTENTAZUREFILECONNECTIONSTRING without WEBSITE_CONTENTSHARE through the Azure portal. We also have WEBSITE_RUN_FROM_PACKAGE set to 1.

I'm also not sure how this will work when you have your ARM template deployment mode set to Complete? Will it not remove the generated app setting WEBSITE_CONTENTSHARE?

Like most, we're also lost.

I now have my ARM template successfully deploying my function app into a Windows Consumption Plan. When deployed, the message Storage is not configured, Function scaling will be limited. Click to learn more is no longer displayed. Slot swaps are also working as expected.

My main findings from this process are:

If you currently have an Azure Function app WITHOUT the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE application settings, I believe the only way to fix this is to re-deploy your app, ensuring that the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting is in place as part of the app service creation.

Having the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING in place as part of the resource creation is key. When using ARM my findings are that it must be deployed as an app setting during the main app service deployment, with a resource type of Microsoft.Web/sites. Having a separate resource type of Microsoft.Web/sites/config in your ARM template to deploy the application settings will not work.

I do not include the WEBSITE_CONTENTSHARE setting in my ARM template. This is created by the runtime when my ARM template is deployed. This is a sign that the deployment is working well. With the approach described here, I am able to deploy the initial resources and then re-deploy the template multiple times without receiving errors related to the WEBSITE_CONTENTSHARE setting.

A separate key requirement for me was that the production site application settings should only be deployed during the initial resource creation. The only way I wanted to get new (future) application settings into the production site is via a slot swap. To achieve this I added some logic into my ARM template to handle the following.

1) App settings in the ARM template will only be deployed to the production site during initial site creation, they will not be added to the production site as part of future deployments.

2) App settings in the ARM template are always applied to the staging slot. They are then swapped into production using a swap slot.

To achieve the above, the appSettings for the production site in my ARM template are conditional. If the resource does not exist, I deploy the full set of app settings in the template (to ensure that the app service is created correctly). If the resource has already been created, I pass a null for the app settings. When deployed this retains the app settings that are already in place for the production site.

I'm also totally confused. If WEBSITE_CONTENTAZUREFILECONNECTIONSTRING is required for Consumption plans, but it cant be configured to stick to a slot, how am I supposed to swap between a staging and production slot where I want each one to run on a different storage account? This has been possible with Web Apps forever, and seems like a very common use case. As far as I can tell, swapping function app slots is completely broken / unusable until this is fixed. Would love for someone to tell me why / how I'm wrong though! I know the original issue references ARM templates, but this seems like a much more broad problem.

Same issue on Elastic Premium plan. Deploying to stage slot same ARM template with same WEBSITE_CONTENTSHARE makes production slot pointing to same binaries as stage slot.
Can't deploy without WEBSITE_CONTENTSHARE at all as I get 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest' error

I am confused. What is the correct thing to do?

If you're running on elastic premium or consumption, then you must meet one of the following criteria:

You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined

or

If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

as @ehamai says?

or

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: This should always be set as it tells app service that you are using azure files for content storage.

WEBSITE_CONTENTSHARE:

This can now be omitted completely from you ARM templates for Consumption sku functions which will auto-generate the field and avoid unintended swaps. This means you can use the same template for creation and updates thereafter.

Unfortunately, we found that this auto-generation of WEBSITE_CONTENTSHARE was overlooked for Elastic Premium ski so the issue of having to include it during creation and omit it during updates still stands. The fix for this is currently rolling out and has reached half our fleet. It should be completely rolled out in the next 2 weeks and after than the guidance will be the same for both skus and WEBSITE_CONTENTSHARE can be omitted completely.

Hope that addresses some of your concerns!

as @shubDhond says?

I get an error if I have an azure function on consumption plan with no WEBSITE_CONTENTSHARE (actually the production slot has no appsettings at all) on either slot and i:

1. deploy ARM to staging slot
2. swap
3. redeploy to staging slot

Then it tells me that i need the WEBSITE_CONTENTSHARE. It is like it can't generate a share for the old production slot. I haven't tried to remove the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, because this thread says not to do it, except @ehamai, that tells me that i can do it, if i do a "WEBSITE_RUN_FROM_PACKAGE".

The funny thing is, I have a function running with this setup, but with a ~2 runtime instead of ~3, and it is working. Is there a problem with ~3 and deployment slots?
This is very confusing.

No matter what this spontaneous slots swap is very scary, anyway as we need to create both of these WEBSITE_ variables we are filling in ARM the latter ourselves too as per definition here. The webapp configuration diagonostic tool on the portal shows no error anymore.

reassign: @mattchenderson

Any update on this?

We too have been adviced by Microsoft support that the "WEBSITE_CONTENTSHARE" property must be set. When it is not possible to set it as a slot setting this is quite problematic for our build pipelines and ARM templates. Please advice!

I agree too. It's really time for some explanation on how to use slots here!

I also agree, this thread was started over 15 months ago and there is still no stable resolution.
We cannot use slots until this has been properly resolved with a trusted solution, slots are a fantastic feature but they need to be reliable.

Hi all,

Extremely sorry for the delay in response here, this thread was not being monitored as well as it should have been.

To address the confusion, the behaviour described by @clawrenceks above is correct as of now. For sites which do not already have Azure Files storage configured, you will be required to provide both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE. Once these are provided and your app is now configured to run on Azure Files, you can omit WEBSITE_CONTENTSHARE from your templates thereafter to avoid inadvertently swapping your content.

The way the API currently works is that on site creation ('Microsoft.Web/sites' resource) if you provide WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and not WEBSITE_CONTENTSHARE, then a content share will be generated for you. However on updates of an existing 'Microsoft.Web/sites' resource or a 'Microsoft.Web/sites/config' resource, the API looks to see if there is already a value for WEBSITE_CONTENTSHARE for the app and if it isn't present, it throws an error.

I assume this was to protect against customers inadvertently wiping their content while switching to azure files, in the case they provide WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and we generate a new WEBSITE_CONTENTSHARE for them (essentially wiping their content since this share would be new). This is much safer during site creation because the site would start with a clean slate anyways and we don't risk wiping your content.

I can totally understand the confusion though for you all wishing to azure files. I will have to think of how to best address this while still keeping our update operations safe from wiping your content. As for now the guidance for you all who don't have azure files configured and wish to make the switch, you'll need to provide both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE for the initial switch and then the guidance would be the same to omit WEBSITE_CONTENTSHARE from your template thereafter.

If there are any suggestions as to how you'd like to see the update case handled, that would be greatly appreciated as well!

@shubDhond so we need to deploy connectionstring and contentshare appsettings on the first deploy to the production slot, but not on deploys after that. Is there any way of doing this automatically? Like detect if a resource has been deployed through ARM? Or do we manually need to pass this info into the ARM ( fx through a parameter that tells if this is the first deployment?

@mslot unfortunately I don't think its possible to tell within a template whether a resource already exists or not but this should be possible with this (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-use-conditions) combined with a parameter passed to the template telling it whether the site is configured for Azure Files already. This can be determined by getting the site and seeing whether the app settings have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE.

@mslot unfortunately I don't think its possible to tell within a template whether a resource already exists or not but this should be possible with this (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-use-conditions) combined with a parameter passed to the template telling it whether the site is configured for Azure Files already. This can be determined by getting the site and seeing whether the app settings have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE.

I really hope this gets fixed soon. It renders use of slots useless in my workflow. It needs to be fully automtatic. This solution is a hack workaround in my eyes and it doesn't make sense to introduce when it is working for webapps because it diverges to much on something that should just work the same introducing "black magic" for others coming in to a project.

I really hope this gets fixed so we can start using it.I think it keeps a lot of folks from using this feature.

@mslot I totally understand your pain with this and I'm sorry we weren't able to identify this issue sooner. I will speak to the devs who initially implemented this behaviour in the coming week and see if we can find a safe fix for this issue which could avoid the possibility of customers inadvertently moving to using an empty azure files share for their content. Once we have a proposed solution I'll update here.

@shubDhond I don't really understand the Azure Files "part" of this. I deploy my Azure Function project using Azure DevOps by first creating a deploymentslot, deploy to this and then swap. I'm using "RunFromPackage" deployment method and this does not seem to work when using a classic StorageAccount. I'm NOT using Azure Files and I seem to have the same problem related to the WEBSITES_CONTENTSHARE setting for the two slots.

Hi @cannehag could you please open a new issue for this? There may be some strange behavior happening with the RunFromPackage app setting being marked as sticky causing similar symptoms to what is described here. I would suggest a new issue so we don't add confusion here as the issues are likely unrelated.