Configuration and management FAQs for Web Apps in Azure

If you plan to move App Service resources to a new resource group or subscription, there are a few limitations to be aware of. For more information, see App Service limitations.

Currently, Azure Application Insights doesn't support the move operation. If your original resource group includes an Application Insights resource, you cannot move that resource. If you include the Application Insights resource when you try to move an App Service app, the entire move operation fails. However, Application Insights and the App Service plan do not need to be in the same resource group as the app for the app to function correctly.

For more information, see App Service limitations.

App Service limitations shows you how to move resources to either a new subscription or to a new resource group in the same subscription. You can get information about the resource move checklist, learn which services support the move operation, and learn more about App Service limitations and other topics.

To set the server time zone for your web app:

1. In the Azure portal, in your App Service subscription, go to the Application settings menu.
2. Under App settings, add this setting:
   • Key = WEBSITE_TIME_ZONE
   • Value = The time zone you want
3. Select Save.

For the App services that run on Windows, see the output from the Windows tzutil /L command. Use the value from the second line of each entry. For example: "Tonga Standard Time". Some of these values are also listed in the Timezone column in Default Time Zones.

To get the list of outbound IP addresses for your web app:

1. In the Azure portal, on your web app blade, go to the Properties menu.
2. Search for outbound ip addresses.

The list of outbound IP addresses appears.

To set up a dedicated or reserved IP address for inbound calls made to your Azure app website, install and configure an IP-based TLS/SSL certificate.

Note that to use a dedicated or reserved IP address for inbound calls, your App Service plan must be in a Basic or higher service plan.

A common cause of backup failure is that some files are in use by the application. Files that are in use are locked while you perform the backup. This prevents these files from being backed up and might result in a "Partially Succeeded" status. You can potentially prevent this from occurring by excluding files from the backup process. You can choose to back up only what is needed. For more information, see Backup just the important parts of your site with Azure web apps.

To remove the headers from the HTTP response, update your site's web.config file. For more information, see Remove standard server headers on your Azure websites.

Currently, the Web Apps feature of Azure App Service is in compliance with PCI Data Security Standard (DSS) version 3.0 Level 1. PCI DSS version 3.1 is on our roadmap. Planning is already underway for how adoption of the latest standard will proceed.

PCI DSS version 3.1 certification requires disabling Transport Layer Security (TLS) 1.0. Currently, disabling TLS 1.0 is not an option for most App Service plans. However, If you use App Service Environment or are willing to migrate your workload to App Service Environment, you can get greater control of your environment. This involves disabling TLS 1.0 by contacting Azure Support. In the near future, we plan to make these settings accessible to users.

For more information, see Azure App Service web app compliance with PCI Standard 3.0 and 3.1.

In Standard and Premium App Service plans, when you deploy your web app to App Service, you can deploy to a separate deployment slot instead of to the default production slot. Deployment slots are live web apps that have their own host names. Web app content and configuration elements can be swapped between two deployment slots, including the production slot.

For more information about using deployment slots, see Set up a staging environment in App Service.

To review WebJob logs:

1. Sign in to your Kudu website (https://*yourwebsitename*.scm.chinacloudsites.cn).
2. Select the WebJob.
3. Select the Toggle Output button.
4. To download the output file, select the Download link.
5. For individual runs, select Individual Invoke.
6. Select the Toggle Output button.
7. Select the download link.

If you use Hybrid Connections to access SQL Server, a Azure .NET update on May 10, 2016, might cause connections to fail. You might see this message:

Exception: System.Data.Entity.Core.EntityException: The underlying provider failed on Open. —> System.OverflowException: Arithmetic operation resulted in an overflow. or (64 bit Web app) System.OverflowException: Array dimensions exceeded supported range, at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake

Resolution

The exception was caused by an issue with the Hybrid Connection Manager that has since been fixed. Be sure to update your Hybrid Connection Manager to resolve this issue.

To add a URL rewrite rule, create a web.config file with the relevant config entries in the wwwroot folder. For more information, see Azure App Services: Understanding URL rewrite.

At the site level, you have two options for controlling inbound traffic to App Service:

• Turn on dynamic IP restrictions. To learn how to turn on dynamic IP restrictions, see IP and domain restrictions for Azure websites.
• Turn on Module Security. To learn how to turn on Module Security, see ModSecurity web application firewall on Azure websites.

If you use App Service Environment, you can use Barracuda firewall.

In the App Service shared tenant environment, it is not possible to block specific ports because of the nature of the infrastructure. TCP ports 4020, 4022, and 4024 also might be open for Visual Studio remote debugging.

In App Service Environment, you have full control over inbound and outbound traffic. You can use Network Security Groups to restrict or block specific ports. For more information about App Service Environment, see Introducing App Service Environment.

You have two options for capturing an F12 trace:

• F12 HTTP trace
• F12 console output

F12 HTTP trace

1. In Internet Explorer, go to your website. It's important to sign in before you do the next steps. Otherwise, the F12 trace captures sensitive sign-in data.
2. Press F12.
3. Verify that the Network tab is selected, and then select the green Play button.
4. Do the steps that reproduce the issue.
5. Select the red Stop button.
6. Select the Save button (disk icon), and save the HAR file (in Internet Explorer and Microsoft Edge) or right-click the HAR file, and then select Save as HAR with content (in Chrome).

F12 console output

1. Select the Console tab.
2. For each tab that contains more than zero items, select the tab (Error, Warning, or Information). If the tab isn't selected, the tab icon is gray or black when you move the cursor away from it.
3. Right-click in the message area of the pane, and then select Copy all.
4. Paste the copied text in a file, and then save the file.

To view an HAR file, you can use the HAR viewer.

If you try to connect an Azure web app to a virtual network that's connected to Azure ExpressRoute, it fails. The following message appears: "Gateway is not a VPN gateway."

Currently, you cannot have point-to-site VPN connections to a virtual network that is connected to ExpressRoute. A point-to-site VPN and ExpressRoute cannot coexist for the same virtual network. For more information, see ExpressRoute and site-to-site VPN connections limits and limitations.

Currently, connecting an App Service web app to a virtual network that has a static routing (policy-based) gateway is not supported. If your target virtual network already exists, it must have point-to-site VPN enabled, with a dynamic routing gateway, before it can be connected to an app. If your gateway is set to static routing, you cannot enable a point-to-site VPN.

For more information, see Integrate an app with an Azure virtual network.

Sometimes, creating an App Service Environment fails. In that case, you see the following error in the Activity logs:

ResourceID: /subscriptions/{SubscriptionID}/resourceGroups/Default-Networking/providers/Microsoft.Web/hostingEnvironments/{ASEname}
Error:{"error":{"code":"ResourceDeploymentFailure","message":"The resource provision operation did not complete within the allowed timeout period."}}

To resolve this, make sure that none of the following conditions are true:

• The subnet is too small.
• The subnet is not empty.
• ExpressRoute prevents the network connectivity requirements of an App Service Environment.
• A bad Network Security Group prevents the network connectivity requirements of an App Service Environment.
• Forced tunneling is turned on.

For more information, see Frequent issues when deploying (creating) a new Azure App Service Environment.

You can't delete an App Service plan if any App Service apps are associated with the App Service plan. Before you delete an App Service plan, remove all associated App Service apps from the App Service plan.

You can create a scheduled WebJob by using Cron expressions:

1. Create a settings.job file.
2. In this JSON file, include a schedule property by using a Cron expression:

   { "schedule": "{second}
   {minute} {hour} {day}
   {month} {day of the week}" }
   

To perform penetration testing, submit a request.

To learn how to use a custom domain name with an App Service app that uses Azure Traffic Manager for load balancing, see Configure a custom domain name for an Azure web app with Traffic Manager.

For detailed documentation for authentication and authorization in App Service, see docs for various identify provider sign-ins:

• Azure Active Directory

When you create a new website by using Web Apps in Azure, a default sitename.chinacloudsites.cn domain is assigned to your site. If you add a custom host name to your site and don't want users to be able to access your default *.chinacloudsites.cn domain, you can redirect the default URL. To learn how to redirect all traffic from your website's default domain to your custom domain, see Redirect the default domain to your custom domain in Azure web apps.

The quickest way to find the version of Azure .NET that's installed in App Service is by using the Kudu console. You can access the Kudu console from the portal or by using the URL of your App Service app. For detailed instructions, see Determine the installed .NET version in App Service.

If Azure Autoscale hasn't scaled in or scaled out the web app instance as you expected, you might be running into a scenario in which we intentionally choose not to scale to avoid an infinite loop due to "flapping." This usually happens when there isn't an adequate margin between the scale-out and scale-in thresholds. To learn how to avoid "flapping" and to read about other Autoscale best practices, see Autoscale best practices.

Autoscale is triggered when metrics exceed preconfigured boundaries. Sometimes, you might notice that the capacity is only partially filled compared to what you expected. This might occur when the number of instances you want are not available. In that scenario, Autoscale partially fills in with the available number of instances. Autoscale then runs the rebalance logic to get more capacity. It allocates the remaining instances. Note that this might take a few minutes.

If you don't see the expected number of instances after a few minutes, it might be because the partial refill was enough to bring the metrics within the boundaries. Or, Autoscale might have scaled down because it reached the lower metrics boundary.

If none of these conditions apply and the problem persists, submit a support request.

To turn on compression both for static and dynamic content types, add the following code to the application-level web.config file:

<system.webServer>
    <urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>

You also can specify the specific dynamic and static MIME types that you want to compress. For more information, see our response to a forum question in httpCompression settings on a simple Azure website.

To migrate sites from Windows and Linux web servers to App Service, you can use Azure App Service Migration Assistant. The migration tool creates web apps and databases in Azure as needed, and then publishes the content. For more information, see Azure App Service Migration Assistant.

For all certificates issued after 9/1/2020, the maximum duration is now 397 days. Certificates issued before 9/1/2020 have a maximum validity of 825 days until they are renewed, rekeyed etc. Any certificate renewed after 9/1/2020 will be affected by this change and users may notice a shorter validity on their renewed certificates. GoDaddy has implemented a subscription service that both meets the new requirements while honoring existing customer certificates. Thirty days before the newly-issued certificate expires, the service automatically issues a second certificate that extends the duration to the original expiration date. App Service is working with GoDaddy to address this change and make sure that our customers receive the full duration of their certificates.