WEBSITE_CONTENTOVERVNET setting is not legacy and is required for Functions and Logic Apps using Secured Storage Accounts

Question

WEBSITE_CONTENTOVERVNET setting is not legacy and is required for Functions and Logic Apps using Secured Storage Accounts

Martin 5

The MS documentation states the following app setting for Logic Apps and Function Apps is legacy

WEBSITE_CONTENTOVERVNET and should be replaced with WEBSITE_CONTENTSHARE when using private endpoints on secure storage accounts with Azure Functions and Logic Apps.

This is however false and without WEBSITE_CONTENTOVERVNET set to 1 our deployments fail. Setting the new WEBSITE_CONTENTSHARE setting doesn't work.

Please update your documentation as this setting is clearly not legacy and is required otherwise deployments with Terraform fail. See below documents which should be corrected:

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-17T11:25:28.5533333+00:00

Hello @Martin,
The WEBSITE_CONTENTOVERVNET setting is indeed described as a legacy app setting in the Microsoft documentation. It has been replaced by the vnetContentShareEnabled site property. The documentation states that a value of 1 for WEBSITE_CONTENTOVERVNET enables your function app to scale when the storage account is restricted to a virtual network, but it is only required when using WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.

If you are experiencing deployment failures when using Terraform without this setting, it may be necessary to ensure that your configurations align with the requirements of your specific deployment scenario, including any dependencies on the legacy setting.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-18T13:36:50.6233333+00:00

Hi @Martin,

Just checking in to see if above information was helpful. If you have any further updates on this issue, please feel free to post back.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-21T14:01:28.49+00:00

Hi @Martin,

If you had a chance to review my response to your question and found it helpful, please consider clicking "Upvote" on my post. Let us know if you need any further assistance.
ESD-TechMonkey 0 Reputation points

2025-12-16T01:29:27.8766667+00:00

I seem to have encountered this issue/inconsistency as well.

Deploying azfunctions w/ the backing storage account over "public" but default deny, locked down to the vnet/subnet that the function is integrated with, even after making sure:

Subnet is delegated to Microsoft.Web/serverFarms, storage service endpoint is assigned for the vnet, outboundvnetrouting is enabled via .bicep (reverting the API version to Microsoft.Web/sites@2024-04-01, but still the VnetContentShareEnabled property is not enabled - seemingly has to be enabled manually (either through the Az module or Portal GUI ( Virtual Network Integration -> Configuration routing -> ``Content storage), or else the functions simply can't start, return 500 errors or simply "not available".

1 answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-17T11:25:28.5533333+00:00

Hello @Martin,
The WEBSITE_CONTENTOVERVNET setting is indeed described as a legacy app setting in the Microsoft documentation. It has been replaced by the vnetContentShareEnabled site property. The documentation states that a value of 1 for WEBSITE_CONTENTOVERVNET enables your function app to scale when the storage account is restricted to a virtual network, but it is only required when using WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.

If you are experiencing deployment failures when using Terraform without this setting, it may be necessary to ensure that your configurations align with the requirements of your specific deployment scenario, including any dependencies on the legacy setting.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-18T13:36:50.6233333+00:00

Hi @Martin,

Just checking in to see if above information was helpful. If you have any further updates on this issue, please feel free to post back.
Ranashekar Guda 2,905 Reputation points Moderator

2025-04-21T14:01:28.49+00:00

Hi @Martin,

If you had a chance to review my response to your question and found it helpful, please consider clicking "Upvote" on my post. Let us know if you need any further assistance.
ESD-TechMonkey 0 Reputation points

2025-12-16T01:29:27.8766667+00:00

I seem to have encountered this issue/inconsistency as well.

Deploying azfunctions w/ the backing storage account over "public" but default deny, locked down to the vnet/subnet that the function is integrated with, even after making sure:

Subnet is delegated to Microsoft.Web/serverFarms, storage service endpoint is assigned for the vnet, outboundvnetrouting is enabled via .bicep (reverting the API version to Microsoft.Web/sites@2024-04-01, but still the VnetContentShareEnabled property is not enabled - seemingly has to be enabled manually (either through the Az module or Portal GUI ( Virtual Network Integration -> Configuration routing -> ``Content storage), or else the functions simply can't start, return 500 errors or simply "not available".

Answer 1

Hello Martin,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your WEBSITE_CONTENTOVERVNET setting is not legacy and is required for Functions and Logic Apps using Secured Storage Accounts.

To resolve the issue, follow the below steps:

Step 1:

Configure content over VNet and the content share: az functionapp config appsettings set -g <rg> -n <app> --settings WEBSITE_CONTENTOVERVNET=1 WEBSITE_CONTENTSHARE=<share> WEBSITE_CONTENTAZUREFILECONNECTIONSTRING="<conn>" (see App settings reference and Azure Files note on connection strings in the Functions host repo GitHub. - https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings

Step 2:

Lock Storage to your VNet and/or add a Private Endpoint for File subresource: az storage account network-rule add --account-name <sa> --vnet-name <vnet> --subnet <subnet>; az network private-endpoint create -g <rg> -n <pe> --vnet-name <vnet> --subnet <subnet> --private-connection-resource-id <saId> --group-ids file Configure Azure Files endpoints; Functions VNet+PE tutorial.

Step 3:

Enable regional VNet integration and force egress through VNet: az functionapp vnet-integration add -g <rg> -n <app> --vnet <vnet> --subnet <subnet>; az functionapp config appsettings set -g <rg> -n <app> --settings WEBSITE_VNET_ROUTE_ALL=1 (Networking options; background on WEBSITE_VNET_ROUTE_ALL (blog) ()). - https://github.com/Azure/azure-functions-host/issues/8135. This helps you integrate the Function and route all.

Step 4:

If supported in your API version, turn on the newer site flag: az resource update -g <rg> -n <app> --resource-type Microsoft.Web/sites --set properties.vnetContentShareEnabled=true (documented in App settings/site properties and surfaced in the built‑in policy for config routing (AzAdvertizer). - https://learn.microsoft.com/en-us/azure/storage/files/storage-files-networking-endpoints

Step 5:

Implement model dependencies so the Function app waits for storage+share+networking: resource func 'Microsoft.Web/sites@2023-01-01' = { name: appName; properties:{}; dependsOn: [ fileShare, privateEndpoint, vnetLink ] } (see Microsoft sample template with VNet integration (GitHub) () and the VNet + Private Endpoint tutorial flow. - https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-vnet and https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options gives more insight.

Step 6:

Ensure *.file.core.windows.net resolves to the PE via a Private DNS zone and link: az network private-dns zone create -g <rg> -n privatelink.file.core.windows.net && az network private-dns link vnet create -g <rg> -n <link> -z privatelink.file.core.windows.net -v <vnet> --registration-enabled false Azure Files DNS forwarding; Private Endpoint DNS zones. This helps in fixing DNS for Private Endpoint.

Step 7:

Lastly, for secured storage scenarios, keep WEBSITE_CONTENTOVERVNET=1 alongside the content share settings to ensure reliable content mounting over private networking (see App settings reference and practical PE guidance for Functions (blog) ()). - https://www.thebestcsharpprogrammerintheworld.com/2020/07/20/website_vnet_route_all-and-azure-functions/

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Share via

WEBSITE_CONTENTOVERVNET setting is not legacy and is required for Functions and Logic Apps using Secured Storage Accounts

1 answer

Your answer