Is WEBSITE_VNET_ROUTE_ALL redundant or soon to be?

Question

Recently started seeing this new warning message

   The legacy app setting 'WEBSITE_VNET_ROUTE_ALL' is being overridden by the vnetRouteAllEnabled configuration setting.  

Question 1: Does this mean WEBSITE_VNET_ROUTE_ALL is now or going to be redundant? Is there a timeline? As per my testing, WEBSITE_VNET_ROUTE_ALL = 1 seems to be honoured and the function's outbound IPs are not used.

Found that we have vnetRouteAllEnabled at two places in the resource JSON.
The first one is at https://resources.azure.com/subscriptions/394875-fake-subscription-id-098/resourceGroups/testrg/providers/Microsoft.Web/sites/funapp1 under siteConfig

• This value is always null and doesn't reflect the "Route All" setting from the Azure portal.

The second one is at https://resources.azure.com/subscriptions/394875-fake-subscription-id-098/resourceGroups/testrg/providers/Microsoft.Web/sites/funapp1/config/web under properties and it reflects the value from the "Route All" setting in the Azure portal.

Question 2: Why do we have two representations of the same field and why is one always null?

Answer 1

Hi @rubberduckdev,

We've updated our docs recently to address this change, you can have a look here.

Does this mean WEBSITE_VNET_ROUTE_ALL is now or going to be redundant? Is there a timeline? As per my testing, WEBSITE_VNET_ROUTE_ALL = 1 seems to be honoured and the function's outbound IPs are not used.

vnetRouteAllEnabled will replace WEBSITE_VNET_ROUTE_ALL application setting. The setting won't go away but flipping this toggle will overwrite the value if it's been priorly set. The reasoning behind it is to make it more visible when you want to have application routing across a regional vnet.

Why do we have two representations of the same field and why is one always null?

vnetRouteAllEnabled isn't new and has been part of Microsft.Web/sites and Microsoft.Web/sites/config for a while. I don't know of hand why the property is listed for both objects but Microsoft.Web/sites/config is the object that really represents the app service. More than likely, that's why you see the property set under that object and not under /sites