20180116-Azure Webapp Toc

Table of Contents
App Service on Linux

Overview
About Web Apps
About App Service on Linux
Compare hosting options
Quickstarts
Create .NET Core app
Create PHP app
Create Node.js app
Create Java app
Create Ruby app
Deploy custom Docker image
Tutorials
1 - App with DB
.NET Core with SQL DB
Ruby with MySQL
PHP with MySQL
Node.js with MongoDB
Python custom container with PostgreSQL
1 - Custom Docker image
2 - Map Custom Domain
3 - Bind SSL Certificate
4 - Add CDN
Samples
Azure CLI
Azure PowerShell
Concepts
How App Service works
App Service plans
App Service Environment
Authentication and authorization
Choose deployment type
How-To guides
Configure application
Use app settings
Deploy to Azure
Deploy the app
Set deployment credentials
Create staging environments
Map custom domain
Buy domain
Map domains with Traffic Manager
Migrate an active domain
Secure app
Buy SSL cert
Authenticate users
Configure TLS mutual authentication
Scale app
Scale up server capacity
Scale out to multiple instances
Monitor app
Quotas & alerts
Enable logs
Manage app
Back up an app
Restore a backup
Clone an app
Move resources
Reference
Azure CLI
Azure PowerShell
REST API
Resources
Azure Roadmap
Pricing
Quota Information
Service Updates & Release Notes
Azure Updates
Azure SDK for .NET 3.0
Azure SDK for .NET 2.5.1
Best practices
Samples
Videos
Cookbooks
Reference Architectures
Deployment Scripts
Troubleshooting
Troubleshoot with Visual Studio
Troubleshoot Node.js app
Troubleshoot HTTP 502 & 503
Troubleshoot performance issues
FAQ
Web Apps overview
10/30/2017 • 2 min to read • Edit Online
Azure App Service Web Apps (or just Web Apps) is a service for hosting web applications, REST APIs, and mobile
back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python.
You can run and scale apps with ease on Windows or Linux VMs (see App Service on Linux).
Web Apps not only adds the power of Microsoft Azure to your application, such as security, load balancing,
autoscaling, and automated management. You can also take advantage of its DevOps capabilities, such as
continuous deployment from VSTS, GitHub, Docker Hub, and other sources, package management, staging
environments, custom domain, and SSL certificates.
With App Service, you pay for the Azure compute resources you use. The compute resources you use is
determined by the App Service plan that you run your Web Apps on. For more information, see App Service plans
in Azure Web Apps.
The following 5-minute video introduces Azure App Service Web Apps.
Why use Web Apps?

Here are some key features of App Service Web Apps:
Multiple languages and frameworks - Web Apps has first-class support for ASP.NET, ASP.NET Core, Java,
Ruby, Node.js, PHP, or Python. You can also run PowerShell and other scripts or executables as background
services.
DevOps optimization - Set up continuous integration and deployment with Visual Studio Team Services,
GitHub, BitBucket, Docker Hub, or Azure Container Service. Promote updates through test and staging
environments. Manage your apps in Web Apps by using Azure PowerShell or the cross-platform command-line
interface (CLI).
Global scale with high availability - Scale up or out manually or automatically. Host your apps anywhere in
Microsoft's global datacenter infrastructure, and the App Service SLA promises high availability.
Connections to SaaS platforms and on-premises data - Choose from more than 50 connectors for
enterprise systems (such as SAP), SaaS services (such as Salesforce), and internet services (such as Facebook).
Access on-premises data using Hybrid Connections and Azure Virtual Networks.
Security and compliance - App Service is ISO, SOC, and PCI compliant. Authenticate users with Azure Active
Directory or with social login (Google, Facebook, Twitter, and Microsoft). Create IP address restrictions and
manage service identities.
Application templates - Choose from an extensive list of application templates in the Azure Marketplace, such
as WordPress, Joomla, and Drupal.
Visual Studio integration - Dedicated tools in Visual Studio streamline the work of creating, deploying, and
debugging.
API and mobile features - Web Apps provides turn-key CORS support for RESTful API scenarios, and
simplifies mobile app scenarios by enabling authentication, offline data sync, push notifications, and more.
Serverless code - Run a code snippet or script on-demand without having to explicitly provision or manage
infrastructure, and pay only for the compute time your code actually uses (see Azure Functions).
Besides Web Apps in App Service, Azure offers other services that can be used for hosting websites and web
applications. For most scenarios, Web Apps is the best choice. For microservice architecture, consider Service
Fabric. If you need more control over the VMs that your code runs on, consider Azure Virtual Machines. For more
information about how to choose between these Azure services, see Azure App Service, Virtual Machines, Service
Fabric, and Cloud Services comparison.
Next steps
Create your first web app.
ASP.NET
PHP
Node.js
Java
Python
HTML
Introduction to Azure App Service on Linux
Web App is a fully managed compute platform that is optimized for hosting websites and web applications.
Customers can use App Service on Linux to host web apps natively on Linux for supported application stacks. The
following sections lists the application stacks that are currently supported.
Languages
App Service on Linux supports a number of Built-in images in order to increase developer productivity. If the
runtime your application requires is not supported in the built-in images, there are instructions on how to build
your own Docker image to deploy to Web App for Containers.
LANGUAGE SUPPORTED VERSIONS
Node.js 4.4, 4.5, 6.2, 6.6, 6.9-6.11, 8.0, 8.1
PHP 5.6, 7.0
.NET Core 1.0, 1.1
Ruby 2.3
Deployments
FTP
Local Git
GitHub
Bitbucket
DevOps
Staging environments
Azure Container Registry and DockerHub CI/CD
Console, Publishing, and Debugging

Environments
Deployments
Basic console
SSH
Scaling
Customers can scale web apps up and down by changing the tier of their App Service plan
Locations
Check the Azure Status Dashboard.
Limitations
The Azure portal shows only features that currently work for Web App for Containers. As we enable more
features, they will become visible on the portal.
Some features, such as virtual network integration, Azure Active Directory/third-party authentication, or Kudu site
extensions, are not available yet. Once these features are available, we will update our documentation and blog
about the changes.
App Service on Linux is only supported with Basic and Standard app service plans and does not have a Free or
Shared tier. The following are also important restrictions for App Service on Linux:
You cannot create Web App for Containers in an App Service plan already hosting non-Linux Web Apps.
When creating Web App for Containers in a resource group containing non-Linux Web Apps, you must create
an App Service plan in a different region than the existing App Service plan.
Troubleshooting
When your application fails to start or you want to check the logging from your app, check the Docker logs in the
LogFiles directory. You can access this directory either through your SCM site or via FTP. To log the stdout and
stderr from your container, you need to enable Docker Container logging under Diagnostics Logs.
You can access the SCM site from Advanced Tools in the Development Tools menu.
Next steps
See the following links to get started with App Service on Linux. You can post questions and concerns on our
forum.
How to use a custom Docker image for Web App for Containers
Using .NET Core in Azure App Service on Linux
Using Ruby in Azure App Service on Linux
Azure App Service Web App for Containers FAQ
SSH support for Azure App Service on Linux
Set up staging environments in Azure App Service
Docker Hub Continuous Deployment with Web App for Containers
Azure App Service, Virtual Machines, Service Fabric,
and Cloud Services comparison
Overview
Azure offers several ways to host web sites: Azure App Service, Virtual Machines, Service Fabric, and Cloud
Services. This article helps you understand the options and make the right choice for your web application.
Azure App Service is the best choice for most web apps. Deployment and management are integrated into the
platform, sites can scale quickly to handle high traffic loads, and the built-in load balancing and traffic manager
provide high availability. You can move existing sites to Azure App Service easily with an online migration tool, use
an open-source app from the Web Application Gallery, or create a new site using the framework and tools of your
choice. The WebJobs feature makes it easy to add background job processing to your App Service web app.
Service Fabric is a good choice if you’re creating a new app or re-writing an existing app to use a microservice
architecture. Apps, which run on a shared pool of machines, can start small and grow to massive scale with
hundreds or thousands of machines as needed. Stateful services make it easy to consistently and reliably store app
state, and Service Fabric automatically manages service partitioning, scaling, and availability for you. Service Fabric
also supports WebAPI with Open Web Interface for .NET (OWIN) and ASP.NET Core. Compared to App Service,
Service Fabric also provides more control over, or direct access to, the underlying infrastructure. You can remote
into your servers or configure server startup tasks. Cloud Services is similar to Service Fabric in degree of control
versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development.
If you have an existing application that would require substantial modifications to run in App Service or Service
Fabric, you could choose Virtual Machines in order to simplify migrating to the cloud. However, correctly
configuring, securing, and maintaining VMs requires much more time and IT expertise compared to Azure App
Service and Service Fabric. If you are considering Azure Virtual Machines, make sure you take into account the
ongoing maintenance effort required to patch, update, and manage your VM environment. Azure Virtual Machines
is Infrastructure-as-a-Service (IaaS), while App Service and Service Fabric are Platform-as-a-Service (Paas).
Feature Comparison
The following table compares the capabilities of App Service, Cloud Services, Virtual Machines, and Service Fabric
to help you make the best choice. For current information about the SLA for each option, see Azure Service Level
Agreements.
APP SERVICE (WEB CLOUD SERVICES VIRTUAL

FEATURE APPS) (WEB ROLES) MACHINES SERVICE FABRIC NOTES
Near-instant X X Deploying an
deployment application or an
application
update to a
Cloud Service, or
creating a VM,
takes several
minutes at least;
deploying an
application to a
web app takes
seconds.
Scale up to larger X X
machines without
redeploy
Web server X X
instances share
content and
configuration,
which means you
don't have to
redeploy or
reconfigure as
you scale.
Multiple X X X Service Fabric

deployment allows you to
environments have multiple
(production and environments for
staging) your apps or to
deploy different
versions of your
app side-by-side.
Automatic OS X X Partially through

update Patch
management Orchestration
Application (POA)
and fully in the
future.
Seamless X X
platform
switching (easily
move between
32 bit and 64 bit)
Deploy code with X X

GIT, FTP
Deploy code with X X Cloud Services

Web Deploy supports the use
of Web Deploy to
deploy updates
to individual role
instances.
However, you
can't use it for
initial deployment
of a role, and if
you use Web
Deploy for an
update you have
to deploy
separately to
each instance of a
role. Multiple
instances are
required in order
to qualify for the
Cloud Service SLA
for production
environments.
WebMatrix X X
support
Access to services X X X X
like Service Bus,
Storage, SQL
Database
Host web or web X X X X

services tier of a
multi-tier
architecture
Host middle tier X X X X App Service web

of a multi-tier apps can easily
architecture host a REST API
middle tier, and
the WebJobs
feature can host
background
processing jobs.
You can run
WebJobs in a
dedicated website
to achieve
independent
scalability for the
tier.
Integrated X X
MySQL-as-a-
service support
Support for X X X X Service Fabric

ASP.NET, classic supports the
ASP, Node.js, creation of a web
PHP, Python front-end using
ASP.NET 5 or you
can deploy any
type of
application
(Node.js, Java,
etc) as a guest
executable.
Scale out to X X X X Virtual Machines

multiple can scale out to
instances without multiple
redeploy instances, but the
services running
on them must be
written to handle
this scale-out.
You have to
configure a load
balancer to route
requests across
the machines,
and create an
Affinity Group to
prevent
simultaneous
restarts of all
instances due to
maintenance or
hardware failures.
Support for SSL X X X X For App Service

web apps, SSL for
custom domain
names is only
supported for
Basic and
Standard mode.
For information
about using SSL
with web apps,
see Configuring
an SSL certificate
for an Azure
Website.
Visual Studio X X X X
integration
Remote X X X
Debugging
Deploy code with X X X X

TFS
Network isolation X X X X See also Azure

with Azure Websites Virtual
Virtual Network Network
Integration
Support for X X X X
Azure Traffic
Manager
Integrated X X X
Endpoint
Monitoring
Remote desktop X X X
access to servers
Install any X X X Service Fabric

custom MSI allows you to
host any
executable file as
a guest
executable or you
can install any
app on the VMs.
Ability to X X X
define/execute
start-up tasks
Can listen to ETW X X X

events
Scenarios and recommendations

Here are some common application scenarios with recommendations as to which Azure web hosting option might
be most appropriate for each.
I need a web front end with background processing and database backend to run business applications
integrated with on-premises assets.
I need a reliable way to host my corporate website that scales well and offers global reach.
I have an IIS6 application running on Windows Server 2003.
I'm a small business owner, and I need an inexpensive way to host my site but with future growth in mind.
I'm a web or graphic designer, and I want to design and build web sites for my customers.
I'm migrating my multi-tier application with a web front-end to the Cloud.
My application depends on highly customized Windows or Linux environments and I want to move it to the
cloud.
My site uses open source software, and I want to host it in Azure.
I have a line-of-business application that needs to connect to the corporate network.
I want to host a REST API or web service for mobile clients.
I need a web front end with background processing and database backend to run business applications
integrated with on-premises assets.
Azure App Service is a great solution for complex business applications. It lets you develop apps that scale
automatically on a load balanced platform, are secured with Active Directory, and connect to your on-premises
resources. It makes managing those apps easy through a world-class portal and APIs, and allows you to gain
insight into how customers are using them with app insight tools. The Webjobs feature lets you run background
processes and tasks as part of your web tier, while hybrid connectivity and VNET features make it easy to connect
back to on-premises resources. Azure App Service provides three 9's SLA for web apps and enables you to:
Run your applications reliably on a self-healing, auto-patching cloud platform.
Scale automatically across a global network of datacenters.
Back up and restore for disaster recovery.
Be ISO, SOC2, and PCI compliant.
Integrate with Active Directory
I need a reliable way to host my corporate website that scales well and offers global reach.
Azure App Service is a great solution for hosting corporate websites. It enables web apps to scale quickly and easily
to meet demand across a global network of datacenters. It offers local reach, fault tolerance, and intelligent traffic
management. All on a platform that provides world-class management tools, allowing you to gain insight into site
health and site traffic quickly and easily. Azure App Service provides three 9's SLA for web apps and enables you to:
Run your websites reliably on a self-healing, auto-patching cloud platform.
Scale automatically across a global network of datacenters.
Back up and restore for disaster recovery.
Manage logs and traffic with integrated tools.
Be ISO, SOC2, and PCI compliant.
Integrate with Active Directory
I have an IIS6 application running on Windows Server 2003.
Azure App Service makes it easy to avoid the infrastructure costs associated with migrating older IIS6 applications.
Microsoft has created easy to use migration tools and detailed migration guidance that enable you to check
compatibility and identify any changes that need to be made. Integration with Visual Studio, TFS, and common
CMS tools makes it easy to deploy IIS6 applications directly to the cloud. Once deployed, the Azure Portal provides
robust management tools that enable you to scale down to manage costs and up to meet demand as necessary.
With the migration tool you can:
Quickly and easily migrate your legacy Windows Server 2003 web application to the cloud.
Opt to leave your attached SQL database on-premises to create a hybrid application.
Automatically move your SQL database along with your legacy application.
I'm a small business owner, and I need an inexpensive way to host my site but with future growth in mind.
Azure App Service is a great solution for this scenario, because you can start using it for free and then add more
capabilities when you need them. Each free web app comes with a domain provided by Azure
(your_company.azurewebsites.net), and the platform includes integrated deployment and management tools as
well as an application gallery that make it easy to get started. There are many other services and scaling options
that allow the site to evolve with increased user demand. With Azure App Service, you can:
Begin with the free tier and then scale up as needed.
Use the Application Gallery to quickly set up popular web applications, such as WordPress.
Add additional Azure services and features to your application as needed.
Secure your web app with HTTPS.
NOTE
App Service Free and Shared (preview) hosting plans are base tiers that run on the same Azure VM as other App Service
apps. Some apps may belong to other customers. These tiers are intended to be used only for development and testing
purposes.
I'm a web or graphic designer, and I want to design and build websites for my customers
For web developers and designers, Azure App Service integrates easily with a variety of frameworks and tools,
includes deployment support for Git and FTP, and offers tight integration with tools and services such as Visual
Studio and SQL Database. With App Service, you can:
Use command-line tools for automated tasks.
Work with popular languages such as .Net, PHP, Node.js, and Python.
Select three different scaling levels for scaling up to very high capacities.
Integrate with other Azure services, such as SQL Database, Service Bus and Storage, or partner offerings from
the Azure Store, such as MySQL and MongoDB.
Integrate with tools such as Visual Studio, Git, WebMatrix, WebDeploy, TFS, and FTP.
I'm migrating my multi-tier application with a web front-end to the Cloud
If you’re running a multi-tier application, such as a web server that connects to a database, Azure App Service is a
good option that offers tight integration with Azure SQL Database. And you can use the WebJobs feature for
running backend processes.
Choose Service Fabric for one or more of your tiers if you need more control over the server environment, such as
the ability to remote into your server or configure server startup tasks.
Choose Virtual Machines for one or more of your tiers if you want to use your own machine image or run server
software or services that you can't configure on Service Fabric.
My application depends on highly customized Windows or Linux environments and I want to move it to the
cloud.
If your application requires complex installation or configuration of software and the operating system, Virtual
Machines is probably the best solution. With Virtual Machines, you can:
Use the Virtual Machine gallery to start with an operating system, such as Windows or Linux, and then
customize it for your application requirements.
Create and upload a custom image of an existing on-premises server to run on a virtual machine in Azure.
My site uses open source software, and I want to host it in Azure
If your open source framework is supported on App Service, the languages and frameworks needed by your
application are configured for you automatically. App Service enables you to:
Use many popular open source languages, such as .NET, PHP, Node.js, and Python.
Set up WordPress, Drupal, Umbraco, DNN, and many other third-party web applications.
Migrate an existing application or create a new one from the Application Gallery.
If your open source framework is not supported on App Service, you can run it on one of the other Azure web
hosting options. With Virtual Machines, you install and configure the software on the machine image, which can be
Windows or Linux-based.
I have a line -of-business application that needs to connect to the corporate network
If you want to create a line-of-business application, your website might require direct access to services or data on
the corporate network. This is possible on App Service, Service Fabric, and Virtual Machines using the Azure Virtual
Network service. On App Service you can use the VNET integration feature, which allows your Azure applications to
run as if they were on your corporate network.
I want to host a REST API or web service for mobile clients
HTTP-based web services enable you to support a wide variety of clients, including mobile clients. Frameworks like
ASP.NET Web API integrate with Visual Studio to make it easier to create and consume REST services. These
services are exposed from a web endpoint, so it is possible to use any web hosting technique on Azure to support
this scenario. However, App Service is a great choice for hosting REST APIs. With App Service, you can:
Quickly create a mobile app or API app to host the HTTP web service in one of Azure’s globally distributed
datacenters.
Migrate existing services or create new ones.
Achieve SLA for availability with a single instance, or scale out to multiple dedicated machines.
Use the published site to provide REST APIs to any HTTP clients, including mobile clients.
NOTE
If you want to get started with Azure App Service before signing up for an account, go to
https://trywebsites.azurewebsites.net, where you can immediately create a short-lived starter app in Azure App Service for
free. No credit card required, no commitments.
Next Steps
For more information about the three web hosting options, see Introducing Azure.
To get started with the chosen options for your application, see the following resources:
Azure App Service
Azure Cloud Services
Azure Virtual Machines
Service Fabric
Create a .NET Core web app in App Service on Linux
NOTE
This article deploys an app to App Service on Linux. To deploy to App Service on Windows, see Create an ASP.NET Core web
app in Azure.
App Service on Linux provides a highly scalable, self-patching web hosting service using the Linux operating
system. This quickstart shows how to create a .NET Core app on App Service on Linux. You create the web app
using the Azure CLI, and you use Git to deploy the .NET Core code to the web app.
You can follow the steps below using a Mac, Windows, or Linux machine.
Prerequisites
To complete this quickstart:
Install Git
Install .NET Core SDK 1.1
If you don't have an Azure subscription, create a free account before you begin.
Create the app locally

In a terminal window on your machine, create a directory named hellodotnetcore and change the current
directory to it.
md hellodotnetcore
cd hellodotnetcore
Create a new .NET Core web app.
dotnet new web
Run the app locally

Restore the NuGet packages and run the app.
dotnet restore
dotnet run
Open a web browser, and navigate to the app at http://localhost:5000 .

You see the Hello World message from the sample app displayed in the page.
In your terminal window, press Ctrl+C to exit the web server. Initialize a Git repository for the .NET Core project.
git init
git add .
git commit -m "first commit"
Launch Azure Cloud Shell

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common
Azure tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into
the Cloud Shell, and then press enter to run it. There are two ways to launch the Cloud Shell:
Click Try It in the upper right corner of a code block.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
Create a deployment user

In the Cloud Shell, create deployment credentials with the az webapp deployment user set command. A
deployment user is required for FTP and local Git deployment to a web app. The user name and password are
account level. They are different from your Azure subscription credentials.
In the following example, replace <username> and <password> (including brackets) with a new user name and
password. The user name must be unique. The password must be at least eight characters long, with two of the
following three elements: letters, numbers, symbols.
az webapp deployment user set --user-name <username> --password <password>
If you get a 'Conflict'. Details: 409 error, change the username. If you get a 'Bad Request'. Details: 400 error,
use a stronger password.
You create this deployment user only once; you can use it for all your Azure deployments.
NOTE
Record the user name and password. You need them to deploy the web app later.
Create a resource group

In the Cloud Shell, create a resource group with the az group create command.
A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts
are deployed and managed.
The following example creates a resource group named myResourceGroup in the West Europe location. To see all
supported locations for App Service, run the az appservice list-locations command.
az group create --name myResourceGroup --location "West Europe"
You generally create your resource group and the resources in a region near you.
Create an Azure App Service plan

In the Cloud Shell, create an App Service plan in the resource group with the az appservice plan create command.
The following example creates an App Service plan named myAppServicePlan in the Standard pricing tier (
--sku S1 ) and in a Linux container ( --is-linux ).
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku S1 --is-linux
When the App Service plan has been created, the Azure CLI shows information similar to the following example:
{
"adminSiteName": null,
"appServicePlanName": "myAppServicePlan",
"geoRegion": "West Europe",
"hostingEnvironmentProfile": null,
"id": "/subscriptions/0000-
0000/resourceGroups/myResourceGroup/providers/Microsoft.Web/serverfarms/myAppServicePlan",
"kind": "linux",
"location": "West Europe",
"maximumNumberOfWorkers": 1,
"name": "myAppServicePlan",
< JSON data removed for brevity. >
"targetWorkerSizeId": 0,
"type": "Microsoft.Web/serverfarms",
"workerTierName": null
}
Create a web app

In the Cloud Shell, create a web app in the myAppServicePlan App Service plan with the az webapp create
command.
In the following example, replace <app_name> with a globally unique app name (valid characters are a-z , 0-9 ,
and - ). The runtime is set to dotnetcore|1.1 . To see all supported runtimes, run az webapp list-runtimes.
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app_name> --runtime
"dotnetcore|1.1" --deployment-local-git
When the web app has been created, the Azure CLI shows output similar to the following example:
Local git is configured with url of 'https://<username>@<app_name>.scm.azurewebsites.net/<app_name>.git'

{
"availabilityState": "Normal",
"clientAffinityEnabled": true,
"clientCertEnabled": false,
"cloningInfo": null,
"containerSize": 0,
"dailyMemoryTimeQuota": 0,
"defaultHostName": "<app_name>.azurewebsites.net",
"deploymentLocalGitUrl": "https://<username>@<app_name>.scm.azurewebsites.net/<app_name>.git",
"enabled": true,
}
You’ve created an empty web app in a Linux container, with git deployment enabled.
NOTE
The URL of the Git remote is shown in the property, with the format
deploymentLocalGitUrl
https://<username>@<app_name>.scm.azurewebsites.net/<app_name>.git . Save this URL as you'll need it later.
Browse to your newly created web app. Replace <app name> with your web app name.
http://<app name>.azurewebsites.net
Push to Azure from Git
In the local terminal window, add an Azure remote to your local Git repository. This Azure remote was created for
you in Create a web app.
git remote add azure <deploymentLocalGitUrl-from-create-step>
Push to the Azure remote to deploy your app with the following command. When prompted for a password, make
sure that you enter the password you created in Configure a deployment user, not the password you use to log in
to the Azure portal.
git push azure master
This command may take a few minutes to run. While running, it displays information similar to the following
example:
Counting objects: 22, done.

Delta compression using up to 8 threads.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (22/22), 51.21 KiB | 3.94 MiB/s, done.
Total 22 (delta 1), reused 0 (delta 0)
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id '741f16d1db'.
remote: Generating deployment script.
remote: Project file path: ./hellodotnetcore.csproj
remote: Generated deployment script files
remote: Running deployment command...
remote: Handling ASP.NET Core Web Application deployment.
remote: ...............................................................................................
remote: Restoring packages for /home/site/repository/hellodotnetcore.csproj...
remote: ....................................
remote: Installing System.Xml.XPath 4.0.1.
remote: Installing System.Diagnostics.Tracing 4.1.0.
remote: Installing System.Threading.Tasks.Extensions 4.0.0.
remote: Installing System.Reflection.Emit.ILGeneration 4.0.1.
remote: ...
remote: Finished successfully.
remote: Running post deployment command(s)...
remote: Deployment successful.
To https://cephalin-dotnetcore.scm.azurewebsites.net/cephalin-dotnetcore.git
* [new branch] master -> master
Browse to the app

Browse to the deployed application using your web browser.
http://<app_name>.azurewebsites.net
The Node.js sample code is running in an web app with built-in image.
Congratulations! You've deployed your first Node.js app to App Service on Linux.
Update and redeploy the code

In the local directory, open the Startup.cs file. Make a small change to the text in the method call
context.Response.WriteAsync :
await context.Response.WriteAsync("Hello Azure!");
Commit your changes in Git, and then push the code changes to Azure.
git commit -am "updated output"

Once deployment has completed, switch back to the browser window that opened in the Browse to the app step,
and hit refresh.
Manage your new Azure web app

Go to the Azure portal to manage the web app you created.
From the left menu, click App Services, and then click the name of your Azure web app.
You see your web app's Overview page. Here, you can perform basic management tasks like browse, stop, start,
restart, and delete.
The left menu provides different pages for configuring your app.
Clean up resources
In the preceding steps, you created Azure resources in a resource group. If you don't expect to need these
resources in the future, delete the resource group by running the following command in the Cloud Shell:
az group delete --name myResourceGroup
This command may take a minute to run.
Next steps
Build a .NET Core and SQL Database web app in Azure App Service on Linux
Create a PHP web app in App Service on Linux
NOTE
This article deploys an app to App Service on Linux. To deploy to App Service on Windows, see Create a PHP web app in
Azure.
system. This quickstart tutorial shows how to deploy a PHP app to Azure App Service on Linux. You create the web
app with built-in image using the Azure CLI in Cloud Shell, and you use Git to deploy the PHP code to the web app.
Prerequisites
Install Git
Install PHP
Download the sample

In a terminal window, run the following commands to clone the sample application to your local machine, and
navigate to the directory containing the sample code.
git clone https://github.com/Azure-Samples/php-docs-hello-world

cd php-docs-hello-world
Run the app locally

Run the application locally by opening a terminal window and using the php command to launch the built-in PHP
web server.
php -S localhost:8080
Open a web browser, and navigate to the sample app at http://localhost:8080 .

You see the Hello World! message from the sample app displayed in the page.
In your terminal window, press Ctrl+C to exit the web server.

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure
tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into the
Cloud Shell, and then press enter to run it. There are two ways to launch the Cloud Shell:

NOTE


{
"kind": "linux",
}
Create a web app

command.
In the following example, replace <app_name> with a globally unique app name (valid characters are a-z , 0-9 , and
- ). The runtime is set to PHP|7.0 . To see all supported runtimes, run az webapp list-runtimes.
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app_name> --runtime "PHP|7.0"
--deployment-local-git
{
"containerSize": 0,
"enabled": true,
}
You’ve created an empty new web app, with git deployment enabled.
NOTE
Browse to the site to see your newly created web app with built-in image. Replace <app name> with your web app
name.

example:

Writing objects: 100% (2/2), 352 bytes | 0 bytes/s, done.
remote: Preparing deployment for commit id '25f18051e9'.
remote: Handling Basic Web Site deployment.
remote: Kudu sync from: '/home/site/repository' to: '/home/site/wwwroot'
remote: Copying file: '.gitignore'
remote: Copying file: 'LICENSE'
remote: Copying file: 'README.md'
remote: Copying file: 'index.php'
remote: Ignoring: .git
To https://<app_name>.scm.azurewebsites.net/<app_name>.git
cc39b1e..25f1805 master -> master
Browse to the app

The PHP sample code is running in a web app with built-in image.
Congratulations! You've deployed your first PHP app to App Service on Linux.
Update locally and redeploy the code

In the local directory, open the index.php file within the PHP app, and make a small change to the text within the
string next to echo :
echo "Hello Azure!";

and refresh the page.

Clean up resources
In the preceding steps, you created Azure resources in a resource group. If you don't expect to need these resources
in the future, delete the resource group by running the following command in the Cloud Shell:
Next steps
PHP with MySQL
Create a Node.js web app in Azure App Service on
Linux
NOTE
This article deploys an app to App Service on Linux. To deploy to App Service on Windows, see Create a Node.js web app in
Azure.
system. This quickstart shows how to deploy a Node.js app to App Service on Linux using a built-in image. You
create the web app with built-in image using the Azure CLI, and you use Git to deploy the Node.js code to the web
app.
Prerequisites
Install Git
Install Node.js and NPM
Download the sample

In a terminal window on your machine, run the following command to clone the sample app repository to your
local machine.
git clone https://github.com/Azure-Samples/nodejs-docs-hello-world
You use this terminal window to run all the commands in this quickstart.
Change to the directory that contains the sample code.
cd nodejs-docs-hello-world
Run the app locally
Run the application locally by opening a terminal window and using the npm start script to launch the built in
Node.js HTTP server.
npm start
Open a web browser, and navigate to the sample app at http://localhost:1337 .

You see the Hello World message from the sample app displayed in the page.
In your terminal window, press Ctrl+C to exit the web server.

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure
tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into the
Cloud Shell, and then press enter to run it. There are two ways to launch the Cloud Shell:

NOTE


{
"kind": "linux",
}
Create a web app

command.
In the following example, replace <app_name> with a globally unique app name (valid characters are a-z , 0-9 , and
- ). The runtime is set to NODE|6.9 . To see all supported runtimes, run az webapp list-runtimes.
"NODE|6.9" --deployment-local-git

{
"containerSize": 0,
"enabled": true,
}
You’ve created an empty web app, with git deployment enabled.
NOTE
Browse to your newly created web app. Replace <app name> with your web app name.
example:

Writing objects: 100% (23/23), 3.71 KiB | 0 bytes/s, done.
remote: Preparing deployment for commit id 'bf114df591'.
remote: Generating deployment script for node.js Web Site
remote: Handling node.js deployment.
remote: Kudu sync from: '/home/site/repository' to: '/home/site/wwwroot'
remote: Copying file: '.gitignore'
remote: Copying file: 'LICENSE'
remote: Copying file: 'README.md'
remote: Copying file: 'index.js'
remote: Copying file: 'package.json'
remote: Copying file: 'process.json'
remote: Deleting file: 'hostingstart.html'
remote: Ignoring: .git
remote: Using start-up script index.js from package.json.
remote: Node.js versions available on the platform are: 4.4.7, 4.5.0, 6.2.2, 6.6.0, 6.9.1.
remote: Selected node.js version 6.9.1. Use package.json file to choose a different version.
remote: Selected npm version 3.10.8
To https://<app_name>.scm.azurewebsites.net:443/<app_name>.git
Browse to the app

The Node.js sample code is running in a web app with built-in image.
Congratulations! You've deployed your first Node.js app to App Service on Linux.
Update and redeploy the code

In the local directory, open the index.js file in the Node.js app, and make a small change to the text in the call to
response.end :
response.end("Hello Azure!");

and hit refresh.

Clean up resources
Next steps
Node.js with MongoDB
1 min to read •
Edit O nline
Create a Ruby App in App Service on Linux
App Service on Linux provides a highly scalable, self-patching web hosting service. This quickstart shows you how
to create a basic Ruby on Rails application you then deploy it to Azure as a Web App on Linux.
Prerequisites
Install Ruby 2.4.1 or higher
Install Git
Download the sample

In a terminal window, run the following command to clone the sample app repository to your local machine:
git clone https://github.com/Azure-Samples/ruby-docs-hello-world
Run the application locally

Run the rails server in order for the application to work. Change to the hello-world directory, and the rails server
command starts the server.
cd hello-world\bin
rails server
Using your web browser, navigate to http://localhost:3000 to test the app locally.
Modify app to display welcome message
Modify the application so it displays a welcome message. First, you must setup a route by modifying the
~/workspace/ruby-docs-hello-world/config/routes.rb file to include a route named hello .
Rails.application.routes.draw do
#For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
root 'application#hello'
end
Change the application's controller so it returns the message as HTML to the browser.
Open ~/workspace/hello-world/app/controllers/application_controller.rb for editing. Modify the
ApplicationController class to look like the following code sample:
class ApplicationController > ActionController :: base

protect_from_forgery with: :exception
def hello
render html: "Hello, world from Azure Web App on Linux!"
end
end
Your app is now configured. Using your web browser, navigate to http://localhost:3000 to confirm the root
landing page.

NOTE
Create a Ruby web app on Azure

A resource group is required to contain the assets needed for your web app. To create a resource group, use the
az group create
command.
az group create --location westeurope --name myResourceGroup
Use the az appservice plan create command to create an app service plan for your web app.
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --is-linux
Next, issue the az webapp create command to create the web app that uses the newly created service plan. Notice
that the runtime is set to ruby|2.3 . Don't forget to replace <app name> with a unique app name.
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app name> \

--runtime "ruby|2.3" --deployment-local-git
The output from the command reveals information about the newly created web app as well as the deployment
URL. It should look similar to the following sample. Copy the URL for later use in this tutorial.
https://<deployment user name>@<app name>.scm.azurewebsites.net/<app name>.git
Once the web app is created, an Overview page is available to view. Navigate to it. The following splash page is
displayed:
Deploy your application

Run the following commands to deploy the local application to your Azure website:
git remote add azure <Git deployment URL from above>
git add -A
git commit -m "Initial deployment commit"
Confirm that the remote deployment operations report success. The commands produce output similar to the
following text:
remote: Using sass-rails 5.0.6

remote: Updating files in vendor/cache
remote: Bundle gems are installed into ./vendor/bundle
remote: Updating files in vendor/cache
remote: ~site/repository
To https://<your web app name>.scm.azurewebsites.net/<your web app name>.git
579ccb....2ca5f31 master -> master
myuser@ubuntu1234:~workspace/<app name>$
Once the deployment has completed, restart your web app for the deployment to take effect by using the az
webapp restart command, as shown here:
az webapp restart --name <app name> --resource-group myResourceGroup
Navigate to your site and verify the results.
NOTE
While the app is restarting, attempting to browse the site results in an HTTP status code Error 503 Server unavailable .
It may take a few minutes to fully restart.
Clean up deployment
After the sample script has been run, the following command can be used to remove the resource group and all
resources associated with it.

Next steps
Ruby on Rails with MySQL
Run a custom Docker Hub image in Azure Web App
for Containers
App Service provides pre-defined application stacks on Linux with support for specific versions, such as PHP 7.0
and Node.js 4.5. You can also use a custom Docker image to run your web app on an application stack that is not
already defined in Azure. This quickstart shows how to create a web app and deploy the official Nginx Docker
image to it. You create the web app using the Azure CLI.


NOTE


{
"kind": "linux",
}
Create a Web App for Container

Create a web app in the myAppServicePlan App Service plan with the az webapp create command. Don't forget to
replace <app name> with a unique app name.
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app name> --deployment-
container-image-name nginx
In the preceding command, --deployment-container-image-name points to the public Docker Hub image
https://hub.docker.com/r/_/nginx/.
{
"containerSize": 0,
"defaultHostName": "<app name>.azurewebsites.net",
"deploymentLocalGitUrl": "https://<username>@<app name>.scm.azurewebsites.net/<app name>.git",
"enabled": true,
}
Browse to the app

Browse to the following URL using your web browser.
Congratulations! You've deployed a custom Docker image to Web App for Containers.
Next steps
Use a custom Docker image
Build a .NET Core and SQL Database web app in
Azure App Service on Linux
system. This tutorial shows how to create a .NET Core web app and connect it to a SQL Database. When you're
done, you'll have a .NET Core MVC app running in App Service on Linux.
What you learn how to:

Create a SQL Database in Azure
Connect a .NET Core app to SQL Database
Deploy the app to Azure
Update the data model and redeploy the app
Stream diagnostic logs from Azure
Manage the app in the Azure portal
Prerequisites
To complete this tutorial:
1. Install Git
2. Install .NET Core SDK 1.1.2
Create local .NET Core app

In this step, you set up the local .NET Core project.
Clone the sample application
In the terminal window, cd to a working directory.
Run the following commands to clone the sample repository and change to its root.
git clone https://github.com/azure-samples/dotnetcore-sqldb-tutorial

cd dotnetcore-sqldb-tutorial
The sample project contains a basic CRUD (create-read-update-delete) app using Entity Framework Core.
Run the application
Run the following commands to install the required packages, run database migrations, and start the application.
dotnet restore
dotnet ef database update
dotnet run
Navigate to http://localhost:5000 in a browser. Select the Create New link and create a couple to-do items.
To stop .NET Core at any time, press Ctrl+C in the terminal.

Create production SQL Database
In this step, you create a SQL Database in Azure. When your app is deployed to Azure, it uses this cloud database.
For SQL Database, this tutorial uses Azure SQL Database.
Create a SQL Database logical server
In the Cloud Shell, create a SQL Database logical server with the az sql server create command.
Replace the <server_name> placeholder with a unique SQL Database name. This name is used as the part of the
SQL Database endpoint, <server_name>.database.windows.net , so the name needs to be unique across all logical
servers in Azure. The name must contain only lowercase letters, numbers, and the hyphen (-) character, and must
be between 3 and 50 characters long. Also, replace <db_username> and <db_password> with a username and
password of your choice.
az sql server create --name <server_name> --resource-group myResourceGroup --location "West Europe" --admin-
user <db_username> --admin-password <db_password>
When the SQL Database logical server is created, the Azure CLI shows information similar to the following
example:
{
"administratorLogin": "sqladmin",
"administratorLoginPassword": null,
"fullyQualifiedDomainName": "<server_name>.database.windows.net",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Sql/servers/<server_name>",
"identity": null,
"kind": "v12.0",
"location": "westeurope",
"name": "<server_name>",
"resourceGroup": "myResourceGroup",
"state": "Ready",
"tags": null,
"type": "Microsoft.Sql/servers",
"version": "12.0"
}
Configure a server firewall rule

Create an Azure SQL Database server-level firewall rule using the az sql server firewall create command. When
both starting IP and end IP are set to 0.0.0.0, the firewall is only opened for other Azure resources.
az sql server firewall-rule create --resource-group myResourceGroup --server <server_name> --name AllowYourIp
--start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0
Create a database
Create a database with an S0 performance level in the server using the az sql db create command.
az sql db create --resource-group myResourceGroup --server <server_name> --name coreDB --service-objective S0
Create connection string

Replace the following string with the <server_name>, <db_username>, and <db_password> you used earlier.
Server=tcp:<server_name>.database.windows.net,1433;Initial Catalog=coreDB;Persist Security Info=False;User ID=

<db_username>;Password=
<db_password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
This is the connection string for your .NET Core app. Copy it for use later.
Deploy app to Azure

In this step, you deploy your SQL Database-connected .NET Core application to App Service on Linux.
Configure local git deployment
NOTE
Create an App Service plan

{
"kind": "linux",
}
Create a web app

command.
and - ). The runtime is set to dotnetcore|1.1 . To see all supported runtimes, run az webapp list-runtimes.

"dotnetcore|1.1" --deployment-local-git

{
"containerSize": 0,
"enabled": true,
}
You’ve created an empty web app in a Linux container, with git deployment enabled.
NOTE
Configure an environment variable

To set connection strings for your Azure app, use the az webapp config appsettings set command in the Cloud
Shell. In the following command, replace <app name>, as well as the <connection_string> parameter with the
connection string you created earlier.
az webapp config connection-string set --resource-group myResourceGroup --name <app name> --settings
MyDbConnection='<connection_string>' --connection-string-type SQLServer
Next, set ASPNETCORE_ENVIRONMENT app setting to Production. This setting lets you know whether you are running in
Azure, because you use SQLLite for your local development environment and SQL Database for your Azure
environment.
The following example configures a ASPNETCORE_ENVIRONMENT app setting in your Azure web app. Replace the
<app_name> placeholder.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings

ASPNETCORE_ENVIRONMENT="Production"
Connect to SQL Database in production

In your local repository, open Startup.cs and find the following code:
services.AddDbContext<MyDatabaseContext>(options =>
options.UseSqlite("Data Source=localdatabase.db"));
Replace it with the following code, which uses the environment variables that you configured earlier.
// Use SQL Database if in Azure, otherwise, use SQLLite

if(Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == "Production")
services.AddDbContext<DotNetCoreSqlDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("MyDbConnection")));
else
services.AddDbContext<DotNetCoreSqlDbContext>(options =>
options.UseSqlite("Data Source=MvcMovie.db"));
// Automatically perform database migration

services.BuildServiceProvider().GetService<DotNetCoreSqlDbContext>().Database.Migrate();
If this code detects that it is running in production (which indicates the Azure environment), then it uses the
connection string you configured to connect to the SQL Database.
The Database.Migrate() call helps you when it is run in Azure, because it automatically creates the databases that
your .NET Core app needs, based on its migration configuration.
Save your changes.
example:

Writing objects: 100% (98/98), 524.98 KiB | 5.58 MiB/s, done.
remote: .
remote: Preparing deployment for commit id '0c497633b8'.
remote: Project file path: ./DotNetCoreSqlDb.csproj
remote: Handling ASP.NET Core Web Application deployment.
remote: .
remote: .
remote: .
remote: App container will begin restart within 10 seconds.
Browse to the Azure web app

Browse to the deployed web app using your web browser.
Add a few to-do items.
Congratulations! You're running a data-driven .NET Core app in App Service on Linux.
Update locally and redeploy

In this step, you make a change to your database schema and publish it to Azure.
Update your data model
Open Models\Todo.cs in the code editor. Add the following property to the ToDo class:
public bool Done { get; set; }
Run Code First Migrations locally

Run a few commands to make updates to your local database.
dotnet ef migrations add AddProperty
Update the local database:
dotnet ef database update
Use the new property

Make some changes in your code to use the Done property. For simplicity in this tutorial, you're only going to
change the Index and Create views to see the property in action.
Open Controllers\TodosController.cs.
Find the method and add Done to the list of properties in the
Create() Bind attribute. When you're done, your
Create() method signature looks like the following code:
public async Task<IActionResult> Create([Bind("ID,Description,CreatedDate,Done")] Todo todo)
Open Views\Todos\Create.cshtml.
In the Razor code, you should see a <div class="form-group"> element for Description , and then another
<div class="form-group"> element for CreatedDate . Immediately following these two elements, add another
<div class="form-group"> element for Done :
<div class="form-group">
<label asp-for="Done" class="col-md-2 control-label"></label>
<div class="col-md-10">
<input asp-for="Done" class="form-control" />
<span asp-validation-for="Done" class="text-danger"></span>
</div>
</div>
Open Views\Todos\Index.cshtml.
Search for the empty <th></th> element. Just above this element, add the following Razor code:
<th>
@Html.DisplayNameFor(model => model.Done)
</th>
Find the <td> element that contains the asp-action tag helpers. Just above this element, add the following Razor
code:
<td>
@Html.DisplayFor(modelItem => item.CreatedDate)
</td>
That's all you need to see the changes in the Index and Create views.
Test your changes locally
Run the app locally.
dotnet run
In your browser, navigate to http://localhost:5000/ . You can now add a to-do item and check Done. Then it
should show up in your homepage as a completed item. Remember that the Edit view doesn't show the Done
field, because you didn't change the Edit view.
Publish changes to Azure
git commit -am "added done field"

Once the git push is complete, navigate to your Azure web app and try out the new functionality.
All your existing to-do items are still displayed. When you republish your .NET Core app, existing data in your SQL
Database is not lost. Also, Entity Framework Core Migrations only changes the data schema and leaves your
existing data intact.
Manage your Azure web app

Go to the Azure portal to see the web app you created.
From the left menu, click App Services, then click the name of your Azure web app.
By default, the portal shows your web app's Overview page. This page gives you a view of how your app is doing.
Here, you can also perform basic management tasks like browse, stop, start, restart, and delete. The tabs on the left
side of the page show the different configuration pages you can open.
Clean up resources
Next steps
What you learned:
Create a SQL Database in Azure
Connect a .NET Core app to SQL Database
Stream logs from Azure to your terminal
Advance to the next tutorial to learn how to map a custom DNS name to your web app.
Map an existing custom DNS name to Azure Web Apps
Build a Ruby and MySQL web app in Azure App
Service on Linux
system. This tutorial shows how to create a Ruby web app and connect it to a MySQL database. When you're
finished, you'll have a Ruby on Rails app running on App Service on Linux.
In this tutorial, you learn how to:

Create a MySQL database in Azure
Connect a Ruby on Rails app to MySQL
Prerequisites
Install Git
Install Ruby 2.3
Install Ruby on Rails 5.1
Install and start MySQL
Prepare local MySQL

In this step, you create a database in your local MySQL server for your use in this tutorial.
Connect to local MySQL server
In a terminal window, connect to your local MySQL server. You can use this terminal window to run all the
commands in this tutorial.
mysql -u root -p
If you're prompted for a password, enter the password for the root account. If you don't remember your root
account password, see MySQL: How to Reset the Root Password.
If your command runs successfully, then your MySQL server is running. If not, make sure that your local MySQL
server is started by following the MySQL post-installation steps.
Exit your server connection by typing quit .
quit
Create a Ruby on Rails app locally

In this step, you get a Ruby on Rails sample application, configure its database connection, and run it locally.
Clone the sample
Run the following command to clone the sample repository.
git clone https://github.com/Azure-Samples/rubyrails-tasks.git
cd to your cloned directory. Install the required packages.
cd rubyrails-tasks
bundle install --path vendor/bundle
Configure MySQL connection

In the repository, open config/database.yml and supply the local MySQL root user name and password (line 13). If
you installed MySQL using a tool like Homebrew, then the credentials in the file are already set to the default
values (which is root and an empty password).
default: &default
adapter: mysql2
encoding: utf8
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
username: root
password:
socket: /tmp/mysql.sock
Run the sample locally

Run the Rails migrations to create the tables the application needs. To see which tables are created in the
migrations, look in the db/migrate directory in the Git repository.
rake db:create
rake db:migrate
Run the application.

rails server
Navigate to http://localhost:3000 in a browser. Add a few tasks in the page.
To stop the Rails server, type Ctrl + C in the terminal.

Create MySQL in Azure

In this step, you create a MySQL database in Azure Database for MySQL (Preview). Later, you configure the Ruby
on Rails application to connect to this database.
Create a MySQL server
Create a server in Azure Database for MySQL (Preview) with the az mysql server create command.
In the following command, substitute your MySQL server name where you see the <mysql_server_name>
placeholder (valid characters are a-z , 0-9 , and - ). This name is part of the MySQL server's hostname (
<mysql_server_name>.mysql.database.azure.com ), it needs to be globally unique.
az mysql server create --name <mysql_server_name> --resource-group myResourceGroup --location "North Europe" -
-admin-user adminuser --admin-password My5up3r$tr0ngPa$w0rd!
When the MySQL server is created, the Azure CLI shows information similar to the following example:
{
"administratorLogin": "adminuser",
"fullyQualifiedDomainName": "<mysql_server_name>.database.mysql.database.azure.com",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.DBforMySQL/servers/<mysql_server_name>",
"location": "northeurope",
"name": "<mysql_server_name>",
...
}
Configure server firewall

Create a firewall rule for your MySQL server to allow client connections by using the az mysql server firewall-rule
create command.
az mysql server firewall-rule create --name allIPs --server <mysql_server_name> --resource-group

myResourceGroup --start-ip-address 0.0.0.0 --end-ip-address 255.255.255.255
NOTE
Azure Database for MySQL (Preview) doesn't currently limit connections only to Azure services. As IP addresses in Azure are
dynamically assigned, it is better to enable all IP addresses. The service is in preview. Better methods for securing your
database are planned.
Connect to production MySQL server locally

In the terminal window, connect to the MySQL server in Azure. Use the value you specified previously for
<mysql_server_name>.
mysql -u adminuser@<mysql_server_name> -h <mysql_server_name>.mysql.database.azure.com -P 3306 -p
When prompted for a password, use My5up3r$tr0ngPa$w0rd!, which you specified when you created the
database server.
Create a production database
At the mysql prompt, create a database.
CREATE DATABASE sampledb;
Create a user with permissions

Create a database user called railsappuser and give it all privileges in the sampledb database.
CREATE USER 'railsappuser' IDENTIFIED BY 'MySQLAzure2017';

GRANT ALL PRIVILEGES ON sampledb.* TO 'railsappuser';
Exit the server connection by typing quit .
quit
Connect app to Azure MySQL

In this step, you connect the Ruby on Rails application to the MySQL database you created in Azure Database for
MySQL (Preview).
Configure the database connection
In the repository, open config/database.yml. At the bottom of the file, replace the production variables with the
following code. For the <mysql_server_name> placeholder, use the name of the MySQL server you created.
production:
<<: *default
host: <%= ENV['DB_HOST'] %>
port: 3306
database: <%= ENV['DB_DATABASE'] %>
username: <%= ENV['DB_USERNAME'] %>
password: <%= ENV['DB_PASSWORD'] %>
sslca: ssl/BaltimoreCyberTrustRoot.crt.pem
Save the changes.
NOTE
The sslca is added and points to an existing .pem file in the sample repository. By default, Azure Database for MySQL
enforces SSL connections from clients. This .pem certificate is how you make SSL connections to Azure Database for MySQL.
For more information, see Configure SSL connectivity in your application to securely connect to Azure Database for MySQL.
Test the application locally

In the local terminal, set the following environment variables:
export DB_HOST=<mysql_server_name>.mysql.database.azure.com
export DB_DATABASE=sampledb
export DB_USERNAME=railsappuser@<mysql_server_name>
export DB_PASSWORD=MySQLAzure2017
Run Rails database migrations with the production values you just configured to create the tables in your MySQL
database in Azure Database for MySQL (Preview).
rake db:migrate RAILS_ENV=production
When running in the production environment, the Rails application needs precompiled assets. Generate the
required assets with the following command:
rake assets:precompile
The Rails production environment also uses secrets to manage security. Generate a secret key.
rails secret
Save the secret key to the respective variables used by the Rails production environment. For convenience, you use
the same key for both variables.
export RAILS_MASTER_KEY=<output_of_rails_secret>
export SECRET_KEY_BASE=<output_of_rails_secret>
Enable the Rails production environment to serve JavaScript and CSS files.
export RAILS_SERVE_STATIC_FILES=true
Run the sample application in the production environment.
rails server -e production
Navigate to http://localhost:3000 . If the page loads without errors, the Ruby on Rails application is connecting to
the MySQL database in Azure.
Add a few tasks in the page.

Commit your changes
Run the following Git commands to commit your changes:
git add .
git commit -m "database.yml updates"
Your app is ready to be deployed.

Deploy to Azure
In this step, you deploy the MySQL-connected Rails application to Azure App Service.
Configure a deployment user
NOTE

{
"kind": "linux",
}
Create a web app

command.
and - ). The runtime is set to RUBY|2.3 , which deploys the default Ruby image. To see all supported runtimes, run
az webapp list-runtimes.

"RUBY|2.3" --deployment-local-git

{
"containerSize": 0,
"enabled": true,
}
NOTE
Configure database settings

In App Service, you set environment variables as app settings by using the az webapp config appsettings set
command in the Cloud Shell.
The following Cloud Shell command configures the app settings DB_HOST , DB_DATABASE , DB_USERNAME , and
DB_PASSWORD . Replace the placeholders <appname> and <mysql_server_name>.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings DB_HOST="
<mysql_server_name>.mysql.database.azure.com" DB_DATABASE="sampledb"
DB_USERNAME="railsappuser@<mysql_server_name>" DB_PASSWORD="MySQLAzure2017"
Configure Rails environment variables

In the local terminal, generate a new secret key for the Rails production environment in Azure.
rails secret
Configure the variables required by Rails production environment.

In the following Cloud Shell command, replace the two <output_of_rails_secret> placeholders with the new secret
key you generated in the local terminal.

RAILS_MASTER_KEY="<output_of_rails_secret>" SECRET_KEY_BASE="<output_of_rails_secret>"
RAILS_SERVE_STATIC_FILES="true" ASSETS_PRECOMPILE="true"
ASSETS_PRECOMPILE="true" tells the default Ruby container to precompile assets at each Git deployment.
In the local terminal, add an Azure remote to your local Git repository.
git remote add azure <paste_copied_url_here>
Push to the Azure remote to deploy the Ruby on Rails application. You are prompted for the password you
supplied earlier as part of the creation of the deployment user.
During deployment, Azure App Service communicates its progress with Git.

remote: Preparing deployment for commit id 'a5e076db9c'.
remote: Running custom deployment command...
...
< Output has been truncated for readability >

Browse to http://<app_name>.azurewebsites.net and add a few tasks to the list.
Congratulations, you're running a data-driven Ruby on Rails app in Azure App Service.
Update model locally and redeploy

In this step, you make a simple change to the task data model and the webapp, and then publish the update to
Azure.
For the tasks scenario, you modify the application so that you can mark a task as complete.
Add a column
In the terminal, navigate to the root of the Git repository.
Generate a new migration that adds a boolean column called Done to the Tasks table:
rails generate migration add_Done_to_Tasks Done:boolean
This command generates a new migration file in the db/migrate directory.

In the terminal, run Rails database migrations to make the change in the local database.
rake db:migrate
Update application logic

Open the app/controllers/tasks_controller.rb file. At the end of the file, find the following line:
params.require(:task).permit(:Description)
Modify this line to include the new Done parameter.
params.require(:task).permit(:Description, :Done)
Update the views

Open the app/views/tasks/_form.html.erb file, which is the Edit form.
Find the line <%=f.error_span(:Description) %> and insert the following code directly below it:
<%= f.label :Done, :class => 'control-label col-lg-2' %>

<div class="col-lg-10">
<%= f.check_box :Done, :class => 'form-control' %>
</div>
Open the app/views/tasks/show.html.erb file, which is the single-record View page.

Find the line <dd><%= @task.Description %></dd> and insert the following code directly below it:
<dt><strong><%= model_class.human_attribute_name(:Done) %>:</strong></dt>

<dd><%= check_box "task", "Done", {:checked => @task.Done, :disabled => true}%></dd>
Open the app/views/tasks/index.html.erb file, which is the Index page for all records.
Find the line <th><%= model_class.human_attribute_name(:Description) %></th> and insert the following code directly
below it:
<th><%= model_class.human_attribute_name(:Done) %></th>
In the same file, find the line <td><%= task.Description %></td> and insert the following code directly below it:
<td><%= check_box "task", "Done", {:checked => task.Done, :disabled => true} %></td>
Test the changes locally
In the local terminal, run the Rails server.
rails server
To see the task status change, navigate to http://localhost:3000 and add or edit items.

In the terminal, run Rails database migrations for the production environment to make the change in the Azure
database.
rake db:migrate RAILS_ENV=production
Commit all the changes in Git, and then push the code changes to Azure.
git add .
git commit -m "added complete checkbox"
Once the git push is complete, navigate to the Azure web app and test the new functionality.
If you added any tasks, they are retained in the database. Updates to the data schema leave existing data intact.
Manage the Azure web app

You see your web app's Overview page. Here, you can perform basic management tasks like stop, start, restart,
browse, and delete.
The left menu provides pages for configuring your app.
Clean up resources
Next steps
In this tutorial, you learned how to:
Connect a Ruby on Rails app to MySQL
Advance to the next tutorial to learn how to map a custom DNS name to a web app.
Build a PHP and MySQL web app in Azure App
Service on Linux
NOTE
This article deploys an app to App Service on Linux. To deploy to App Service on Windows, see Build a PHP and MySQL web
app in Azure.
system. This tutorial shows how to create a PHP web app and connect it to a MySQL database. When you're
finished, you'll have a Laravel app running on App Service on Linux.

Connect a PHP app to MySQL
Prerequisites
Install Git
Install PHP 5.6.4 or above
Install Composer
Enable the following PHP extensions Laravel needs: OpenSSL, PDO-MySQL, Mbstring, Tokenizer, XML
Install and start MySQL
Prepare local MySQL

In this step, you create a database in your local MySQL server for your use in this tutorial.
Connect to local MySQL server
In a terminal window, connect to your local MySQL server. You can use this terminal window to run all the
commands in this tutorial.
mysql -u root -p
If you're prompted for a password, enter the password for the root account. If you don't remember your root
account password, see MySQL: How to Reset the Root Password.
If your command runs successfully, then your MySQL server is running. If not, make sure that your local MySQL
server is started by following the MySQL post-installation steps.
Create a database locally
Exit your server connection by typing quit .
quit
Create a PHP app locally

In this step, you get a Laravel sample application, configure its database connection, and run it locally.
Clone the sample
git clone https://github.com/Azure-Samples/laravel-tasks
cd to your cloned directory. Install the required packages.

cd laravel-tasks
composer install
Configure MySQL connection

In the repository root, create a file named .env. Copy the following variables into the .env file. Replace the
<root_password> placeholder with the MySQL root user's password.
APP_ENV=local
APP_DEBUG=true
APP_KEY=SomeRandomString
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=sampledb
DB_USERNAME=root
DB_PASSWORD=<root_password>
For information on how Laravel uses the .env file, see Laravel Environment Configuration.
Run the sample locally
Run Laravel database migrations to create the tables the application needs. To see which tables are created in the
migrations, look in the database/migrations directory in the Git repository.
php artisan migrate
Generate a new Laravel application key.
php artisan key:generate
Run the application.
php artisan serve
Navigate to http://localhost:8000 in a browser. Add a few tasks in the page.

To stop PHP, type Ctrl + C in the terminal.

Create MySQL in Azure

In this step, you create a MySQL database in Azure Database for MySQL (Preview). Later, you configure the PHP
application to connect to this database.
Create a MySQL server
Create a server in Azure Database for MySQL (Preview) with the az mysql server create command.
In the following command, substitute your MySQL server name where you see the <mysql_server_name>
placeholder (valid characters are a-z , 0-9 , and - ). This name is part of the MySQL server's hostname (
<mysql_server_name>.database.windows.net ), it needs to be globally unique.
az mysql server create --name <mysql_server_name> --resource-group myResourceGroup --location "North Europe" -
-admin-user adminuser --admin-password My5up3r$tr0ngPa$w0rd! --ssl-enforcement Disabled
When the MySQL server is created, the Azure CLI shows information similar to the following example:
{
"administratorLogin": "adminuser",
"fullyQualifiedDomainName": "<mysql_server_name>.database.windows.net",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.DBforMySQL/servers/<mysql_server_name>",
"location": "northeurope",
"name": "<mysql_server_name>",
...
}
Configure server firewall

Create a firewall rule for your MySQL server to allow client connections by using the az mysql server firewall-rule
create command.
az mysql server firewall-rule create --name allIPs --server <mysql_server_name> --resource-group

myResourceGroup --start-ip-address 0.0.0.0 --end-ip-address 255.255.255.255
NOTE
Azure Database for MySQL (Preview) doesn't currently limit connections only to Azure services. As IP addresses in Azure are
dynamically assigned, it is better to enable all IP addresses. The service is in preview. Better methods for securing your
database are planned.
Connect to production MySQL server locally

In the terminal window, connect to the MySQL server in Azure. Use the value you specified previously for
<mysql_server_name>.
mysql -u adminuser@<mysql_server_name> -h <mysql_server_name>.database.windows.net -P 3306 -p
When prompted for a password, use $tr0ngPa$w0rd!, which you specified when you created the database server.
Create a production database
Create a user with permissions

Create a database user called phpappuser and give it all privileges in the sampledb database.
CREATE USER 'phpappuser' IDENTIFIED BY 'MySQLAzure2017';

GRANT ALL PRIVILEGES ON sampledb.* TO 'phpappuser';
Exit the server connection by typing quit .
quit
Connect app to Azure MySQL

In this step, you connect the PHP application to the MySQL database you created in Azure Database for MySQL
(Preview).
Configure the database connection
In the repository root, create an .env.production file and copy the following variables into it. Replace the
placeholder <mysql_server_name>.
APP_ENV=production
APP_DEBUG=true
APP_KEY=SomeRandomString
DB_CONNECTION=mysql
DB_HOST=<mysql_server_name>.mysql.database.azure.com
DB_DATABASE=sampledb
DB_USERNAME=phpappuser@<mysql_server_name>
DB_PASSWORD=MySQLAzure2017
Save the changes.
TIP
To secure your MySQL connection information, this file is already excluded from the Git repository (See .gitignore in the
repository root). Later, you learn how to configure environment variables in App Service to connect to your database in
Azure Database for MySQL (Preview). With environment variables, you don't need the .env file in App Service.
Test the application locally

Run Laravel database migrations with .env.production as the environment file to create the tables in your MySQL
database in Azure Database for MySQL (Preview). Remember that .env.production has the connection information
to your MySQL database in Azure.
php artisan migrate --env=production --force
.env.production doesn't have a valid application key yet. Generate a new one for it in the terminal.
php artisan key:generate --env=production --force
Run the sample application with .env.production as the environment file.
php artisan serve --env=production
Navigate to http://localhost:8000 . If the page loads without errors, the PHP application is connecting to the
MySQL database in Azure.
Add a few tasks in the page.

Commit your changes
Run the following Git commands to commit your changes:
git add .
git commit -m "database.php updates"
Your app is ready to be deployed.
Deploy to Azure
In this step, you deploy the MySQL-connected PHP application to Azure App Service.
Configure a deployment user
NOTE

{
"kind": "linux",
}
Create a web app

command.
and - ). The runtime is set to PHP|7.0 . To see all supported runtimes, run az webapp list-runtimes.

"PHP|7.0" --deployment-local-git

{
"containerSize": 0,
"enabled": true,
}
NOTE
Configure database settings

command.
The following command configures the app settings DB_HOST , DB_DATABASE , DB_USERNAME , and DB_PASSWORD .
Replace the placeholders <appname> and <mysql_server_name>.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings DB_HOST="
<mysql_server_name>.database.windows.net" DB_DATABASE="sampledb" DB_USERNAME="phpappuser@<mysql_server_name>"
DB_PASSWORD="MySQLAzure2017"
You can use the PHP getenv method to access the settings. the Laravel code uses an env wrapper over the PHP
getenv . For example, the MySQL configuration in config/database.php looks like the following code:
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
...
],
Configure Laravel environment variables

Laravel needs an application key in App Service. You can configure it with app settings.
Use php artisan to generate a new application key without saving it to .env.
php artisan key:generate --show
Set the application key in the App Service web app by using the az webapp config appsettings set command.
Replace the placeholders <appname> and <outputofphpartisankey:generate>.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings APP_KEY="
<output_of_php_artisan_key:generate>" APP_DEBUG="true"
APP_DEBUG="true" tells Laravel to return debugging information when the deployed web app encounters errors.
When running a production application, set it to false , which is more secure.
Set the virtual application path
Set the virtual application path for the web app. This step is required because the Laravel application lifecycle
begins in the public directory instead of the application's root directory. Other PHP frameworks whose lifecycle
start in the root directory can work without manual configuration of the virtual application path.
Set the virtual application path by using the az resource update command. Replace the <appname> placeholder.
az resource update --name web --resource-group myResourceGroup --namespace Microsoft.Web --resource-type

config --parent sites/<app_name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --
api-version 2015-06-01
By default, Azure App Service points the root virtual application path (/) to the root directory of the deployed
application files (sites\wwwroot).
Add an Azure remote to your local Git repository.
git remote add azure <paste_copied_url_here>
Push to the Azure remote to deploy the PHP application. You are prompted for the password you supplied earlier
as part of the creation of the deployment user.
During deployment, Azure App Service communicates its progress with Git.

remote: Preparing deployment for commit id 'a5e076db9c'.
...
NOTE
You may notice that the deployment process installs Composer packages at the end. App Service does not run these
automations during default deployment, so this sample repository has three additional files in its root directory to enable it:
.deployment - This file tells App Service to run bash deploy.sh as the custom deployment script.
deploy.sh - The custom deployment script. If you review the file, you will see that it runs php composer.phar install
after npm install .
composer.phar - The Composer package manager.
You can use this approach to add any step to your Git-based deployment to App Service. For more information, see Custom
Deployment Script.

Browse to http://<app_name>.azurewebsites.net and add a few tasks to the list.
Congratulations, you're running a data-driven PHP app in Azure App Service.
Update model locally and redeploy

In this step, you make a simple change to the task data model and the webapp, and then publish the update to
Azure.
For the tasks scenario, you modify the application so that you can mark a task as complete.
Add a column
In the terminal, navigate to the root of the Git repository.
Generate a new database migration for the tasks table:
php artisan make:migration add_complete_column --table=tasks
This command shows you the name of the migration file that's generated. Find this file in database/migrations and
open it.
Replace the up method with the following code:
public function up()

{
Schema::table('tasks', function (Blueprint $table) {
$table->boolean('complete')->default(False);
});
}
The preceding code adds a boolean column in the tasks table called complete .
Replace the down method with the following code for the rollback action:
public function down()

{
Schema::table('tasks', function (Blueprint $table) {
$table->dropColumn('complete');
});
}
In the terminal, run Laravel database migrations to make the change in the local database.
php artisan migrate
Based on the Laravel naming convention, the model Task (see app/Task.php) maps to the tasks table by default.
Update application logic
Open the routes/web.php file. The application defines its routes and business logic here.
At the end of the file, add a route with the following code:
/**
* Toggle Task completeness
*/
Route::post('/task/{id}', function ($id) {
error_log('INFO: post /task/'.$id);
$task = Task::findOrFail($id);
$task->complete = !$task->complete;
$task->save();
return redirect('/');
});
The preceding code makes a simple update to the data model by toggling the value of complete .
Update the view
Open the resources/views/tasks.blade.php file. Find the <tr> opening tag and replace it with:
<tr class="{{ $task->complete ? 'success' : 'active' }}" >
The preceding code changes the row color depending on whether the task is complete.
In the next line, you have the following code:
<td class="table-text"><div>{{ $task->name }}</div></td>
Replace the entire line with the following code:
<td>
<form action="{{ url('task/'.$task->id) }}" method="POST">
{{ csrf_field() }}
<button type="submit" class="btn btn-xs">

<i class="fa {{$task->complete ? 'fa-check-square-o' : 'fa-square-o'}}"></i>
</button>
{{ $task->name }}
</form>
</td>
The preceding code adds the submit button that references the route that you defined earlier.
Test the changes locally
From the root directory of the Git repository, run the development server.
php artisan serve
To see the task status change, navigate to http://localhost:8000 and select the checkbox.
In the terminal, run Laravel database migrations with the production connection string to make the change in the
Azure database.
php artisan migrate --env=production --force
Commit all the changes in Git, and then push the code changes to Azure.
git add .
git commit -m "added complete checkbox"
Once the git push is complete, navigate to the Azure web app and test the new functionality.
If you added any tasks, they are retained in the database. Updates to the data schema leave existing data intact.
Manage the Azure web app

You see your web app's Overview page. Here, you can perform basic management tasks like stop, start, restart,
browse, and delete.
The left menu provides pages for configuring your app.
Clean up resources
Next steps
Connect a PHP app to MySQL
Advance to the next tutorial to learn how to map a custom DNS name to a web app.
Build a Node.js and MongoDB web app in Azure
App Service on Linux
NOTE
This article deploys an app to App Service on Linux. To deploy to App Service on Windows, see Build a Node.js and MongoDB
web app in Azure.
system. This tutorial shows how to create a Node.js web app, connect it locally to a MongoDB database, then
deploy to Azure connected to a CosmosDB database using the MongoDB API. When you're done, you'll have a
MEAN application (MongoDB, Express, AngularJS, and Node.js) running in App Service on Linux. For simplicity, the
sample application uses the MEAN.js web framework.
What you learn how to:

Create a CosmosDB database using the MongoDB API in Azure
Connect a Node.js app to MongoDB
Prerequisites
1. Install Git
2. Install Node.js v6.0 or above and NPM
3. Install Gulp.js (required by MEAN.js)
4. Install and run MongoDB Community Edition
Test local MongoDB

Open the terminal window and cd to the bin directory of your MongoDB installation. You can use this terminal
window to run all the commands in this tutorial.
Run mongo in the terminal to connect to your local MongoDB server.
mongo
If your connection is successful, then your MongoDB database is already running. If not, make sure that your local
MongoDB database is started by following the steps at Install MongoDB Community Edition. Often, MongoDB is
installed, but you still need to start it by running mongod .
When you're done testing your MongoDB database, type Ctrl+C in the terminal.
Create local Node.js app

In this step, you set up the local Node.js project.
git clone https://github.com/Azure-Samples/meanjs.git
This sample repository contains a copy of the MEAN.js repository. It is modified to run on App Service (for more
information, see the MEAN.js repository README file).
Run the application
Run the following commands to install the required packages and start the application.
cd meanjs
npm install
npm start
Ignore the config.domain warning. When the app is fully loaded, you see something similar to the following
message:
--
MEAN.JS - Development Environment
Environment: development
Server: http://0.0.0.0:3000
Database: mongodb://localhost/mean-dev
App version: 0.5.0
MEAN.JS version: 0.5.0
--
Navigate to http://localhost:3000 in a browser. Click Sign Up in the top menu and create a test user.
The MEAN.js sample application stores user data in the database. If you are successful at creating a user and
signing in, then your app is writing data to the local MongoDB database.
Select Admin > Manage Articles to add some articles.
To stop Node.js at any time, press Ctrl+C in the terminal.

Create production MongoDB

In this step, you create a MongoDB database in Azure. When your app is deployed to Azure, it uses this cloud
database.
For MongoDB, this tutorial uses Azure Cosmos DB. Cosmos DB supports MongoDB client connections.
Create a Cosmos DB account
In the Cloud Shell, create a Cosmos DB account with the az cosmosdb create command.
In the following command, substitute a unique Cosmos DB name for the <cosmosdb_name> placeholder. This
name is used as the part of the Cosmos DB endpoint, https://<cosmosdb_name>.documents.azure.com/ , so the name
needs to be unique across all Cosmos DB accounts in Azure. The name must contain only lowercase letters,
numbers, and the hyphen (-) character, and must be between 3 and 50 characters long.
az cosmosdb create --name <cosmosdb_name> --resource-group myResourceGroup --kind MongoDB
The --kind MongoDB parameter enables MongoDB client connections.

When the Cosmos DB account is created, the Azure CLI shows information similar to the following example:
{
"consistencyPolicy":
{
"defaultConsistencyLevel": "Session",
"maxIntervalInSeconds": 5,
"maxStalenessPrefix": 100
},
"databaseAccountOfferType": "Standard",
"documentEndpoint": "https://<cosmosdb_name>.documents.azure.com:443/",
"failoverPolicies":
...
< Output truncated for readability >
}
Connect app to production MongoDB

In this step, you connect your MEAN.js sample application to the Cosmos DB database you just created, using a
MongoDB connection string.
Retrieve the database key
To connect to the Cosmos DB database, you need the database key. In the Cloud Shell, use the az cosmosdb list-
keys command to retrieve the primary key.
az cosmosdb list-keys --name <cosmosdb_name> --resource-group myResourceGroup
The Azure CLI shows information similar to the following example:
{
"primaryMasterKey":
"RS4CmUwzGRASJPMoc0kiEvdnKmxyRILC9BWisAYh3Hq4zBYKr0XQiSE4pqx3UchBeO4QRCzUt1i7w0rOkitoJw==",
"primaryReadonlyMasterKey":
"HvitsjIYz8TwRmIuPEUAALRwqgKOzJUjW22wPL2U8zoMVhGvregBkBk9LdMTxqBgDETSq7obbwZtdeFY7hElTg==",
"secondaryMasterKey":
"Lu9aeZTiXU4PjuuyGBbvS1N9IRG3oegIrIh95U6VOstf9bJiiIpw3IfwSUgQWSEYM3VeEyrhHJ4rn3Ci0vuFqA==",
"secondaryReadonlyMasterKey":
"LpsCicpVZqHRy7qbMgrzbRKjbYCwCKPQRl0QpgReAOxMcggTvxJFA94fTi0oQ7xtxpftTJcXkjTirQ0pT7QFrQ=="
}
Copy the value of primaryMasterKey . You need this information in the next step.
Configure the connection string in your Node.js application
In your local MEAN.js repository, in the config/env/ folder, create a file named local-production.js. .gitignore is
configured to keep this file out of the repository.
Copy the following code into it. Be sure to replace the two <cosmosdb_name> placeholders with your Cosmos DB
database name, and replace the <primary_master_key> placeholder with the key you copied in the previous step.
module.exports = {
db: {
uri: 'mongodb://<cosmosdb_name>:<primary_master_key>@<cosmosdb_name>.documents.azure.com:10250/mean?
ssl=true&sslverifycertificate=false'
}
};
The ssl=true option is required because Cosmos DB requires SSL.

Save your changes.
Test the application in production mode
In a local terminal window, run the following command to minify and bundle scripts for the production
environment. This process generates the files needed by the production environment.
gulp prod
In a local terminal window, run the following command to use the connection string you configured in
config/env/local-production.js. Ignore the certificate error and the config.domain warning.
NODE_ENV=production node server.js
NODE_ENV=production sets the environment variable that tells Node.js to run in the production environment.
node server.js starts the Node.js server with server.js in your repository root. This is how your Node.js
application is loaded in Azure.
When the app is loaded, check to make sure that it's running in the production environment:
--
MEAN.JS
Environment: production
Server: http://0.0.0.0:8443
Database: mongodb://<cosmosdb_name>:
<primary_master_key>@<cosmosdb_name>.documents.azure.com:10250/mean?ssl=true&sslverifycertificate=false
App version: 0.5.0
MEAN.JS version: 0.5.0
Navigate to http://localhost:8443 in a browser. Click Sign Up in the top menu and create a test user. If you are
successful creating a user and signing in, then your app is writing data to the Cosmos DB database in Azure.
In the terminal, stop Node.js by typing Ctrl+C .
Deploy app to Azure

In this step, you deploy your MongoDB-connected Node.js application to Azure App Service.
Configure local git deployment
NOTE

{
"kind": "linux",
}
Create a linux based web app

command.
and - ). The runtime is set to NODE|6.9 . To see all supported runtimes, run az webapp list-runtimes.

"NODE|6.9" --deployment-local-git
{
"containerSize": 0,
"enabled": true,
}
You’ve created an empty web app, with git deployment enabled.
NOTE
Configure an environment variable

By default, the MEAN.js project keeps config/env/local-production.js out of the Git repository. So for your Azure
web app, you use app settings to define your MongoDB connection string.
To set app settings, use the az webapp config appsettings set command in the Cloud Shell.
The following example configures a MONGODB_URI app setting in your Azure web app. Replace the <app_name>,
<cosmosdb_name>, and <primary_master_key> placeholders.

MONGODB_URI="mongodb://<cosmosdb_name>:<primary_master_key>@<cosmosdb_name>.documents.azure.com:10250/mean?
ssl=true"
In Node.js code, you access this app setting with process.env.MONGODB_URI , just like you would access any
environment variable.
In your local MEAN.js repository, open config/env/production.js (not config/env/local-production.js), which has
production-environment specific configuration. Note that the default MEAN.js app is already configured to use the
MONGODB_URI environment variable that you created.
db: {
uri: ... || process.env.MONGODB_URI || ...,
...
},

example:

remote: Preparing deployment for commit id '6c7c716eee'.
remote: Handling node.js deployment.
.
.
.
You may notice that the deployment process runs Gulp after npm install . App Service does not run Gulp or Grunt
tasks during deployment, so this sample repository has two additional files in its root directory to enable it:
.deployment - This file tells App Service to run bash deploy.sh as the custom deployment script.
deploy.sh - The custom deployment script. If you review the file, you will see that it runs gulp prod after
npm install and bower install .
You can use this approach to add any step to your Git-based deployment. If you restart your Azure web app at any
point, App Service doesn't rerun these automation tasks.
Click Sign Up in the top menu and create a dummy user.

If you are successful and the app automatically signs in to the created user, then your MEAN.js app in Azure has
connectivity to the Cosmos DB database MongoDB API.
Select Admin > Manage Articles to add some articles.
Congratulations! You're running a data-driven Node.js app in Azure App Service on Linux.
Update data model and redeploy

In this step, you change the article data model and publish your change to Azure.
Update the data model
In your local MEAN.js repository, open modules/articles/server/models/article.server.model.js.
In ArticleSchema , add a String type called comment . When you're done, your schema code should look like this:
var ArticleSchema = new Schema({

...,
user: {
type: Schema.ObjectId,
ref: 'User'
},
comment: {
type: String,
default: '',
trim: true
}
});
Update the articles code

Update the rest of your articles code to use comment .
There are five files you need to modify: the server controller and the four client views.
Open modules/articles/server/controllers/articles.server.controller.js.
In the update function, add an assignment for article.comment . The following code shows the completed update
function:
exports.update = function (req, res) {
var article = req.article;
article.title = req.body.title;
article.content = req.body.content;
article.comment = req.body.comment;
...
};
Open modules/articles/client/views/view-article.client.view.html.
Just above the closing </section> tag, add the following line to display comment along with the rest of the article
data:
<p class="lead" ng-bind="vm.article.comment"></p>
Open modules/articles/client/views/list-articles.client.view.html.
Just above the closing </a> tag, add the following line to display comment along with the rest of the article data:
<p class="list-group-item-text" ng-bind="article.comment"></p>
Open modules/articles/client/views/admin/list-articles.client.view.html.
Inside the <div class="list-group"> element and just above the closing </a> tag, add the following line to display
comment along with the rest of the article data:
<p class="list-group-item-text" data-ng-bind="article.comment"></p>
Open modules/articles/client/views/admin/form-article.client.view.html.
Find the <div class="form-group"> element that contains the submit button, which looks like this:
<button type="submit" class="btn btn-default">{{vm.article._id ? 'Update' : 'Create'}}</button>
</div>
Just above this tag, add another <div class="form-group"> element that lets people edit the comment field. Your
new element should look like this:
<label class="control-label" for="comment">Comment</label>
<textarea name="comment" data-ng-model="vm.article.comment" id="comment" class="form-control" cols="30"
rows="10" placeholder="Comment"></textarea>
</div>

Save all your changes.
In the local terminal window, test your changes in production mode again.
gulp prod
NODE_ENV=production node server.js
NOTE
Remember that your config/env/production.js has been reverted, and the MONGODB_URI environment variable is only set in
your Azure web app and not on your local machine. If you look at the config file, you find that the production configuration
defaults to use a local MongoDB database. This makes sure that you don't touch production data when you test your code
changes locally.
Navigate to http://localhost:8443 in a browser and make sure that you're signed in.
Select Admin > Manage Articles, then add an article by selecting the + button.
You see the new Comment textbox now.
In the terminal, stop Node.js by typing Ctrl+C .

Commit your changes in Git, then push the code changes to Azure.
git commit -am "added article comment"

Once the git push is complete, navigate to your Azure web app and try out the new functionality.
If you added any articles earlier, you still can see them. Existing data in your Cosmos DB is not lost. Also, your
updates to the data schema and leaves your existing data intact.

Clean up resources
Next steps
What you learned:
Create a CosmosDB database using the MongoDB API in Azure
Connect a Node.js app to MongoDB
Stream logs from Azure to your terminal
Build a Docker Python and PostgreSQL web app in
Azure
Web App for Containers provides a highly scalable, self-patching web hosting service. This tutorial shows how to
create a basic Docker Python web app in Azure. You connect this app to a PostgreSQL database. When you are
done, you have a Python Flask application running within a Docker container on App Service on Linux.
You can follow the steps below on macOS. Linux and Windows instructions are the same in most cases, but the
differences are not detailed in this tutorial.
Prerequisites
1. Install Git
2. Install Python
3. Install and run PostgreSQL
4. Install Docker Community Edition

If you choose to install and use the CLI locally, this article requires that you are running the Azure CLI version 2.0 or
later. Run az --version to find the version. If you need to install or upgrade, see Install Azure CLI 2.0.
Test local PostgreSQL installation and create a database

Open the terminal window and run psql postgres to connect to your local PostgreSQL server.
psql postgres
If your connection is successful, your PostgreSQL database is running. If not, make sure that your local PostgresQL
database is started by following the steps at Downloads - PostgreSQL Core Distribution.
Create a database called eventregistration and set up a separate database user named manager with password
supersecretpass.
CREATE DATABASE eventregistration;

CREATE USER manager WITH PASSWORD 'supersecretpass';
GRANT ALL PRIVILEGES ON DATABASE eventregistration TO manager;
Type \q to exit the PostgreSQL client.
Create local Python Flask application

In this step, you set up the local Python Flask project.
Open the terminal window, and CD to a working directory.
Run the following commands to clone the sample repository and go to the 0.1-initialapp release.
git clone https://github.com/Azure-Samples/docker-flask-postgres.git

cd docker-flask-postgres
git checkout tags/0.1-initialapp
This sample repository contains a Flask application.

Run the application
NOTE
In a later step you simplify this process by building a Docker container to use with the production database.
Install the required packages and start the application.
pip install virtualenv

virtualenv venv
source venv/bin/activate
pip install -r requirements.txt
cd app
FLASK_APP=app.py DBHOST="localhost" DBUSER="manager" DBNAME="eventregistration" DBPASS="supersecretpass" flask
db upgrade
run
When the app is fully loaded, you see something similar to the following message:
INFO [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO [alembic.runtime.migration] Will assume transactional DDL.
INFO [alembic.runtime.migration] Running upgrade -> 791cd7d80402, empty message
* Serving Flask app "app"
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
Navigate to http://127.0.0.1:5000 in a browser. Click Register! and create a test user.
The Flask sample application stores user data in the database. If you are successful at registering a user, your app is
writing data to the local PostgreSQL database.
To stop the Flask server at anytime, type Ctrl+C in the terminal.
Create a production PostgreSQL database

In this step, you create a PostgreSQL database in Azure. When your app is deployed to Azure, it uses this cloud
database.
Log in to Azure
You are now going to use the Azure CLI 2.0 to create the resources needed to host your Python application in Web
App for Containers. Log in to your Azure subscription with the az login command and follow the on-screen
directions.
az login

Create a resource group with the az group create.
The following example creates a resource group in the West US region:
az group create --name myResourceGroup --location "West US"
Use the az appservice list-locations Azure CLI command to list available locations.
Create an Azure Database for PostgreSQL server
Create a PostgreSQL server with the az postgres server create command.
In the following command, substitute a unique server name for the <postgresql_name> placeholder and a user
name for the <admin_username> placeholder. The server name is used as part of your PostgreSQL endpoint (
https://<postgresql_name>.postgres.database.azure.com ), so the name needs to be unique across all servers in
Azure. The user name is for the initial database admin user account. You are prompted to pick a password for this
user.
az postgres server create --resource-group myResourceGroup --name <postgresql_name> --admin-user

<admin_username>
When the Azure Database for PostgreSQL server is created, the Azure CLI shows information similar to the
following example:
{
"administratorLogin": "<my_admin_username>",
"fullyQualifiedDomainName": "<postgresql_name>.postgres.database.azure.com",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.DBforPostgreSQL/servers/<postgresql_name>",
"location": "westus",
"name": "<postgresql_name>",
"sku": {
"capacity": 100,
"family": null,
"name": "PGSQLS3M100",
"size": null,
"tier": "Basic"
},
"sslEnforcement": null,
"storageMb": 2048,
"tags": null,
"type": "Microsoft.DBforPostgreSQL/servers",
"userVisibleState": "Ready",
"version": null
}
Create a firewall rule for the Azure Database for PostgreSQL server
Run the following Azure CLI command to allow access to the database from all IP addresses.
az postgres server firewall-rule create --resource-group myResourceGroup --server-name <postgresql_name> --

start-ip-address=0.0.0.0 --end-ip-address=255.255.255.255 --name AllowAllIPs
The Azure CLI confirms the firewall rule creation with output similar to the following example:
{
"endIpAddress": "255.255.255.255",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.DBforPostgreSQL/servers/<postgresql_name>/firew
allRules/AllowAllIPs",
"name": "AllowAllIPs",
"startIpAddress": "0.0.0.0",
"type": "Microsoft.DBforPostgreSQL/servers/firewallRules"
}
Connect your Python Flask application to the database
In this step, you connect your Python Flask sample application to the Azure Database for PostgreSQL server you
created.
Create an empty database and set up a new database application user
Create a database user with access to a single database only. You use these credentials to avoid giving the
application full access to the server.
Connect to the database (you're prompted for your admin password).
psql -h <postgresql_name>.postgres.database.azure.com -U <my_admin_username>@<postgresql_name> postgres
Create the database and user from the PostgreSQL CLI.
CREATE DATABASE eventregistration;

CREATE USER manager WITH PASSWORD 'supersecretpass';
GRANT ALL PRIVILEGES ON DATABASE eventregistration TO manager;
Type \q to exit the PostgreSQL client.

Test the application locally against the Azure PostgreSQL database
Going back now to the app folder of the cloned Github repository, you can run the Python Flask application by
updating the database environment variables.
FLASK_APP=app.py DBHOST="<postgresql_name>.postgres.database.azure.com" DBUSER="manager@<postgresql_name>"

DBNAME="eventregistration" DBPASS="supersecretpass" flask db upgrade
FLASK_APP=app.py DBHOST="<postgresql_name>.postgres.database.azure.com" DBUSER="manager@<postgresql_name>"
DBNAME="eventregistration" DBPASS="supersecretpass" flask run
When the app is fully loaded, you see something similar to the following message:

INFO [alembic.runtime.migration] Running upgrade -> 791cd7d80402, empty message
Navigate to http://127.0.0.1:5000 in a browser. Click Register! and create a test registration. You are now writing
data to the database in Azure.
Running the application from a Docker Container
Build the Docker container image.
cd ..
docker build -t flask-postgresql-sample .
Docker displays a confirmation that it successfully created the container.
Successfully built 7548f983a36b
Add database environment variables to an environment variable file db.env. The app connects to the Azure
Database for PostgreSQL production database.
DBHOST="<postgresql_name>.postgres.database.azure.com"
DBUSER="manager@<postgresql_name>"
DBNAME="eventregistration"
DBPASS="supersecretpass"
Run the app from within the Docker container. The following command specifies the environment variable file and
maps the default Flask port 5000 to local port 5000.
docker run -it --env-file db.env -p 5000:5000 flask-postgresql-sample
The output is similar to what you saw earlier. However, the initial database migration no longer needs to be
performed and therefore is skipped.

The database already contains the registration you created previously.

Upload the Docker container to a container registry
In this step, you upload the Docker container to a container registry. Use Azure Container Registry, but you could
also use other popular ones such as Docker Hub.
Create an Azure Container Registry
In the following command to create a container registry replace <registry_name> with a unique Azure container
registry name of your choice.
az acr create --name <registry_name> --resource-group myResourceGroup --location "West US" --sku Basic
Output
{
"adminUserEnabled": false,
"creationDate": "2017-05-04T08:50:55.635688+00:00",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/<registry_name>",
"location": "westus",
"loginServer": "<registry_name>.azurecr.io",
"name": "<registry_name>",
"provisioningState": "Succeeded",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"storageAccount": {
"name": "<registry_name>01234"
},
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}
Retrieve the registry credentials for pushing and pulling Docker images
To show registry credentials, enable admin mode first.
az acr update --name <registry_name> --admin-enabled true

az acr credential show -n <registry_name>
You see two passwords. Make note of the user name and the first password.
{
"passwords": [
{
"name": "password",
"value": "<registry_password>"
},
{
"name": "password2",
"value": "<registry_password2>"
}
],
"username": "<registry_name>"
}
Upload your Docker container to Azure Container Registry
docker login <registry_name>.azurecr.io -u <registry_name> -p "<registry_password>"

docker tag flask-postgresql-sample <registry_name>.azurecr.io/flask-postgresql-sample
docker push <registry_name>.azurecr.io/flask-postgresql-sample
Deploy the Docker Python Flask application to Azure

In this step, you deploy your Docker container-based Python Flask application to Azure App Service.
Create an App Service plan with the az appservice plan create command.
An App Service plan specifies the location, size, and features of the web server farm that hosts your app. You can
save money when hosting multiple apps by configuring the web apps to share a single App Service plan.
App Service plans define:
Region (for example: North Europe, East US, or Southeast Asia)
Instance size (small, medium, or large)
Scale count (1 to 10 instances)
SKU (Basic, Standard)
The following example creates a Linux-based App Service plan named myAppServicePlan using the S1 pricing tier:
When the App Service plan is created, the Azure CLI shows information similar to the following example:
{
"geoRegion": "West US",
"kind": "linux",
"location": "West US",
"numberOfSites": 0,
"perSiteScaling": false,
"reserved": true,
"sku": {
"capabilities": null,
"capacity": 1,
"family": "S",
"locations": null,
"name": "S1",
"size": "S1",
"skuCapacity": null,
"tier": "Standard"
},
"status": "Ready",
"subscription": "00000000-0000-0000-0000-000000000000",
"tags": null,
"targetWorkerCount": 0,
}
Create a web app

Create a web app in the myAppServicePlan App Service plan with the az webapp create command.
The web app gives you a hosting space to deploy your code and provides a URL for you to view the deployed
application. Use to create the web app.
In the following command, replace the <app_name> placeholder with a unique app name. This name is part of the
default URL for the web app, so the name needs to be unique across all apps in Azure App Service.
az webapp create --name <app_name> --resource-group myResourceGroup --plan myAppServicePlan
When the web app has been created, the Azure CLI shows information similar to the following example:
{
"containerSize": 0,
"enabled": true,
...
}
Configure the database environment variables
Earlier in the tutorial, you defined environment variables to connect to your PostgreSQL database.
command.
The following example specifies the database connection details as app settings. It also uses the PORT variable to
map PORT 5000 from your Docker Container to receive HTTP traffic on PORT 80.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings DBHOST="
<postgresql_name>.postgres.database.azure.com" DBUSER="manager@<postgresql_name>" DBPASS="supersecretpass"
DBNAME="eventregistration" PORT=5000
Configure Docker container deployment

AppService can automatically download and run a Docker container.
az webapp config container set --resource-group myResourceGroup --name <app_name> --docker-registry-server-user

"<registry_name>" --docker-registry-server-password "<registry_password>" --docker-custom-image-name "
<registry_name>.azurecr.io/flask-postgresql-sample" --docker-registry-server-url
"https://<registry_name>.azurecr.io"
Whenever you update the Docker container or change the settings, restart the app. Restarting ensures that all
settings are applied and the latest container is pulled from the registry.
az webapp restart --resource-group myResourceGroup --name <app_name>

NOTE
The web app takes longer to load because the container has to be downloaded and started after the container configuration
is changed.
You see previously registered guests that were saved to the Azure production database in the previous step.
Congratulations! You're running a Docker container-based Python Flask app in Azure App Service.
Update data model and redeploy
In this step, you add the number of attendees to each event registration by updating the Guest model.
Check out the 0.2-migration release with the following git command:
git checkout tags/0.2-migration
This release already made the necessary changes to views, controllers, and model. It also includes a database
migration generated via alembic ( flask db migrate ). You can see all changes made via the following git command:
git diff 0.1-initialapp 0.2-migration

Run the following commands to test your changes locally by running the flask server.
Mac / Linux:
source venv/bin/activate
cd app
db upgrade
run
Navigate to http://127.0.0.1:5000 in your browser to view the changes. Create a test registration.

Build the new docker image, push it to the container registry, and restart the app.
docker build -t flask-postgresql-sample .
docker tag flask-postgresql-sample <registry_name>.azurecr.io/flask-postgresql-sample
docker push <registry_name>.azurecr.io/flask-postgresql-sample
az appservice web restart --resource-group myResourceGroup --name <app_name>
Navigate to your Azure web app and try out the new functionality again. Create another event registration.

Next steps
Use a custom Docker image for Web App for
Containers
Web App for Containers provides built-in Docker images on Linux with support for specific versions, such as PHP
7.0 and Node.js 4.5. Web App for Containers uses the Docker container technology to host both built-in images
and custom images as a platform as a service. In this tutorial, you learn how to build a custom Docker image and
deploy it to Web App for Containers. This pattern is useful when the built-in images don't include your language of
choice, or when your application requires a specific configuration that isn't provided within the built-in images.
Prerequisites
To complete this tutorial, you need:
Git
An active Azure subscription
Docker
A Docker Hub account
Download the sample

In a terminal window, run the following command to clone the sample app repository to your local machine, then
change to the directory that contains the sample code.
git clone https://github.com/Azure-Samples/docker-django-webapp-linux.git --config core.autocrlf=input

cd docker-django-webapp-linux
Build the image from the Docker file

In the Git repository, take a look at Dockerfile. This file describes the Python environment that is required to run
your application. Additionally, the image sets up an SSH server for secure communication between the container
and the host.
FROM python:3.4
RUN mkdir /code

WORKDIR /code
ADD requirements.txt /code/
RUN pip install -r requirements.txt
ADD . /code/
# ssh
ENV SSH_PASSWD "root:Docker!"
RUN apt-get update \
&& apt-get install -y --no-install-recommends dialog \
&& apt-get update \
&& apt-get install -y --no-install-recommends openssh-server \
&& echo "$SSH_PASSWD" | chpasswd
COPY sshd_config /etc/ssh/

COPY init.sh /usr/local/bin/
RUN chmod u+x /usr/local/bin/init.sh

EXPOSE 8000 2222
#CMD ["python", "/code/manage.py", "runserver", "0.0.0.0:8000"]
ENTRYPOINT ["init.sh"]
To build the Docker image, run the docker build command, and provide a name, mydockerimage , and tag, v1.0.0 .
Replace <docker-id> with your Docker Hub account ID.
docker build --tag <docker-id>/mydockerimage:v1.0.0 .
The command produces output similar to the following:
# The output from the commands in this article has been shortened for brevity.
Sending build context to Docker daemon 5.558MB

Step 1/13 : FROM python:3.4
---> 9ff45ddb54e9
Step 2/13 : RUN mkdir /code
---> Using cache
---> f3f3ac01db0a
Step 3/13 : WORKDIR /code
---> Using cache
---> 38b32f15b442
.
.
.
Step 13/13 : ENTRYPOINT init.sh
---> Running in 5904e4c70043
---> e7cf08275692
Removing intermediate container 5904e4c70043
Successfully built e7cf08275692
Successfully tagged cephalin/mydockerimage:v1.0.0
Test that the build works by running the Docker container. Issue the docker run command and pass the name and
tag of the image to it. Be sure to specify the port using the -p argument.
docker run -p 2222:8000 <docker-ID>/mydockerimage:v1.0.0
Verify the web app and container are functioning correctly by browsing to http://localhost:2222 .
Push the Docker image to Docker Hub
A registry is an application that hosts images and provides services image and container services. In order to share
your image, you must push it to a registry.
NOTE
Pushing to a Private Docker Registry? See the optional instructions to Push a Docker image to Private Registry.
Docker Hub is a registry for Docker images that allows you to host your own repositories, either public or private.
To push a custom Docker image to the public Docker Hub, use the docker push command and provide a full image
name and tag. A full image name and tag looks like the following sample:
<docker-id>/image-name:tag
If you haven't logged in to Docker Hub, do so using the docker login command before attempting to push an
image.
docker login --username <docker-id> --password <docker-hub-password>
A "login succeeded" message confirms that you are logged in. Once logged in, you can push the image to Docker
Hub using the docker push command.
docker push <docker-id>/mydockerimage:v1.0.0
Verify that the push succeeded by examining the command's output.

The push refers to a repository [docker.io/<docker-id>/mydockerimage:v1.0.0]
c33197c3f6d4: Pushed
ccd2c850ee43: Pushed
02dff2853466: Pushed
6ce78153632a: Pushed
efef3f03cc58: Pushed
3439624d77fb: Pushed
3a07adfb35c5: Pushed
2fcec228e1b7: Mounted from library/python
97d2d3bae505: Mounted from library/python
95aadeabf504: Mounted from library/python
b456afdc9996: Mounted from library/python
d752a0310ee4: Mounted from library/python
db64edce4b5b: Mounted from library/python
d5d60fc34309: Mounted from library/python
c01c63c6823d: Mounted from library/python
v1.0.0: digest: sha256:21f2798b20555f4143f2ca0591a43b4f6c8138406041f2d32ec908974feced66 size: 3676

Deploy app to Azure

You can host native Linux applications in the cloud by using Azure Web Apps. To create a Web App for Containers,
you must run Azure CLI commands that create a group, then a service plan, and finally the web app itself.
Create a Linux App Service plan
{
"kind": "linux",
}
Create a web app

command. Don't forget to replace <app_name> with a unique app name, and with your Docker ID.
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app_name> --deployment-

container-image-name <docker-ID>/mydockerimage:v1.0.0
{
"containerSize": 0,
"enabled": true,
}
Configure environment variables

Most Docker images have environment variables that need to be configured. If you are using an existing Docker
image built by someone else, the image may use a port other than 80. You tell Azure about the port that your
image uses by using the WEBSITES_PORT app setting. The GitHub page for the Python sample in this tutorial shows
that you need to set WEBSITES_PORT to 8000.
To set app settings, use the az webapp config appsettings set command in the Cloud Shell. App settings are case-
sensitive and space-separated.
az webapp config appsettings set --resource-group myResourceGroup --name <app_name> --settings

WEBSITES_PORT=8000
NOTE
Deploying from a Private Docker Registry? See the optional instructions to Configure Web App to use Docker container from
a Private Registry.
Test the web app

Verify that the web app works by browsing to it ( http://<app_name>azurewebsites.net ).
Change web app and redeploy

In your local Git repository, open app/templates/app/index.html. Locate the first HTML element and change it to.
<nav class="navbar navbar-inverse navbar-fixed-top">

<div class="container">
<div class="navbar-header">
<a class="navbar-brand" href="#">Azure App Service - Updated Here!</a>
</div>
</div>
</nav>
Once you've modified the Python file and saved it, you must rebuild and push the new Docker image. Then restart
the web app for the changes to take effect. Use the same commands that you have previously used in this tutorial.
You can refer to Build the image from the Docker file and Push the Docker image to Docker Hub. Test the web app
by following the instructions in Test the web app.
Connect to Web App for Containers using SSH

SSH enables secure communication between a container and a client. In order for a custom Docker image to
support SSH, you must build it into a Dockerfile. You enable SSH in the Docker file itself. The SSH instructions have
already been added to the sample dockerfile, so you can follow these instructions with your own custom image:
A RUN instruction that calls apt-get , then sets the password for the root account to "Docker!" .
ENV SSH_PASSWD "root:Docker!"

RUN apt-get update \
&& apt-get install -y --no-install-recommends dialog \
&& apt-get update \
&& apt-get install -y --no-install-recommends openssh-server \
&& echo "$SSH_PASSWD" | chpasswd
NOTE
This configuration does not allow external connections to the container. SSH is available only through the Kudu/SCM
Site. The Kudu/SCM site is authenticated with the publishing credentials.
A COPY instruction that instructs the Docker engine to copy the sshd_config file to the /etc/ssh/ directory.
Your configuration file should be based on this sshd_config file.
COPY sshd_config /etc/ssh/
NOTE
The sshd_config file must include the following items:
Ciphers must include at least one item in this list: aes128-cbc,3des-cbc,aes256-cbc .
MACs must include at least one item in this list: hmac-sha1,hmac-sha1-96 .
An EXPOSE instruction that exposes port 2222 in the container. Although the root password is known, port
2222 cannot be accessed from the internet. It is an internal port accessible only by containers within the
bridge network of a private virtual network. After that, commands copy SSH configuration details and start
the ssh service.
EXPOSE 8000 2222
Make sure to start the ssh service by using a shell script in the /bin directory.
#!/bin/bash
service ssh start
Open SSH connection to container

Web App for Containers does not allow external connections to the container. SSH is available only through the
Kudu site, which is accessible at https://<app_name>.scm.azurewebsites.net .
To connect, browse to https://<app_name>.scm.azurewebsites.net/webssh/host and sign in with your Azure account.
You are then redirected to a page displaying an interactive console.
You may wish to verify that certain applications are running in the container. To inspect the container and verify
running processes, issue the top command at the prompt.
top
The top command exposes all running processes in a container.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1 root 20 0 945616 35372 15348 S 0.0 2.1 0:04.63 node
20 root 20 0 55180 2776 2516 S 0.0 0.2 0:00.00 sshd
42 root 20 0 944596 33340 15352 S 0.0 1.9 0:05.80 node /opt/s+
56 root 20 0 59812 5244 4512 S 0.0 0.3 0:00.93 sshd
58 root 20 0 20228 3128 2664 S 0.0 0.2 0:00.00 bash
62 root 20 0 21916 2272 1944 S 0.0 0.1 0:03.15 top
63 root 20 0 59812 5344 4612 S 0.0 0.3 0:00.03 sshd
65 root 20 0 20228 3140 2672 S 0.0 0.2 0:00.00 bash
71 root 20 0 59812 5380 4648 S 0.0 0.3 0:00.02 sshd
73 root 20 0 20228 3160 2696 S 0.0 0.2 0:00.00 bash
77 root 20 0 21920 2304 1972 R 0.0 0.1 0:00.00 top
Congratulations! You've configured a custom Docker image for a Web App for Containers.
Use a private image from Docker Hub (optional)

In Create a web app, you specified an image on Docker Hub in the az webapp create command. This is good
enough for a public image. To use a private image, you need to configure your Docker account ID and password in
your Azure web app.
In the Cloud Shell, follow the az webapp create command with az webapp config container set. Replace
<app_name>, and also and with your Docker ID and password.
az webapp config container set --name <app_name> --resource-group myResourceGroup --docker-registry-server-

user <docker-id> --docker-registry-server-password <password>
The command reveals output similar to the following JSON string, showing that the configuration change
succeeded:
[
{
"name": "WEBSITES_ENABLE_APP_SERVICE_STORAGE",
"slotSetting": false,
"value": "false"
},
{
"name": "DOCKER_REGISTRY_SERVER_USERNAME",
"value": "<docker-id>"
},
{
"name": "DOCKER_REGISTRY_SERVER_PASSWORD",
"value": null
},
{
"name": "DOCKER_CUSTOM_IMAGE_NAME",
"value": "DOCKER|<image-name-and-tag>"
}
]
Use a Docker image from any private registry (optional)

In this section, you learn how to use a Docker image from a private registry in Web App for Containers, and it uses
Azure Container Registry as an example. The steps for using other private registries are similar.
Azure Container Registry is a managed Docker service from Azure for hosting private images. The deployments
may be any type, including Docker Swarm, Kubernetes, and Web App for Containers.
Create an Azure Container Registry
In the Cloud Shell, use the az acr create command to create an Azure Container Registry. Pass in the name,
resource group, and Basic for the SKU. Available SKUs are Classic , Basic , Standard , and Premium .
az acr create --name <azure-container-registry-name> --resource-group myResourceGroup --sku Basic --admin-

enabled true
Creating a container produces the following output:
- Finished ..
Create a new service principal and assign access:
az ad sp create-for-rbac --scopes
/subscriptions/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/<azure-
container-registry-name> --role Owner --password <password>
Use an existing service principal and assign access:

az role assignment create --scope
/subscriptions/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/<azure-
container-registry-name> --role Owner --assignee <app-id>
{
"adminUserEnabled": false,
"creationDate": "2017-08-09T04:21:09.654153+00:00",
"id":
"/subscriptions/<subscriptionId>/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registri
es/<azure-container-registry-name>",
"location": "westeurope",
"loginServer": "<azure-container-registry-name>.azurecr.io",
"name": "<azure-container-registry-name>",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"storageAccount": {
"name": "myazurecontainerre042025"
},
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}
Log in to Azure Container Registry

In order to push an image to the registry, you need to supply credentials so the registry accepts the push. You can
retrieve these credentials by using the az acr show command in the Cloud Shell.
az acr credential show --name <azure-container-registry-name>
The command reveals two passwords that can be used with the user name.
<
"passwords": [
{
"name": "password",
"value": "{password}"
},
{
"value": "{password}"
}
],
"username": "<registry-username>"
}
From your local terminal window, log in to the Azure Container Registry using the docker login command. The
server name is required to log in. Use the format {azure-container-registry-name>.azurecr.io .
docker login <azure-container-registry-name>.azurecr.io --username <registry-username> --password <password>
Confirm that the login succeeded.

Push an image to Azure Container Registry
NOTE
If you're using your own image, tag the image as follows:
docker tag <azure-container-registry-name>.azurecr.io/mydockerimage
Push the image by using the docker push command. Tag the image with the name of the registry, followed by
your image name and tag.
docker push <azure-container-registry-name>.azurecr.io/mydockerimage:v1.0.0
Verify that the push successfully added a container to the registry by listing the ACR repositories.
az acr repository list -n <azure-container-registry-name>
Listing the images in the registry confirms that mydockerimage is in the registry.
[
"mydockerimage"
]
Configure Web App to use the image from Azure Container Registry (or any private registry)
You can configure Web App for Containers so that it runs a container stored in the Azure Container Registry. Using
the Azure Container Registry is just like using any private registry, so if you need to use your own private registry,
the steps to complete this task are similar.
In the Cloud Shell, run az acr credential show to display the username and password for the Azure Container
Registry. Copy the username and one of the passwords so you can use it to configure the web app in the next step.
az acr credential show --name <azure-container-registry-name>
{
"passwords": [
{
"name": "password",
"value": "password"
},
{
"value": "password2"
}
],
"username": "<registry-username>"
}
In the Cloud Shell, run the az webapp config container set command to assign the custom Docker image to the
web app. Replace <app_name>, <docker-registry-server-url>, <registry-username>, and <password>. For Azure
Container Registry, <docker-registry-server-url> is in the format
https://<azure-container-registry-name>.azurecr.io .
az webapp config container set --name <app_name> --resource-group myResourceGroup --docker-custom-image-name

mydockerimage --docker-registry-server-url https://<azure-container-registry-name>.azurecr.io --docker-
registry-server-user <registry-username> --docker-registry-server-password <password>
NOTE
https:// is required in <docker-registry-server-url>.
The command reveals output similar to the following JSON string, showing that the configuration change
succeeded:
[
{
"name": "DOCKER_CUSTOM_IMAGE_NAME",
"value": "mydockerimage"
},
{
"name": "DOCKER_REGISTRY_SERVER_URL",
"value": "<azure-container-registry-name>.azurecr.io"
},
{
"name": "DOCKER_REGISTRY_SERVER_USERNAME",
"value": "<registry-username>"
},
{
"name": "DOCKER_REGISTRY_SERVER_PASSWORD",
"value": null
}
]
Clean up deployment
After the sample script has been run, the following command can be used to remove the resource group and all
resources associated with it.
Next steps
Build a Docker Python and PostgreSQL web app in Azure
Map an existing custom DNS name to Azure Web
Apps
Azure Web Apps provides a highly scalable, self-patching web hosting service. This tutorial shows you how to
map an existing custom DNS name to Azure Web Apps.

Map a subdomain (for example, www.contoso.com ) by using a CNAME record
Map a root domain (for example, contoso.com ) by using an A record
Map a wildcard domain (for example, *.contoso.com ) by using a CNAME record
Automate domain mapping with scripts
You can use either a CNAME record or an A record to map a custom DNS name to App Service.
NOTE
We recommend that you use a CNAME for all custom DNS names except a root domain (for example, contoso.com ).
To migrate a live site and its DNS domain name to App Service, see Migrate an active DNS name to Azure App
Service.
Prerequisites
Create an App Service app, or use an app that you created for another tutorial.
Purchase a domain name and make sure you have access to the DNS registry for your domain provider
(such as GoDaddy).
For example, to add DNS entries for contoso.com and www.contoso.com , you must be able to configure the
DNS settings for the contoso.com root domain.
NOTE
If you don't have an existing domain name, consider purchasing a domain using the Azure portal.
Prepare the app

To map a custom DNS name to a web app, the web app's App Service plan must be a paid tier (Shared, Basic,
Standard, or Premium). In this step, you make sure that the App Service app is in the supported pricing tier.
NOTE
purposes.
Sign in to Azure
Open the Azure portal and sign in with your Azure account.
Navigate to the app in the Azure portal
From the left menu, select App Services, and then select the name of the app.
You see the management page of the App Service app.

Check the pricing tier
In the left navigation of the app page, scroll to the Settings section and select Scale up (App Service plan).
The app's current tier is highlighted by a blue border. Check to make sure that the app is not in the Free tier.
Custom DNS is not supported in the Free tier.
If the App Service plan is not Free, close the Choose your pricing tier page and skip to Map a CNAME record.
Scale up the App Service plan
Select any of the non-free tiers (Shared, Basic, Standard, or Premium).
Click Select.
When you see the following notification, the scale operation is complete.
Map a CNAME record

In the tutorial example, you add a CNAME record for the www subdomain (for example, www.contoso.com ).
Access DNS records with domain provider
Sign in to the website of your domain provider.
Find the page for managing DNS records. Every domain provider has its own DNS records interface, so consult
the provider's documentation. Look for areas of the site labeled Domain Name, DNS, or Name Server
Management.
Often, you can find the DNS records page by viewing your account information, and then looking for a link such
as My domains. Go to that page and then look for a link that is named something like Zone file, DNS Records,
or Advanced configuration.
The following screenshot is an example of a DNS records page:
In the example screenshot, you select Add to create a record. Some providers have different links to add different
record types. Again, consult the provider's documentation.
NOTE
For certain providers, such as GoDaddy, changes to DNS records don't become effective until you select a separate Save
Changes link.
Create the CNAME record

Add a CNAME record to map a subdomain to the app's default hostname ( <app_name>.azurewebsites.net , where
<app_name> is the name of your app).
For the domain example, add a CNAME record that maps the name
www.contoso.com www to
<app_name>.azurewebsites.net .
After you add the CNAME, the DNS records page looks like the following example:
Enable the CNAME record mapping in Azure

In the left navigation of the app page in the Azure portal, select Custom domains.
In the Custom domains page of the app, add the fully qualified custom DNS name ( www.contoso.com ) to the list.
Select the + icon next to Add hostname.
Type the fully qualified domain name that you added a CNAME record for, such as www.contoso.com .
Select Validate.
The Add hostname button is activated.
Make sure that Hostname record type is set to CNAME (www.example.com or any subdomain).
Select Add hostname.
It might take some time for the new hostname to be reflected in the app's Custom domains page. Try
refreshing the browser to update the data.
If you missed a step or made a typo somewhere earlier, you see a verification error at the bottom of the page.
Map an A record
In the tutorial example, you add an A record for the root domain (for example, contoso.com ).
Copy the app's IP address
To map an A record, you need the app's external IP address. You can find this IP address in the app's Custom
domains page in the Azure portal.
In the Custom domains page, copy the app's IP address.

Management.
NOTE
Changes link.
Create the A record

To map an A record to an app, App Service requires two DNS records:
An A record to map to the app's IP address.
A TXT record to map to the app's default hostname <app_name>.azurewebsites.net . App Service uses this
record only at configuration time, to verify that you own the custom domain. After your custom domain is
validated and configured in App Service, you can delete this TXT record.
For the contoso.com domain example, create the A and TXT records according to the following table ( @ typically
represents the root domain).
RECORD TYPE HOST VALUE
A @ IP address from Copy the app's IP

address
TXT @ <app_name>.azurewebsites.net
When the records are added, the DNS records page looks like the following example:
Enable the A record mapping in the app

Back in the app's Custom domains page in the Azure portal, add the fully qualified custom DNS name (for
example, contoso.com ) to the list.
Type the fully qualified domain name that you configured the A record for, such as contoso.com .
Select Validate.
Make sure that Hostname record type is set to A record (example.com).
If you missed a step or made a typo somewhere earlier, you see a verification error at the bottom of the page.
Map a wildcard domain

In the tutorial example, you map a wildcard DNS name (for example, *.contoso.com ) to the App Service app by
adding a CNAME record.
Management.
NOTE
Changes link.
Create the CNAME record

Add a CNAME record to map a wildcard name to the app's default hostname ( <app_name>.azurewebsites.net ).
For the *.contoso.com domain example, the CNAME record will map the name * to
<app_name>.azurewebsites.net .
When the CNAME is added, the DNS records page looks like the following example:
Enable the CNAME record mapping in the app
You can now add any subdomain that matches the wildcard name to the app (for example, sub1.contoso.com
and sub2.contoso.com match *.contoso.com ).
Type a fully qualified domain name that matches the wildcard domain (for example, sub1.contoso.com ), and then
select Validate.
Make sure that Hostname record type is set to CNAME record (www.example.com or any subdomain).
Select the + icon again to add another hostname that matches the wildcard domain. For example, add
sub2.contoso.com .
Test in browser
Browse to the DNS name(s) that you configured earlier (for example, contoso.com , www.contoso.com ,
sub1.contoso.com , and sub2.contoso.com ).
Resolve 404 error “Web Site not found”

If you receive an HTTP 404 (Not Found) error when browsing to the URL of your custom domain, verify that your
domain resolves to your app's IP address using WhatsmyDNS.net. If not, it may be due to one of the following
reasons:
The custom domain configured is missing an A record and/or a CNAME record.
The browser client has cached the old IP address of your domain. Clear the cache and test DNS resolution
again. On a Windows machine, you clear the cache with ipconfig /flushdns .
Direct default URL to a custom directory

By default, App Service directs web requests to the root directory of your app code. However, certain web
frameworks don't start in the root directory. For example, Laravel starts in the public subdirectory. To continue
the contoso.com DNS example, such an app would be accessible at http://contoso.com/public , but you would
really want to direct http://contoso.com to the public directory instead. This step doesn't involve DNS
resolution, but customizing the virtual directory.
To do this, select Application settings in the left-hand navigation of your web app page.
At the bottom of the page, the root virtual directory / points to site\wwwroot by default, which is the root
directory of your app code. Change it to point to the site\wwwroot\public instead, for example, and save your
changes.
Once the operation completes, you app should return the right page at the root path (for example,
http://contoso.com).
Automate with scripts

You can automate management of custom domains with scripts, using the Azure CLI or Azure PowerShell.
Azure CLI
The following command adds a configured custom DNS name to an App Service app.
az webapp config hostname add \

--webapp-name <app_name> \
--resource-group <resource_group_name> \
--hostname <fully_qualified_domain_name>
For more information, see Map a custom domain to a web app.

Azure PowerShell
The following command adds a configured custom DNS name to an App Service app.
Set-AzureRmWebApp `
-Name <app_name> `
-ResourceGroupName <resource_group_name> `
-HostNames @("<fully_qualified_domain_name>","<app_name>.azurewebsites.net")
For more information, see Assign a custom domain to a web app.
Next steps
Map a subdomain by using a CNAME record
Map a root domain by using an A record
Map a wildcard domain by using a CNAME record
Automate domain mapping with scripts
Advance to the next tutorial to learn how to bind a custom SSL certificate to a web app.
Bind an existing custom SSL certificate to Azure Web Apps
Bind an existing custom SSL certificate to Azure Web
Apps
Azure Web Apps provides a highly scalable, self-patching web hosting service. This tutorial shows you how to bind
a custom SSL certificate that you purchased from a trusted certificate authority to Azure Web Apps. When you're
finished, you'll be able to access your web app at the HTTPS endpoint of your custom DNS domain.

Upgrade your app's pricing tier
Bind your custom SSL certificate to App Service
Enforce HTTPS for your app
Automate SSL certificate binding with scripts
NOTE
If you need to get a custom SSL certificate, you can get one in the Azure portal directly and bind it to your web app. Follow
the App Service Certificates tutorial.
Prerequisites
Create an App Service app
Map a custom DNS name to your web app
Acquire an SSL certificate from a trusted certificate authority
Have the private key you used to sign the SSL certificate request
Requirements for your SSL certificate
To use a certificate in App Service, the certificate must meet all the following requirements:
Signed by a trusted certificate authority
Exported as a password-protected PFX file
Contains private key at least 2048 bits long
Contains all intermediate certificates in the certificate chain
NOTE
Elliptic Curve Cryptography (ECC) certificates can work with App Service but are not covered by this article. Work with
your certificate authority on the exact steps to create ECC certificates.
Prepare your web app

To bind a custom SSL certificate to your web app, your App Service plan must be in the Basic, Standard, or
Premium tier. In this step, you make sure that your web app is in the supported pricing tier.
Log in to Azure
Open the Azure portal.
Navigate to your web app
From the left menu, click App Services, and then click the name of your web app.
You have landed in the management page of your web app.

In the left-hand navigation of your web app page, scroll to the Settings section and select Scale up (App Service
plan).
Check to make sure that your web app is not in the Free or Shared tier. Your web app's current tier is highlighted
by a dark blue box.
Custom SSL is not supported in the Free or Shared tier. If you need to scale up, follow the steps in the next
section. Otherwise, close the Choose your pricing tier page and skip to Upload and bind your SSL certificate.
Scale up your App Service plan
Select one of the Basic, Standard, or Premium tiers.
Click Select.
Bind your SSL certificate

You are ready to upload your SSL certificate to your web app.
Merge intermediate certificates
If your certificate authority gives you multiple certificates in the certificate chain, you need to merge the certificates
in order.
To do this, open each certificate you received in a text editor.
Create a file for the merged certificate, called mergedcertificate.crt. In a text editor, copy the content of each
certificate into this file. The order of your certificates should follow the order in the certificate chain, beginning with
your certificate and ending with the root certificate. It looks like the following example:
-----BEGIN CERTIFICATE-----
<your entire Base64 encoded SSL certificate>
-----END CERTIFICATE-----
<The entire Base64 encoded intermediate certificate 1>
<The entire Base64 encoded intermediate certificate 2>
<The entire Base64 encoded root certificate>
Export certificate to PFX

Export your merged SSL certificate with the private key that your certificate request was generated with.
If you generated your certificate request using OpenSSL, then you have created a private key file. To export your
certificate to PFX, run the following command. Replace the placeholders <private-key-file> and <merged-
certificate-file> with the paths to your private key and your merged certificate file.
openssl pkcs12 -export -out myserver.pfx -inkey <private-key-file> -in <merged-certificate-file>
When prompted, define an export password. You'll use this password when uploading your SSL certificate to App
Service later.
If you used IIS or Certreq.exe to generate your certificate request, install the certificate to your local machine, and
then export the certificate to PFX.
Upload your SSL certificate
To upload your SSL certificate, click SSL certificates in the left navigation of your web app.
Click Upload Certificate.
In PFX Certificate File, select your PFX file. In Certificate password, type the password that you created when
you exported the PFX file.
Click Upload.
When App Service finishes uploading your certificate, it appears in the SSL certificates page.
Bind your SSL certificate

In the SSL bindings section, click Add binding.
In the Add SSL Binding page, use the dropdowns to select the domain name to secure, and the certificate to use.
NOTE
If you have uploaded your certificate but don't see the domain name(s) in the Hostname dropdown, try refreshing the
browser page.
In SSL Type, select whether to use Server Name Indication (SNI) or IP-based SSL.
SNI-based SSL - Multiple SNI-based SSL bindings may be added. This option allows multiple SSL certificates
to secure multiple domains on the same IP address. Most modern browsers (including Internet Explorer,
Chrome, Firefox, and Opera) support SNI (find more comprehensive browser support information at Server
Name Indication).
IP-based SSL - Only one IP-based SSL binding may be added. This option allows only one SSL certificate to
secure a dedicated public IP address. To secure multiple domains, you must secure them all using the same SSL
certificate. This is the traditional option for SSL binding.
Click Add Binding.
When App Service finishes uploading your certificate, it appears in the SSL bindings sections.
Remap A record for IP SSL

If you don't use IP-based SSL in your web app, skip to Test HTTPS for your custom domain.
By default, your web app uses a shared public IP address. When you bind a certificate with IP-based SSL, App
Service creates a new, dedicated IP address for your web app.
If you have mapped an A record to your web app, update your domain registry with this new, dedicated IP address.
Your web app's Custom domain page is updated with the new, dedicated IP address. Copy this IP address, then
remap the A record to this new IP address.
Test HTTPS
All that's left to do now is to make sure that HTTPS works for your custom domain. In various browsers, browse to
https://<your.custom.domain> to see that it serves up your web app.
NOTE
If your web app gives you certificate validation errors, you're probably using a self-signed certificate.
If that's not the case, you may have left out intermediate certificates when you export your certificate to the PFX file.
Enforce HTTPS
By default, anyone can still access your web app using HTTP. You can redirect all HTTP requests to the HTTPS port.
In your web app page, in the left navigation, select Custom domains. Then, in HTTPS Only, select On.
When the operation is complete, navigate to any of the HTTP URLs that point to your app. For example:
http://contoso.com
http://www.contoso.com

You can automate SSL bindings for your web app with scripts, using the Azure CLI or Azure PowerShell.
Azure CLI
The following command uploads an exported PFX file and gets the thumbprint.
thumbprint=$(az webapp config ssl upload \

--name <app_name> \
--resource-group <resource_group_name> \
--certificate-file <path_to_PFX_file> \
--certificate-password <PFX_password> \
--query thumbprint \
--output tsv)
The following command adds an SNI-based SSL binding, using the thumbprint from the previous command.
az webapp config ssl bind \

--name <app_name> \
--resource-group <resource_group_name>
--certificate-thumbprint $thumbprint \
--ssl-type SNI \
Azure PowerShell
The following command uploads an exported PFX file and adds an SNI-based SSL binding.
New-AzureRmWebAppSSLBinding `
-WebAppName <app_name> `
-ResourceGroupName <resource_group_name> `
-Name <dns_name> `
-CertificateFilePath <path_to_PFX_file> `
-CertificatePassword <PFX_password> `
-SslState SniEnabled
Public certificates (optional)

You can upload public certificates to your web app. You can use public certificates for apps in App Service
Environments also. If you need to store the certificate in the LocalMachine certificate store, you need to use a web
app on App Service Environment. For more information, see How to configure public certificates to your Web App.
Next steps
Upgrade your app's pricing tier
Bind your custom SSL certificate to App Service
Enforce HTTPS for your app
Automate SSL certificate binding with scripts
Advance to the next tutorial to learn how to use Azure Content Delivery Network.
Add a Content Delivery Network (CDN) to an Azure App Service
For more information, see Use an SSL certificate in your application code in Azure App Service.
Add a Content Delivery Network (CDN) to an Azure
App Service
Azure Content Delivery Network (CDN) caches static web content at strategically placed locations to provide
maximum throughput for delivering content to users. The CDN also decreases server load on your web app. This
tutorial shows how to add Azure CDN to a web app in Azure App Service.
Here's the home page of the sample static HTML site that you'll work with:
What you'll learn:

Create a CDN endpoint.
Refresh cached assets.
Use query strings to control cached versions.
Use a custom domain for the CDN endpoint.
Prerequisites
Install Git
Install Azure CLI 2.0
Create the web app

To create the web app that you'll work with, follow the static HTML quickstart through the Browse to the app step.
Have a custom domain ready
To complete the custom domain step of this tutorial, you need to own a custom domain and have access to your
DNS registry for your domain provider (such as GoDaddy). For example, to add DNS entries for contoso.com and
www.contoso.com , you must have access to configure the DNS settings for the contoso.com root domain.
If you don't already have a domain name, consider following the App Service domain tutorial to purchase a domain
using the Azure portal.
Log in to the Azure portal

Open a browser and navigate to the Azure portal.
Create a CDN profile and endpoint

In the left navigation, select App Services, and then select the app that you created in the static HTML quickstart.
In the App Service page, in the Settings section, select Networking > Configure Azure CDN for your app.
In the Azure Content Delivery Network page, provide the New endpoint settings as specified in the table.
SETTING SUGGESTED VALUE DESCRIPTION
CDN profile myCDNProfile Select Create new to create a CDN

profile. A CDN profile is a collection of
CDN endpoints with the same pricing
tier.
Pricing tier Standard Akamai The pricing tier specifies the provider
and available features. In this tutorial,
we are using Standard Akamai.
CDN endpoint name Any name that is unique in the You access your cached resources at the
azureedge.net domain domain
<endpointname>.azureedge.net.
Select Create.
Azure creates the profile and endpoint. The new endpoint appears in the Endpoints list on the same page, and
when it's provisioned the status is Running.
Test the CDN endpoint
If you selected Verizon pricing tier, it typically takes about 90 minutes for endpoint propagation. For Akamai, it
takes a couple minutes for propagation
The sample app has an index.html file and css, img, and js folders that contain other static assets. The content
paths for all of these files are the same at the CDN endpoint. For example, both of the following URLs access the
bootstrap.css file in the css folder:
http://<appname>.azurewebsites.net/css/bootstrap.css
http://<endpointname>.azureedge.net/css/bootstrap.css
Navigate a browser to the following URL:
http://<endpointname>.azureedge.net/index.html
You see the same page that you ran earlier in an Azure web app. Azure CDN has retrieved the origin web app's
assets and is serving them from the CDN endpoint
To ensure that this page is cached in the CDN, refresh the page. Two requests for the same asset are sometimes
required for the CDN to cache the requested content.
For more information about creating Azure CDN profiles and endpoints, see Getting started with Azure CDN.
Purge the CDN
The CDN periodically refreshes its resources from the origin web app based on the time-to-live (TTL) configuration.
The default TTL is seven days.
At times you might need to refresh the CDN before the TTL expiration -- for example, when you deploy updated
content to the web app. To trigger a refresh, you can manually purge the CDN resources.
In this section of the tutorial, you deploy a change to the web app and purge the CDN to trigger the CDN to refresh
its cache.
Deploy a change to the web app
Open the index.html file and add "- V2" to the H1 heading, as shown in the following example:
<h1>Azure App Service - Sample Static HTML Site - V2</h1>
Commit your change and deploy it to the web app.
git commit -am "version 2"

Once deployment has completed, browse to the web app URL and you see the change.
http://<appname>.azurewebsites.net/index.html
Browse to the CDN endpoint URL for the home page and you don't see the change because the cached version in
the CDN hasn't expired yet.
Purge the CDN in the portal

To trigger the CDN to update its cached version, purge the CDN.
In the portal left navigation, select Resource groups, and then select the resource group that you created for your
web app (myResourceGroup).
In the list of resources, select your CDN endpoint.
At the top of the Endpoint page, click Purge.
Enter the content paths you wish to purge. You can pass a complete file path to purge an individual file, or a path
segment to purge and refresh all content in a folder. Since you changed index.html , make sure that is one of the
paths.
At the bottom of the page, select Purge.
Verify that the CDN is updated
Wait until the purge request finishes processing, typically a couple of minutes. To see the current status, select the
bell icon at the top of the page.
Browse to the CDN endpoint URL for index.html , and now you see the V2 that you added to the title on the home
page. This shows that the CDN cache has been refreshed.
For more information, see Purge an Azure CDN endpoint.
Use query strings to version content

The Azure CDN offers the following caching behavior options:
Ignore query strings
Bypass caching for query strings
Cache every unique URL
The first of these is the default, which means there is only one cached version of an asset regardless of the query
string in the URL.
In this section of the tutorial, you change the caching behavior to cache every unique URL.
Change the cache behavior
In the Azure portal CDN Endpoint page, select Cache.
Select Cache every unique URL from the Query string caching behavior drop-down list.
Select Save.
Verify that unique URLs are cached separately

In a browser, navigate to the home page at the CDN endpoint, but include a query string:
http://<endpointname>.azureedge.net/index.html?q=1
The CDN returns the current web app content, which includes "V2" in the heading.
To ensure that this page is cached in the CDN, refresh the page.
Open index.html and change "V2" to "V3", and deploy the change.
git commit -am "version 3"

In a browser, go to the CDN endpoint URL with a new query string such as q=2 . The CDN gets the current
index.html file and displays "V3". But if you navigate to the CDN endpoint with the q=1 query string, you see
"V2".
This output shows that each query string is treated differently:

q=1 was used before, so cached contents are returned (V2).
q=2 is new, so the latest web app contents are retrieved and returned (V3).
For more information, see Control Azure CDN caching behavior with query strings.
Map a custom domain to a CDN endpoint

You'll map your custom domain to your CDN Endpoint by creating a CNAME record. A CNAME record is a DNS
feature that maps a source domain to a destination domain. For example, you might map cdn.contoso.com or
static.contoso.com to contoso.azureedge.net .
If you don't have a custom domain, consider following the App Service domain tutorial to purchase a domain using
the Azure portal.
Find the hostname to use with the CNAME
In the Azure portal Endpoint page, make sure Overview is selected in the left navigation, and then select the +
Custom Domain button at the top of the page.
In the Add a custom domain page, you see the endpoint host name to use in creating a CNAME record. The host
name is derived from your CDN endpoint URL: <EndpointName>.azureedge.net.
Configure the CNAME with your domain registrar

Navigate to your domain registrar's web site, and locate the section for creating DNS records. You might find this in
a section such as Domain Name, DNS, or Name Server Management.
Find the section for managing CNAMEs. You may have to go to an advanced settings page and look for the words
CNAME, Alias, or Subdomains.
Create a CNAME record that maps your chosen subdomain (for example, static or cdn) to the Endpoint host
name shown earlier in the portal.
Enter the custom domain in Azure
Return to the Add a custom domain page, and enter your custom domain, including the subdomain, in the dialog
box. For example, enter cdn.contoso.com .
Azure verifies that the CNAME record exists for the domain name you have entered. If the CNAME is correct, your
custom domain is validated.
It can take time for the CNAME record to propagate to name servers on the Internet. If your domain is not validated
immediately, wait a few minutes and try again.
Test the custom domain
In a browser, navigate to the index.html file using your custom domain (for example, cdn.contoso.com/index.html )
to verify that the result is the same as when you go directly to <endpointname>azureedge.net/index.html .
For more information, see Map Azure CDN content to a custom domain.
Clean up resources
Next steps
What you learned:
Create a CDN endpoint.
Refresh cached assets.
Use query strings to control cached versions.
Use a custom domain for the CDN endpoint.
Learn how to optimize CDN performance in the following articles:
Improve performance by compressing files in Azure CDN
Pre-load assets on an Azure CDN endpoint
Azure CLI Samples
The following table includes links to bash scripts built using the Azure CLI.
Create app
Create a web app and deploy files with FTP Creates an Azure web app and deploys a file to it using FTP.
Create a web app and deploy code from GitHub Creates an Azure web app and deploys code from a public
GitHub repository.
Create a web app with continuous deployment from GitHub Creates an Azure web app with continuous publishing from a
GitHub repository you own.
Create a web app and deploy code from a local Git repository Creates an Azure web app and configures code push from a
local Git repository.
Create a web app and deploy code to a staging environment Creates an Azure web app with a deployment slot for staging
code changes.
Create an ASP.NET Core web app in a Docker container Creates an Azure web app on Linux and loads a Docker image
from Docker Hub.
Configure app
Map a custom domain to a web app Creates an Azure web app and maps a custom domain name
to it.
Bind a custom SSL certificate to a web app Creates an Azure web app and binds the SSL certificate of a
custom domain name to it.
Scale app
Scale a web app manually Creates an Azure web app and scales it across 2 instances.
Scale a web app worldwide with a high-availability architecture Creates two Azure web apps in two different geographical
regions and makes them available through a single endpoint
using Azure Traffic Manager.
Connect app to resources
Connect a web app to a SQL Database Creates an Azure web app and a SQL database, then adds the
database connection string to the app settings.
Connect a web app to a storage account Creates an Azure web app and a storage account, then adds
the storage connection string to the app settings.
Connect a web app to a redis cache Creates an Azure web app and a redis cache, then adds the
redis connection details to the app settings.)
Connect a web app to Cosmos DB Creates an Azure web app and a Cosmos DB, then adds the
Cosmos DB connection details to the app settings.
Back up and restore app
Back up a web app Creates an Azure web app and creates a one-time backup for
it.
Create a scheduled backup for a web app Creates an Azure web app and creates a scheduled backup for
it.
Restores a web app from a backup Restores an Azure web app from a backup.
Monitor app
Monitor a web app with web server logs Creates an Azure web app, enables logging for it, and
downloads the logs to your local machine.
Azure PowerShell Samples
The following table includes links to PowerShell scripts built using the Azure PowerShell.
Create app
Create a web app with deployment from GitHub Creates an Azure web app that pulls code from GitHub.
Create a web app with continuous deployment from GitHub Creates an Azure web app that continuously deploys code
from GitHub.
Create a web app and deploy code with FTP Creates an Azure web app and upload files from a local
directory using FTP.
Create a web app and deploy code from a local Git repository Creates an Azure web app and configures code push from a
local Git repository.
Create a web app and deploy code to a staging environment Creates an Azure web app with a deployment slot for staging
code changes.
Configure app
Map a custom domain to a web app Creates an Azure web app and maps a custom domain name
to it.
Bind a custom SSL certificate to a web app Creates an Azure web app and binds the SSL certificate of a
custom domain name to it.
Scale app
Scale a web app manually Creates an Azure web app and scales it across 2 instances.
Scale a web app worldwide with a high-availability architecture Creates two Azure web apps in two different geographical
regions and makes them available through a single endpoint
using Azure Traffic Manager.
Connect app to resources
Connect a web app to a SQL Database Creates an Azure web app and a SQL database, then adds the
database connection string to the app settings.
Connect a web app to a storage account Creates an Azure web app and a storage account, then adds
the storage connection string to the app settings.
Back up and restore app
Back up a web app Creates an Azure web app and creates a one-time backup for
it.
Create a scheduled backup for a web app Creates an Azure web app and creates a scheduled backup for
it.
Delete a backup for a web app Deletes an existing backup for a web app.
Monitor app
Monitor a web app with web server logs Creates an Azure web app, enables logging for it, and
downloads the logs to your local machine.
1 min to read •
Edit O nline
Azure App Service plan overview
In App Service, an app runs in an App Service plan. An App Service plan defines a set of compute resources for a
web app to run. These compute resources are analogous to the server farm in conventional web hosting. One or
more apps can be configured to run on the same computing resources (or in the same App Service plan).
When you create an App Service plan in a certain region (for example, West Europe), a set of compute resources is
created for that plan in that region. Whatever apps you put into this App Service plan run on these compute
resources as defined by your App Service plan. Each App Service plan defines:
Region (West US, East US, etc.)
Number of VM instances
Size of VM instances (Small, Medium, Large)
Pricing tier (Free, Shared, Basic, Standard, Premium, PremiumV2, Isolated, Consumption)
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for
the plan. There are a few categories of pricing tiers:
Shared compute: Free and Shared, the two base tiers, runs an app on the same Azure VM as other App
Service apps, including apps of other customers. These tiers allocate CPU quotas to each app that runs on the
shared resources, and the resources cannot scale out.
Dedicated compute: The Basic, Standard, Premium, and PremiumV2 tiers run apps on dedicated Azure
VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more
VM instances are available to you for scale-out.
Isolated: This tier runs dedicated Azure VMs on dedicated Azure Virtual Networks, which provides network
isolation on top of compute isolation to your apps. It provides the maximum scale-out capabilities.
Consumption: This tier is only available to function apps. It scales the functions dynamically depending on
workload. For more information, see Azure Functions hosting plans comparison.
NOTE
purposes.
Each tier also provides a specific subset of App Service features. These features include custom domains and SSL
certificates, autoscaling, deployment slots, backups, Traffic Manager integration, and more. The higher the tier, the
more features are available. To find out which features are supported in each pricing tier, see App Service plan
details.
NOTE
The new PremiumV2 pricing tier provides Dv2-series VMs with faster processors, SSD storage, and double memory-to-core
ratio compared to Standard tier. PremiumV2 also supports higher scale via increased instance count while still providing all
the advanced capabilities found in the Standard plan. All features available in the existing Premium tier are included in
PremiumV2.
Similar to other dedicated tiers, three VM sizes are available for this tier:
Small (one CPU core, 3.5 GiB of memory)
Medium (two CPU cores, 7 GiB of memory)
Large (four CPU cores, 14 GiB of memory)
For PremiumV2 pricing information, see App Service Pricing.
To get started with the new PremiumV2 pricing tier, see Configure PremiumV2 tier for App Service.
How does my app run and scale?

In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and cannot scale out. In other
tiers, an app runs and scales as follows.
When you create an app in App Service, it is put into an App Service plan. When the app runs, it runs on all the VM
instances configured in the App Service plan. If multiple apps are in the same App Service plan, they all share the
same VM instances. If you have multiple deployment slots for an app, all deployment slots also run on the same
VM instances. If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and
memory on these VM instances.
In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM
instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in
the plan are scaled out together based on the autoscale settings.
For information on scaling out an app, see Scale instance count manually or automatically.
How much does my App Service plan cost?

This section describes how App Service apps are billed. For detailed, region-specific pricing information, see App
Service Pricing.
Except for Free tier, an App Service plan carries an hourly charge on the compute resources it uses.
In the Shared tier, each app receives a quota of CPU minutes, so each app is charged hourly for the CPU quota.
In the dedicated compute tiers (Basic, Standard, Premium, PremiumV2), The App Service plan defines the
number of VM instances the apps are scaled to, so each VM instance in the App Service plan has an hourly
charge. These VM instances are charged the same regardless how many apps are running on them. To avoid
unexpected charges, see Clean up an App Service plan.
In the Isolated tier, the App Service Environment defines the number of isolated workers that run your apps,
and each worker is charged hourly. In addition, there's an hourly base fee for the running the App Service
Environment itself.
(Azure Functions only) The Consumption tier dynamically allocates VM instances to service a function app's
workload, and is charged dynamically per second by Azure. For more information, see Azure Functions pricing.
You don't get charged for using the App Service features that are available to you (configuring custom domains,
SSL certificates, deployment slots, backups, etc.). The exceptions are:
App Service Domains - you pay when you purchase one in Azure and when you renew it each year.
App Service Certificates - you pay when you purchase one in Azure and when you renew it each year.
IP-based SSL connections - There's an hourly charge for each IP-based SSL connection, but some Standard tier
or above gives you one IP-based SSL connection for free. SNI-based SSL connections are free.
NOTE
If you integrate App Service with another Azure service, you may need to consider charges from these other services. For
example, if you use Azure Traffic Manager to scale your app geographically, Azure Traffic Manager also charges you based on
your usage. To estimate your cross-services cost in Azure, see Pricing calculator.
What if my app needs more capabilities or features?

Your App Service plan can be scaled up and down at any time. It is as simple as changing the pricing tier of the
plan. You can choose a lower pricing tier at first and scale up later when you need more App Service features.
For example, you can start testing your web app in a Free App Service plan and pay nothing. When you want to
add your custom DNS name to the web app, just scale your plan up to Shared tier. Later, when you want to add a
custom SSL certificate, scale your plan up to Basic tier. When you want to have staging environments, scale up to
Standard tier. When you need more cores, memory, or storage, scale up to a bigger VM size in the same tier.
The same works in the reverse. When you feel you no longer need the capabilities or features of a higher tier, you
can scale down to a lower tier, which saves you money.
For information on scaling up the App Service plan, see Scale up an app in Azure.
If your app is in the same App Service plan with other apps, you may want to improve the app's performance by
isolating the compute resources. You can do it by moving the app into a separate App Service plan. For more
information, see Move an app to another App Service plan.
Should I put an app in a new plan or an existing plan?

Since you pay for the computing resources your App Service plan allocates (see How much does my App Service
plan cost?), you can potentially save money by putting multiple apps into one App Service plan. You can continue
to add apps to an existing plan as long as the plan has enough resources to handle the load. However, keep in
mind that apps in the same App Service plan all share the same compute resources. To determine whether the new
app has the necessary resources, you need to understand the capacity of the existing App Service plan, and the
expected load for the new app. Overloading an App Service plan can potentially cause downtime for your new and
existing apps.
Isolate your app into a new App Service plan when:
The app is resource-intensive.
You want to scale the app independently from the other apps the existing plan.
The app needs resource in a different geographical region.
This way you can allocate a new set of resources for your app and gain greater control of your apps.
Manage an App Service plan

Manage an App Service plan
Introduction to App Service environments
Overview
Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated
environment for securely running App Service apps at high scale. This capability can host your web apps, mobile
apps, API apps, and functions.
App Service environments (ASEs) are appropriate for application workloads that require:
Very high scale.
Isolation and secure network access.
High memory utilization.
Customers can create multiple ASEs within a single Azure region or across multiple Azure regions. This flexibility
makes ASEs ideal for horizontally scaling stateless application tiers in support of high RPS workloads.
ASEs are isolated to running only a single customer's applications and are always deployed into a virtual network.
Customers have fine-grained control over inbound and outbound application network traffic. Applications can
establish high-speed secure connections over VPNs to on-premises corporate resources.
ASEs enable high-scale app hosting with secure network access. For more information, see the AzureCon Deep
Dive on ASEs.
Multiple ASEs can be used to scale horizontally. For more information, see how to set up a geo-distributed app
footprint.
ASEs can be used to configure security architecture, as shown in the AzureCon Deep Dive. To see how the
security architecture shown in the AzureCon Deep Dive was configured, see the article on how to implement a
layered security architecture with App Service environments.
Apps running on ASEs can have their access gated by upstream devices, such as web application firewalls
(WAFs). For more information, see Configure a WAF for App Service environments.
Dedicated environment
An ASE is dedicated exclusively to a single subscription and can host 100 instances. The range can span 100
instances in a single App Service plan to 100 single-instance App Service plans, and everything in between.
An ASE is composed of front ends and workers. Front ends are responsible for HTTP/HTTPS termination and
automatic load balancing of app requests within an ASE. Front ends are automatically added as the App Service
plans in the ASE are scaled out.
Workers are roles that host customer apps. Workers are available in three fixed sizes:
One vCPU/3.5 GB RAM
Two vCPU/7 GB RAM
Four vCPU/14 GB RAM
Customers do not need to manage front ends and workers. All infrastructure is automatically added as customers
scale out their App Service plans. As App Service plans are created or scaled in an ASE, the required infrastructure
is added or removed as appropriate.
There is a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE.
In addition, there is a cost per App Service plan vCPU. All apps hosted in an ASE are in the Isolated pricing SKU. For
information on pricing for an ASE, see the App Service pricing page and review the available options for ASEs.
Virtual network support

An ASE can be created only in an Azure Resource Manager virtual network. To learn more about Azure virtual
networks, see the Azure virtual networks FAQ. An ASE always exists in a virtual network, and more precisely, within
a subnet of a virtual network. You can use the security features of virtual networks to control inbound and
outbound network communications for your apps.
An ASE can be either internet-facing with a public IP address or internal-facing with only an Azure internal load
balancer (ILB) address.
Network Security Groups restrict inbound network communications to the subnet where an ASE resides. You can
use NSGs to run apps behind upstream devices and services such as WAFs and network SaaS providers.
Apps also frequently need to access corporate resources such as internal databases and web services. If you deploy
the ASE in a virtual network that has a VPN connection to the on-premises network, the apps in the ASE can access
the on-premises resources. This capability is true regardless of whether the VPN is a site-to-site or Azure
ExpressRoute VPN.
For more information on how ASEs work with virtual networks and on-premises networks, see App Service
Environment network considerations.
App Service Environment v1

App Service Environment has two versions: ASEv1 and ASEv2. The preceding information was based on ASEv2.
This section shows you the differences between ASEv1 and ASEv2.
In ASEv1, you need to manage all of the resources manually. That includes the front ends, workers, and IP
addresses used for IP-based SSL. Before you can scale out your App Service plan, you need to first scale out the
worker pool where you want to host it.
ASEv1 uses a different pricing model from ASEv2. In ASEv1, you pay for each vCPU allocated. That includes vCPUs
used for front ends or workers that aren't hosting any workloads. In ASEv1, the default maximum-scale size of an
ASE is 55 total hosts. That includes workers and front ends. One advantage to ASEv1 is that it can be deployed in a
classic virtual network and a Resource Manager virtual network. To learn more about ASEv1, see App Service
Environment v1 introduction.
Authentication and authorization in Azure App
Service
What is App Service Authentication / Authorization?

App Service Authentication / Authorization is a feature that provides a way for your application to sign in users so
that you don't have to change code on the app backend. It provides an easy way to protect your application and
work with per-user data.
App Service uses federated identity, in which a third-party identity provider stores accounts and authenticates
users. The application relies on the provider's identity information so that the app doesn't have to store that
information itself. App Service supports five identity providers out of the box: Azure Active Directory, Facebook,
Google, Microsoft Account, and Twitter. Your app can use any number of these identity providers to provide your
users with options for how they sign in. To expand the built-in support, you can integrate another identity provider
or your own custom identity solution.
If you want to get started right away, see one of the following tutorials Add authentication to your iOS app (or
Android, Windows, Xamarin.iOS, Xamarin.Android, Xamarin.Forms, or Cordova).
How authentication works in App Service

In order to authenticate by using one of the identity providers, you first need to configure the identity provider to
know about your application. The identity provider will then provide IDs and secrets that you provide to App
Service. This completes the trust relationship so that App Service can validate user assertions, such as
authentication tokens, from the identity provider.
To sign in a user by using one of these providers, the user must be redirected to an endpoint that signs in users for
that provider. If customers are using a web browser, you can have App Service automatically direct all
unauthenticated users to the endpoint that signs in users. Otherwise, you will need to direct your customers to
{your App Service base URL}/.auth/login/<provider> , where <provider> is one of the following values: aad,
facebook, google, microsoft, or twitter. Mobile and API scenarios are explained in sections later in this article.
Users who interact with your application through a web browser will have a cookie set so that they can remain
authenticated as they browse your application. For other client types, such as mobile, a JSON web token (JWT),
which should be presented in the X-ZUMO-AUTH header, will be issued to the client. The Mobile Apps client SDKs will
handle this for you. Alternatively, an Azure Active Directory identity token or access token may be directly included
in the Authorization header as a bearer token.
App Service will validate any cookie or token that your application issues to authenticate users. To restrict who can
access your application, see the Authorization section later in this article.
Mobile authentication with a provider SDK
After everything is configured on the backend, you can modify mobile clients to sign in with App Service. There are
two approaches here:
Use an SDK that a given identity provider publishes to establish identity and then gain access to App Service.
Use a single line of code so that the Mobile Apps client SDK can sign in users.
TIP
Most applications should use a provider SDK to get a more consistent experience when users sign in, to use refresh support,
and to get other benefits that the provider specifies.
When you use a provider SDK, users can sign in to an experience that integrates more tightly with the operating
system that the app is running on. This also gives you a provider token and some user information on the client,
which makes it much easier to consume graph APIs and customize the user experience. Occasionally on blogs and
forums, you will see this referred to as the "client flow" or "client-directed flow" because code on the client signs in
users, and the client code has access to a provider token.
After a provider token is obtained, it needs to be sent to App Service for validation. After App Service validates the
token, App Service creates a new App Service token that is returned to the client. The Mobile Apps client SDK has
helper methods to manage this exchange and automatically attach the token to all requests to the application
backend. Developers can also keep a reference to the provider token if they so choose.
Mobile authentication without a provider SDK
If you do not want to set up a provider SDK, you can allow the Mobile Apps feature of Azure App Service to sign in
for you. The Mobile Apps client SDK will open a web view to the provider of your choosing and sign in the user.
Occasionally on blogs and forums, you will see this referred to as the "server flow" or "server-directed flow"
because the server manages the process that signs in users, and the client SDK never receives the provider token.
Code to start this flow is included in the authentication tutorial for each platform. At the end of the flow, the client
SDK has an App Service token, and the token is automatically attached to all requests to the application backend.
Service -to -service authentication
Although you can give users access to your application, you can also trust another application to call your own API.
For example, you could have one web app call an API in another web app. In this scenario, you use credentials for a
service account instead of user credentials to get a token. A service account is also known as a service principal in
Azure Active Directory parlance, and authentication that uses such an account is also known as a service-to-service
scenario.
IMPORTANT
Because mobile apps run on customer devices, mobile applications do not count as trusted applications and should not use
a service principal flow. Instead, they should use a user flow that was detailed earlier.
For service-to-service scenarios, App Service can protect your application by using Azure Active Directory. The
calling application just needs to provide an Azure Active Directory service principal authorization token that is
obtained by providing the client ID and client secret from Azure Active Directory. An example of this scenario that
uses ASP.NET API apps is explained by the tutorial, [Service principal authentication for API Apps][apia-service].
If you want to use App Service authentication to handle a service-to-service scenario, you can use client certificates
or basic authentication. For information about client certificates in Azure, see How To Configure TLS Mutual
Authentication for Web Apps. For information about basic authentication in ASP.NET, see Authentication Filters in
ASP.NET Web API 2.
Service account authentication from an App Service logic app to an API app is a special case that is detailed in
Using your custom API hosted on App Service with Logic apps.
How authorization works in App Service

You have full control over the requests that can access your application. App Service Authentication / Authorization
can be configured with any of the following behaviors:
Allow only authenticated requests to reach your application.
If a browser sends an anonymous request, App Service will redirect to a page for the identity provider that
you choose so that users can sign in. If the request comes from a mobile device, the returned response is an
HTTP 401 Unauthorized response.
With this option, you don't need to write any authentication code at all in your app. If you need finer
authorization, information about the user is available to your code.
Allow all requests to reach your application, but validate authenticated requests, and pass along
authentication information in the HTTP headers.
This option defers authorization decisions to your application code. It provides more flexibility in handling
anonymous requests, but you have to write code.
Allow all requests to reach your application, and take no action on authentication information in the
requests.
In this case, the Authentication / Authorization feature is off. The tasks of authentication and authorization
are entirely up to your application code.
The previous behaviors are controlled by the Action to take when request is not authenticated option in the
Azure portal. If you choose Log in with provider name **, all requests have to be authenticated. **Allow
request (no action) defers the authorization decision to your code, but it still provides authentication
information. If you want to have your code handle everything, you can disable the Authentication / Authorization
feature.
Working with user identities in your application

App Service passes some user information to your application by using special headers. External requests prohibit
these headers and will only be present if set by App Service Authentication / Authorization. Some example headers
include:
X-MS-CLIENT-PRINCIPAL-NAME
X-MS-CLIENT-PRINCIPAL-ID
X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN
X-MS-TOKEN-FACEBOOK-EXPIRES-ON
Code that is written in any language or framework can get the information that it needs from these headers. For
ASP.NET 4.6 apps, the ClaimsPrincipal is automatically set with the appropriate values.
Your application can also obtain additional user details through an HTTP GET on the /.auth/me endpoint of your
application. A valid token that's included with the request will return a JSON payload with details about the
provider that's being used, the underlying provider token, and some other user information. The Mobile Apps
server SDKs provide helper methods to work with this data. For more information, see How to use the Azure
Mobile Apps Node.js SDK, and Work with the .NET backend server SDK for Azure Mobile Apps.
Documentation and additional resources

Identity providers
The following tutorials show how to configure App Service to use different authentication providers:
How to configure your app to use Azure Active Directory login
How to configure your app to use Facebook login
How to configure your app to use Google login
How to configure your app to use Microsoft Account login
How to configure your app to use Twitter login
If you want to use an identity system other than the ones provided here, you can also use the preview custom
authentication support in the Mobile Apps .NET server SDK, which can be used in web apps, mobile apps, or API
apps.
Mobile applications
The following tutorials show how to add authentication to your mobile clients by using the server-directed flow:
Add authentication to your iOS app
Add Authentication to your Android app
Add Authentication to your Windows app
Add authentication to your Xamarin.iOS app
Add authentication to your Xamarin.Android app
Add authentication to your Xamarin.Forms app
Add Authentication to your Cordova app
Use the following resources if you want to use the client-directed flow for Azure Active Directory:
Use the Active Directory Authentication Library for iOS
Use the Active Directory Authentication Library for Android
Use the Active Directory Authentication Library for Windows and Xamarin
Use the following resources if you want to use the client-directed flow for Facebook:
Use the Facebook SDK for iOS
Use the following resources if you want to use the client-directed flow for Twitter:
Use Twitter Fabric for iOS
Use the following resources if you want to use the client-directed flow for Google:
Use the Google Sign-In SDK for iOS
Custom image or built-in platform image?
App Service on Linux offers two different paths to getting your application published to the web:
Custom image deployment: "Dockerize" your app into a Docker image that contains all of your files and
dependencies in a ready-to-run package.
App deployment with a built-in platform image: Our built-in platform images contain common web app
runtimes and dependencies, such as Node and PHP. Use any one of the Azure App Service deployment methods
to deploy your app to your web app's storage, and then use a built-in platform image to run it.
Which method is right for your app? The primary factors to consider are:
Availability of Docker in your development workflow: Custom image development requires basic
knowledge of the Docker development workflow. Deployment of a custom image to a web app requires
publication of your custom image to a repository host like Docker Hub. If you are familiar with Docker and can
add Docker tasks to your build workflow, or if you are already publishing your app as a Docker image, a custom
image is almost certainly the best choice.
Unique runtime requirements: The built-in platform images are designed to meet the needs of most web
apps, but are limited in their customizability. Your app may have unique dependencies or other runtime
requirements that exceed what the built-in images are capable of.
Build requirements: With continuous deployment, you can get your app up and running on Azure directly
from source code. No external build or publication process is required. However, there is a limit to the
customizability and availability of build tools within the Kudu deployment engine. Your app may outgrow
Kudu's capabilities as it grows in its dependencies or requirements for custom build logic.
Disk read/write requirements: All web apps are allocated a storage volume for web content. This volume,
backed by Azure Storage, is mounted to /home in the app's filesystem. Unlike files in the container filesystem,
files in the content volume are accessible across all scale instances of an app, and modifications will persist
across app restarts. However, the disk latency of the content volume is higher and more variable than the
latency of the local container filesystem, and access can be impacted by platform upgrades, unplanned
downtime, and network connectivity issues. Apps that require heavy read-only access to content files may
benefit from custom image deployment, which places files in the image filesystem instead of on the content
volume.
Build resource usage: When an app is deployed from source, the deployment scripts run by Kudu use the
same App Service Plan compute and storage resources as the running app. Large app deployments may
consume more resources or time than desired. In particular, many deployment workflows generate heavy disk
activity on the app content volume, which is not optimized for such activity. A custom image delivers all of your
app's files and dependencies to Azure in a single package with no need for additional file transfers or
deployment actions.
Need for rapid iteration: Dockerizing an app requires additional build steps. For changes to take effect, you
must push your new image to a repository with each update. These updates are then pulled to the Azure
environment. If one of the built-in containers meets your app's needs, deploying from source may offer a faster
development workflow.
Configure web apps in Azure App Service
This topic explains how to configure a web app using the Azure Portal.
NOTE
Although this article refers to web apps, it also applies to API apps and mobile apps.
Application settings
1. In the Azure Portal, open the blade for the web app.
2. Click Application settings.
The Application settings blade has settings grouped under several categories.
General settings
Framework versions. Set these options if your app uses any these frameworks:
.NET Framework: Set the .NET framework version.
PHP: Set the PHP version, or OFF to disable PHP.
Java: Select the Java version or OFF to disable Java. Use the Web Container option to choose between Tomcat
and Jetty versions.
Python: Select the Python version, or OFF to disable Python.
For technical reasons, enabling Java for your app disables the .NET, PHP, and Python options.
Platform. Selects whether your web app runs in a 32-bit or 64-bit environment. The 64-bit environment requires
Basic or Standard mode. Free and Shared modes always run in a 32-bit environment.
NOTE
purposes.
Web Sockets. Set ON to enable the WebSocket protocol; for example, if your web app uses ASP.NET SignalR or
socket.io.
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system
conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If
your app runs continuous WebJobs or runs WebJobs triggered using a CRON expression, you should enable
Always On, or the web jobs may not run reliably.
Managed Pipeline Version. Sets the IIS pipeline mode. Leave this set to Integrated (the default) unless you have a
legacy app that requires an older version of IIS.
Auto Swap. If you enable Auto Swap for a deployment slot, App Service will automatically swap the web app into
production when you push an update to that slot. For more information, see Deploy to staging slots for web apps
in Azure App Service.
Debugging
Remote Debugging. Enables remote debugging. When enabled, you can use the remote debugger in Visual
Studio to connect directly to your web app. Remote debugging will remain enabled for 48 hours.
App settings
This section contains name/value pairs that you web app will load on start up.
For .NET apps, these settings are injected into your .NET configuration AppSettings at runtime, overriding
existing settings.
PHP, Python, Java and Node applications can access these settings as environment variables at runtime. For
each app setting, two environment variables are created; one with the name specified by the app setting entry,
and another with a prefix of APPSETTING_. Both contain the same value.
Connection strings
Connection strings for linked resources.
For .NET apps, these connection strings are injected into your .NET configuration connectionStrings settings at
runtime, overriding existing entries where the key equals the linked database name.
For PHP, Python, Java and Node applications, these settings will be available as environment variables at runtime,
prefixed with the connection type. The environment variable prefixes are as follows:
SQL Server: SQLCONNSTR_
MySQL: MYSQLCONNSTR_
SQL Database: SQLAZURECONNSTR_
Custom: CUSTOMCONNSTR_
For example, if a MySql connection string were named connectionstring1 , it would be accessed through the
environment variable MYSQLCONNSTR_connectionString1 .
Default documents
The default document is the web page that is displayed at the root URL for a website. The first matching file in the
list is used.
Web apps might use modules that route based on URL, rather than serving static content, in which case there is no
default document as such.
Handler mappings
Use this area to add custom script processors to handle requests for specific file extensions.
Extension. The file extension to be handled, such as *.php or handler.fcgi.
Script Processor Path. The absolute path of the script processor. Requests to files that match the file extension
will be processed by the script processor. Use the path D:\home\site\wwwroot to refer to your app's root
directory.
Additional Arguments. Optional command-line arguments for the script processor
Virtual applications and directories
To configure virtual applications and directories, specify each virtual directory and its corresponding physical path
relative to the website root. Optionally, you can select the Application checkbox to mark a virtual directory as an
application.
Enabling diagnostic logs

To enable diagnostic logs:
1. In the blade for your web app, click All settings.
2. Click Diagnostic logs.
Options for writing diagnostic logs from a web application that supports logging:
Application Logging. Writes application logs to the file system. Logging lasts for a period of 12 hours.
Level. When application logging is enabled, this option specifies the amount of information that will be recorded
(Error, Warning, Information, or Verbose).
Web server logging. Logs are saved in the W3C extended log file format.
Detailed error messages. Saves detailed error messages .htm files. The files are saved under
/LogFiles/DetailedErrors.
Failed request tracing. Logs failed requests to XML files. The files are saved under /LogFiles/W3SVCxxx, where xxx
is a unique identifier. This folder contains an XSL file and one or more XML files. Make sure to download the XSL
file, because it provides functionality for formatting and filtering the contents of the XML files.
To view the log files, you must create FTP credentials, as follows:
1. In the blade for your web app, click All settings.
2. Click Deployment credentials.
3. Enter a user name and password.
4. Click Save.
The full FTP user name is “app\username” where app is the name of your web app. The username is listed in the
web app blade, under Essentials.
Other configuration tasks

SSL
In Basic or Standard mode, you can upload SSL certificates for a custom domain. For more information, see [Enable
HTTPS for a web app].
To view your uploaded certificates, click All Settings > Custom domains and SSL.
Domain names
Add custom domain names for your web app. For more information, see [Configure a custom domain name for a
web app in Azure App Service].
To view your domain names, click All Settings > Custom domains and SSL.
Deployments
Set up continuous deployment. See Using Git to deploy Web Apps in Azure App Service.
Deployment slots. See Deploy to Staging Environments for Web Apps in Azure App Service.
To view your deployment slots, click All Settings > Deployment slots.
Monitoring
In Basic or Standard mode, you can test the availability of HTTP or HTTPS endpoints, from up to three geo-
distributed locations. A monitoring test fails if the HTTP response code is an error (4xx or 5xx) or the response takes
more than 30 seconds. An endpoint is considered available if the monitoring tests succeed from all the specified
locations.
For more information, see How to: Monitor web endpoint status.
NOTE
If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you
can immediately create a short-lived starter web app in App Service. No credit cards required; no commitments.
Next steps
Configure a custom domain name in Azure App Service
Enable HTTPS for an app in Azure App Service
Scale a web app in Azure App Service
Monitoring basics for Web Apps in Azure App Service
Deploy your app to Azure App Service using FTP/S
This article shows you how to use FTP or FTPS to deploy your web app, mobile app backend, or API app to Azure
App Service.
The FTP/S endpoint for your app is already active. No configuration is necessary to enable FTP/S deployment.
IMPORTANT
We are continuously taking steps to improve Microsoft Azure Platform security. As part of this ongoing effort an upgrade of
Web Applications is planned for Germany Central and Germany Northeast regions. During this Web Apps will be disabling
the use of plain text FTP protocol for deployments. Our recommendation to our customers is to switch to FTPS for
deployments. We do not expect any disruption to your service during this upgrade which is planned for 9/5. We appreciate
you support in this effort.
Step 1: Set deployment credentials

To access the FTP server for your app, you first need deployment credentials.
To set or reset your deployment credentials, see Azure App Service Deployment Credentials. This tutorial
demonstrates the use of user-level credentials.
Step 2: Get FTP connection information

1. In the Azure portal, open your app's resource blade.
2. Select Overview in the left menu, then note the values for FTP/Deployment User, FTP Host Name, and
FTPS Host Name.
NOTE
The FTP/Deployment User user value as displayed by the Azure Portal including the app name in order to provide
proper context for the FTP server. You can find the same information when you select Properties in the left menu.
Also, the deployment password is never shown. If you forget your deployment password, go back to step 1 and reset
your deployment password.
Step 3: Deploy files to Azure
1. From your FTP client (Visual Studio, FileZilla, etc), use the connection information you gathered to connect to
your app.
2. Copy your files and their respective directory structure to the /site/wwwroot directory in Azure (or the
/site/wwwroot/App_Data/Jobs/ directory for WebJobs).
3. Browse to your app's URL to verify the app is running properly.
NOTE
Unlike Git-based deployments, FTP deployment doesn't support the following deployment automations:
dependency restore (such as NuGet, NPM, PIP, and Composer automations)
compilation of .NET binaries
generation of web.config (here is a Node.js example)
You must restore, build, and generate these necessary files manually on your local machine and deploy them together with
your app.
Next steps
For more advanced deployment scenarios, try deploying to Azure with Git. Git-based deployment to Azure enables
version control, package restore, MSBuild, and more.
More Resources
Azure App Service Deployment Credentials
Sync content from a cloud folder to Azure App
Service
This tutorial shows you how to deploy to Azure App Service by syncing your content from popular cloud storage
services like Dropbox and OneDrive.
Overview of content sync deployment

The on-demand content sync deployment is powered by the Kudu deployment engine integrated with App Service.
In the Azure Portal, you can designate a folder in your cloud storage, work with your app code and content in that
folder, and sync to App Service with the click of a button. Content sync utilizes the Kudu process for build and
deployment.
How to enable content sync deployment

To enable content sync from the Azure Portal, follow these steps:
1. In your app's blade in the Azure Portal, click Settings > Deployment Source. Click Choose Source, then
select OneDrive or Dropbox as the source for deployment.
NOTE
Because of underlying differences in the APIs, OneDrive for Business is not supported at this time.
2. Complete the authorization workflow to enable App Service to access a specific pre-defined designated path
for OneDrive or Dropbox where all of your App Service content will be stored.
After authorization the App Service platform will give you the option to create a content folder under the
designated content path, or to choose an existing content folder under this designated content path. The
designated content paths under your cloud storage accounts used for App Service sync are the following:
OneDrive: Apps\Azure Web Apps
Dropbox: Dropbox\Apps\Azure
3. After the initial content sync the content sync can be initiated on demand from the Azure portal. Deployment
history is available with the Deployments blade.
More information for Dropbox deployment is available under Deploy from Dropbox.
Continuous Deployment to Azure App Service
This tutorial shows you how to configure a continuous deployment workflow for your Azure Web Apps. App
Service integration with BitBucket, GitHub, and Visual Studio Team Services (VSTS) enables a continuous
deployment workflow where Azure pulls in the most recent updates from your project published to one of these
services. Continuous deployment is a great option for projects where multiple and frequent contributions are
being integrated.
To find out how to configure continuous deployment manually from a cloud repository not listed by the Azure
Portal (such as GitLab), see Setting up continuous deployment using manual steps.
Enable continuous deployment

To enable continuous deployment,
1. Publish your app content to the repository that will be used for continuous deployment.
For more information on publishing your project to these services, see Create a repo (GitHub), Create a repo
(BitBucket), and Get started with VSTS.
2. In your app's menu blade in the Azure portal, click APP DEPLOYMENT > Deployment options. Click
Choose Source, then select the deployment source.
NOTE
To configure a VSTS account for App Service deployment please see this tutorial.
3. Complete the authorization workflow.

4. In the Deployment source blade, choose the project and branch to deploy from. When you're done, click
OK.
NOTE
When enabling continuous deployment with GitHub or BitBucket, both public and private projects will be displayed.
App Service creates an association with the selected repository, pulls in the files from the specified branch,
and maintains a clone of your repository for your App Service app. When you configure VSTS continuous
deployment from the Azure portal, the integration uses the App Service Kudu deployment engine, which
already automates build and deployment tasks with every git push . You do not need to separately set up
continuous deployment in VSTS. After this process completes, the Deployment options app blade will
show an active deployment that indicates deployment has succeeded.
5. To verify the app is successfully deployed, click the URL at the top of the app's blade in the Azure portal.
6. To verify that continuous deployment is occurring from the repository of your choice, push a change to the
repository. Your app should update to reflect the changes shortly after the push to the repository completes.
You can verify that it has pulled in the update in the Deployment options blade of your app.
Continuous deployment of a Visual Studio solution

Pushing a Visual Studio solution to Azure App Service is just as easy as pushing a simple index.html file. The App
Service deployment process streamlines all the details, including restoring NuGet dependencies and building the
application binaries. You can follow the source control best practices of maintaining code only in your Git
repository, and let App Service deployment take care of the rest.
The steps for pushing your Visual Studio solution to App Service are the same as in the previous section, provided
that you configure your solution and repository as follows:
Use the Visual Studio source control option to generate a .gitignore file such as the image below or
manually add a .gitignore file in your repository root with content similar to this .gitignore sample.
Add the entire solution's directory tree to your repository, with the .sln file in the repository root.
Once you have set up your repository as described, and configured your app in Azure for continuous publishing
from one of the online Git repositories, you can develop your ASP.NET application locally in Visual Studio and
continuously deploy your code simply by pushing your changes to your online Git repository.
Disable continuous deployment

To disable continuous deployment,
1. In your app's menu blade in the Azure portal, click APP DEPLOYMENT > Deployment options. Then click
Disconnect in the Deployment options blade.
2. After answering Yes to the confirmation message, you can return to your app's blade and click APP
DEPLOYMENT > Deployment options if you would like to set up publishing from another source.
Additional Resources
How to investigate common issues with continuous deployment
How to use PowerShell for Azure
How to use the Azure Command-Line Tools for Mac and Linux
Git documentation
Project Kudu
Use Azure to automatically generate a CI/CD pipeline to deploy an ASP.NET 4 app
NOTE
Local Git Deployment to Azure App Service
This tutorial shows you how to deploy your app to Azure Web Apps from a Git repository on your local computer.
App Service supports this approach with the Local Git deployment option in the Azure Portal.
Many of the Git commands described in this article are performed automatically when creating an App Service
app using the Azure Command-Line Interface as described here.
Prerequisites
To complete this tutorial, you need:
Git. You can download the installation binary here.
Basic knowledge of Git.
A Microsoft Azure account. If you don't have an account, you can sign up for a free trial or activate your Visual
Studio subscriber benefits.
NOTE
can immediately create a short-lived starter app in App Service. No credit cards required; no commitments.
Step 1: Create a local repository

Perform the following tasks to create a new Git repository.
1. Start a command-line tool, such as GitBash (Windows) or Bash (Unix Shell). On OS X systems you can access
the command-line through the Terminal application.
2. Navigate to the directory where the content to deploy would be located.
3. Use the following command to initialize a new Git repository:
git init
Step 2: Commit your content

App Service supports applications created in a variety of programming languages.
1. If your repository already includes content skip this point and move to point 2 below. If your repository
does not already include content simply populate with a static .html file as follows:
Using a text editor, create a new file named index.html at the root of the Git repository
Add the following text as the contents for the index.html file and save it: Hello Git!
2. From the command-line, verify that you are under the root of your Git repository. Then use the following
command to add files to your repository:
git add -A
1. Next, commit the changes to the repository by using the following command:
git commit -m "Hello Azure App Service"
Step 3: Enable the App Service app repository

Perform the following steps to enable a Git repository for your App Service app.
1. Log in to the Azure Portal.
2. In your App Service app's blade, click Settings > Deployment source. Click Choose source, then click
Local Git Repository, and then click OK.
3. If this is your first time setting up a repository in Azure, you need to create login credentials for it. You will
use them to log into the Azure repository and push changes from your local Git repository. From your
app's blade, click Deployment > Deployment credentials, then configure your deployment username
and password. When you're done, click Save.
Step 4: Deploy your project

Use the following steps to publish your app to App Service using Local Git.
1. In your app's blade in the Azure Portal, click Settings > Properties for the Git URL.
Git URL is the remote reference to deploy to from your local repository. You'll use this URL in the following
steps.
2. Using the command-line, verify that you are in the root of your local Git repository.
3. Use git remote to add the remote reference listed in Git URL from step 1. Your command will look similar
to the following:
git remote add azure

https://<username>@localgitdeployment.scm.azurewebsites.net:443/localgitdeployment.git
NOTE
The remote command adds a named reference to a remote repository. In this example, it creates a reference named
'azure' for your web app's repository.
4. Push your content to App Service using the new azure remote you just created.
You will be prompted for the password you created earlier when you reset your deployment credentials in the
Azure Portal. Enter the password (note that Gitbash does not echo asterisks to the console as you type your
password).
1. Go back to your app in the Azure Portal. A log entry of your most recent push should be displayed in the
Deployments blade.
2. Click the Browse button at the top of the app's blade to verify the content has been deployed.
Troubleshooting
The following are errors or problems commonly encountered when using Git to publish to an App Service app in
Azure:
Symptom: Unable to access '[siteURL]': Failed to connect to [scmAddress]

Cause: This error can occur if the app is not up and running.
Resolution: Start the app in the Azure Portal. Git deployment will not work unless the app is running.
Symptom: Couldn't resolve host 'hostname'

Cause: This error can occur if the address information entered when creating the 'azure' remote was incorrect.
Resolution: Use the git remote -v command to list all remotes, along with the associated URL. Verify that the
URL for the 'azure' remote is correct. If needed, remove and recreate this remote using the correct URL.
Symptom: No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as
'master'.
Cause: This error can occur if you do not specify a branch when performing a git push operation, and have not set
the push.default value used by Git.
Resolution: Perform the push operation again, specifying the master branch. For example:
Symptom: src refspec [branchname] does not match any.

Cause: This error can occur if you attempt to push to a branch other than master on the 'azure' remote.
Resolution: Perform the push operation again, specifying the master branch. For example:

Symptom: RPC failed; result=22, HTTP code = 502.
Cause: This error can occur if you attempt to push a large git repository over HTTPS.
Resolution: Change the git configuration on the local machine to make the postBuffer bigger
git config --global http.postBuffer 524288000
Symptom: Error - Changes committed to remote repository but your web app not updated.
Cause: This error can occur if you are deploying a Node.js app containing a package.json file that specifies
additional required modules.
Resolution: Additional messages containing 'npm ERR!' should be logged prior to this error, and can provide
additional context on the failure. The following are known causes of this error and the corresponding 'npm ERR!'
message:
Malformed package.json file: npm ERR! Couldn't read dependencies.
Native module that does not have a binary distribution for Windows:
npm ERR! `cmd "/c" "node-gyp rebuild"` failed with 1
OR
npm ERR! [modulename@version] preinstall: `make || gmake`
Additional Resources
Git documentation
Project Kudu documentation
Continuous Deployment to Azure App Service
How to use PowerShell for Azure
How to use the Azure Command-Line Interface
Provision and deploy microservices predictably in
Azure
This tutorial shows how to provision and deploy an application composed of microservices in Azure App Service as
a single unit and in a predictable manner using JSON resource group templates and PowerShell scripting.
When provisioning and deploying high-scale applications that are composed of highly decoupled microservices,
repeatability and predictability are crucial to success. Azure App Service enables you to create microservices that
include web apps, mobile apps, API apps, and logic apps. Azure Resource Manager enables you to manage all the
microservices as a unit, together with resource dependencies such as database and source control settings. Now,
you can also deploy such an application using JSON templates and simple PowerShell scripting.
NOTE
What you will do

In the tutorial, you will deploy an application that includes:
Two web apps (i.e. two microservices)
A backend SQL Database
App settings, connection strings, and source control
Application insights, alerts, autoscaling settings
Tools you will use

In this tutorial, you will use the following tools. Since it’s not comprehensive discussion on tools, I’m going to stick
to the end-to-end scenario and just give you a brief intro to each, and where you can find more information on it.
Azure Resource Manager templates (JSON )
Every time you create a web app in Azure App Service, for example, Azure Resource Manager uses a JSON template
to create the entire resource group with the component resources. A complex template from the Azure Marketplace
like the Scalable WordPress app can include the MySQL database, storage accounts, the App Service plan, the web
app itself, alert rules, app settings, autoscale settings, and more, and all these templates are available to you through
PowerShell. For information on how to download and use these templates, see Using Azure PowerShell with Azure
Resource Manager.
For more information on the Azure Resource Manager templates, see Authoring Azure Resource Manager
Templates
Azure SDK 2.6 for Visual Studio
The newest SDK contains improvements to the Resource Manager template support in the JSON editor. You can
use this to quickly create a resource group template from scratch or open an existing JSON template (such as a
downloaded gallery template) for modification, populate the parameters file, and even deploy the resource group
directly from an Azure Resource Group solution.
For more information, see Azure SDK 2.6 for Visual Studio.
Azure PowerShell 0.8.0 or later
Beginning in version 0.8.0, the Azure PowerShell installation includes the Azure Resource Manager module in
addition to the Azure module. This new module enables you to script the deployment of resource groups.
For more information, see Using Azure PowerShell with Azure Resource Manager
Azure Resource Explorer
This preview tool enables you to explore the JSON definitions of all the resource groups in your subscription and
the individual resources. In the tool, you can edit the JSON definitions of a resource, delete an entire hierarchy of
resources, and create new resources. The information readily available in this tool is very helpful for template
authoring because it shows you what properties you need to set for a particular type of resource, the correct values,
etc. You can even create your resource group in the Azure Portal, then inspect its JSON definitions in the explorer
tool to help you templatize the resource group.
Deploy to Azure button
If you use GitHub for source control, you can put a Deploy to Azure button into your README.MD, which enables a
turn-key deployment UI to Azure. While you can do this for any simple web app, you can extend this to enable
deploying an entire resource group by putting an azuredeploy.json file in the repository root. This JSON file, which
contains the resource group template, will be used by the Deploy to Azure button to create the resource group. For
an example, see the ToDoApp sample, which you will use in this tutorial.
Get the sample resource group template

So now let’s get right to it.
1. Navigate to the ToDoApp App Service sample.
2. In readme.md, click Deploy to Azure.
3. You’re taken to the deploy-to-azure site and asked to input deployment parameters. Notice that most of the
fields are populated with the repository name and some random strings for you. You can change all the
fields if you want, but the only things you have to enter are the SQL Server administrative login and the
password, then click Next.
4. Next, click Deploy to start the deployment process. Once the process runs to completion, click the
http://todoappXXXX.azurewebsites.net link to browse the deployed application.
The UI would be a little slow when you first browse to it because the apps are just starting up, but convince
yourself that it’s a fully-functional application.
5. Back in the Deploy page, click the Manage link to see the new application in the Azure Portal.
6. In the Essentials dropdown, click the resource group link. Note also that the web app is already connected to
the GitHub repository under External Project.
7. In the resource group blade, note that there are already two web apps and one SQL Database in the resource
group.
Everything that you just saw in a few short minutes is a fully deployed two-microservice application, with all the
components, dependencies, settings, database, and continuous publishing, set up by an automated orchestration in
Azure Resource Manager. All this was done by two things:
The Deploy to Azure button
azuredeploy.json in the repo root
You can deploy this same application tens, hundreds, or thousands of times and have the exact same configuration
every time. The repeatability and the predictability of this approach enables you to deploy high-scale applications
with ease and confidence.
Examine (or edit) AZUREDEPLOY.JSON

Now let’s look at how the GitHub repository was set up. You will be using the JSON editor in the Azure .NET SDK, so
if you haven’t already installed Azure .NET SDK 2.6, do it now.
1. Clone the ToDoApp repository using your favorite git tool. In the screenshot below, I’m doing this in the
Team Explorer in Visual Studio 2013.
2. From the repository root, open azuredeploy.json in Visual Studio. If you don’t see the JSON Outline pane,
you need to install Azure .NET SDK.
I’m not going to describe every detail of the JSON format, but the More Resources section has links for learning the
resource group template language. Here, I’m just going to show you the interesting features that can help you get
started in making your own custom template for app deployment.
Parameters
Take a look at the parameters section to see that most of these parameters are what the Deploy to Azure button
prompts you to input. The site behind the Deploy to Azure button populates the input UI using the parameters
defined in azuredeploy.json. These parameters are used throughout the resource definitions, such as resource
names, property values, etc.
Resources
In the resources node, you can see that 4 top-level resources are defined, including a SQL Server instance, an App
Service plan, and two web apps.
App Service plan
Let’s start with a simple root-level resource in the JSON. In the JSON Outline, click the App Service plan named
[hostingPlanName] to highlight the corresponding JSON code.
Note that the type element specifies the string for an App Service plan (it was called a server farm a long, long
time ago), and other elements and properties are filled in using the parameters defined in the JSON file, and this
resource doesn’t have any nested resources.
NOTE
Note also that the value of apiVersion tells Azure which version of the REST API to use the JSON resource definition with,
and it can affect how the resource should be formatted inside the {} .
SQL Server
Next, click on the SQL Server resource named SQLServer in the JSON Outline.
Note the following about the highlighted JSON code:
The use of parameters ensures that the created resources are named and configured in a way that makes them
consistent with one another.
The SQLServer resource has two nested resources, each has a different value for type .
The nested resources inside “resources”: […] , where the database and the firewall rules are defined, have a
dependsOn element that specifies the resource ID of the root-level SQLServer resource. This tells Azure
Resource Manager, “before you create this resource, that other resource must already exist; and if that other
resource is defined in the template, then create that one first”.
NOTE
For detailed information on how to use the resourceId() function, see Azure Resource Manager Template
Functions.
The effect of the dependsOn element is that Azure Resource Manager can know which resources can be created
in parallel and which resources must be created sequentially.
Web app
Now, let’s move on to the actual web apps themselves, which are more complicated. Click the
[variables(‘apiSiteName’)] web app in the JSON Outline to highlight its JSON code. You’ll notice that things are
getting much more interesting. For this purpose, I’ll talk about the features one by one:
R o o t r e so u r c e
The web app depends on two different resources. This means that Azure Resource Manager will create the web app
only after both the App Service plan and the SQL Server instance are created.
A p p se t t i n g s
The app settings are also defined as a nested resource.

In the properties element for config/appsettings , you have two app settings in the format “<name>” : “<value>” .
PROJECT is a KUDU setting that tells Azure deployment which project to use in a multi-project Visual Studio
solution. I will show you later how source control is configured, but since the ToDoApp code is in a multi-project
Visual Studio solution, we need this setting.
clientUrl is simply an app setting that the application code uses.
C o n n e c t i o n st r i n g s
The connection strings are also defined as a nested resource.
In the properties element for config/connectionstrings , each connection string is also defined as a name:value
pair, with the specific format of “<name>” : {“value”: “…”, “type”: “…”} . For the type element, possible values are
MySql , SQLServer , SQLAzure , and Custom .
TIP
For a definitive list of the connection string types, run the following command in Azure PowerShell:
[Enum]::GetNames("Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.DatabaseType")
So u r c e c o n t r o l
The source control settings are also defined as a nested resource. Azure Resource Manager uses this resource to
configure continuous publishing (see caveat on IsManualIntegration later) and also to kick off the deployment of
application code automatically during the processing of the JSON file.
RepoUrl and branch should be pretty intuitive and should point to the Git repository and the name of the branch
to publish from. Again, these are defined by input parameters.
Note in the dependsOn element that, in addition to the web app resource itself, sourcecontrols/web also depends on
config/appsettings and config/connectionstrings . This is because once sourcecontrols/web is configured, the
Azure deployment process will automatically attempt to deploy, build, and start the application code. Therefore,
inserting this dependency helps you make sure that the application has access to the required app settings and
connection strings before the application code is run.
NOTE
Note also that IsManualIntegration is set to true . This property is necessary in this tutorial because you do not actually
own the GitHub repository, and thus cannot actually grant permission to Azure to configure continuous publishing from
ToDoApp (i.e. push automatic repository updates to Azure). You can use the default value false for the specified repository
only if you have configured the owner’s GitHub credentials in the Azure portal before. In other words, if you have set up
source control to GitHub or BitBucket for any app in the Azure Portal previously, using your user credentials, then Azure will
remember the credentials and use them whenever you deploy any app from GitHub or BitBucket in the future. However, if
you haven’t done this already, deployment of the JSON template will fail when Azure Resource Manager tries to configure the
web app’s source control settings because it cannot log into GitHub or BitBucket with the repository owner’s credentials.
Compare the JSON template with deployed resource group

Here, you can go through all the web app’s blades in the Azure Portal, but there’s another tool that’s just as useful, if
not more. Go to the Azure Resource Explorer preview tool, which gives you a JSON representation of all the
resource groups in your subscriptions, as they actually exist in the Azure backend. You can also see how the
resource group’s JSON hierarchy in Azure corresponds with the hierarchy in the template file that’s used to create
it.
For example, when I go to the Azure Resource Explorer tool and expand the nodes in the explorer, I can see the
resource group and the root-level resources that are collected under their respective resource types.
If you drill down to a web app, you should be able to see web app configuration details similar to the below
screenshot:
Again, the nested resources should have a hierarchy very similar to those in your JSON template file, and you
should see the app settings, connection strings, etc., properly reflected in the JSON pane. The absence of settings
here may indicate an issue with your JSON file and can help you troubleshoot your JSON template file.
Deploy the resource group template yourself

The Deploy to Azure button is great, but it allows you to deploy the resource group template in azuredeploy.json
only if you have already pushed azuredeploy.json to GitHub. The Azure .NET SDK also provides the tools for you to
deploy any JSON template file directly from your local machine. To do this, follow the steps below:
1. In Visual Studio, click File > New > Project.
2. Click Visual C# > Cloud > Azure Resource Group, then click OK.
3. In Select Azure Template, select Blank Template and click OK.
4. Drag azuredeploy.json into the Template folder of your new project.
5. From Solution Explorer, open the copied azuredeploy.json.

6. Just for the sake of the demonstration, let’s add some standard Application Insight resources to our JSON
file, by clicking Add Resource. If you’re just interested in deploying the JSON file, skip to the deploy steps.
7. Select Application Insights for Web Apps, then make sure an existing App Service plan and web app is
selected, and then click Add.
You’ll now be able to see several new resources that, depending on the resource and what it does, have
dependencies on either the App Service plan or the web app. These resources are not enabled by their
existing definition and you’re going to change that.
8. In the JSON Outline, click appInsights AutoScale to highlight its JSON code. This is the scaling setting for your
App Service plan.
9. In the highlighted JSON code, locate the location and enabled properties and set them as shown below.
10. In the JSON Outline, click CPUHigh appInsights to highlight its JSON code. This is an alert.
11. Locate the location and isEnabled properties and set them as shown below. Do the same for the other
three alerts (purple bulbs).
12. You’re now ready to deploy. Right-click the project and select Deploy > New Deployment.
13. Log into your Azure account if you haven’t already done so.
14. Select an existing resource group in your subscription or create a new one, select azuredeploy.json, and
then click Edit Parameters.
You’ll now be able to edit all the parameters defined in the template file in a nice table. Parameters that
define defaults will already have their default values, and parameters that define a list of allowed values will
be shown as dropdowns.
15. Fill in all the empty parameters, and use the GitHub repo address for ToDoApp in repoUrl. Then, click Save.
NOTE
Autoscaling is a feature offered in Standard tier or higher, and plan-level alerts are features offered in Basic tier or
higher, you’ll need to set the sku parameter to Standard or Premium in order to see all your new App Insights
resources light up.
16. Click Deploy. If you selected Save passwords, the password will be saved in the parameter file in plain text.
Otherwise, you’ll be asked to input the database password during the deployment process.
That’s it! Now you just need to go to the Azure Portal and the Azure Resource Explorer tool to see the new alerts
and autoscale settings added to your JSON deployed application.
Your steps in this section mainly accomplished the following:
1. Prepared the template file
2. Created a parameter file to go with the template file
3. Deployed the template file with the parameter file
The last step is easily done by a PowerShell cmdlet. To see what Visual Studio did when it deployed your
application, open Scripts\Deploy-AzureResourceGroup.ps1. There’s a lot of code there, but I’m just going to
highlight all the pertinent code you need to deploy the template file with the parameter file.
The last cmdlet, New-AzureResourceGroup , is the one that actually performs the action. All this should demonstrate to
you that, with the help of tooling, it is relatively straightforward to deploy your cloud application predictably. Every
time you run the cmdlet on the same template with the same parameter file, you’re going to get the same result.
Summary
In DevOps, repeatability and predictability are keys to any successful deployment of a high-scale application
composed of microservices. In this tutorial, you have deployed a two-microservice application to Azure as a single
resource group using the Azure Resource Manager template. Hopefully, it has given you the knowledge you need in
order to start converting your application in Azure into a template and can provision and deploy it predictably.
More resources
Azure Resource Manager Template Language
Authoring Azure Resource Manager Templates
Azure Resource Manager Template Functions
Deploy an application with Azure Resource Manager template
Using Azure PowerShell with Azure Resource Manager
Troubleshooting Resource Group Deployments in Azure
Configure deployment credentials for Azure App
Service
Azure App Service supports two types of credentials for local Git deployment and FTP/S deployment. These are not
the same as your Azure Active Directory credentials.
User-level credentials: one set of credentials for the entire Azure account. It can be used to deploy to App
Service for any app, in any subscription, that the Azure account has permission to access. These are the
default credentials set that you configure in App Services > <app_name> > Deployment credentials.
This is also the default set that's surfaced in the portal GUI (such as the Overview and Properties of your
app's resource page).
NOTE
When you delegate access to Azure resources via Role Based Access Control (RBAC) or co-admin permissions, each
Azure user that receives access to an app can use his/her personal user-level credentials until access is revoked. These
deployment credentials should not be shared with other Azure users.
App-level credentials: one set of credentials for each app. It can be used to deploy to that app only. The
credentials for each app is generated automatically at app creation, and is found in the app's publish profile.
You cannot manually configure the credentials, but you can reset them for an app anytime.
NOTE
In order to give someone access to these credentials via Role Based Access Control (RBAC), you need to make them
contributor or higher on the Web App. Readers are not allowed to publish, and hence can't access those credentials.
Set and reset user-level credentials

You can configure your user-level credentials in any app's resource page. Regardless in which app you configure
these credentials, it applies to all apps and for all subscriptions in your Azure account.
To configure your user-level credentials:
1. In the Azure portal, click App Service > <any_app> > Deployment credentials.
NOTE
In the portal, you must have at least one app before you can access the deployment credentials page. However, with
the Azure CLI, you can configure user-level credentials without an existing app.
2. Configure the user name and password, and then click Save.
Once you have set your deployment credentials, you can find the Git deployment username in your app's
Overview,
and FTP deployment username in your app's Properties.

NOTE
Azure does not show your user-level deployment password. If you forget the password, you can't retrieve it. However, you
can reset your credentials by following the steps in this section.
Get and reset app-level credentials

For each app in App Service, its app-level credentials are stored in the XML publish profile.
To get the app-level credentials:
1. In the Azure portal, click App Service > <any_app> > Overview.
2. Click ...More > Get publish profile, and download starts for a .PublishSettings file.
3. Open the .PublishSettings file and find the <publishProfile> tag with the attribute publishMethod="FTP" .
Then, get its userName and password attributes. These are the app-level credentials.
Similar to the user-level credentials, the FTP deployment username is in the format of
<app_name>\<username> , and the Git deployment username is just <username> without the preceding
<app_name>\ .
To reset the app-level credentials:

1. In the Azure portal, click App Service > <any_app> > Overview.
2. Click ...More > Reset publish profile. Click Yes to confirm the reset.
The reset action invalidates any previously-downloaded .PublishSettings files.
Next steps
Find out how to use these credentials to deploy your app from local Git or using FTP/S.
Set up staging environments in Azure App Service
When you deploy your web app, web app on Linux, mobile back end, and API app to App Service, you can deploy
to a separate deployment slot instead of the default production slot when running in the Standard or Premium
App Service plan mode. Deployment slots are actually live apps with their own hostnames. App content and
configurations elements can be swapped between two deployment slots, including the production slot. Deploying
your application to a deployment slot has the following benefits:
You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production ensures that all instances of the slot are
warmed up before being swapped into production. This eliminates downtime when you deploy your app. The
traffic redirection is seamless, and no requests are dropped as a result of swap operations. This entire
workflow can be automated by configuring Auto Swap when pre-swap validation is not needed.
After a swap, the slot with previously staged app now has the previous production app. If the changes swapped
into the production slot are not as you expected, you can perform the same swap immediately to get your "last
known good site" back.
Each App Service plan mode supports a different number of deployment slots. To find out the number of slots
your app's mode supports, see App Service Pricing.
When your app has multiple slots, you cannot change the mode.
Scaling is not available for non-production slots.
Linked resource management is not supported for non-production slots. In the Azure Portal only, you can
avoid this potential impact on a production slot by temporarily moving the non-production slot to a different
App Service plan mode. Note that the non-production slot must once again share the same mode with the
production slot before you can swap the two slots.
Add a deployment slot

The app must be running in the Standard or Premium mode in order for you to enable multiple deployment
slots.
1. In the Azure Portal, open your app's resource blade.
2. Choose the Deployment slots option, then click Add Slot.
NOTE
If the app is not already in the Standard or Premium mode, you will receive a message indicating the supported
modes for enabling staged publishing. At this point, you have the option to select Upgrade and navigate to the
Scale tab of your app before continuing.
3. In the Add a slot blade, give the slot a name, and select whether to clone app configuration from another
existing deployment slot. Click the check mark to continue.
The first time you add a slot, you will only have two choices: clone configuration from the default slot in
production or not at all. After you have created several slots, you will be able to clone configuration from a
slot other than the one in production:
4. In your app's resource blade, click Deployment slots, then click a deployment slot to open that slot's
resource blade, with a set of metrics and configuration just like any other app. The name of the slot is
shown at the top of the blade to remind you that you are viewing the deployment slot.
5. Click the app URL in the slot's blade. Notice the deployment slot has its own hostname and is also a live app.
To limit public access to the deployment slot, see App Service Web App – block web access to non-production
deployment slots.
There is no content after deployment slot creation. You can deploy to the slot from a different repository branch,
or an altogether different repository. You can also change the slot's configuration. Use the publish profile or
deployment credentials associated with the deployment slot for content updates. For example, you can publish to
this slot with git.
Configuration for deployment slots

When you clone configuration from another deployment slot, the cloned configuration is editable. Furthermore,
some configuration elements will follow the content across a swap (not slot specific) while other configuration
elements will stay in the same slot after a swap (slot specific). The following lists show the configuration that will
change when you swap slots.
Settings that are swapped:
General settings - such as framework version, 32/64-bit, Web sockets
App settings (can be configured to stick to a slot)
Connection strings (can be configured to stick to a slot)
Handler mappings
Monitoring and diagnostic settings
WebJobs content
Settings that are not swapped:
Publishing endpoints
Custom Domain Names
SSL certificates and bindings
Scale settings
WebJobs schedulers
To configure an app setting or connection string to stick to a slot (not swapped), access the Application Settings
blade for a specific slot, then select the Slot Setting box for the configuration elements that should stick the slot.
Note that marking a configuration element as slot specific has the effect of establishing that element as not
swappable across all the deployment slots associated with the app.
Swap deployment slots

You can swap deployment slots in the Overview or Deployment slots view of your app's resource blade.
IMPORTANT
Before you swap an app from a deployment slot into production, make sure that all non-slot specific settings are configured
exactly as you want to have it in the swap target.
1. To swap deployment slots, click the Swap button in the command bar of the app or in the command bar of
a deployment slot.
2. Make sure that the swap source and swap target are set properly. Usually, the swap target is the production
slot. Click OK to complete the operation. When the operation finishes, the deployment slots have been
swapped.
For the Swap with preview swap type, see Swap with preview (multi-phase swap).
Swap with preview (multi-phase swap)

Swap with preview, or multi-phase swap, simplify validation of slot-specific configuration elements, such as
connection strings. For mission-critical workloads, you want to validate that the app behaves as expected when
the production slot's configuration is applied, and you must perform such validation before the app is swapped
into production. Swap with preview is what you need.
NOTE
Swap with preview is not supported in web apps on Linux.
When you use the Swap with preview option (see Swap deployment slots), App Service does the following:
Keeps the destination slot unchanged so existing workload on that slot (e.g. production) is not impacted.
Applies the configuration elements of the destination slot to the source slot, including the slot-specific
connection strings and app settings.
Restarts the worker processes on the source slot using these aforementioned configuration elements.
When you complete the swap: Moves the pre-warmed-up source slot into the destination slot. The destination
slot is moved into the source slot as in a manual swap.
When you cancel the swap: Reapplies the configuration elements of the source slot to the source slot.
You can preview exactly how the app will behave with the destination slot's configuration. Once you complete
validation, you complete the swap in a separate step. This step has the added advantage that the source slot is
already warmed up with the desired configuration, and clients will not experience any downtime.
Samples for the Azure PowerShell cmdlets available for multi-phase swap are included in the Azure PowerShell
cmdlets for deployment slots section.
Configure Auto Swap

Auto Swap streamlines DevOps scenarios where you want to continuously deploy your app with zero cold start
and zero downtime for end customers of the app. When a deployment slot is configured for Auto Swap into
production, every time you push your code update to that slot, App Service will automatically swap the app into
production after it has already warmed up in the slot.
IMPORTANT
When you enable Auto Swap for a slot, make sure the slot configuration is exactly the configuration intended for the target
slot (usually the production slot).
NOTE
Auto swap is not supported in web apps on Linux.
Configuring Auto Swap for a slot is easy. Follow the steps below:
1. In Deployment Slots, select a non-production slot, and choose Application Settings in that slot's
resource blade.
2. Select On for Auto Swap, select the desired target slot in Auto Swap Slot, and click Save in the command
bar. Make sure configuration for the slot is exactly the configuration intended for the target slot.
The Notifications tab will flash a green SUCCESS once the operation is complete.
NOTE
To test Auto Swap for your app, you can first select a non-production target slot in Auto Swap Slot to become
familiar with the feature.
3. Execute a code push to that deployment slot. Auto Swap will happen after a short time and the update will be
reflected at your target slot's URL.
To rollback a production app after swap

If any errors are identified in production after a slot swap, roll the slots back to their pre-swap states by swapping
the same two slots immediately.
Custom warm-up before swap

Some apps may require custom warm-up actions. The applicationInitialization configuration element in
web.config allows you to specify custom initialization actions to be performed before a request is received. The
swap operation will wait for this custom warm-up to complete. Here is a sample web.config fragment.
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostname="[app hostname]" />
</applicationInitialization>
To delete a deployment slot

In the blade for a deployment slot, open the deployment slot's blade, click Overview (the default page), and click
Delete in the command bar.
Azure PowerShell cmdlets for deployment slots
Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell, including
support for managing deployment slots in Azure App Service.
For information on installing and configuring Azure PowerShell, and on authenticating Azure PowerShell with
your Azure subscription, see How to install and configure Microsoft Azure PowerShell.
Create a web app
New-AzureRmWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -
AppServicePlan [app service plan name]
Create a deployment slot
New-AzureRmWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name]
-AppServicePlan [app service plan name]
Initiate a swap with review (multi-phase swap) and apply destination slot configuration to source slot
$ParametersObject = @{targetSlot = "[slot name – e.g. “production”]"}

Invoke-AzureRmResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots
-ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-
07-01
Cancel a pending swap (swap with review) and restore source slot configuration

-ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01
Swap deployment slots

$ParametersObject = @{targetSlot = "[slot name – e.g. “production”]"}
-ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01
Delete deployment slot
Remove-AzureRmResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name

[app name]/[slot name] -ApiVersion 2015-07-01
Azure Command-Line Interface (Azure CLI) commands for

Deployment Slots
The Azure CLI provides cross-platform commands for working with Azure, including support for managing App
Service deployment slots.
For instructions on installing and configuring the Azure CLI, including information on how to connect Azure
CLI to your Azure subscription, see Install and Configure the Azure CLI.
To list the commands available for Azure App Service in the Azure CLI, call azure site -h .
NOTE
For Azure CLI 2.0 commands for deployment slots, see az appservice web deployment slot.
azure site list

For information about the apps in the current subscription, call azure site list, as in the following example.
azure site list webappslotstest
azure site create

To create a deployment slot, call azure site create and specify the name of an existing app and the name of the
slot to create, as in the following example.
azure site create webappslotstest --slot staging
To enable source control for the new slot, use the --git option, as in the following example.
azure site create --git webappslotstest --slot staging
azure site swap

To make the updated deployment slot the production app, use the azure site swap command to perform a swap
operation, as in the following example. The production app will not experience any down time, nor will it undergo
a cold start.
azure site swap webappslotstest
azure site delete

To delete a deployment slot that is no longer needed, use the azure site delete command, as in the following
example.
azure site delete webappslotstest --slot staging
NOTE
See a web app in action. Try App Service immediately and create a short-lived starter app—no credit card required, no
commitments.
Next Steps
Azure App Service Web App – block web access to non-production deployment slots Introduction to App Service
on Linux Microsoft Azure Free Trial
Buy a custom domain name for Azure Web Apps
App Service domains (preview) are top-level domains that are managed directly in Azure. They make it easy to
manage custom domains for Azure Web Apps. This tutorial shows you how to buy an App Service domain and
assign DNS names to Azure Web Apps.
This article is for Azure App Service (Web Apps, API Apps, Mobile Apps, Logic Apps). For Azure VM or Azure
Storage, see Assign App Service domain to Azure VM or Azure Storage. For Cloud Services, see Configuring a
custom domain name for an Azure cloud service.
Prerequisites
Create an App Service app, or use an app that you created for another tutorial.
Remove the spending limit on your subscription. You cannot buy App Service domains with free subscription
credits.
Prepare the app

NOTE
purposes.
To use custom domains in Azure Web Apps, your web app's App Service plan must be a paid tier (Shared, Basic,
Standard, or Premium). In this step, you make sure that the web app is in the supported pricing tier.
Sign in to Azure
Navigate to the app in the Azure portal
From the left menu, select App Services, and then select the name of the app.
You see the management page of the App Service app.

In the left navigation of the app page, scroll to the Settings section and select Scale up (App Service plan).
The app's current tier is highlighted by a blue border. Check to make sure that the app is not in the Free tier.
Custom DNS is not supported in the Free tier.
If the App Service plan is not Free, close the Choose your pricing tier page and skip to Buy the domain.
Scale up the App Service plan
Select any of the non-free tiers (Shared, Basic, Standard, or Premium).
Click Select.
Buy the domain
Sign in to Azure
Launch Buy domains
In the Web Apps tab, click the name of your web app, select Settings, and then select Custom domains
In the Custom domains page, click Buy Domain.
NOTE
If you cannot see the App Service Domains section, you need to remove the spending limit on your Azure account (see
Prerequisites).
Configure the domain purchase

In the App Service Domain page, in the Search for domain box, type the domain name you want to buy and
type Enter . The suggested available domains are shown just below the text box. Select one or more domains you
want to buy.
NOTE
The following top-level domains are supported by App Service domains: com, net, co.uk, org, nl, in, biz, org.uk, and co.in.
Click the Contact Information and fill out the domain's contact information form. When finished, click OK to
return to the App Service Domain page.
It is important that you fill out all required fields with as much accuracy as possible. Incorrect data for contact
information can result in failure to purchase domains.
Next, select the desired options for your domain. See the following table for explanations:
SETTING SUGGESTED VALUE DESCRIPTION
Privacy protection Enable Opt in to "Privacy protection", which is

included in the purchase price for free.
Some top-level domains are managed
by registrars that do not support
privacy protection, and they are listed
on the Privacy protection page.
Assign default hostnames www and @ Select the desired hostname bindings, if
desired. When the domain purchase
operation is complete, your web app
can be accessed at the selected
hostnames. If the web app is behind
Azure Traffic Manager, you don't see
the option to assign the root domain
(@), because Traffic Manager does not
support A records. You can make
changes to the hostname assignments
after the domain purchase completes.
Accept terms and purchase
Click Legal Terms to review the terms and the charges, then click Buy.
NOTE
App Service Domains use Azure DNS to host the domains. In addition to the domain registration fee, usage charges for
Azure DNS apply. For information, see Azure DNS Pricing.
Back in the App Service Domain page, click OK. While the operation is in progress, you see the following
notifications:
Test the hostnames

If you have assigned default hostnames to your web app, you also see a success notification for each selected
hostname.
You also see the selected hostnames in the Custom domains page, in the Custom Hostnames section.
To test the hostnames, navigate to the listed hostnames in the browser. In the example in the preceding
screenshot, try navigating to kontoso.net and www.kontoso.net.
Assign hostnames to web app

If you choose not to assign one or more default hostnames to your web app during the purchase process, or if
you need to assign a hostname not listed, you can assign a hostname at anytime.
You can also assign hostnames in the App Service Domain to any other web app. The steps depend on whether
the App Service Domain and the web app belong to the same subscription.
Different subscription: Map custom DNS records from the App Service Domain to the web app like an
externally purchased domain. For information on adding custom DNS names to an App Service Domain, see
Manage custom DNS records. To map an external purchased domain to a web app, see Map an existing custom
DNS name to Azure Web Apps.
Same subscription: Use the following steps.
Launch add hostname
In the App Services page, select the name of your web app that you want to assign hostnames to, select Settings,
and then select Custom domains.
Make sure that your purchased domain is listed in the App Service Domains section, but don't select it.
NOTE
All App Service Domains in the same subscription are shown in the web app's Custom domains page. If your domain is in
the web app's subscription, but you cannot see it in the web app's Custom domains page, try reopening the Custom
domains page or refresh the webpage. Also, check the notification bell at the top of the Azure portal for progress or
creation failures.

Configure hostname
In the Add hostname dialog, type the fully qualified domain name of your App Service Domain or any
subdomain. For example:
kontoso.net
www.kontoso.net
abc.kontoso.net
When finished, select Validate. The hostname record type is automatically selected for you.
When the operation is complete, you see a success notification for the assigned hostname.
Close add hostname
In the Add hostname page, assign any other hostname to your web app, as desired. When finished, close the
Add hostname page.
You should now see the newly assigned hostname(s) in your app's Custom domains page.
Test the hostnames

Navigate to the listed hostnames in the browser. In the example in the preceding screenshot, try navigating to
abc.kontoso.net.
Renew the domain

The App Service domain you bought is valid for one year from the time of purchase. By default, the domain is
configured to renew automatically by charging your payment method for the next year. If you want to turn off
automatic renewal, or if you want to manually renew your domain, follow the steps here.
In the Web Apps tab, click the name of your web app, select Settings, and then select Custom domains.
In the App Service Domains section, select the domain you want to configure.
From the left navigation of the domain, select Domain renewal. To stop renewing your domain automatically,
select Off, and then Save.
To manually renew your domain, select Renew domain. However, this button is not active until 90 days before
the domain's expiration.
Manage custom DNS records

In Azure, DNS records for an App Service Domain are managed using Azure DNS. You can add, remove, and
update DNS records, just like for an externally purchased domain.
Open App Service Domain
In the Azure portal, from the left menu, select More Services > App Service Domains.
Select the domain to manage.

Access DNS zone
In the domain's left menu, select DNS zone.
This action opens the DNS zone page of your App Service Domain in Azure DNS. For information on how to edit
DNS records, see How to manage DNS Zones in the Azure portal.
Cancel purchase (delete domain)

After you purchase the App Service Domain, you have five days to cancel your purchase for a full refund. After five
days, you can delete the App Service Domain, but cannot receive a refund.
Open App Service Domain
In the Azure portal, from the left menu, select More Services > App Service Domains.
Select the domain to you want to cancel or delete.

Delete hostname bindings
In the domain's left menu, select Hostname bindings. The hostname bindings from all Azure services are listed
here.
You cannot delete the App Service Domain until all hostname bindings are deleted.
Delete each hostname binding by selecting ... > Delete. After all the bindings are deleted, select Save.
Cancel or delete
In the domain's left menu, select Overview.
If the cancellation period on the purchased domain has not elapsed, select Cancel purchase. Otherwise, you see a
Delete button instead. To delete the domain without a refund, select Delete.
To confirm the operation, select Yes.

After the operation is complete, the domain is released from your subscription and available for anyone to
purchase again.
Direct default URL to a custom directory

By default, App Service directs web requests to the root directory of your app code. To direct them to a
subdirectory, such as public , see Direct default URL to a custom directory.
More resources
FAQ : App Service Domain (preview) and Custom Domains
Configuring a custom domain name for a web app in
Azure App Service using Traffic Manager
When you use a Microsoft Azure Traffic Manager to load balance traffic to your Azure Website, that website can
then be accessed using the *.trafficmanager.net domain name assigned by Azure. You can also associate a
custom domain name, such as www.contoso.com, with your website in order to provide a more recognizable
domain name for your users.
This article provides generic instructions for using a custom domain name with an App Service app that is
integrated with Traffic Manager for load balancing.
If you do not already have a Traffic Manager profile, use the information in Create a Traffic Manager profile using
Quick Create to create one. Note the .trafficmanager.net domain name associated with your Traffic Manager
profile, as this will be used later by later steps in this document.
This article is for Azure App Service (Web Apps, API Apps, Mobile Apps, Logic Apps); for Cloud Services, see
Configuring a custom domain name for an Azure cloud service.
NOTE
If you app is load-balanced by Azure Traffic Manager, click the selector at the top of this article to get specific steps.
Custom domain names are not enabled for Free tier. You must scale up to a higher pricing tier, which may change how
much you are billed for your subscription. See App Service Pricing for more information.
Understanding DNS records

The Domain Name System (DNS) is used to locate things on the internet. For example, when you enter an address
in your browser, or click a link on a web page, it uses DNS to translate the domain into an IP address. The IP
address is sort of like a street address, but it's not very human friendly. For example, it is much easier to remember
a DNS name like contoso.com than it is to remember an IP address such as 192.168.1.88 or
2001:0:4137:1f67:24a2:3888:9cce:fea3.
The DNS system is based on records. Records associate a specific name, such as contoso.com, with either an IP
address or another DNS name. When an application, such as a web browser, looks up a name in DNS, it finds the
record, and uses whatever it points to as the address. If the value it points to is an IP address, the browser will use
that value. If it points to another DNS name, then the application has to do resolution again. Ultimately, all name
resolution will end in an IP address.
When you create an Azure Website, a DNS name is automatically assigned to the site. This name takes the form of
<yoursitename>.azurewebsites.net. When you add your website as an Azure Traffic Manager endpoint, your
website is then accessible through the <yourtrafficmanagerprofile>.trafficmanager.net domain.
NOTE
When your website is configured as a Traffic Manager endpoint, you will use the .trafficmanager.net address when creating
DNS records.
You can only use CNAME records with Traffic Manager
There are also multiple types of records, each with their own functions and limitations, but for websites configured
to as Traffic Manager endpoints, we only care about one; CNAME records.
CNAME or Alias record
A CNAME record maps a specific DNS name, such as mail.contoso.com or www.contoso.com, to another
(canonical) domain name. In the case of Azure Websites using Traffic Manager, the canonical domain name is the
<myapp>.trafficmanager.net domain name of your Traffic Manager profile. Once created, the CNAME creates
an alias for the <myapp>.trafficmanager.net domain name. The CNAME entry will resolve to the IP address of
your <myapp>.trafficmanager.net domain name automatically, so if the IP address of the website changes, you
do not have to take any action.
Once traffic arrives at Traffic Manager, it then routes the traffic to your website, using the load balancing method it
is configured for. This is completely transparent to visitors to your website. They will only see the custom domain
name in their browser.
NOTE
Some domain registrars only allow you to map subdomains when using a CNAME record, such as www.contoso.com, and
not root names, such as contoso.com. For more information on CNAME records, see the documentation provided by your
registrar, the Wikipedia entry on CNAME record, or the IETF Domain Names - Implementation and Specification document.
Configure your web apps for standard mode

Setting a custom domain name on a web app that is integrated with Traffic Manager is only available for the
Standard pricing tier.
For more information on the App Service pricing tiers, including how to change your app's pricing tier, see Scale up
an app in Azure.
Add a DNS record for your custom domain

NOTE
If you have purchased domain through Azure App Service Web Apps then skip following steps and refer to the final step of
Buy Domain for Web Apps article.
To associate your custom domain with a web app in Azure App Service, you must add a new entry in the DNS table
for your custom domain. You do this by using the management tools from your domain provider.
Find the page for managing DNS records. Every domain provider has its own DNS records interface, so consult the
provider's documentation. Look for areas of the site labeled Domain Name, DNS, or Name Server
Management.
Often, you can find the DNS records page by viewing your account information, and then looking for a link such as
My domains. Go to that page and then look for a link that is named something like Zone file, DNS Records, or
Advanced configuration.
NOTE
Changes link.
While the specifics of each domain provider vary, you map from your custom domain name (such as
contoso.com) to the Traffic Manager domain name (contoso.trafficmanager.net) that is integrated with your
web app.
NOTE
If a record is already in use and you need to preemptively bind your apps to it, you can create an additional CNAME record.
For example, to preemptively bind www.contoso.com to your web app, create a CNAME record from awverify.www to
contoso.trafficmanager.net. You can then add "www.contoso.com" to your Web App without changing the "www" CNAME
record. For more information, see Create DNS records for a web app in a custom domain.
Once you have finished adding or modifying DNS records at your domain provider, save the changes.
Enable Traffic Manager

After the records for your domain name have propagated, you should be able to use your browser to verify that
your custom domain name can be used to access your web app in Azure App Service.
NOTE
It can take some time for your CNAME to propagate through the DNS system. You can use a service such as
http://www.digwebinterface.com/ to verify that the CNAME is available.
If you have not already added your web app as a Traffic Manager endpoint, you must do this before name
resolution will work, as the custom domain name routes to Traffic Manager. Traffic Manager then routes to your
web app. Use the information in Add or Delete Endpoints to add your web app as an endpoint in your Traffic
Manager profile.
NOTE
If your web app is not listed when adding an endpoint, verify that it is configured for Standard App Service plan mode. You
must use Standard mode for your web app in order to work with Traffic Manager.
1. In your browser, open the Azure Portal.
2. In the Web Apps tab, click the name of your web app, select Settings, and then select Custom domains
3. In the Custom domains blade, click Add hostname.

4. Use the Hostname text boxes to enter the Traffic Manager domain name to associate with this web app.
5. Click Validate to save the domain name configuration.

6. Upon clicking Validate Azure will kick off Domain Verification workflow. This will check for Domain ownership
as well as Hostname availability and report success or detailed error with prescriptive guidence on how to fix
the error.
7. Upon successful validation Add hostname button will become active and you will be able to the assign
hostname. Now navigate to your custom domain name in a browser. You should now see your app running
using your custom domain name.
Once configuration has completed, the custom domain name will be listed in the domain names section of
your web app.
At this point, you should be able to enter the Traffic Manager domain name name in your browser and see that it
successfully takes you to your web app.
Next steps
For more information, see the Node.js Developer Center.
NOTE
Migrate an active DNS name to Azure App Service
This article shows you how to migrate an active DNS name to Azure App Service without any downtime.
When you migrate a live site and its DNS domain name to App Service, that DNS name is already serving live
traffic. You can avoid downtime in DNS resolution during the migration by binding the active DNS name to your
App Service app preemptively.
If you're not worried about downtime in DNS resolution, see Map an existing custom DNS name to Azure Web
Apps.
Prerequisites
To complete this how-to:
Make sure that your App Service app is not in FREE tier.
Bind the domain name preemptively

When you bind a custom domain preemptively, you accomplish both of the following before making any changes
to your DNS records:
Verify domain ownership
Enable the domain name for your app
When you finally migrate your custom DNS name from the old site to the App Service app, there will be no
downtime in DNS resolution.
Find the page for managing DNS records. Every domain provider has its own DNS records interface, so consult the
provider's documentation. Look for areas of the site labeled Domain Name, DNS, or Name Server
Management.
Often, you can find the DNS records page by viewing your account information, and then looking for a link such as
My domains. Go to that page and then look for a link that is named something like Zone file, DNS Records, or
Advanced configuration.
NOTE
Changes link.
Create domain verification record

To verify domain ownership, Add a TXT record. The TXT record maps from awverify.<subdomain> to
<appname>.azurewebsites.net.
The TXT record you need depends on the DNS record you want to migrate. For examples, see the following table (
@ typically represents the root domain):
DNS RECORD EXAMPLE TXT HOST TXT VALUE
@ (root) awverify <appname>.azurewebsites.net
www (sub) awverify.www <appname>.azurewebsites.net
* (wildcard) awverify.* <appname>.azurewebsites.net
In your DNS records page, note the record type of the DNS name you want to migrate. App Service supports
mappings from CNAME and A records.
Enable the domain for your app
In the Azure portal, in the left navigation of the app page, select Custom domains.
In the Custom domains page, select the + icon next to Add hostname.
Type the fully qualified domain name that you added the TXT record for, such as www.contoso.com . For a wildcard
domain (like *.contoso.com), you can use any DNS name that matches the wildcard domain.
Select Validate.
Make sure that Hostname record type is set to the DNS record type you want to migrate.
It might take some time for the new hostname to be reflected in the app's Custom domains page. Try refreshing
the browser to update the data.
Your custom DNS name is now enabled in your Azure app.
Remap the active DNS name

The only thing left to do is remapping your active DNS record to point to App Service. Right now, it still points to
your old site.
Copy the app's IP address (A record only)
If you are remapping a CNAME record, skip this section.
To remap an A record, you need the App Service app's external IP address, which is shown in the Custom domains
page.
Close the Add hostname page by selecting X in the upper-right corner.
In the Custom domains page, copy the app's IP address.
Update the DNS record

Back in the DNS records page of your domain provider, select the DNS record to remap.
For the contoso.com root domain example, remap the A or CNAME record like the examples in the following table:
FQDN EXAMPLE RECORD TYPE HOST VALUE
contoso.com (root) A @ IP address from Copy the

app's IP address
www.contoso.com (sub) CNAME www <appname>.azurewebsites.

net
*.contoso.com (wildcard) CNAME * <appname>.azurewebsites.

net
Save your settings.

DNS queries should start resolving to your App Service app immediately after DNS propagation happens.
Next steps
Learn how to bind a custom SSL certificate to App Service.
Bind an existing custom SSL certificate to Azure Web Apps
Buy and Configure an SSL Certificate for your Azure
App Service
This tutorial shows you how to secure your web app by purchasing an SSL certificate for your Azure App Service,
securely storing it in Azure Key Vault, and associating it with a custom domain.
Step 1 - Log in to Azure

Log in to the Azure portal at http://portal.azure.com
Step 2 - Place an SSL Certificate order

You can place an SSL Certificate order by creating a new App Service Certificate In the Azure portal.
Enter a friendly Name for your SSL certificate and enter the Domain Name
NOTE
This step is one of the most critical parts of the purchase process. Make sure to enter correct host name (custom domain)
that you want to protect with this certificate. DO NOT append the Host name with WWW.
Select your Subscription, Resource Group, and Certificate SKU
WARNING
App Service Certificates can only be used by other App Services within the same subscription.
Step 3 - Store the certificate in Azure Key Vault
NOTE
Key Vault is an Azure service that helps safeguard cryptographic keys and secrets used by cloud applications and services.
Once the SSL Certificate purchase is complete, you need to open the App Service Certificates page.
The certificate status is “Pending Issuance” as there are few more steps you need to complete before you can
start using this certificate.
Click Certificate Configuration inside the Certificate Properties page and Click on Step 1: Store to store this
certificate in Azure Key Vault.
From the Key Vault Status page, click Key Vault Repository to choose an existing Key Vault to store this
certificate OR Create New Key Vault to create new Key Vault inside same subscription and resource group.
NOTE
Azure Key Vault has minimal charges for storing this certificate. For more information, see Azure Key Vault Pricing Details.
Once you have selected the Key Vault Repository to store this certificate in, the Store option should show success.
Step 4 - Verify the Domain Ownership
From the same Certificate Configuration page you used in Step 3, click Step 2: Verify.
Choose the preferred domain verification method.
There are four types of domain verification supported by App Service Certificates: App Service, Domain, Mail, and
Manual Verification. These verification types are explained in more details in the Advanced section.
NOTE
App Service Verification is the most convenient option when the domain you want to verify is already mapped to an App
Service app in the same subscription. It takes advantage of the fact that the App Service app has already verified the domain
ownership.
Click on Verify button to complete this step.

After clicking Verify, use the Refresh button until the Verify option should show success.
Step 5 - Assign Certificate to App Service App
NOTE
Before performing the steps in this section, you must have associated a custom domain name with your app. For more
information, see Configuring a custom domain name for a web app.
In the Azure portal, click the App Service option on the left of the page.
Click the name of your app to which you want to assign this certificate.
In the Settings, click SSL certificates.
Click Import App Service Certificate and select the certificate that you just purchased.
In the ssl bindings section Click on Add bindings, and use the dropdowns to select the domain name to secure
with SSL, and the certificate to use. You may also select whether to use Server Name Indication (SNI) or IP based
SSL.
Click Add Binding to save the changes and enable SSL.
NOTE
If you selected IP based SSL and your custom domain is configured using an A record, you must perform the following
additional steps. These are explained in more details in the Advanced section.
At this point, you should be able to visit your app using HTTPS:// instead of HTTP:// to verify that the certificate
has been configured correctly.
Step 6 - Management tasks

Azure CLI
#!/bin/bash
fqdn=<replace-with-www.{yourdomain}>
pfxPath=<replace-with-path-to-your-.PFX-file>
pfxPassword=<replace-with-your=.PFX-password>
resourceGroup=myResourceGroup
webappname=mywebapp$RANDOM
# Create a resource group.

az group create --location westeurope --name $resourceGroup
# Create an App Service plan in Basic tier (minimum required by custom domains).
az appservice plan create --name $webappname --resource-group $resourceGroup --sku B1
# Create a web app.

az webapp create --name $webappname --resource-group $resourceGroup \
--plan $webappname
echo "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

read -p "Press [Enter] key when ready ..."
# Before continuing, go to your DNS configuration UI for your custom domain and follow the
# instructions at https://aka.ms/appservicecustomdns to configure a CNAME record for the
# hostname "www" and point it your web app's default domain name.
# Map your prepared custom domain name to the web app.

az webapp config hostname add --webapp-name $webappname --resource-group $resourceGroup \
--hostname $fqdn
# Upload the SSL certificate and get the thumbprint.

thumbprint=$(az webapp config ssl upload --certificate-file $pfxPath \
--certificate-password $pfxPassword --name $webappname --resource-group $resourceGroup \
--query thumbprint --output tsv)
# Binds the uploaded SSL certificate to the web app.

az webapp config ssl bind --certificate-thumbprint $thumbprint --ssl-type SNI \
--name $webappname --resource-group $resourceGroup
echo "You can now browse to https://$fqdn"
PowerShell
$fqdn="<Replace with your custom domain name>"
$pfxPath="<Replace with path to your .PFX file>"
$pfxPassword="<Replace with your .PFX password>"
$webappname="mywebapp$(Get-Random)"
$location="West Europe"
# Create a resource group.

New-AzureRmResourceGroup -Name $webappname -Location $location
# Create an App Service plan in Free tier.

New-AzureRmAppServicePlan -Name $webappname -Location $location `
-ResourceGroupName $webappname -Tier Free
# Create a web app.

New-AzureRmWebApp -Name $webappname -Location $location -AppServicePlan $webappname `
-ResourceGroupName $webappname
Write-Host "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

Read-Host "Press [Enter] key when ready ..."
# Before continuing, go to your DNS configuration UI for your custom domain and follow the
# instructions at https://aka.ms/appservicecustomdns to configure a CNAME record for the
# hostname "www" and point it your web app's default domain name.
# Upgrade App Service plan to Basic tier (minimum required by custom SSL certificates)
Set-AzureRmAppServicePlan -Name $webappname -ResourceGroupName $webappname `
-Tier Basic
# Add a custom domain name to the web app.

Set-AzureRmWebApp -Name $webappname -ResourceGroupName $webappname `
-HostNames @($fqdn,"$webappname.azurewebsites.net")
# Upload and bind the SSL certificate to the web app.

New-AzureRmWebAppSSLBinding -WebAppName $webappname -ResourceGroupName $webappname -Name $fqdn `
-CertificateFilePath $pfxPath -CertificatePassword $pfxPassword -SslState SniEnabled
Advanced
Verifying Domain Ownership
There are two more types of domain verification supported by App service Certificates: Mail, and Manual
Verification.
Mail Verification
Verification email has already been sent to the Email Address(es) associated with this custom domain. To complete
the Email verification step, open the email and click the verification link.
If you need to resend the verification email, click the Resend Email button.
Domain Verification
Choose this option only for an App Service domain that you purchased from Azure.. Azure automatically adds the
verification TXT record for you and completes the process.
Manual Verification
IMPORTANT
HTML Web Page Verification (only works with Standard Certificate SKU)
1. Create an HTML file named "starfield.html"

2. Content of this file should be the exact name of the Domain Verification Token. (You can copy the token
from the Domain Verification Status page)
3. Upload this file at the root of the web server hosting your domain
/.well-known/pki-validation/starfield.html
4. Click Refresh to update the certificate status after verification is completed. It might take few minutes for
verification to complete.
TIP
Verify in a terminal using curl -G http://<domain>/.well-known/pki-validation/starfield.html the response should
contain the <verification-token> .
DNS TXT Record Verification

1. Using your DNS manager, Create a TXT record on the @ subdomain with value equal to the Domain
Verification Token.
2. Click “Refresh” to update the Certificate status after verification is completed.
TIP
You need to create a TXT record on @.<domain> with value <verification-token> .
Assign Certificate to App Service App
If you selected IP based SSL and your custom domain is configured using an A record, you must perform the
following additional steps:
After you have configured an IP based SSL binding, a dedicated IP address is assigned to your app. You can find
this IP address on the Custom domain page under settings of your app, right above the Hostnames section. It is
listed as External IP Address
This IP address is different than the virtual IP address used previously to configure the A record for your domain. If
you are configured to use SNI based SSL, or are not configured to use SSL, no address is listed for this entry.
Using the tools provided by your domain name registrar, modify the A record for your custom domain name to
point to the IP address from the previous step.
Rekey and Sync the Certificate

If you ever need to rekey your certificate, select the Rekey and Sync option from the Certificate Properties page.
Click Rekey Button to initiate the process. This process can take 1-10 minutes to complete.
Rekeying your certificate rolls the certificate with a new certificate issued from the certificate authority.
Why is my SSL certificate not auto-renewed?
If your SSL certificate is configured for auto-renewal, but it is not automatically renewed, you may have a pending
domain verification. Note the following:
GoDaddy, which generates App Service certificates, requires domain verification once every three years. The
domain administrator receives an email once every three years to verify the domain. Failure to check the email
or verify your domain prevents the App Service certificate from being automatically renewed.
All App Service certificates issued prior to March 31 2017 require reverification of domain at the time of next
renewal (even if the auto-renewal is enabled for the certificate). This is a result of change in GoDaddy policy.
Check your email and complete this one-time domain verification to continue the auto-renewal of the App
Service certificate.
More resources
Use an SSL certificate in your application code in Azure App Service
FAQ : App Service Certificates
Configure your App Service app to use Azure Active
Directory login
This article shows you how to configure Azure App Services to use Azure Active Directory as an authentication
provider.
Configure Azure Active Directory using express settings

1. In the Azure portal, navigate to your App Service app. In the left navigation, select Authentication /
Authorization.
2. If Authentication / Authorization is not enabled, select On.
3. Select Azure Active Directory, and then select Express under Management Mode.
4. Select OK to register the App Service app in Azure Active Directory. This creates a new app registration. If you
want to choose an existing app registration instead, click Select an existing app and then search for the name
of a previously created app registration within your tenant. Click the app registration to select it and click OK.
Then click OK on the Azure Active Directory settings page. By default, App Service provides authentication but
does not restrict authorized access to your site content and APIs. You must authorize users in your app code.
5. (Optional) To restrict access to your site to only users authenticated by Azure Active Directory, set Action to
take when request is not authenticated to Log in with Azure Active Directory. This requires that all
requests be authenticated, and all unauthenticated requests are redirected to Azure Active Directory for
authentication.
6. Click Save.
You are now ready to use Azure Active Directory for authentication in your App Service app.
(Alternative method) Manually configure Azure Active Directory with

advanced settings
You can also choose to provide configuration settings manually. This is the preferred solution if the AAD tenant
you wish to use is different from the tenant with which you sign into Azure. To complete the configuration, you
must first create a registration in Azure Active Directory, and then you must provide some of the registration
details to App Service.
Register your App Service app with Azure Active Directory
1. Log on to the Azure portal, and navigate to your App Service app. Copy your app URL. You will use this to
configure your Azure Active Directory app registration.
2. Navigate to Active Directory, then select the App registrations, then click New application registration at
the top to start a new app registration.
3. In the Create page, enter a Name for your app registration, select the Web App / API type, in the Sign-on
URL box paste the application URL (from step 1). Then click to Create.
4. In a few seconds, you should see the new app registration you just created.
5. Once the app registration has been added, click on the app registration name, click on Settings at the top, then
click on Properties
6. In the App ID URI box, paste in the Application URL (from step 1), also in the Home Page URL paste in the
Application URL (from step 1) as well, then click Save
7. Now click on the Reply URLs, edit the Reply URL, paste in the Application URL (from step 1), modify the
protocol to make sure you have https:// protocol (not http://), then appended to the end of the URL,
/.auth/login/aad/callback (For example, https://contoso.azurewebsites.net/.auth/login/aad/callback ). Click
Save.
8. At this point, copy the Application ID for the app. Keep it for later use. You will need it to configure your App
Service app.
9. Close the Registered app page. On the App registrations page, click on the Endpoints button at the top,
then copy the Federation Metadata Document URL.
10. Open a new browser window and navigate to the URL by pasting and browsing to the XML page. At the top of
document is an EntityDescriptor element, there should be an entityID attribute of the form
https://sts.windows.net/ followed by a GUID specific to your tenant (called a "tenant ID"). Copy this value - it
serves as your Issuer URL. You will configure your application to use it later.
Add Azure Active Directory information to your App Service app
1. Back in the Azure portal, navigate to your App Service app. Click Authentication/Authorization. If the
Authentication/Authorization feature is not enabled, turn the switch to On. Click on Azure Active Directory,
under Authentication Providers, to configure your app. (Optional) By default, App Service provides
authentication but does not restrict authorized access to your site content and APIs. You must authorize users
in your app code. Set Action to take when request is not authenticated to Log in with Azure Active
Directory. This option requires that all requests be authenticated, and all unauthenticated requests are
redirected to Azure Active Directory for authentication. 2.In the Active Directory Authentication configuration,
click Advanced under Management Mode. Paste the Application ID into the Client ID box (from step 8) and
paste in the entityId (from step 10) into the Issuer URL value. Then click OK.
2. On the Active Directory Authentication configuration page, click Save.
You are now ready to use Azure Active Directory for authentication in your App Service app.
(Optional) Configure a native client application

Azure Active Directory also allows you to register native clients, which provides greater control over permissions
mapping. You need this if you wish to perform logins using a library such as the Active Directory
Authentication Library.
1. Navigate to Azure Active Directory in the Azure portal.
2. In the left navigation, select App registrations. Click New app registration at the top.
3. In the Create page, enter a Name for your app registration. Select Native in Application type.
4. In the Redirect URI box, enter your site's /.auth/login/done endpoint, using the HTTPS scheme. This value
should be similar to https://contoso.azurewebsites.net/.auth/login/done. If creating a Windows application,
instead use the package SID as the URI.
5. Click Create.
6. Once the app registration has been added, select it to open it. Find the Application ID and make a note of this
value.
7. Click All settings > Required permissions > Add > Select an API.
8. Type the name of the App Service app that you registered earlier to search for it, then select it and click Select.
9. Select Access <app_name>. Then click Select. Then click Done.
You have now configured a native client application that can access your App Service app.
Related Content
App Service Authentication / Authorization overview
Add authentication to your Mobile App: iOS, Android, Windows Universal, Xamarin.Android, Xamarin.iOS,
Xamarin.Forms, Cordova
Learn how to add App Service authenication to your mobile app.
How to configure your App Service application to
use Facebook login
This topic shows you how to configure Azure App Service to use Facebook as an authentication provider.
To complete the procedure in this topic, you must have a Facebook account that has a verified email address and a
mobile phone number. To create a new Facebook account, go to facebook.com.
Register your application with Facebook

1. Log on to the Azure portal, and navigate to your application. Copy your URL. You will use this to configure your
Facebook app.
2. In another browser window, navigate to the Facebook Developers website and sign-in with your Facebook
account credentials.
3. (Optional) If you have not already registered, click Apps > Register as a Developer, then accept the policy
and follow the registration steps.
4. Click My Apps > Add a New App > Website > Skip and Create App ID.
5. In Display Name, type a unique name for your app, type your Contact Email, choose a Category for your
app, then click Create App ID and complete the security check. This takes you to the developer dashboard for
your new Facebook app.
6. Under "Facebook Login," click Get Started. Add your application's Redirect URI to Valid OAuth redirect
URIs, then click Save Changes.
NOTE
Your redirect URI is the URL of your application appended with the path, /.auth/login/facebook/callback. For
example, https://contoso.azurewebsites.net/.auth/login/facebook/callback . Make sure that you are using
the HTTPS scheme.
7. In the left-hand navigation, click Settings. On the App Secret field, click Show, provide your password if
requested, then make a note of the values of App ID and App Secret. You use these later to configure your
application in Azure.
IMPORTANT
The app secret is an important security credential. Do not share this secret with anyone or distribute it within a client
application.
8. The Facebook account which was used to register the application is an administrator of the app. At this point,
only administrators can sign into this application. To authenticate other Facebook accounts, click App Review
and enable Make public to enable general public access using Facebook authentication.
Add Facebook information to your application

1. Back in the Azure portal, navigate to your application. Click Settings > Authentication / Authorization, and
make sure that App Service Authentication is On.
2. Click Facebook, paste in the App ID and App Secret values which you obtained previously, optionally
enable any scopes needed by your application, then click OK.
By default, App Service provides authentication but does not restrict authorized access to your site content
and APIs. You must authorize users in your app code.
3. (Optional) To restrict access to your site to only users authenticated by Facebook, set Action to take when
request is not authenticated to Facebook. This requires that all requests be authenticated, and all
unauthenticated requests are redirected to Facebook for authentication.
4. When done configuring authentication, click Save.
You are now ready to use Facebook for authentication in your app.
Related Content
use Google login
This topic shows you how to configure Azure App Service to use Google as an authentication provider.
To complete the procedure in this topic, you must have a Google account that has a verified email address. To
create a new Google account, go to accounts.google.com.
Register your application with Google

1. Log on to the Azure portal, and navigate to your application. Copy your URL, which you use later to configure
your Google app.
2. Navigate to the Google apis website, sign in with your Google account credentials, click Create Project,
provide a Project name, then click Create.
3. Under Social APIs click Google+ API and then Enable.
4. In the left navigation, Credentials > OAuth consent screen, then select your Email address, enter a Product
Name, and click Save.
5. In the Credentials tab, click Create credentials > OAuth client ID, then select Web application.
6. Paste the App Service URL you copied earlier into Authorized JavaScript Origins, then paste your redirect
URI into Authorized Redirect URI. The redirect URI is the URL of your application appended with the path,
/.auth/login/google/callback. For example, https://contoso.azurewebsites.net/.auth/login/google/callback .
Make sure that you are using the HTTPS scheme. Then click Create.
7. On the next screen, make a note of the values of the client ID and client secret.
IMPORTANT
The client secret is an important security credential. Do not share this secret with anyone or distribute it within a
client application.
Add Google information to your application

1. Back in the Azure portal, navigate to your application. Click Settings, and then Authentication /
Authorization.
2. If the Authentication / Authorization feature is not enabled, turn the switch to On.
3. Click Google. Paste in the App ID and App Secret values which you obtained previously, and optionally
enable any scopes your application requires. Then click OK.
4. (Optional) To restrict access to your site to only users authenticated by Google, set Action to take when
request is not authenticated to Google. This requires that all requests be authenticated, and all
unauthenticated requests are redirected to Google for authentication.
5. Click Save.
You are now ready to use Google for authentication in your app.
Related Content
use Microsoft Account login
This topic shows you how to configure Azure App Service to use Microsoft Account as an authentication provider.
Register your app with Microsoft Account

1. Log on to the Azure portal, and navigate to your application. Copy your URL, which later you use to configure
your app with Microsoft Account.
2. Navigate to the My Applications page in the Microsoft Account Developer Center, and log on with your
Microsoft account, if required.
3. Click Add an app, then type an application name, and click Create application.
4. Make a note of the Application ID, as you will need it later.
5. Under "Platforms," click Add Platform and select "Web".
6. Under "Redirect URIs" supply the endpoint for your application, then click Save.
NOTE
Your redirect URI is the URL of your application appended with the path, /.auth/login/microsoftaccount/callback.
For example, https://contoso.azurewebsites.net/.auth/login/microsoftaccount/callback .
Make sure that you are using the HTTPS scheme.
7. Under "Application Secrets," click Generate New Password. Make note of the value that appears. Once
you leave the page, it will not be displayed again.
IMPORTANT
The password is an important security credential. Do not share the password with anyone or distribute it within a
client application.
Add Microsoft Account information to your App Service application

1. Back in the Azure portal, navigate to your application, click Settings > Authentication / Authorization.
2. If the Authentication / Authorization feature is not enabled, switch it On.
3. Click Microsoft Account. Paste in the Application ID and Password values which you obtained previously,
and optionally enable any scopes your application requires. Then click OK.
4. (Optional) To restrict access to your site to only users authenticated by Microsoft account, set Action to take
when request is not authenticated to Microsoft Account. This requires that all requests be authenticated,
and all unauthenticated requests are redirected to Microsoft account for authentication.
5. Click Save.
You are now ready to use Microsoft Account for authentication in your app.
Related content
use Twitter login
This topic shows you how to configure Azure App Service to use Twitter as an authentication provider.
To complete the procedure in this topic, you must have a Twitter account that has a verified email address and
phone number. To create a new Twitter account, go to twitter.com.
Register your application with Twitter

1. Log on to the Azure portal, and navigate to your application. Copy your URL. You will use this to configure
your Twitter app.
2. Navigate to the Twitter Developers website, sign in with your Twitter account credentials, and click Create
New App.
3. Type in the Name and a Description for your new app. Paste in your application's URL for the Website
value. Then, for the Callback URL, paste the Callback URL you copied earlier. This is your Mobile App
gateway appended with the path, /.auth/login/twitter/callback. For example,
https://contoso.azurewebsites.net/.auth/login/twitter/callback . Make sure that you are using the HTTPS
scheme.
4. At the bottom the page, read and accept the terms. Then click Create your Twitter application. This registers
the app displays the application details.
5. Click the Settings tab, check Allow this application to be used to sign in with Twitter, then click Update
Settings.
6. Select the Keys and Access Tokens tab. Make a note of the values of Consumer Key (API Key) and
Consumer secret (API Secret).
NOTE
The consumer secret is an important security credential. Do not share this secret with anyone or distribute it with
your app.
Add Twitter information to your application

1. Back in the Azure portal, navigate to your application. Click Settings, and then Authentication /
Authorization.
2. If the Authentication / Authorization feature is not enabled, turn the switch to On.
3. Click Twitter. Paste in the App ID and App Secret values which you obtained previously. Then click OK.
4. (Optional) To restrict access to your site to only users authenticated by Twitter, set Action to take when
request is not authenticated to Twitter. This requires that all requests be authenticated, and all
unauthenticated requests are redirected to Twitter for authentication.
5. Click Save.
You are now ready to use Twitter for authentication in your app.
Related Content
How To Configure TLS Mutual Authentication for
Web App
Overview
You can restrict access to your Azure web app by enabling different types of authentication for it. One way to do so
is to authenticate using a client certificate when the request is over TLS/SSL. This mechanism is called TLS mutual
authentication or client certificate authentication and this article will detail how to setup your web app to use client
certificate authentication.
Note: If you access your site over HTTP and not HTTPS, you will not receive any client certificate. So if your
application requires client certificates you should not allow requests to your application over HTTP.
NOTE
Configure Web App for Client Certificate Authentication

To setup your web app to require client certificates you need to add the clientCertEnabled site setting for your web
app and set it to true. This setting is not currently available through the management experience in the Portal, and
the REST API will need to be used to accomplish this.
You can use the ARMClient tool to make it easy to craft the REST API call. After you log in with the tool you will
need to issue the following command:
ARMClient PUT subscriptions/{Subscription Id}/resourcegroups/{Resource Group

Name}/providers/Microsoft.Web/sites/{Website Name}?api-version=2015-04-01 @enableclientcert.json -verbose
replacing everything in {} with information for your web app and creating a file called enableclientcert.json with the
following JSON content:
{
"location": "My Web App Location",
"properties": {
"clientCertEnabled": true
}
}
Make sure to change the value of "location" to wherever your web app is located e.g. North Central US or West US
etc.
You can also use https://resources.azure.com to flip the clientCertEnabled property to true .
Note: If you run ARMClient from Powershell, you will need to escape the @ symbol for the JSON file with a
back tick `.
Accessing the Client Certificate From Your Web App
If you are using ASP.NET and configure your app to use client certificate authentication, the certificate will be
available through the HttpRequest.ClientCertificate property. For other application stacks, the client cert will be
available in your app through a base64 encoded value in the "X-ARR-ClientCert" request header. Your application
can create a certificate from this value and then use it for authentication and authorization purposes in your
application.
Special Considerations for Certificate Validation

The client certificate that is sent to the application does not go through any validation by the Azure Web Apps
platform. Validating this certificate is the responsibility of the web app. Here is sample ASP.NET code that validates
certificate properties for authentication purposes.
using System;
using System.Collections.Specialized;
using System.Security.Cryptography.X509Certificates;
using System.Web;
namespace ClientCertificateUsageSample
{
public partial class cert : System.Web.UI.Page
{
public string certHeader = "";
public string errorString = "";
private X509Certificate2 certificate = null;
public string certThumbprint = "";
public string certSubject = "";
public string certIssuer = "";
public string certSignatureAlg = "";
public string certIssueDate = "";
public string certExpiryDate = "";
public bool isValidCert = false;
//
// Read the certificate from the header into an X509Certificate2 object
// Display properties of the certificate on the page
//
protected void Page_Load(object sender, EventArgs e)
{
NameValueCollection headers = base.Request.Headers;
certHeader = headers["X-ARR-ClientCert"];
if (!String.IsNullOrEmpty(certHeader))
{
try
{
byte[] clientCertBytes = Convert.FromBase64String(certHeader);
certificate = new X509Certificate2(clientCertBytes);
certSubject = certificate.Subject;
certIssuer = certificate.Issuer;
certThumbprint = certificate.Thumbprint;
certSignatureAlg = certificate.SignatureAlgorithm.FriendlyName;
certIssueDate = certificate.NotBefore.ToShortDateString() + " " +
certificate.NotBefore.ToShortTimeString();
certExpiryDate = certificate.NotAfter.ToShortDateString() + " " +
certificate.NotAfter.ToShortTimeString();
}
catch (Exception ex)
{
errorString = ex.ToString();
}
finally
{
isValidCert = IsValidClientCertificate();
if (!isValidCert) Response.StatusCode = 403;
if (!isValidCert) Response.StatusCode = 403;
else Response.StatusCode = 200;
}
}
else
{
certHeader = "";
}
}
//
// This is a SAMPLE verification routine. Depending on your application logic and security
requirements,
// you should modify this method
//
private bool IsValidClientCertificate()
{
// In this example we will only accept the certificate as a valid certificate if all the
conditions below are met:
// 1. The certificate is not expired and is active for the current time on server.
// 2. The subject name of the certificate has the common name nildevecc
// 3. The issuer name of the certificate has the common name nildevecc and organization name
Microsoft Corp
// 4. The thumbprint of the certificate is 30757A2E831977D8BD9C8496E4C99AB26CB9622B
//
// This example does NOT test that this certificate is chained to a Trusted Root Authority (or
revoked) on the server
// and it allows for self signed certificates
//
if (certificate == null || !String.IsNullOrEmpty(errorString)) return false;
// 1. Check time validity of certificate

if (DateTime.Compare(DateTime.Now, certificate.NotBefore) < 0 || DateTime.Compare(DateTime.Now,
certificate.NotAfter) > 0) return false;
// 2. Check subject name of certificate

bool foundSubject = false;
string[] certSubjectData = certificate.Subject.Split(new char[] { ',' },
StringSplitOptions.RemoveEmptyEntries);
foreach (string s in certSubjectData)
{
if (String.Compare(s.Trim(), "CN=nildevecc") == 0)
{
foundSubject = true;
break;
}
}
if (!foundSubject) return false;
// 3. Check issuer name of certificate

bool foundIssuerCN = false, foundIssuerO = false;
string[] certIssuerData = certificate.Issuer.Split(new char[] { ',' },
StringSplitOptions.RemoveEmptyEntries);
foreach (string s in certIssuerData)
{
if (String.Compare(s.Trim(), "CN=nildevecc") == 0)
{
foundIssuerCN = true;
if (foundIssuerO) break;
}
if (String.Compare(s.Trim(), "O=Microsoft Corp") == 0)

{
foundIssuerO = true;
if (foundIssuerCN) break;
}
}
if (!foundIssuerCN || !foundIssuerO) return false;

if (!foundIssuerCN || !foundIssuerO) return false;
// 4. Check thumprint of certificate

if (String.Compare(certificate.Thumbprint.Trim().ToUpper(),
"30757A2E831977D8BD9C8496E4C99AB26CB9622B") != 0) return false;
// If you also want to test if the certificate chains to a Trusted Root Authority you can
uncomment the code below
//
//X509Chain certChain = new X509Chain();
//certChain.Build(certificate);
//bool isValidCertChain = true;
//foreach (X509ChainElement chElement in certChain.ChainElements)
//{
// if (!chElement.Certificate.Verify())
// {
// isValidCertChain = false;
// break;
// }
//}
//if (!isValidCertChain) return false;
return true;
}
}
}
Scale up an app in Azure
NOTE
The new PremiumV2 tier gives you faster CPUs, SSD storage, and double the memory-to-core ratio than the existing
pricing tiers. To scale up to PremiumV2 tier, see Configure PremiumV2 tier for App Service.
This article shows you how to scale your app in Azure App Service. There are two workflows for scaling, scale up
and scale out, and this article explains the scale up workflow.
Scale up: Get more CPU, memory, disk space, and extra features like dedicated virtual machines (VMs), custom
domains and certificates, staging slots, autoscaling, and more. You scale up by changing the pricing tier of the
App Service plan that your app belongs to.
Scale out: Increase the number of VM instances that run your app. You can scale out to as many as 20
instances, depending on your pricing tier. App Service Environments in Isolated tier further increases your
scale-out count to 100 instances. For more information about scaling out, see Scale instance count manually
or automatically. There you find out how to use autoscaling, which is to scale instance count automatically
based on predefined rules and schedules.
The scale settings take only seconds to apply and affect all apps in your App Service plan. They do not require
you to change your code or redeploy your application.
For information about the pricing and features of individual App Service plans, see App Service Pricing Details.
NOTE
Before you switch an App Service plan from the Free tier, you must first remove the spending limits in place for your Azure
subscription. To view or change options for your Microsoft Azure App Service subscription, see Microsoft Azure
Subscriptions.
Scale up your pricing tier

1. In your browser, open the Azure portal.
2. In your App Service app page, click All settings, and then click Scale Up.
3. Choose your tier, and then click Select.
The Notifications tab will flash a green SUCCESS after the operation is complete.
Scale related resources

If your app depends on other services, such as Azure SQL Database or Azure Storage, you can scale up these
resources separately. These resources are not managed by the App Service plan.
1. In Essentials, click the Resource group link.
2. In the Summary part of the Resource group page, click a resource that you want to scale. The following
screenshot shows a SQL Database resource and an Azure Storage resource.
3. For a SQL Database resource, click Settings > Pricing tier to scale the pricing tier.
You can also turn on geo-replication for your SQL Database instance.
For an Azure Storage resource, click Settings > Configuration to scale up your storage options.
Compare pricing tiers
For detailed information, such as VM sizes for each pricing tier, see App Service Pricing Details. For a table of
service limits, quotas, and constraints, and supported features in each tier, see App Service limits.
NOTE
If you want to get started with Azure App Service before you sign up for an Azure account, go to Try App Service where
you can immediately create a short-lived starter web app in App Service. No credit cards are required and there are no
commitments.
Next steps
For information about pricing, support, and SLA, visit the following links:
Data Transfers Pricing Details
Microsoft Azure Support Plans
Service Level Agreements
SQL Database Pricing Details
Virtual Machine and Cloud Service Sizes for Microsoft Azure
For information about Azure App Service best practices, including building a scalable and resilient
architecture, see Best Practices: Azure App Service Web Apps.
For videos about scaling App Service apps, see the following resources:
When to Scale Azure Websites - with Stefan Schackow
Auto Scaling Azure Websites, CPU or Scheduled - with Stefan Schackow
How Azure Websites Scale - with Stefan Schackow
Scale instance count manually or automatically
In the Azure Portal, you can manually set the instance count of your service, or, you can set parameters to have it
automatically scale based on demand. This is typically referred to as Scale out or Scale in.
Before scaling based on instance count, you should consider that scaling is affected by Pricing tier in addition to
instance count. Different pricing tiers can have different numbers cores and memory, and so they will have better
performance for the same number of instances (which is Scale up or Scale down). This article specifically covers
Scale in and out.
You can scale in the portal, and you can also use the REST API or .NET SDK to adjust scale manually or
automatically.
Scaling manually
1. In the Azure Portal, click Browse, then navigate to the resource you want to scale, such as an App Service plan.
2. Click Settings > Scale out (App Service plan).
3. At the top of the Scale blade you can see a history of autoscale actions of the service.
NOTE
Only actions that are performed by autoscale will show up in this chart. If you manually adjust the instance count, the
change will not be reflected in this chart.
4. You can manually adjust the number Instances with slider.

5. Click the Save command and you'll be scaled to that number of instances almost immediately.
Scaling based on a pre-set metric

If you want the number of instances to automatically adjust based on a metric, select the metric you want in the
Scale by dropdown. For example, for an App Service plan you can scale by CPU Percentage.
1. When you select a metric you'll get a slider, and/or, text boxes to enter the number of instances you want to
scale between:
Autoscale will never take your service below or above the boundaries that you set, no matter your load.
2. Second, you choose the target range for the metric. For example, if you chose CPU percentage, you can set a
target for the average CPU across all of the instances in your service. A scale out will happen when the average
CPU exceeds the maximum you define, likewise, a scale in will happen whenever the average CPU drops below
the minimum.
3. Click the Save command. Autoscale will check every few minutes to make sure that you are in the instance
range and target for your metric. When your service receives additional traffic, you will get more instances
without doing anything.
Scale based on other metrics
You can scale based on metrics other than the presets that appear in the Scale by dropdown, and can even have a
complex set of scale out and scale in rules.
Adding or changing a rule
1. Choose the schedule and performance rules in the Scale by dropdown:
2. If you previously had autoscale, on you'll see a view of the exact rules that you had.
3. To scale based on another metric click the Add Rule row. You can also click one of the existing rows to change
from the metric you previously had to the metric you want to scale by.
4. Now you need to select which metric you want to scale by. When choosing a metric there are a couple
things to consider:
The resource the metric comes from. Typically, this will be the same as the resource you are scaling.
However, if you want to scale by the depth of a Storage queue, the resource is the queue that you want to
scale by.
The metric name itself.
The time aggregation of the metric. This is how the data is combine over the duration.
5. After choosing your metric you choose the threshold for the metric, and the operator. For example, you could
say Greater than 80%.
6. Then choose the action that you want to take. There are a couple different type of actions:
Increase or decrease by - this will add or remove the Value number of instances you define
Increase or decrease percent - this will change the instance count by a percent. For example, you could
put 25 in the Value field, and if you currently had 8 instances, 2 would be added.
Increase or decrease to - this will set the instance count to the Value you define.
7. Finally, you can choose cool down - how long this rule should wait after the previous scale action to scale again.
8. After configuring your rule hit OK.
9. Once you have configured all of the rules you want, be sure to hit the Save command.
Scaling with multiple steps
The examples above are pretty basic. However, if you want to be more agressive about scaling up (or down), you
can even add multiple scale rules for the same metric. For example, you can define two scale rules on CPU
percentage:
1. Scale out by 1 instance if CPU percentage is above 60%
2. Scale out by 3 instances if CPU percentage is above 85%
With this additional rule, if your load exceeds 85% before a scale action, you will get two additional instances
instead of one.
Scale based on a schedule

By default, when you create a scale rule it will always apply. You can see that when you click on the profile header:
However, you may want to have more agressive scaling during the day, or the week, than on the weekend. You
could even shut down your service entirely off working hours.
1. To do this, on the profile you have, select recurrence instead of always, and choose the times that you want
the profile to apply.
2. For example, to have a profile that applies during the week, in the Days dropdown uncheck Saturday and
Sunday.
3. To have a profile that applies during the daytime, set the Start time to the time of day that you want to start
at.
4. Click OK.
5. Next, you will need to add the profile that you want to apply at other times. Click the Add Profile row.
6. Name your new, second, profile, for example you could call it Off work.
7. Then select recurrence again, and choose the instance count range you want during this time.
8. As with the Default profile, choose the Days you want this profile to apply to, and the Start time during the
day.
NOTE
Autoscale will use the Daylight savings rules for whichever Time zone you select. However, during Daylight savings
time the UTC offset will show the base Time zone offset, not the Daylight savings UTC offset.
9. Click OK.
10. Now, you will need to add whatever rules you want to apply during your second profile. Click Add Rule, and
then you could construct the same rule you have during the Default profile.
11. Be sure to create both a rule for scale out and scale in, or else during the profile the instance count will only
grow (or decrease).
12. Finally, click Save.
Next steps
Monitor service metrics to make sure your service is available and responsive.
Enable monitoring and diagnostics to collect detailed high-frequency metrics on your service.
Receive alert notifications whenever operational events happen or metrics cross a threshold.
Monitor application performance if you want to understand exactly how your code is performing in the cloud.
View events and activity log to learn everything that has happened in your service.
Monitor availability and responsiveness of any web page with Application Insights so you can find out if your
page is down.
How to: Monitor Apps in Azure App Service
App Service provides built in monitoring functionality in the Azure portal. The Azure portal includes the ability to
review quotas and metrics for an app as well as the App Service plan, setting up alerts and even scaling
automatically based on these metrics.
NOTE
Understanding Quotas and Metrics

Quotas
Applications hosted in App Service are subject to certain limits on the resources they can use. The limits are
defined by the App Service plan associated with the app.
NOTE
purposes.
If the application is hosted in a Free or Shared plan, then the limits on the resources the app can use are defined
by Quotas.
If the application is hosted in a Basic, Standard or Premium plan, then the limits on the resources they can use
are set by the size (Small, Medium, Large) and instance count (1, 2, 3, ...) of the App Service plan.
Quotas for Free or Shared apps are:
CPU(Short)
Amount of CPU allowed for this application in a 5-minute interval. This quota resets every five minutes.
CPU(Day)
Total amount of CPU allowed for this application in a day. This quota resets every 24 hours at midnight
UTC.
Memory
Total amount of memory allowed for this application.
Bandwidth
Total amount of outgoing bandwidth allowed for this application in a day. This quota resets every 24
hours at midnight UTC.
Filesystem
Total amount of storage allowed.
The only quota applicable to apps hosted on Basic, Standard, and Premium plans is Filesystem.
More information about the specific quotas, limits, and features available to the different App Service SKUs can be
found here: Azure Subscription Service Limits
Quota Enforcement
If an application exceeds the CPU (short), CPU (Day), or bandwidth quota then the application is stopped until
the quota resets. During this time, all incoming requests result in an HTTP 403.
If the application memory quota is exceeded, then the application is restarted.

If the Filesystem quota is exceeded, then any write operation fails, which includes any writes to logs.
Quotas can be increased or removed from your app by upgrading your App Service plan.
Metrics
Metrics provide information about the app, or App Service plan's behavior.
For an Application, the available metrics are:
Average Response Time
The average time taken for the app to serve requests in ms.
Average memory working set
The average amount of memory in MiBs used by the app.
CPU Time
The amount of CPU in seconds consumed by the app. For more information about this metric, see: CPU
time vs CPU percentage
Data In
The amount of incoming bandwidth consumed by the app in MiBs.
Data Out
The amount of outgoing bandwidth consumed by the app in MiBs.
Http 2xx
Count of requests resulting in an HTTP status code >= 200 but < 300.
Http 3xx
Http 401
Count of requests resulting in HTTP 401 status code.
Http 403
Http 404
Http 406
Http 4xx
Http Server Errors
Memory working set
Current amount of memory used by the app in MiBs.
Requests
Total number of requests regardless of their resulting HTTP status code.
For an App Service plan, the available metrics are:
NOTE
App Service plan metrics are only available for plans in Basic, Standard, and Premium tiers.
CPU Percentage
The average CPU used across all instances of the plan.
Memory Percentage
The average memory used across all instances of the plan.
Data In
The average incoming bandwidth used across all instances of the plan.
Data Out
The average outgoing bandwidth used across all instances of the plan.
Disk Queue Length
The average number of both read and write requests that were queued on storage. A high disk queue
length is an indication of an application that might be slowing down due to excessive disk I/O.
Http Queue Length
The average number of HTTP requests that had to sit on the queue before being fulfilled. A high or
increasing HTTP Queue length is a symptom of a plan under heavy load.
CPU time vs CPU percentage
There are two metrics that reflect CPU usage. CPU time and CPU percentage
CPU Time is useful for apps hosted in Free or Shared plans since one of their quotas is defined in CPU minutes
used by the app.
CPU percentage is useful for apps hosted in basic, standard, and premium plans since they can be scaled out.
CPU percentage is a good indication of the overall usage across all instances.
Metrics Granularity and Retention Policy

Metrics for an application and app service plan are logged and aggregated by the service with the following
granularities and retention policies:
Minute granularity metrics are retained for 30 hours
Hour granularity metrics are retained for 30 days
Day granularity metrics are retained for 30 days
Monitoring Quotas and Metrics in the Azure portal.
You can review the status of the different quotas and metrics affecting an application in the Azure portal.
Quotas can be found under Settings>Quotas. The UX allows you to review: (1) the quotas name, (2) its reset
interval, (3) its current limit, and (4) current value.
Metrics can be access directly from the resource page. You can also customize the chart by: (1) click on it, and
select (2) edit chart. From here you can change the (3) time range, (4) chart type, and (5) metrics to display.
You can learn more about metrics here: Monitor service metrics.
Alerts and Autoscale

Metrics for an App or App Service plan can be hooked up to alerts. To learn more about it, see Receive alert
notifications.
App Service apps hosted in basic, standard, or premium App Service plans support autoscale. Autoscale allows
you to configure rules that monitor the App Service plan metrics. Rules can increase or decrease the instance
count providing additional resources as needed. Rules can also help you save money when the application is over-
provisioned. You can learn more about auto scale here: How to Scale and here Best practices for Azure Monitor
autoscaling
NOTE
Enable diagnostics logging for web apps in Azure
App Service
Overview
Azure provides built-in diagnostics to assist with debugging an App Service web app. In this article, you learn how
to enable diagnostic logging and add instrumentation to your application, as well as how to access the information
logged by Azure.
This article uses the Azure portal, Azure PowerShell, and the Azure Command-Line Interface (Azure CLI) to work
with diagnostic logs. For information on working with diagnostic logs using Visual Studio, see Troubleshooting
Azure in Visual Studio.
NOTE
Web server diagnostics and application diagnostics

App Service web apps provide diagnostic functionality for logging information from both the web server and the
web application. These are logically separated into web server diagnostics and application diagnostics.
Web server diagnostics
You can enable or disable the following kinds of logs:
Detailed Error Logging - Detailed error information for HTTP status codes that indicate a failure (status code
400 or greater). It may contain information that can help determine why the server returned the error code.
Failed Request Tracing - Detailed information on failed requests, including a trace of the IIS components used
to process the request and the time taken in each component. It is useful if you are attempting to increase site
performance or isolate what is causing a specific HTTP error to be returned.
Web Server Logging - Information about HTTP transactions using the W3C extended log file format. It is useful
when determining overall site metrics such as the number of requests handled or how many requests are from
a specific IP address.
Application diagnostics
Application diagnostics allows you to capture information produced by a web application. ASP.NET applications can
use the System.Diagnostics.Trace class to log information to the application diagnostics log. For example:
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
At runtime, you can retrieve these logs to help with troubleshooting. For more information, see Troubleshooting
Azure web apps in Visual Studio.
App Service web apps also log deployment information when you publish content to a web app. It happens
automatically and there are no configuration settings for deployment logging. Deployment logging allows you to
determine why a deployment failed. For example, if you are using a custom deployment script, you might use
deployment logging to determine why the script is failing.
How to enable diagnostics
To enable diagnostics in the Azure portal, go to the page for your web app and click Settings > Diagnostics logs.
When you enable application diagnostics, you also choose the Level. This setting allows you to filter the
information captured to informational, warning, or error information. Setting it to verbose logs all information
produced by the application.
NOTE
Unlike changing the web.config file, enabling Application diagnostics or changing diagnostic log levels does not recycle the
app domain that the application runs within.
For Application logging, you can turn on the file system option temporarily for debugging purposes. This option
turns off automatically in 12 hours. You can also turn on the blob storage option to select a blob container to write
logs to.
For Web server logging, you can select storage or file system. Selecting storage allows you to select a storage
account, and then a blob container that the logs are written to.
If you store logs on the file system, the files can be accessed by FTP, or downloaded as a Zip archive by using the
Azure PowerShell or Azure Command-Line Interface (Azure CLI).
By default, logs are not automatically deleted (with the exception of Application Logging (Filesystem)). To
automatically delete logs, set the Retention Period (Days) field.
NOTE
If you regenerate your storage account's access keys, you must reset the respective logging configuration to use the updated
keys. To do this:
1. In the Configure tab, set the respective logging feature to Off. Save your setting.
2. Enable logging to the storage account blob or table again. Save your setting.
Any combination of file system, table storage, or blob storage can be enabled at the same time, and have individual
log level configurations. For example, you may wish to log errors and warnings to blob storage as a long-term
logging solution, while enabling file system logging with a level of verbose.
While all three storage locations provide the same basic information for logged events, table storage and blob
storage log additional information such as the instance ID, thread ID, and a more granular timestamp (tick format)
than logging to file system.
NOTE
Information stored in table storage or blob storage can only be accessed using a storage client or an application that can
directly work with these storage systems. For example, Visual Studio 2013 contains a Storage Explorer that can be used to
explore table or blob storage, and HDInsight can access data stored in blob storage. You can also write an application that
accesses Azure Storage by using one of the Azure SDKs.
NOTE
Diagnostics can also be enabled from Azure PowerShell using the Set-AzureWebsite cmdlet. If you have not installed Azure
PowerShell, or have not configured it to use your Azure Subscription, see How to Use Azure PowerShell.
How to: Download logs

Diagnostic information stored to the web app file system can be accessed directly using FTP. It can also be
downloaded as a Zip archive using Azure PowerShell or the Azure Command-Line Interface.
The directory structure that the logs are stored in is as follows:
Application logs - /LogFiles/Application/. This folder contains one or more text files containing information
produced by application logging.
Failed Request Traces - /LogFiles/W3SVC#########/. This folder contains an XSL file and one or more XML
files. Ensure that you download the XSL file into the same directory as the XML file(s) because the XSL file
provides functionality for formatting and filtering the contents of the XML file(s) when viewed in Internet
Explorer.
Detailed Error Logs - /LogFiles/DetailedErrors/. This folder contains one or more .htm files that provide
extensive information for any HTTP errors that have occurred.
Web Server Logs - /LogFiles/http/RawLogs. This folder contains one or more text files formatted using the
W3C extended log file format.
Deployment logs - /LogFiles/Git. This folder contains logs generated by the internal deployment processes
used by Azure web apps, as well as logs for Git deployments.
FTP
To open an FTP connection to your app's FTP server, see Deploy your app to Azure App Service using FTP/S.
Once connected to your web app's FTP/S server, open the LogFiles folder, where the log files are stored.
Download with Azure PowerShell
To download the log files, start a new instance of Azure PowerShell and use the following command:
Save-AzureWebSiteLog -Name webappname
This command saves the logs for the web app specified by the -Name parameter to a file named logs.zip in the
current directory.
NOTE
If you have not installed Azure PowerShell, or have not configured it to use your Azure Subscription, see How to Use Azure
PowerShell.
Download with Azure Command-Line Interface

To download the log files using the Azure Command Line Interface, open a new command prompt, PowerShell,
Bash, or Terminal session and enter the following command:
azure site log download webappname
This command saves the logs for the web app named 'webappname' to a file named diagnostics.zip in the current
directory.
NOTE
If you have not installed the Azure Command-Line Interface (Azure CLI), or have not configured it to use your Azure
Subscription, see How to Use Azure CLI.
How to: View logs in Application Insights

Visual Studio Application Insights provides tools for filtering and searching logs, and for correlating the logs with
requests and other events.
1. Add the Application Insights SDK to your project in Visual Studio.
In Solution Explorer, right-click your project and choose Add Application Insights. The interface guides
you through steps that include creating an Application Insights resource. Learn more
2. Add the Trace Listener package to your project.
Right-click your project and choose Manage NuGet Packages. Select
Microsoft.ApplicationInsights.TraceListener Learn more
3. Upload your project and run it to generate log data.
4. In the Azure portal, browse to your new Application Insights resource, and open Search. You should see your
log data, along with request, usage, and other telemetry. Some telemetry might take a few minutes to arrive:
click Refresh. Learn more
Learn more about performance tracking with Application Insights
How to: Stream logs
While developing an application, it is often useful to see logging information in near-real time. You can stream
logging information to your development environment using either Azure PowerShell or the Azure Command-Line
Interface.
NOTE
Some types of logging buffer write to the log file, which can result in out of order events in the stream. For example, an
application log entry that occurs when a user visits a page may be displayed in the stream before the corresponding HTTP
log entry for the page request.
NOTE
Log streaming also streams information written to any text file stored in the D:\home\LogFiles\ folder.
Streaming with Azure PowerShell

To stream logging information, start a new instance of Azure PowerShell and use the following command:
Get-AzureWebSiteLog -Name webappname -Tail
This command connects to the web app specified by the -Name parameter and begin streaming information to the
PowerShell window as log events occur on the web app. Any information written to files ending in .txt, .log, or .htm
that are stored in the /LogFiles directory (d:/home/logfiles) is streamed to the local console.
To filter specific events, such as errors, use the -Message parameter. For example:
Get-AzureWebSiteLog -Name webappname -Tail -Message Error
To filter specific log types, such as HTTP, use the -Path parameter. For example:
Get-AzureWebSiteLog -Name webappname -Tail -Path http
To see a list of available paths, use the -ListPath parameter.
NOTE
If you have not installed Azure PowerShell, or have not configured it to use your Azure Subscription, see How to Use Azure
PowerShell.
Streaming with Azure Command-Line Interface

To stream logging information, open a new command prompt, PowerShell, Bash, or Terminal session and enter the
following command:
az webapp log tail --name webappname --resource-group myResourceGroup
This command connects to the web app named 'webappname' and begin streaming information to the window as
log events occur on the web app. Any information written to files ending in .txt, .log, or .htm that are stored in the
/LogFiles directory (d:/home/logfiles) is streamed to the local console.
To filter specific events, such as errors, use the --Filter parameter. For example:
az webapp log tail --name webappname --resource-group myResourceGroup --filter Error
To filter specific log types, such as HTTP, use the --Path parameter. For example:
az webapp log tail --name webappname --resource-group myResourceGroup --path http
NOTE
If you have not installed the Azure Command-Line Interface, or have not configured it to use your Azure Subscription, see
How to Use Azure Command-Line Interface.
How to: Understand diagnostics logs

Application diagnostics logs
Application diagnostics stores information in a specific format for .NET applications, depending on whether you
store logs to the file system, table storage, or blob storage. The base set of data stored is the same across all three
storage types - the date and time the event occurred, the process ID that produced the event, the event type
(information, warning, error), and the event message.
File system
Each line logged to the file system or received using streaming is in the following format:
{Date} PID[{process ID}] {event type/level} {message}
For example, an error event would appear similar to the following sample:
2014-01-30T16:36:59 PID[3096] Error Fatal error on the page!
Logging to the file system provides the most basic information of the three available methods, providing only the
time, process ID, event level, and message.
Table storage
When logging to table storage, additional properties are used to facilitate searching the data stored in the table as
well as more granular information on the event. The following properties (columns) are used for each entity (row)
stored in the table.
PROPERTY NAME VALUE/FORMAT
PartitionKey Date/time of the event in yyyyMMddHH format
RowKey A GUID value that uniquely identifies this entity
Timestamp The date and time that the event occurred
EventTickCount The date and time that the event occurred, in Tick format
(greater precision)
ApplicationName The web app name
Level Event level (for example, error, warning, information)
EventId The event ID of this event

Defaults to 0 if none specified
InstanceId Instance of the web app that the even occurred on
Pid Process ID
Tid The thread ID of the thread that produced the event
Message Event detail message
Blob storage
When logging to blob storage, data is stored in comma-separated values (CSV) format. Similar to table storage,
additional fields are logged to provide more granular information about the event. The following properties are
used for each row in the CSV:
Date The date and time that the event occurred
Level Event level (for example, error, warning, information)
ApplicationName The web app name
InstanceId Instance of the web app that the event occurred on
EventTickCount The date and time that the event occurred, in Tick format
(greater precision)
EventId The event ID of this event

Defaults to 0 if none specified
Pid Process ID
Tid The thread ID of the thread that produced the event
Message Event detail message
The data stored in a blob would look similar to the following example:
date,level,applicationName,instanceId,eventTickCount,eventId,pid,tid,message
2014-01-30T16:36:52,Error,mywebapp,6ee38a,635266966128818593,0,3096,9,An error occurred
NOTE
The first line of the log contains the column headers as represented in this example.
Failed request traces

Failed request traces are stored in XML files named fr######.xml. To make it easier to view the logged
information, an XSL stylesheet named freb.xsl is provided in the same directory as the XML files. If you open one
of the XML files in Internet Explorer, Internet Explorer uses the XSL stylesheet to provide a formatted display of the
trace information, similar to the following example:
Detailed error logs

Detailed error logs are HTML documents that provide more detailed information on HTTP errors that have
occurred. Since they are simply HTML documents, they can be viewed using a web browser.
Web server logs
The web server logs are formatted using the W3C extended log file format. This information can be read using a
text editor or parsed using utilities such as Log Parser.
NOTE
The logs produced by Azure web apps do not support the s-computername, s-ip, or cs-version fields.
Next steps
How to Monitor Web Apps
Troubleshooting Azure web apps in Visual Studio
Analyze web app Logs in HDInsight
NOTE
Back up your app in Azure
The Backup and Restore feature in Azure App Service lets you easily create app backups manually or on a schedule.
You can restore the app to a snapshot of a previous state by overwriting the existing app or restoring to another
app.
For information on restoring an app from backup, see Restore an app in Azure.
What gets backed up

App Service can back up the following information to an Azure storage account and container that you have
configured your app to use.
App configuration
File content
Database connected to your app
The following database solutions are supported with backup feature:
SQL Database
Azure Database for MySQL (Preview)
Azure Database for PostgreSQL (Preview)
MySQL in-app
NOTE
Each backup is a complete offline copy of your app, not an incremental update.
Requirements and restrictions

The Backup and Restore feature requires the App Service plan to be in the Standard tier or Premium tier. For
more information about scaling your App Service plan to use a higher tier, see Scale up an app in Azure.
Premium tier allows a greater number of daily back ups than Standard tier.
You need an Azure storage account and container in the same subscription as the app that you want to back up.
For more information on Azure storage accounts, see the links at the end of this article.
Backups can be up to 10 GB of app and database content. If the backup size exceeds this limit, you get an error.
Create a manual backup

1. In the Azure portal, navigate to your app's page, select Backups. The Backups page is displayed.
NOTE
If you see the following message, click it to upgrade your App Service plan before you can proceed with backups. For
more information, see Scale up an app in Azure.
2. In the Backup page, Click Configure
3. In the Backup Configuration page, click Storage: Not configured to configure a storage account.
4. Choose your backup destination by selecting a Storage Account and Container. The storage account must
belong to the same subscription as the app you want to back up. If you wish, you can create a new storage
account or a new container in the respective pages. When you're done, click Select.
5. In the Backup Configuration page that is still left open, you can configure Backup Database, then select
the databases you want to include in the backups (SQL database or MySQL), then click OK.
NOTE
For a database to appear in this list, its connection string must exist in the Connection strings section of the
Application settings page for your app.
6. In the Backup Configuration page, click Save.

7. In the Backups page, click Backup.
You see a progress message during the backup process.
Once the storage account and container is configured, you can initiate a manual backup at any time.
Configure automated backups

1. In the Backup Configuration page, set Scheduled backup to On.
2. Backup schedule options will show up, set Scheduled Backup to On, then configure the backup schedule
as desired and click OK.
Configure Partial Backups

Sometimes you don't want to back up everything on your app. Here are a few examples:
You set up weekly backups of your app that contains static content that never changes, such as old blog posts
or images.
Your app has over 10 GB of content (that's the max amount you can back up at a time).
You don't want to back up the log files.
Partial backups allow you choose exactly which files you want to back up.
Exclude files from your backup
Suppose you have an app that contains log files and static images that have been backup once and are not going
to change. In such cases, you can exclude those folders and files from being stored in your future backups. To
exclude files and folders from your backups, create a _backup.filter file in the D:\home\site\wwwroot folder of
your app. Specify the list of files and folders you want to exclude in this file.
An easy way to access your files is to use Kudu. Click Advanced Tools -> Go setting for your web app to access
Kudu.
Identify the folders that you want to exclude from your backups. For example, you want to filter out the highlighted
folder and files.
Create a file called _backup.filter and put the preceding list in the file, but remove D:\home . List one directory or
file per line. So the content of the file should be:
\site\wwwroot\Images\brand.png
\site\wwwroot\Images\2014
\site\wwwroot\Images\2013
Upload _backup.filter file to the D:\home\site\wwwroot\ directory of your site using ftp or any other method. If
you wish, you can create the file directly using Kudu DebugConsole and insert the content there.
Run backups the same way you would normally do it, manually or automatically. Now, any files and folders that
are specified in _backup.filter is excluded from the future backups scheduled or manually initiated.
NOTE
You restore partial backups of your site the same way you would restore a regular backup. The restore process does the
right thing.
When a full backup is restored, all content on the site is replaced with whatever is in the backup. If a file is on the site, but
not in the backup it gets deleted. But when a partial backup is restored, any content that is located in one of the blacklisted
directories, or any blacklisted file, is left as is.
How backups are stored

After you have made one or more backups for your app, the backups are visible on the Containers page of your
storage account, and your app. In the storage account, each backup consists of a .zip file that contains the backup
data and an .xml file that contains a manifest of the .zip file contents. You can unzip and browse these files if
you want to access your backups without actually performing an app restore.
The database backup for the app is stored in the root of the .zip file. For a SQL database, this is a BACPAC file (no
file extension) and can be imported. To create a SQL database based on the BACPAC export, see Import a BACPAC
File to Create a New User Database.
WARNING
Altering any of the files in your websitebackups container can cause the backup to become invalid and therefore non-
restorable.

You can automate backup management with scripts, using the Azure CLI or Azure PowerShell.
For samples, see:
Azure CLI samples
Azure PowerShell samples
Next Steps
For information on restoring an app from a backup, see Restore an app in Azure.
Restore an app in Azure
This article shows you how to restore an app in Azure App Service that you have previously backed up (see Back
up your app in Azure). You can restore your app with its linked databases on-demand to a previous state, or create
a new app based on one of your original app's backups. Azure App Service supports the following databases for
backup and restore:
SQL Database
Azure Database for MySQL (Preview)
Azure Database for PostgreSQL (Preview)
MySQL in-app
Restoring from backups is available to apps running in Standard and Premium tier. For information about
scaling up your app, see Scale up an app in Azure. Premium tier allows a greater number of daily backups to be
performed than Standard tier.
Restore an app from an existing backup

1. On the Settings page of your app in the Azure portal, click Backups to display the Backups page. Then
click Restore.
2. In the Restore page, first select the backup source.
The App backup option shows you all the existing backups of the current app, and you can easily select
one. The Storage option lets you select any backup ZIP file from any existing Azure Storage account and
container in your subscription. If you're trying to restore a backup of another app, use the Storage option.
3. Then, specify the destination for the app restore in Restore destination.
WARNING
If you choose Overwrite, all existing data in your current app is erased and overwritten. Before you click OK, make
sure that it is exactly what you want to do.
You can select Existing App to restore the app backup to another app in the same resoure group. Before
you use this option, you should have already created another app in your resource group with mirroring
database configuration to the one defined in the app backup. You can also Create a New app to restore
your content to.
4. Click OK.
Download or delete a backup from a storage account

1. From the main Browse page of the Azure portal, select Storage accounts. A list of your existing storage
accounts is displayed.
2. Select the storage account that contains the backup that you want to download or delete. The page for the
storage account is displayed.
3. In the storage account page, select the container you want
4. Select backup file you want to download or delete.
5. Click Download or Delete depending on what you want to do.
Monitor a restore operation

To see details about the success or failure of the app restore operation, navigate to the Activity Log page in the
Azure portal.
Scroll down to find the desired restore operation and click to select it.
The details page displays the available information related to the restore operation.

You can automate backup management with scripts, using the Azure CLI or Azure PowerShell.
For samples, see:
Azure CLI samples
Azure PowerShell samples
Azure App Service App Cloning Using PowerShell
With the release of Microsoft Azure PowerShell version 1.1.0 a new option has been added to New-
AzureRMWebApp that would give the user the ability to clone an existing Web App to a newly created app in a
different region or in the same region. This will enable customers to deploy a number of apps across different
regions quickly and easily.
App cloning is currently only supported for premium tier app service plans. The new feature uses the same
limitations as Web Apps Backup feature, see Back up a web app in Azure App Service.
NOTE
Cloning an existing App

Scenario: An existing web app in South Central US region, the user would like to clone the contents to a new web
app in North Central US region. This can be accomplished by using the Azure Resource Manager version of the
PowerShell cmdlet to create a new web app with the -SourceWebApp option.
Knowing the resource group name that contains the source web app, we can use the following PowerShell
command to get the source web app's information (in this case named source-webapp):
$srcapp = Get-AzureRmWebApp -ResourceGroupName SourceAzureResourceGroup -Name source-webapp
To create a new App Service Plan, we can use New-AzureRmAppServicePlan command as in the following example
New-AzureRmAppServicePlan -Location "South Central US" -ResourceGroupName DestinationAzureResourceGroup -Name

NewAppServicePlan -Tier Premium
Using the New-AzureRmWebApp command, we can create the new web app in the North Central US region, and
tie it to an existing premium tier App Service Plan, moreover we can use the same resource group as the source
web app, or define a new resource group, the following demonstrates that:
$destapp = New-AzureRmWebApp -ResourceGroupName DestinationAzureResourceGroup -Name dest-webapp -Location

"North Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp
To clone an existing web app including all associated deployment slots, the user will need to use the
IncludeSourceWebAppSlots parameter, the following PowerShell command demonstrates the use of that
parameter with the New-AzureRmWebApp command:

"North Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -IncludeSourceWebAppSlots
To clone an existing web app within the same region, the user will need to create a new resource group and a new
app service plan in the same region, and then using the following PowerShell command to clone the web app
$destapp = New-AzureRmWebApp -ResourceGroupName NewAzureResourceGroup -Name dest-webapp -Location "South
Central US" -AppServicePlan NewAppServicePlan -SourceWebApp $srcap
Cloning an existing App to an App Service Environment

Scenario: An existing web app in South Central US region, the user would like to clone the contents to a new web
app to an existing App Service Environment (ASE).
command to get the source web app's information (in this case named source-webapp):
$srcapp = Get-AzureRmWebApp -ResourceGroupName SourceAzureResourceGroup -Name source-webapp
Knowing the ASE's name, and the resource group name that the ASE belongs to, the user can use the New-
AzureRmWebApp command to create the new web app in the existing ASE, the following demonstrates that:

"North Central US" -AppServicePlan DestinationAppServicePlan -ASEName DestinationASE -ASEResourceGroupName
DestinationASEResourceGroupName -SourceWebApp $srcapp
The Location parameter is required due to legacy reason, but in the case of creating an app in an ASE it will be
ignored.
Cloning an existing App Slot

Scenario: The user would like to clone an existing Web App Slot to either a new Web App or a new Web App slot.
The new Web App can be in the same region as the original Web App slot or in a different region.
command to get the source web app slot's information (in this case named source-webappslot) tied to Web App
source-webapp:
$srcappslot = Get-AzureRmWebAppSlot -ResourceGroupName SourceAzureResourceGroup -Name source-webapp -Slot

source-webappslot
The following demonstrates creating a clone of the source web app to a new web app:

"North Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcappslot
Configuring Traffic Manager while cloning a App

Creating multi-region web apps and configuring Azure Traffic Manager to route traffic to all these web apps, is a n
important scenario to insure that customers' apps are highly available, when cloning an existing web app you have
the option to connect both web apps to either a new traffic manager profile or an existing one - note that only
Azure Resource Manager version of Traffic Manager is supported.
Creating a new Traffic Manager profile while cloning a App
Scenario: The user would like to clone an web app to another region, while configuring an Azure Resource
Manager traffic manager profile that include both web apps. The following demonstrates creating a clone of the
source web app to a new web app while configuring a new Traffic Manager profile:
"South Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -TrafficManagerProfileName
newTrafficManagerProfile
Adding new cloned Web App to an existing Traffic Manager profile

Scenario: The user already have an Azure Resource Manager traffic manager profile that he would like to add both
web apps as endpoints. To do so, we first need to assemble the existing traffic manager profile id, we will need the
subscription id, resource group name and the existing traffic manager profile name.
$TMProfileID = "/subscriptions/<Your subscription ID goes here>/resourceGroups/<Your resource group name goes

here>/providers/Microsoft.TrafficManagerProfiles/ExistingTrafficManagerProfileName"
After having the traffic manger id, the following demonstrates creating a clone of the source web app to a new web
app while adding them to an existing Traffic Manager profile:
$destapp = New-AzureRmWebApp -ResourceGroupName <Resource group name> -Name dest-webapp -Location "South
Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -TrafficManagerProfileId
$TMProfileID
Current Restrictions
This feature is currently in preview, we are working to add new capabilities over time, the following list are the
known restrictions on the current version of app cloning:
Auto scale settings are not cloned
Backup schedule settings are not cloned
VNET settings are not cloned
App Insights are not automatically set up on the destination web app
Easy Auth settings are not cloned
Kudu Extension are not cloned
TiP rules are not cloned
Database content are not cloned
Outbound IP Addresses will change if cloning to a different scale unit
References
Web App Cloning
Back up a web app in Azure App Service
Azure Resource Manager support for Azure Traffic Manager Preview
Introduction to App Service Environment
Using Azure PowerShell with Azure Resource Manager
Move an Azure Web App to another resource group
You can move a Web App and/or its related resources to another resource group in the same subscription, or to a
resource group in a different subscription. This is done as part of standard resource management in Azure. For
more information, see Move Azure resources to new subscription or resource group.
Limitations when moving within the same subscription

When moving a Web App within the same subscription, you cannot move the uploaded SSL certificates. However,
you can move a Web App to the new resource group without moving its uploaded SSL certificate, and your app's
SSL functionality still works.
If you want to move the SSL certificate with the Web App, follow these steps:
1. Delete the uploaded certificate from the Web App.
2. Move the Web App.
3. Upload the certificate to the moved Web App.
Limitations when moving across subscriptions

When moving a Web App across subscriptions, the following limitations apply:
The destination resource group must not have any existing App Service resources. App Service resources
include:
Web Apps
App Service plans
Uploaded or imported SSL certificates
App Service Environments
All App Service resources in the resource group must be moved together.
App Service resources can only be moved from the resource group in which they were originally created. If an
App Service resource is no longer in its original resource group, it must be moved back to that original resource
group first, and then it can be moved across subscriptions.
Azure subscription and service limits, quotas, and
constraints
This document lists some of the most common Microsoft Azure limits, which are also sometimes called quotas. This
document doesn't currently cover all Azure services. Over time, the list will be expanded and updated to cover more
of the platform.
Please visit Azure Pricing Overview to learn more about Azure pricing. There, you can estimate your costs using the
Pricing Calculator or by visiting the pricing details page for a service (for example, Windows VMs). For tips to help
manage your costs, see Prevent unexpected costs with Azure billing and cost management.
NOTE
If you want to raise the limit or quota above the Default Limit, open an online customer support request at no charge. The
limits can't be raised above the Maximum Limit value shown in the following tables. If there is no Maximum Limit column,
then the resource doesn't have adjustable limits.
Free Trial subscriptions are not eligible for limit or quota increases. If you have a Free Trial subscription, you can upgrade to a
Pay-As-You-Go subscription. For more information, see Upgrade Azure Free Trial to Pay-As-You-Go and Free Trial
subscription FAQ.
Limits and the Azure Resource Manager

It is now possible to combine multiple Azure resources in to a single Azure Resource Group. When using Resource
Groups, limits that once were global become managed at a regional level with the Azure Resource Manager. For
more information about Azure Resource Groups, see Azure Resource Manager overview.
In the limits below, a new table has been added to reflect any differences in limits when using the Azure Resource
Manager. For example, there is a Subscription Limits table and a Subscription Limits - Azure Resource
Manager table. When a limit applies to both scenarios, it is only shown in the first table. Unless otherwise indicated,
limits are global across all regions.
NOTE
It is important to emphasize that quotas for resources in Azure Resource Groups are per-region accessible by your
subscription, and are not per-subscription, as the service management quotas are. Let's use vCPU quotas as an example. If
you need to request a quota increase with support for vCPUs, you need to decide how many vCPUs you want to use in which
regions, and then make a specific request for Azure Resource Group vCPU quotas for the amounts and regions that you
want. Therefore, if you need to use 30 vCPUs in West Europe to run your application there, you should specifically request 30
vCPUs in West Europe. But you will not have a vCPU quota increase in any other region -- only West Europe will have the
30-vCPU quota.
As a result, you may find it useful to consider deciding what your Azure Resource Group quotas need to be for your workload
in any one region, and request that amount in each region into which you are considering deployment. See troubleshooting
deployment issues for more help discovering your current quotas for specific regions.
Service-specific limits
Active Directory
API Management
App Service
Application Gateway
Application Insights
Automation
Azure Cosmos DB
Azure Event Grid
Azure Redis Cache
Backup
Batch
BizTalk Services
CDN
Cloud Services
Container Instances
Container Registry
Data Factory
Data Lake Analytics
Data Lake Store
Database Migration Service
DNS
Event Hubs
IoT Hub
IoT Hub Device Provisioning Service
Key Vault
Log Analytics / Operational Insights
Media Services
Mobile Engagement
Mobile Services
Monitor
Multi-Factor Authentication
Networking
Network Watcher
Notification Hub Service
Resource Group
Scheduler
Search
Service Bus
Site Recovery
SQL Database
SQL Data Warehouse
Storage
StorSimple System
Stream Analytics
Subscription
Traffic Manager
Virtual Machines
Virtual Machine Scale Sets
Subscription limits
Subscription limits
RESOURCE DEFAULT LIMIT MAXIMUM LIMIT
Cores per subscription 1 20 10,000
Co-administrators per subscription 200 200
Storage accounts per subscription2 200 250
Cloud services per subscription 20 200
Local networks per subscription 10 500
SQL Database servers per subscription 6 150
DNS servers per subscription 9 100
Reserved IPs per subscription 20 100
Hosted service certificates per 400 400

subscription
Affinity groups per subscription 256 256
1Extra Small instances count as one core towards the core limit despite using a partial core.
2This includes both Standard and Premium storage accounts. If you require more than 200 storage accounts, make
a request through Azure Support. The Azure Storage team will review your business case and may approve up to
250 storage accounts.
Subscription limits - Azure Resource Manager
The following limits apply when using the Azure Resource Manager and Azure Resource Groups. Limits that have
not changed with the Azure Resource Manager are not listed below. Please refer to the previous table for those
limits.
For information about handling limits on Resource Manager requests, see Throttling Resource Manager requests.
VMs per subscription 10,000 1 per Region 10,000 per Region
VM total cores per subscription 201 per Region Contact support
VM per series (Dv2, F, etc.) cores per 201 per Region Contact support
subscription
Co-administrators per subscription Unlimited Unlimited
Storage accounts per subscription 200 2002
Resource Groups per subscription 800 800

Availability Sets per subscription 2,000 per Region 2,000 per Region
Resource Manager API Reads 15,000 per hour 15,000 per hour
Resource Manager API Writes 1,200 per hour 1,200 per hour
Resource Manager API request size 4,194,304 bytes 4,194,304 bytes
Tags per subscription3 unlimited unlimited
Unique tag calculations per 10,000 10,000

subscription3
Cloud services per subscription Not Applicable4 Not Applicable4
Affinity groups per subscription Not Applicable4 Not Applicable4
1Default limits vary by offer Category Type, such as Free Trial, Pay-As-You-Go, and series, such as Dv2, F, G, etc.
2This includes both Standard and Premium storage accounts. If you require more than 200 storage accounts, make
a request through Azure Support. The Azure Storage team will review your business case and may approve up to
250 storage accounts.
3You can apply an unlimited number of tags per subscription. The number of tags per resource or resource group is
limited to 15. Resource Manager only returns a list of unique tag name and values in the subscription when the
number of tags is 10,000 or less. However, you can still find a resource by tag when the number exceeds 10,000.
4These features are no longer required with Azure Resource Groups and the Azure Resource Manager.
NOTE
It is important to emphasize that virtual machine cores have a regional total limit as well as a regional per size series (Dv2, F,
etc.) limit that are separately enforced. For example, consider a subscription with a US East total VM core limit of 30, an A
series core limit of 30, and a D series core limit of 30. This subscription would be allowed to deploy 30 A1 VMs, or 30 D1
VMs, or a combination of the two not to exceed a total of 30 cores (for example, 10 A1 VMs and 20 D1 VMs).
Resource Group limits

Resources per resource group (per 800 Varies per resource type
resource type)
Deployments per resource group in the 800 800

deployment history
Resources per deployment 800 800
Management Locks (per unique scope) 20 20
Number of Tags (per resource or 15 15

resource group)
Tag key length 512 512
Tag value length 256 256
Template limits
VALUE DEFAULT LIMIT MAXIMUM LIMIT
Parameters 256 256
Variables 256 256
Resources (including copy count) 800 800
Outputs 64 64
Template expression 24,576 chars 24,576 chars
Resources in exported templates 200 200
Template size 1 MB 1 MB
Parameter file size 64 KB 64 KB
You can exceed some template limits by using a nested template. For more information, see Using linked templates
when deploying Azure resources. To reduce the number of parameters, variables, or outputs, you can combine
several values into an object. For more information, see Objects as parameters.
If you reach the limit of 800 deployments per resource group, delete deployments from the history that are no
longer needed. You can delete entries from the history with az group deployment delete for Azure CLI, or Remove-
AzureRmResourceGroupDeployment in PowerShell. Deleting an entry from the deployment history does not affect
the deploy resources.
Virtual Machines limits
Virtual Machine limits
Virtual machines per cloud service1 50 50
Input endpoints per cloud service2 150 150
1Virtual machines created in Service Management (instead of Resource Manager) are automatically stored in a
cloud service. You can add more virtual machines to that cloud service for load balancing and availability. See How
to Connect Virtual Machines with a Virtual Network or Cloud Service.
2Input endpoints allow communications to a virtual machine from outside the virtual machine's cloud service.
Virtual machines in the same cloud service or virtual network can automatically communicate with each other. See
How to Set Up Endpoints to a Virtual Machine.
Virtual Machines limits - Azure Resource Manager
The following limits apply when using the Azure Resource Manager and Azure Resource Groups. Limits that have
not changed with the Azure Resource Manager are not listed below. Please refer to the previous table for those
limits.
RESOURCE DEFAULT LIMIT
Virtual machines per availability set 200
Certificates per subscription Unlimited1
1With Azure Resource Manager, certificates are stored in the Azure Key Vault. Although the number of certificates is
unlimited for a subscription, there is still a 1 MB limit of certificates per deployment (which consists of either a
single VM or an availability set).
Virtual Machine Scale Sets limits
Maximum number of VMs in a scale set 1000 1000
Maximum number of VMs based on a 300 300

custom VM image in a scale set
Maximum number of scale sets in a 2000 2000

region
Container Instances limits

Container groups per subscription 201
Number of containers per container group 60
Number of volumes per container group 20
Ports per IP 5
Container creates per hour 601
Container creates per 5 minutes 201
Container deletes per hour 1501
Container deletes per 5 minutes 501
Multiple containers per container group Linux only2
Azure Files volumes Linux only2
GitRepo volumes Linux only2
Secret volumes Linux only2
1 Create an Azure support request to request a limit increase.

2 Windows support for this feature is planned.
Container Registry limits
The following table details the features and limits of the Basic, Standard, and Premium service tiers.
RESOURCE BASIC STANDARD PREMIUM
Storage 10 GiB 100 GiB 500 GiB
ReadOps per minute1, 2 1k 300k 10,000k
WriteOps per minute1, 3 100 500 2k
Download bandwidth MBps1 30 60 100
Upload bandwidth MBps1 10 20 50
Webhooks 2 10 100
Geo-replication N/A N/A Supported (preview)
1 ReadOps, WriteOps, and Bandwidth are minimum estimates. ACR strives to improve performance as usage
requires.
2 docker pull translates to multiple read operations based on the number of layers in the image, plus the manifest
retrieval.
3 docker push translates to multiple write operations, based on the number of layers that must be pushed. A
docker push includes ReadOps to retrieve a manifest for an existing image.
Networking limits
ExpressRoute Limits
The following limits apply to ExpressRoute resources per subscription.
ExpressRoute circuits per subscription 10
ExpressRoute circuits per region per subscription for ARM 10
Maximum number of routes for Azure private peering with 4,000

ExpressRoute standard
Maximum number of routes for Azure private peering with 10,000

ExpressRoute premium add-on
Maximum number of routes for Azure public peering with 200

Maximum number of routes for Azure public peering with 200

Maximum number of routes for Azure Microsoft peering with 200

Maximum number of routes for Azure Microsoft peering with 200

Number of virtual network links allowed per ExpressRoute see table below
circuit
Number of Virtual Networks per ExpressRoute circuit
NUMBER OF VNET LINKS WITH PREMIUM

CIRCUIT SIZE NUMBER OF VNET LINKS FOR STANDARD ADD-ON
50 Mbps 10 20
100 Mbps 10 25
200 Mbps 10 25
500 Mbps 10 40
1 Gbps 10 50
2 Gbps 10 60
5 Gbps 10 75
10 Gbps 10 100
Networking limits
The following limits apply only for networking resources managed through the classic deployment model per
subscription.
Virtual networks 50 100
Local network sites 20 contact support
DNS Servers per virtual network 20 100
Private IP Addresses per virtual network 4096 4096
Concurrent TCP or UDP flows per NIC 500K 500K

of a virtual machine or role instance
Network Security Groups (NSG) 100 200
NSG rules per NSG 200 400
User defined route tables 100 200
User defined routes per route table 100 400
Public IP addresses (dynamic) 5 contact support
Reserved public IP addresses 20 contact support

Public VIP per deployment 5 contact support
Private VIP (ILB) per deployment 1 1
Endpoint Access Control Lists (ACLs) 50 50
Networking Limits - Azure Resource Manager

The following limits apply only for networking resources managed through Azure Resource Manager per region
per subscription.
Virtual networks 50 1000
Subnets per virtual network 1000 10000
Virtual network peerings per Virtual 10 50

Network
DNS Servers per virtual network 9 25
Private IP Addresses per virtual network 4096 8192
Private IP Addresses per network 256 1024

interface
Concurrent TCP or UDP flows per NIC 500K 500K

of a virtual machine or role instance
Network Interfaces (NIC) 350 20000
Network Security Groups (NSG) 100 5000
NSG rules per NSG 200 500
IP addresses and ranges specified for 2000 4000

source or destination in a security
group
Application security groups 200 500
Application security groups per IP 10 20

configuration, per NIC
IP configurations per application 1000 4000

security group
Application security groups that can be 50 100

specified within all security rules of a
network security group
User defined route tables 100 200

User defined routes per route table 100 400
Public IP addresses - dynamic (Basic) 60 contact support
Public IP addresses - static (Basic) 20 contact support
Public IP addresses - static (Standard) 20 contact support
Point-to-Site Root Certificates per VPN 20 20

Gateway
Load Balancer limits
Load Balancers 100 1000
Rules per resource, Basic 150 250
Rules per resource, Standard 1250 1500
Rules per IP configuration 299 299
Frontend IP configurations, Basic 10 contact support
Frontend IP configurations, Standard 10 600
Backend pool, Basic 100, single Availability Set -
Backend pool, Standard 1000, single VNet contact support
HA Ports, Standard 1 per internal frontend -
Contact support in case you need to increase limits from default.

Application Gateway limits
RESOURCE DEFAULT LIMIT NOTE
Application Gateway 50 per subscription Maximum 100
Frontend IP Configurations 2 1 public and 1 private
Frontend Ports 20
Backend Address Pools 20
Backend Servers per pool 100
HTTP Listeners 20
HTTP load balancing rules 200 # of HTTP Listeners * n, n=10 Default

Backend HTTP settings 20 1 per Backend Address Pool
Instances per gateway 10 For more instances, open support ticket
SSL certificates 20 1 per HTTP Listeners
Authentication certificates 5 Maximum 10
Request time out min 1 second
Request time out max 24 hrs
Number of sites 20 1 per HTTP Listeners
URL Maps per listener 1
Maximum file upload size Standard 2 GB
Maximum file upload size WAF 100 MB
Network Watcher limits
Network Watcher 1 per region
Packet Capture sessions 10 per region # of sessions only, not saved captures
Traffic Manager limits
Profiles per subscription 100 1
Endpoints per profile 200
1Contact support in case you need to increase these limits.
DNS limits
Zones per subscription 100 1
Record sets per zone 5000 1
Records per record set 20
1 Contact Azure Support in case you need to increase these limits.
Storage limits
For additional details on storage account limits, see Azure Storage Scalability and Performance Targets.
Number of storage accounts per subscription 2001
Max storage account capacity 500 TiB2
Max number of blob containers, blobs, file shares, tables, No limit

queues, entities, or messages per storage account
Maximum request rate per storage account 20,000 requests per second2
Max ingress3 per storage account (US Regions) 10 Gbps if GRS/ZRS4 enabled, 20 Gbps for LRS2
Max egress3 per storage account (US Regions) 20 Gbps if RA-GRS/GRS/ZRS4 enabled, 30 Gbps for LRS2
Max ingress3 per storage account (Non-US regions) 5 Gbps if GRS/ZRS4 enabled, 10 Gbps for LRS2
Max egress3 per storage account (Non-US regions) 10 Gbps if RA-GRS/GRS/ZRS4 enabled, 15 Gbps for LRS2
1Includes both Standard and Premium storage accounts. If you require more than 200 storage accounts, make a
request through Azure Support. The Azure Storage team will review your business case and may approve up to 250
storage accounts.
2 To get your standard storage accounts to grow past the advertised limits in capacity, ingress/egress and request
rate, please make a request through Azure Support. The Azure Storage team will review the request and may
approve higher limits on a case by case basis.
3 Capped only by the account's ingress/egress limits. Ingress refers to all data (requests) being sent to a storage
account. Egress refers to all data (responses) being received from a storage account.
4Azure Storage redundancy options include:
RA-GRS: Read-access geo-redundant storage. If RA-GRS is enabled, egress targets for the secondary location are
identical to those for the primary location.
GRS: Geo-redundant storage.
ZRS: Zone-redundant storage. Available only for block blobs.
LRS: Locally redundant storage.
The following limits apply when performing management operations using the Azure Resource Manager only.
Storage account management operations (read) 800 per 5 minutes
Storage account management operations (write) 200 per hour
Storage account management operations (list) 100 per 5 minutes
Azure Blob storage limits
RESOURCE TARGET
Max size of single blob container 500 TiB

RESOURCE TARGET
Max number of blocks in a block blob or append blob 50,000 blocks
Max size of a block in a block blob 100 MiB
Max size of a block blob 50,000 X 100 MiB (approx. 4.75 TiB)
Max size of a block in an append blob 4 MiB
Max size of an append blob 50,000 x 4 MiB (approx. 195 GiB)
Max size of a page blob 8 TiB
Max number of stored access policies per blob container 5
Target throughput for single blob Up to 60 MiB per second, or up to 500 requests per second
Azure Files limits

For additional details on Azure Files limits, see Azure Files scalability and performance targets.
RESOURCE TARGET
Max size of a file share 5 TiB
Max size of a file in a file share 1 TiB
Max number of files in a file share No limit
Max IOPS per share 1000 IOPS
Max number of stored access policies per file share 5
Maximum request rate per storage account 20,000 requests per second for files of any valid size3
Target throughput for single file share Up to 60 MiB per second
Maximum open handles for per file 2000 open handles
Maximum number of share snapshots 200 share snapshots
Azure File Sync limits
RESOURCE TARGET HARD LIMIT
Storage Sync Services per subscription 15 Storage Sync Services No
Sync groups per Storage Sync Service 30 sync groups Yes
Cloud endpoints per Sync Group 1 cloud endpoint Yes
Server endpoints per Sync Group 50 server endpoints No

RESOURCE TARGET HARD LIMIT
Server endpoints per server 33-99 server endpoints Yes, but varies based on configuration
Endpoint size 4 TiB No
File system objects (directories and files) 6 million objects No

per sync group
File size 100 GiB No
Minimum file size for a file to be tiered 64 KiB Yes
Azure Queue storage limits
RESOURCE TARGET
Max size of single queue 500 TiB
Max size of a message in a queue 64 KiB
Max number of stored access policies per queue 5
Maximum request rate per storage account 20,000 messages per second assuming 1 KiB message size
Target throughput for single queue (1 KiB messages) Up to 2000 messages per second
Azure Table storage limits
RESOURCE TARGET
Max size of single table 500 TiB
Max size of a table entity 1 MiB
Max number of properties in a table entity 252
Max number of stored access policies per table 5
Maximum request rate per storage account 20,000 transactions per second (assuming 1 KiB entity size)
Target throughput for single table partition (1 KiB entities) Up to 2000 entities per second
Virtual machine disk limits

An Azure virtual machine supports attaching a number of data disks. This article describes scalability and
performance targets for a VM's data disks. Use these targets to help decide the number and type of disk that you
need to meet your performance and capacity requirements.
IMPORTANT
For optimal performance, limit the number of highly utilized disks attached to the virtual machine to avoid possible throttling.
If all attached disks are not highly utilized at the same time, then the virtual machine can support a larger number of disks.
For Azure Managed Disks: The disk limit for managed disks is per region and per disk type. The maximum
limit, and also the default limit, is 10,000 managed disks per region and per disk type for a subscription. For
example, you can create up to 10,000 standard managed disks and also 10,000 premium managed disks in a
region, per subscription.
Managed snapshots and images count against the managed disks limit.
For standard storage accounts: A standard storage account has a maximum total request rate of 20,000
IOPS. The total IOPS across all of your virtual machine disks in a standard storage account should not exceed
this limit.
You can roughly calculate the number of highly utilized disks supported by a single standard storage account
based on the request rate limit. For example, for a Basic Tier VM, the maximum number of highly utilized
disks is about 66 (20,000/300 IOPS per disk), and for a Standard Tier VM, it is about 40 (20,000/500 IOPS
per disk).
For premium storage accounts: A premium storage account has a maximum total throughput rate of 50
Gbps. The total throughput across all of your VM disks should not exceed this limit.
See Virtual machine sizes for additional details.
Managed virtual machine disks
Standard managed virtual machine disks
STANDARD
DISK TYPE S4 S6 S10 S20 S30 S40 S50
Disk size 32 GB 64 GB 128 GB 512 GB 1024 GB (1 2048 GB 4095 GB (4

TB) (2TB) TB)
IOPS per 500 500 500 500 500 500 500

disk
Throughput 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec 60 MB/sec

per disk
Premium managed virtual machine disks: per disk limits
PREMIUM
DISKS TYPE P4 P6 P10 P20 P30 P40 P50
Disk size 32 GB 64 GB 128 GB 512 GB 1024 GB (1 2048 GB (2 4095 GB (4

TB) TB) TB)
IOPS per 120 240 500 2300 5000 7500 7500

disk
Throughput 25 MB/sec 50 MB/sec 100 MB/sec 150 MB/sec 200 MB/sec 250 MB/sec 250 MB/sec
per disk
Premium managed virtual machine disks: per VM limits
Max IOPS Per VM 80,000 IOPS with GS5 VM
Max throughput per VM 2,000 MB/s with GS5 VM
Unmanaged virtual machine disks

Standard unmanaged virtual machine disks: per disk limits
VM TIER BASIC TIER VM STANDARD TIER VM
Disk size 4095 GB 4095 GB
Max 8 KB IOPS per persistent disk 300 500
Max number of disks performing max 66 40

IOPS
Premium unmanaged virtual machine disks: per account limits
Total disk capacity per account 35 TB
Total snapshot capacity per account 10 TB
Max bandwidth per account (ingress + egress1 ) <=50 Gbps
1Ingress refers to all data (requests) being sent to a storage account. Egress refers to all data (responses) being
received from a storage account.

Premium unmanaged virtual machine disks: per disk limits
PREMIUM
STORAGE DISK
TYPE P10 P20 P30 P40 P50
Disk size 128 GiB 512 GiB 1024 GiB (1 TB) 2048 GiB (2 TB) 4095 GiB (4 TB)
Max IOPS per 500 2300 5000 7500 7500

disk
Max throughput 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
per disk
Max number of 280 70 35 17 8

disks per storage
account
Premium unmanaged virtual machine disks: per VM limits
Max IOPS Per VM 80,000 IOPS with GS5 VM
Max throughput per VM 2,000 MB/s with GS5 VM
Cloud Services limits

Web/worker roles per deployment1 25 25

Instance Input Endpoints per 25 25

deployment
Input Endpoints per deployment 25 25
Internal Endpoints per deployment 25 25
1Each Cloud Service with Web/Worker roles can have two deployments, one for production and one for staging.
Also note that this limit refers to the number of distinct roles (configuration) and not the number of instances per
role (scaling).
App Service limits
The following App Service limits include limits for Web Apps, Mobile Apps, API Apps, and Logic Apps.
PREMIUM
RESOURCE FREE SHARED (PREVIEW) BASIC STANDARD (PREVIEW)
Web, mobile, or 10 100 Unlimited2 Unlimited2 Unlimited2

API apps per App
Service plan1
Logic apps per 10 10 10 20 per core 20 per core

App Service plan1
App Service plan 1 per region 10 per resource 100 per resource 100 per resource 100 per resource
group group group group
Compute Shared Shared Dedicated3 Dedicated3 Dedicated3

instance type
Scale-Out (max 1 shared 1 shared 3 dedicated3 10 dedicated3 20 dedicated (50

instances) in ASE)3,4
Storage5 1 GB5 1 GB5 10 GB5 50 GB5 500 GB4,5
CPU time (5 3 minutes 3 minutes Unlimited, pay at Unlimited, pay at Unlimited, pay at
min)6 standard rates standard rates standard rates
CPU time (day)6 60 minutes 240 minutes Unlimited, pay at Unlimited, pay at Unlimited, pay at
standard rates standard rates standard rates
Memory (1 hour) 1024 MB per 1024 MB per app N/A N/A N/A
App Service plan
Bandwidth 165 MB Unlimited, data Unlimited, data Unlimited, data Unlimited, data
transfer rates transfer rates transfer rates transfer rates
apply apply apply apply
Application 32-bit 32-bit 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit

architecture
Web Sockets per 5 35 350 Unlimited Unlimited

instance7
PREMIUM
RESOURCE FREE SHARED (PREVIEW) BASIC STANDARD (PREVIEW)
Concurrent 1 1 1 5 5
debugger
connections per
application
azurewebsites.net X X X X X
subdomain with
FTP/S and SSL
Custom domain X X X X
support
Custom domain Unlimited SNI SSL Unlimited SNI SSL Unlimited SNI SSL
SSL support connections and 1 IP SSL and 1 IP SSL
connections connections
included included
Integrated Load X X X X
Balancer
Always On X X X
Scheduled Scheduled Scheduled

Backups backups every 2 backups every
hours, a max of hour, a max of 50
12 backups per backups per day
day (manual + (manual +
scheduled) scheduled)
Auto Scale X X
WebJobs8 X X X X X
Azure Scheduler X X X X
support
Endpoint X X X
monitoring
Staging Slots 5 20
Custom domains 500 500 500 500

per app
SLA 99.9% 99.95%10 99.95%9
1Apps and storage quotas are per App Service plan unless noted otherwise.
2The actual number of apps that you can host on these machines depends on the activity of the apps, the size of the
machine instances, and the corresponding resource utilization.
3Dedicated instances can be of different sizes. See App Service Pricing for more details.
4Premium tier allows up to 50 computes instances (subject to availability) and 500 GB of disk space when using
App Service Environments, and 20 compute instances and 250 GB storage otherwise.
5The storage limit is the total content size across all apps in the same App Service plan. More storage options are
available in App Service Environment
6These resources are constrained by physical resources on the dedicated instances (the instance size and the
number of instances).
7If you scale an app in the Basic tier to two instances, you have 350 concurrent connections for each of the two
instances.
8Run custom executables and/or scripts on demand, on a schedule, or continuously as a background task within
your App Service instance. Always On is required for continuous WebJobs execution. Azure Scheduler Free or
Standard is required for scheduled WebJobs. There is no predefined limit on the number of WebJobs that can run in
an App Service instance, but there are practical limits that depend on what the application code is trying to do.
9SLA of 99.95% provided for deployments that use multiple instances with Azure Traffic Manager configured for
failover.
Scheduler limits
The following table describes each of the major quotas, limits, defaults, and throttles in Azure Scheduler.
RESOURCE LIMIT DESCRIPTION
Job size Maximum job size is 16K. If a PUT or a PATCH results in a job
larger than these limits, a 400 Bad Request status code is
returned.
Request URL size Maximum size of the request URL is 2048 chars.
Aggregate header size Maximum aggregate header size is 4096 chars.
Header count Maximum header count is 50 headers.
Body size Maximum body size is 8192 chars.
Recurrence span Maximum recurrence span is 18 months.
Time to start time Maximum “time to start time” is 18 months.
Job history Maximum response body stored in job history is 2048 bytes.
Frequency The default max frequency quota is 1 hour in a free job

collection and 1 minute in a standard job collection. The max
frequency is configurable on a job collection to be lower than
the maximum. All jobs in the job collection are limited the
value set on the job collection. If you attempt to create a job
with a higher frequency than the maximum frequency on the
job collection then request will fail with a 409 Conflict status
code.
Jobs The default max jobs quota is 5 jobs in a free job collection and
50 jobs in a standard job collection. The maximum number of
jobs is configurable on a job collection. All jobs in the job
collection are limited the value set on the job collection. If you
attempt to create more jobs than the maximum jobs quota,
then the request fails with a 409 Conflict status code.
Job collections Maximum number of job collection per subscription is

200,000.
RESOURCE LIMIT DESCRIPTION
Job history retention Job history is retained for up to 2 months or up to the last
1000 executions.
Completed and faulted job retention Completed and faulted jobs are retained for 60 days.
Timeout There’s a static (not configurable) request timeout of 60

seconds for HTTP actions. For longer running operations,
follow HTTP asynchronous protocols; for example, return a 202
immediately but continue working in the background.
Batch limits
Batch accounts per region per 3 50

subscription
Dedicated cores per Batch account 20 N/A1
Low-priority cores per Batch account 20 N/A2
Active jobs and job schedules3 per 20 50004

Batch account
Pools per Batch account 20 2500
1 The number of dedicated cores per Batch account can be increased, but the maximum number is unspecified.
Contact Azure support to discuss increase options.
2 The number of low-priority cores per Batch account can be increased, but the maximum number is unspecified.
Contact Azure support to discuss increase options.
3 Completed jobs and job schedules are not limited.
4 Contact Azure support if you want to request an increase beyond this limit.
BizTalk Services limits

The following table shows the limits for Azure Biztalk Services.
RESOURCE FREE (PREVIEW) DEVELOPER BASIC STANDARD PREMIUM
Scale out N/A N/A Yes, in Yes, in increments Yes, in increments

increments of 1 of 1 Standard of 1 Premium
Basic Unit Unit Unit
Scale Limit N/A N/A Up to 8 units Up to 8 units Up to 8 units
EAI Bridges per N/A 25 25 125 500

Unit
EDI Agreements N/A 10 50 250 1000

per Unit
RESOURCE FREE (PREVIEW) DEVELOPER BASIC STANDARD PREMIUM
Hybrid 5 5 10 50 100
Connections per
Unit
Hybrid 5 5 50 250 500

Connection Data
Transfer (GBs) per
Unit
Number of N/A 1 2 5 25
connections
using BizTalk
Adapter Service
per Unit
Archiving N/A Available N/A N/A Available
High Availability N/A N/A Available Available Available
Azure Cosmos DB limits

Azure Cosmos DB is a global scale database in which throughput and storage can be scaled to handle whatever
your application requires. If you have any questions about the scale Azure Cosmos DB provides, please send email
to [email protected].
Mobile Engagement limits
RESOURCE MAXIMUM LIMIT
App Collection Users 5 per App Collection
Average Data points 200 per Active User/Day
Average App-Info set 50 per Active User/Day
Average Messages pushed 20 per Active User/Day
Segments 100 per app
Criteria per segment 10
Active Push Campaigns 50 per app
Total Push Campaigns (includes Active & Completed) 1000 per app
Search limits
Pricing tiers determine the capacity and limits of your search service. Tiers include:
Free multi-tenant service, shared with other Azure subscribers, intended for evaluation and small development
projects.
Basic provides dedicated computing resources for production workloads at a smaller scale, with up to three
replicas for highly available query workloads.
Standard (S1, S2, S3, S3 High Density) is for larger production workloads. Multiple levels exist within the
standard tier so that you can choose a resource configuration that best matches your workload profile.
Limits per subscription
You can create multiple services within a subscription, each one provisioned at a specific tier, limited only by the
number of services allowed at each tier. For example, you could create up to 12 services at the Basic tier and
another 12 services at the S1 tier within the same subscription. For more information about tiers, see Choose a SKU
or tier for Azure Search.
Maximum service limits can be raised upon request. Contact Azure Support if you need more services within the
same subscription.
RESOURCE FREE BASIC S1 S2 S3 S3 HD 1
Maximum 1 12 12 6 6 6
services
Maximum N/A 3 3 SU 4 36 SU 36 SU 36 SU 36 SU
scale in SU 2
1 S3 HD does not support indexers at this time.

2 Search units (SU) are billing units, allocated as either
a replica or a partition. You need both resources for storage,
indexing, and query operations. To learn more about how search units are computed, plus a chart of valid
combinations that stay under the maximum limits, see Scale resource levels for query and index workloads.
3 Free is based on shared resources used by multiple subscribers. At this tier, there are no dedicated resources for
an individual subscriber. For this reason, maximum scale is marked as not applicable.
4 Basic has one fixed partition. At this tier, additional SUs are used for allocating more replicas for increased query
workloads.
Limits per search service
Storage is constrained by disk space or by a hard limit on the maximum number of indexes or documents,
whichever comes first.
RESOURCE FREE BASIC S1 S2 S3 S3 HD
Service Level No 1 Yes Yes Yes Yes Yes

Agreement
(SLA)
Storage per 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB

partition
Partitions per N/A 1 12 12 12 32

service
Partition size N/A 2 GB 25 GB 100 GB 200 GB 200 GB
Replicas N/A 3 12 12 12 12
Maximum 3 5 50 200 200 1000 per

indexes partition or
3000 per
service
RESOURCE FREE BASIC S1 S2 S3 S3 HD
Maximum 3 5 50 200 200 No indexer

indexers support
Maximum 3 5 50 200 200 No indexer

datasources support
Maximum 10,000 1 million 15 million per 60 million per 120 million 1 million per
documents partition or partition or per partition index or 200
180 million 720 million or 1.4 billion million per
per service per service per service partition
1 Free tier
and preview features do not come with service level agreements (SLAs). For all billable tiers, SLAs take
effect when you provision sufficient redundancy for your service. Two or more replicas are required for query (read)
SLA. Three or more replicas are required for query and indexing (read-write) SLA. The number of partitions is not an
SLA consideration.
2 S3 HD has a hard limit of 3 partitions, which is lower than the partition limit for S3. The lower partition limit is
imposed because the index count for S3 HD is substantially higher. Given that service limits exist for both
computing resources (storage and processing) and content (indexes and documents), the content limit is reached
first.
To learn more about limits on a more granular level, such as document size, queries per second, keys, requests, and
responses, see Service limits in Azure Search.
Media Services limits
NOTE
For resources that are not fixed, you may ask for the quotas to be raised, by opening a support ticket. Do not create
additional Azure Media Services accounts in an attempt to obtain higher limits.
Azure Media Services (AMS) accounts in a single subscription 25 (fixed)
Media Reserved Units (RUs) per AMS account 25 (S1, S2)

10 (S3) (1)
Jobs per AMS account 50,000(2)
Chained tasks per job 30 (fixed)
Assets per AMS account 1,000,000
Assets per task 50
Assets per job 100
Unique locators associated with an asset at one time 5(4)
Live channels per AMS account 5

Programs in stopped state per channel 50
Programs in running state per channel 3
Streaming endpoints in running state per AMS account 2
Streaming units per streaming endpoint 10
Storage accounts 1,000(5) (fixed)
Policies 1,000,000(6)
File size In some scenarios, there is a limit on the maximum file size
supported for processing in Media Services. 7
1 S3 RUs are not available in India West. If you change the type (for example, from S2 to S1,) the max RU limits are
reset.
2 This number includes queued, finished, active, and canceled jobs. It does not include deleted jobs. You can delete
the old jobs using IJob.Delete or the DELETE HTTP request.
As of April 1, 2017, any Job record in your account older than 90 days will be automatically deleted, along with its
associated Task records, even if the total number of records is below the maximum quota. If you need to archive the
job/task information, you can use the code described here.
3 When making a request to list Job entities, a maximum of 1,000 jobs is returned per request. If you need to keep
track of all submitted Jobs, you can use top/skip as described in OData system query options.
4 Locators are not designed for
managing per-user access control. To give different access rights to individual users,
use Digital Rights Management (DRM) solutions. For more information, see this section.
5 The storage accounts must be from the same Azure subscription.
6 There is a limit of 1,000,000
policies for different AMS policies (for example, for Locator policy or
ContentKeyAuthorizationPolicy).
NOTE
You should use the same policy ID if you are always using the same days / access permissions / etc. For information and an
example, see this section.
7If you are uploading content to an Asset in Azure Media Services to process it with one of the media processors in
the service (that is, encoders like Media Encoder Standard and Media Encoder Premium Workflow, or analysis
engines like Face Detector), then you should be aware of the constraints on the maximum file sizes supported.
The maximum size supported for a single blob is currently up to 5 TB in Azure Blob Storage. However, additional
limits apply in Azure Media Services based on the VM sizes that are used by the service. The following table shows
the limits on each of the Media Reserved Units (S1, S2, S3.) If your source file is larger than the limits defined in the
table, your encoding job will fail. If you are encoding 4K resolution sources of long duration, you are required to use
S3 Media Reserved Units to achieve the performance needed. If you have 4K content that is larger than 260 GB limit
on the S3 Media Reserved Units, contact us at [email protected] for potential mitigations to support your
scenario.
MEDIA RESERVED UNIT TYPE MAXIMUM INPUT SIZE (GB)
S1 325
S2 640
S3 260
CDN limits
CDN profiles 25 25
CDN endpoints per profile 10 25
Custom domains per endpoint 10 25
A CDN subscription can contain one or more CDN profiles and a CDN profile can contain one or more CDN
endpoints. You may wish to use multiple profiles to organize your CDN endpoints by internet domain, web
application, or some other criteria.
To request an update to your subscription's default limits, open a support ticket.
Mobile Services limits
TIER: FREE BASIC STANDARD
API Calls 500 K 1.5 M / unit 15 M / unit
Active Devices 500 Unlimited Unlimited
Scale N/A Up to 6 units Unlimited units
Push Notifications Notification Hubs Free Tier Notification Hubs Basic Tier Notification Hubs Standard
included, up to 1 M pushes included, up to 10 M pushes Tier included, up to 10 M
pushes
Real time messaging/ Limited 350 / mobile service Unlimited

Web Sockets
Offline synchronizations Limited Included Included
Scheduled jobs Limited Included Included
SQL Database (required) 20 MB included 20 MB included 20 MB included

Standard rates apply for
additional capacity
CPU capacity 60 minutes / day Unlimited Unlimited
Outbound data transfer 165 MB per day (daily Included Included

Rollover)
For additional details on these limits and for information on pricing, see Mobile Services Pricing.
Monitor limits
Autoscale Settings 100 per region per subscription same as default
Metric Alerts 100 active alert rules per subscription call support
Near-Real Time Alerts (Preview) 20 active alert rules per subscription same as default during preview
Notification Hub Service limits

TIER: FREE BASIC STANDARD
Included Pushes 1 Million 10 Million 10 Million
Active Devices 500 200,000 10 million
Tag quota per 60 60 60

installation/registration
For additional details on these limits and for information on pricing, see Notification Hubs Pricing.
Event Hubs limits
The following table lists quotas and limits specific to Azure Event Hubs. For information about Event Hubs pricing,
see Event Hubs pricing.
BEHAVIOR WHEN
LIMIT SCOPE TYPE EXCEEDED VALUE
Number of event Namespace Static Subsequent requests 10

hubs per namespace for creation of a new
event hub will be
rejected.
Number of partitions Entity Static - 32

per event hub
Number of consumer Entity Static - 20

groups per event hub
Number of AMQP Namespace Static Subsequent requests 5,000

connections per for additional
namespace connections will be
rejected and an
exception is received
by the calling code.
Maximum size of System-wide Static - 256 KB

Event Hubs event
Maximum size of an Entity Static - 50 characters

event hub name
BEHAVIOR WHEN
LIMIT SCOPE TYPE EXCEEDED VALUE
Number of non- Entity Static - 5

epoch receivers per
consumer group
Maximum retention Entity Static - 1-7 days

period of event data
Maximum throughput Namespace Static Exceeding the 20

units throughput unit limit
causes your data to
be throttled and
generates a
ServerBusyExceptio
n. You can request a
larger number of
throughput units for a
Standard tier by filing
a support request.
Additional throughput
units are available in
blocks of 20 on a
committed purchase
basis.
Number of Namespace Static Subsequent requests 12

authorization rules for authorization rule
per namespace creation will be
rejected.
Service Bus limits

The following table lists quota information specific to Service Bus messaging. For information about pricing and
other quotas for Service Bus, see the Service Bus Pricing overview.
BEHAVIOR WHEN
QUOTA NAME SCOPE TYPE EXCEEDED VALUE
Maximum number of Namespace Static Subsequent requests 100

basic / standard for additional basic /
namespaces per standard namespaces
Azure subscription will be rejected by the
portal.
Maximum number of Namespace Static Subsequent requests 10

premium namespaces for additional
per Azure premium namespaces
subscription will be rejected by the
portal.
Queue/topic size Entity Defined upon creation Incoming messages 1, 2, 3, 4 or 5 GB.

of the queue/topic. will be rejected and an
exception will be If partitioning is
received by the calling enabled, the
code. maximum queue/topic
size is 80 GB.
BEHAVIOR WHEN
Number of concurrent Namespace Static Subsequent requests NetMessaging: 1,000

connections on a for additional
namespace connections will be AMQP: 5,000
rejected and an
exception will be
received by the calling
code. REST operations
do not count towards
concurrent TCP
connections.
Number of concurrent Entity Static Subsequent receive 5,000

receive requests on a requests will be
queue/topic/subscripti rejected and an
on entity exception will be
code. This quota
applies to the
combined number of
concurrent receive
operations across all
subscriptions on a
topic.
Number of System-wide Static Subsequent requests 10,000

topics/queues per for creation of a new
service namespace topic or queue on the The total number of
service namespace will topics plus queues in
be rejected. As a a service namespace
result, if configured must be less than or
through the Azure equal to 10,000.
portal, an error This is not applicable
message will be to Premium as all
generated. If called entities are
from the partitioned.
management API, an
exception will be
code.
Number of System-wide Static Subsequent requests Basic and Standard

partitioned for creation of a new Tiers - 100
topics/queues per partitioned topic or Premium - 1,000 (per
service namespace queue on the service messaging unit)
namespace will be
rejected. As a result, if Each partitioned
configured through queue or topic counts
the Azure portal, an towards the quota of
error message will be 10,000 entities per
generated. If called namespace.
from the
management API, a
QuotaExceededExce
ption exception will
be received by the
calling code.
BEHAVIOR WHEN
Maximum size of any Entity Static - 260 characters

messaging entity
path: queue or topic
Maximum size of any Entity Static - 50 characters

messaging entity
name: namespace,
subscription, or
subscription rule
Message size for a System-wide Static Incoming messages Maximum message

queue/topic/subscripti that exceed these size: 256KB (Standard
on entity quotas will be rejected tier) / 1MB (Premium
and an exception will tier).
be received by the
calling code. Note Due to system
overhead, this limit is
usually slightly less.
Maximum header size:

64KB
Maximum number of
header properties in
property bag:
byte/int.MaxValue
Maximum size of
property in property
bag: No explicit limit.
Limited by maximum
header size.
Message property System-wide Static A Maximum message

size for a SerializationExcepti property size for each
queue/topic/subscripti on exception is property is 32K.
on entity generated. Cumulative size of all
properties cannot
exceed 64K. This
applies to the entire
header of the
BrokeredMessage,
which has both user
properties as well as
system properties
(such as
SequenceNumber,
Label, MessageId, and
so on).
BEHAVIOR WHEN
Number of System-wide Static Subsequent requests 2,000

subscriptions per for creating additional
topic subscriptions for the
topic will be rejected.
As a result, if
configured through
the portal, an error
message will be
shown. If called from
the management API
an exception will be
code.
Number of SQL filters System-wide Static Subsequent requests 2,000

per topic for creation of
additional filters on
the topic will be
rejected and an
exception will be
code.
Number of correlation System-wide Static Subsequent requests 100,000

filters per topic for creation of
additional filters on
the topic will be
rejected and an
exception will be
code.
Size of SQL System-wide Static Subsequent requests Maximum length of

filters/actions for creation of filter condition string:
additional filters will 1024 (1K).
be rejected and an
exception will be Maximum length of
received by the calling rule action string:
code. 1024 (1K).
Maximum number of
expressions per rule
action: 32.
Number of Entity, namespace Static Subsequent requests Maximum number of

SharedAccessAuthoriz for creation of rules: 12.
ationRule rules per additional rules will be
namespace, queue, or rejected and an Rules that are
topic exception will be configured on a
received by the calling Service Bus
code. namespace apply to
all queues and topics
in that namespace.
IoT Hub limits

The following table lists the limits associated with the different service tiers (S1, S2, S3, F1). For information about
the cost of each unit in each tier, see IoT Hub Pricing.
RESOURCE S1 STANDARD S2 STANDARD S3 STANDARD F1 FREE
Messages/day 400,000 6,000,000 300,000,000 8,000
Maximum units 200 200 10 1
NOTE
If you anticipate using more than 200 units with an S1 or S2 or 10 units with an S3 tier hub, contact Microsoft support.
The following table lists the limits that apply to IoT Hub resources:
RESOURCE LIMIT
Maximum paid IoT hubs per Azure subscription 10
Maximum free IoT hubs per Azure subscription 1
Maximum number of device identities 1000

returned in a single call
IoT Hub message maximum retention for device-to-cloud 7 days

messages
Maximum size of device-to-cloud message 256 KB
Maximum size of device-to-cloud batch 256 KB
Maximum messages in device-to-cloud batch 500
Maximum size of cloud-to-device message 64 KB
Maximum TTL for cloud-to-device messages 2 days
Maximum delivery count for cloud-to-device 100

messages
Maximum delivery count for feedback messages 100

in response to a cloud-to-device message
Maximum TTL for feedback messages in 2 days

response to a cloud-to-device message
Maximum size of device twin 8 KB

(tags, reported properties, and desired properties)
Maximum size of device twin string value 4 KB
Maximum depth of object in device twin 5
Maximum size of direct method payload 8 KB
Job history maximum retention 30 days

RESOURCE LIMIT
Maximum concurrent jobs 10 (for S3), 5 for (S2), 1 (for S1)
Maximum additional endpoints 10 (for S1, S2, S3)
Maximum message routing rules 100 (for S1, S2, S3)
NOTE
If you need more than 10 paid IoT hubs in an Azure subscription, contact Microsoft support.
NOTE
Currently, the maximum number of devices you can connect to a single IoT hub is 500,000. If you want to increase this limit,
contact Microsoft Support.
The IoT Hub service throttles requests when the following quotas are exceeded:
THROTTLE PER-HUB VALUE
Identity registry operations 83.33/sec/unit (5000/min/unit) (for S3)

(create, retrieve, list, update, delete), 1.67/sec/unit (100/min/unit) (for S1 and S2).
individual or bulk import/export
Device connections 6000/sec/unit (for S3), 120/sec/unit (for S2), 12/sec/unit (for
S1).
Minimum of 100/sec.
Device-to-cloud sends 6000/sec/unit (for S3), 120/sec/unit (for S2), 12/sec/unit (for
S1).
Minimum of 100/sec.
Cloud-to-device sends 83.33/sec/unit (5000/min/unit) (for S3), 1.67/sec/unit

(100/min/unit) (for S1 and S2).
Cloud-to-device receives 833.33/sec/unit (50000/min/unit) (for S3), 16.67/sec/unit

(1000/min/unit) (for S1 and S2).
File upload operations 83.33 file upload notifications/sec/unit (5000/min/unit) (for

S3), 1.67 file upload notifications/sec/unit (100/min/unit) (for
S1 and S2).
10000 SAS URIs can be out for an Azure Storage account at
one time.
10 SAS URIs/device can be out at one time.
Direct methods 3000/sec/unit (for S3), 60/sec/unit (for S2), 20/sec/unit (for S1)
Device twin reads 50/sec/unit (for S3), Maximum of 10/sec or 1/sec/unit (for S2),
10/sec (for S1)
Device twin updates 50/sec/unit (for S3), Maximum of 10/sec or 1/sec/unit (for S2),
10/sec (for S1)
THROTTLE PER-HUB VALUE
Jobs operations 83.33/sec/unit (5000/min/unit) (for S3), 1.67/sec/unit

(create, update, list, delete) (100/min/unit) (for S2), 1.67/sec/unit (100/min/unit) (for S1)
Jobs per-device operation throughput 50/sec/unit (for S3), Maximum of 10/sec or 1/sec/unit (for S2),
10/sec (for S1)
IoT Hub Device Provisioning Service limits

The following table lists the limits that apply to IoT Hub Device Provisioning Service resources:
RESOURCE LIMIT
Maximum Device Provisioning Services per Azure subscription 10
Maximum number of enrollments 10,000
Maximum number of registrations 10,000
Maximum number of enrollment groups 100
Maximum number of CAs 10
NOTE
These limits are for public preview. Once the service is generally available, you can contact Microsoft Support to increase the
number of instances in your subscription.
The Device Provisioning Service throttles requests when the following quotas are exceeded:
THROTTLE PER-SERVICE VALUE
Operations 100/min
Device registrations 100/min
Data Factory limits

Data factory is a multi-tenant service that has the following default limits in place to make sure customer
subscriptions are protected from each other's workloads. Many of the limits can be easily raised for your
subscription up to the maximum limit by contacting support.
Version 2
Data factories in an Azure subscription 50 Contact support
Pipelines within a data factory 2500 Contact support
Datasets within a data factory 2500 Contact support
Triggers within a data factory 2500 Contact support

Linked services within a data factory 2500 Contact support
Integration runtimes within a data 2500 Contact support

factory 4
Concurrent pipeline runs per pipeline 20 Contact support
Max activities per pipeline 20 30
Max parameters per pipeline 20 30
Bytes per object for pipeline objects 1 200 KB 200 KB
Bytes per object for dataset and linked 100 KB 2000 KB

service objects 1
Cloud data movement units 3 32 Contact support
Retry count for pipeline activity runs 1 day(timeout) 1 day (timeout)
Write API calls 2500/hr Contact support.
This limit is imposed by Azure Resource

Manager, not Azure Data Factory.
Read API calls 12,500/hr Contact support
This limit is imposed by Azure Resource

Manager, not Azure Data Factory.
Version 1
Data factories in an Azure subscription 50 Contact support
Pipelines within a data factory 2500 Contact support
Datasets within a data factory 5000 Contact support
Concurrent slices per dataset 10 10
Bytes per object for pipeline objects 1 200 KB 200 KB
Bytes per object for dataset and linked 100 KB 2000 KB

service objects 1
HDInsight on-demand cluster cores 60 Contact support

within a subscription 2
Cloud data movement units 3 32 Contact support

Retry count for pipeline activity runs 1000 MaxInt (32 bit)
1 Pipeline, dataset, and linked service objects represent a logical grouping of your
workload. Limits for these objects
do not relate to amount of data you can move and process with the Azure Data Factory service. Data factory is
designed to scale to handle petabytes of data.
2 On-demand HDInsight cores are allocated out of the subscription that contains the data factory. As a result, the
above limit is the Data Factory enforced core limit for on-demand HDInsight cores and is different from the core
limit associated with your Azure subscription.
3 Cloud data movement unit (DMU) is being used in a cloud-to-cloud copy operation. It is a measure that represents
the power (a combination of CPU, memory, and network resource allocation) of a single unit in Data Factory. You
can achieve higher copy throughput by using more DMUs for some scenarios. Refer to Cloud data movement units
section on details.
4 The Integration Runtime (IR) is the compute infrastructure used by Azure Data Factory to provide the following
data integration capabilities across different network environments: data movement, dispatching activities to
compute services, execution of SSIS packages. For more information, see Integration Runtime overview.
RESOURCE DEFAULT LOWER LIMIT MINIMUM LIMIT
Scheduling interval 15 minutes 15 minutes
Interval between retry attempts 1 second 1 second
Retry timeout value 1 second 1 second
Web service call limits

Azure Resource Manager has limits for API calls. You can make API calls at a rate within the Azure Resource
Manager API limits.
Data Lake Analytics limits
Data Lake Analytics makes the complex task of managing distributed infrastructure and complex code easy. It
dynamically provisions resources and lets you do analytics on exabytes of data. When the job completes, it winds
down resources automatically, and you pay only for the processing power used. As you increase or decrease the
size of data stored or the amount of compute used, you don’t have to rewrite code. Many of the default limits can
be easily raised for your subscription by contacting support.
RESOURCE DEFAULT LIMIT COMMENTS
Maximum number of concurrent jobs 20
Maximum number of Analytics Units 250 Use any combination of up to a

(AUs) per account maximum of 250 AUs across 20 jobs.
Maximum script size for job submission 3 MB
Data Lake Store limits

Azure Data Lake Store is an enterprise-wide hyper-scale repository for big data analytic workloads. Data Lake Store
enables you to capture data of any size, type, and ingestion speed in one single place for operational and
exploratory analytics. There is no limit to the amount of data you can store in a Data Lake Store account.
Max number of Data Lake Store 10 Contact Support to request an increase

accounts, per subscription, per region for this limit
Max number of access ACLs, per file or 32 This is a hard limit. Use groups to
folder manage access with fewer entries
Max number of default ACLs, per file or 32 This is a hard limit. Use groups to
folder manage access with fewer entries
Database Migration Service Limits

The Azure Database Migration Service is a fully managed service designed to enable seamless migrations from
multiple database sources to Azure Data platforms with minimal downtime.
Maximum number of services per 2 Contact Support to request an increase

subscription, per region for this limit
Stream Analytics limits
LIMIT IDENTIFIER LIMIT COMMENTS
Maximum number of Streaming Units 200 A request to increase streaming units

per subscription per region for your subscription beyond 200 can
be made by contacting Microsoft
Support.
Maximum number of inputs per job 60 There is a hard limit of 60 inputs per
Stream Analytics job.
Maximum number of outputs per job 60 There is a hard limit of 60 outputs per
Maximum number of functions per job 60 There is a hard limit of 60 functions per
Maximum number of Streaming Units 120 There is a hard limit of 120 Streaming
per job Units per Stream Analytics job.
Maximum number of jobs per region 1500 Each subscription may have up to 1500
jobs per geographical region.
Reference data blob MB 100 Reference data blobs cannot be larger

than 100 MB each.
Active Directory limits

Here are the usage constraints and other service limits for the Azure Active Directory service.
CATEGORY LIMITS
CATEGORY LIMITS
Directories A single user can only be associated with a maximum of 20

Azure Active Directory directories.
Examples of possible combinations:
A single user creates 20 directories.
A single user is added to 20 directories as a member.
A single user creates 10 directories and later is added
by others to 10 different directories.
Objects A maximum of 500,000 objects can be created in a

single directory by users of the Free edition of Azure
Active Directory.
A non-admin user can create no more than 250
objects.
Schema extensions String type extensions can have maximum of 256

characters.
Binary type extensions are limited to 256 bytes.
100 extension values (across ALL types and ALL
applications) can be written to any single object.
Only “User”, “Group”, “TenantDetail”, “Device”,
“Application” and “ServicePrincipal” entities can be
extended with “String” type or “Binary” type single-
valued attributes.
Schema extensions are available only in Graph API-
version 1.21-preview. The application must be granted
write access to register an extension.
Applications A maximum of 100 users can be owners of a single application.
Groups A maximum of 100 users can be owners of a single

group.
Any number of objects can be members of a single
group in Azure Active Directory.
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory is limited to 15K members,
using Azure Active Directory Directory Synchronization
(DirSync).
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory using Azure AD Connect is
limited to 50K members.
Access Panel There is no limit to the number of applications that can

be seen in the Access Panel per end user, for users
assigned licenses for Azure AD Premium or the
Enterprise Mobility Suite.
A maximum of 10 app tiles (examples: Box, Salesforce,
or Dropbox) can be seen in the Access Panel for each
end user for users assigned licenses for Free or Azure
AD Basic editions of Azure Active Directory. This limit
does not apply to Administrator accounts.
CATEGORY LIMITS
Reports A maximum of 1,000 rows can be viewed or downloaded in

any report. Any additional data is truncated.
Administrative units An object can be a member of no more than 30 administrative

units.
Azure Event Grid limits

RESOURCE LIMIT
Event Subscriptions per region 1000
Custom Topics per region 20
StorSimple System limits

Maximum number of storage account 64

credentials
Maximum number of volume containers 64
Maximum number of volumes 255
Maximum number of schedules per 168 A schedule for every hour, every day of
bandwidth template the week (24*7).
Maximum size of a tiered volume on 64 TB for 8100 and 8600 8100 and 8600 are physical devices.
physical devices
Maximum size of a tiered volume on 30 TB for 8010 8010 and 8020 are virtual devices in
virtual devices in Azure 64 TB for 8020 Azure that use Standard Storage and
Premium Storage respectively.
Maximum size of a locally pinned 9 TB for 8100 8100 and 8600 are physical devices.
volume on physical devices 24 TB for 8600
Maximum number of iSCSI connections 512
Maximum number of iSCSI connections 512

from initiators
Maximum number of access control 64

records per device
Maximum number of volumes per 24

backup policy
Maximum number of backups retained 64

per backup policy
Maximum number of schedules per 10

backup policy
Maximum number of snapshots of any 256 This includes local snapshots and cloud
type that can be retained per volume snapshots.
Maximum number of snapshots that 10,000

can be present in any device
Maximum number of volumes that can 16 If there are more than 16

be processed in parallel for backup, volumes, they will be processed
restore, or clone sequentially as processing slots
become available.
New backups of a cloned or a
restored tiered volume cannot
occur until the operation is
finished. However, for a local
volume, backups are allowed
after the volume is online.
Restore and clone recover time for < 2 minutes The volume is made available
tiered volumes within 2 minutes of restore or
clone operation, regardless of
the volume size.
The volume performance may
initially be slower than normal as
most of the data and metadata
still resides in the cloud.
Performance may increase as
data flows from the cloud to the
StorSimple device.
The total time to download
metadata depends on the
allocated volume size. Metadata
is automatically brought into the
device in the background at the
rate of 5 minutes per TB of
allocated volume data. This rate
may be affected by Internet
bandwidth to the cloud.
The restore or clone operation is
complete when all the metadata
is on the device.
Backup operations cannot be
performed until the restore or
clone operation is fully complete.
Restore recover time for locally pinned < 2 minutes The volume is made available
volumes within 2 minutes of the restore
operation, regardless of the
volume size.
The volume performance may
initially be slower than normal as
most of the data and metadata
still resides in the cloud.
Performance may increase as
data flows from the cloud to the
StorSimple device.
The total time to download
metadata depends on the
allocated volume size. Metadata
is automatically brought into the
device in the background at the
rate of 5 minutes per TB of
allocated volume data. This rate
may be affected by Internet
bandwidth to the cloud.
Unlike tiered volumes, in the
case of locally pinned volumes,
the volume data is also
downloaded locally on the
device. The restore operation is
complete when all the volume
data has been brought to the
device.
The restore operations may be
long and the total time to
complete the restore will depend
on the size of the provisioned
local volume, your Internet
bandwidth and the existing data
on the device. Backup operations
on the locally pinned volume are
allowed while the restore
operation is in progress.
Thin-restore availability Last failover
Maximum client read/write throughput 920/720 MB/s with a single 10GbE Up to 2x with MPIO and two network
(when served from the SSD tier)* network interface interfaces.
Maximum client read/write throughput 120/250 MB/s

(when served from the HDD tier)*
Maximum client read/write throughput 11/41 MB/s Read throughput depends on clients
(when served from the cloud tier)* generating and maintaining sufficient
I/O queue depth.
* Maximum throughput per I/O type was measured with 100 percent read and 100 percent write scenarios. Actual
throughput may be lower and depends on I/O mix and network conditions.
Log Analytics limits
NOTE
Log Analytics was formerly known as Operational Insights.
The following limits apply to Log Analytics resources per subscription:
Number of free workspaces per 10 This limit cannot be increased.

subscription
Number of paid workspaces per N/A You are limited by the number of
subscription resources within a resource group and
number of resource groups per
subscription
The following limits apply to each Log Analytics workspace:
FREE STANDARD PREMIUM STANDALONE OMS
Data volume 500 MB1 None None None None

collected per day
Data retention 7 days 1 month 12 months 1 month2 1 month 2

period
1 When customers reach their 500 MB daily data transfer limit, data analysis stops and resumes at the start of the
next day. A day is based on UTC.
2 The data retention period for the Standalone and OMS pricing plans can be increased to 730 days.
CATEGORY LIMITS COMMENTS
Data Collector API Maximum size for a single post is 30 MB Split larger volumes into multiple posts
Maximum size for field values is 32 KB Fields longer than 32 KB are truncated.
Search API 5000 records returned for non- Aggregated data is a search that
aggregated data includes the measure command
500000 records for aggregated data
Backup limits
The following limits apply to Azure Backup.
LIMIT IDENTIFIER DEFAULT LIMIT
Number of servers/machines that can be registered against 50 for Windows Server/Client/SCDPM

each vault 200 for IaaS VMs
Size of a data source for data stored in Azure vault storage 54400 GB max1
Number of backup vaults that can be created in each Azure 25 Recovery Services vaults per region
subscription
Number of times backup can be scheduled per day 3 per day for Windows Server/Client
2 per day for SCDPM
Once a day for IaaS VMs
Data disks attached to an Azure virtual machine for backup 16
Size of individual data disk attached to an Azure virtual 1023 GB 2

machine for backup
1The 54400 GB limit does not apply to IaaS VM backup.

2 We have a private preview for supporting unmanaged disks upto 4TB.
Site Recovery limits
The following limits apply to Azure Site Recovery:
Number of vaults per subscription 25
Number of servers per Azure vault 250
Number of protection groups per Azure vault No limit
Number of recovery plans per Azure vault No limit
Number of servers per protection group No limit
Number of servers per recovery plan 50
Application Insights limits

There are some limits on the number of metrics and events per application (that is, per instrumentation key). Limits
depend on the pricing plan that you choose.
Total data per day 100 GB You can reduce data by setting a cap. If
you need more, you can increase the
limit up to 1,000 GB from the portal.
For capacities greater than 1,000 GB,
send mail to [email protected].
Free data per month 1 GB Additional data is charged per gigabyte.

(Basic price plan)
Throttling 32 k events/second The limit is measured over a minute.
Data retention 90 days This resource is for Search, Analytics,

and Metrics Explorer.
Availability multi-step test detailed 90 days This resource provides detailed results
results retention of each step.
Maximum event size 64 K
Property and metric name length 150 See type schemas
Property value string length 8,192 See type schemas
Trace and exception message length 10 k See type schemas
Availability tests count per app 100
Profiler data retention 5 days
Profiler data sent per day 10GB
For more information, see About pricing and quotas in Application Insights.
API Management limits
RESOURCE LIMIT
API Calls (per unit of scale) 32 million per day1
Data transfer (per unit of scale) 161 GB per day1
Cache 5 GB1
Units of scale Unlimited1
Azure Active Directory Integration Unlimited User Accounts1
1API Management limits are different foreach pricing tier. To see the pricing tiers and their associated limits and
scaling options, see API Management Pricing.
Azure Redis Cache limits
RESOURCE LIMIT
Cache size 530 GB
Databases 64
Max connected clients 40,000
Redis Cache replicas (for high availability) 1
Shards in a premium cache with clustering 10
Azure Redis Cache limits and sizes are different for each pricing tier. To see the pricing tiers and their associated
sizes, see Azure Redis Cache Pricing.
For more information on Azure Redis Cache configuration limits, see Default Redis server configuration.
Because configuration and management of Azure Redis Cache instances is done by Microsoft, not all Redis
commands are supported in Azure Redis Cache. For more information, see Redis commands not supported in
Azure Redis Cache.
Key Vault limits
Key transactions (Max transactions allowed in 10 seconds, per vault per region1):
HSM-KEY SOFTWARE-KEY
HSM-KEY ALL OTHER SOFTWARE-KEY ALL OTHER
KEY TYPE CREATE KEY TRANSACTIONS CREATE KEY TRANSACTIONS
RSA 2048-bit 5 1000 10 2000
RSA 3072-bit 5 250 10 500
RSA 4096-bit 5 125 10 250
Secrets, Managed Storage Account Keys, and vault transactions:
MAX TRANSACTIONS ALLOWED IN 10 SECONDS, PER VAULT PER

TRANSACTIONS TYPE REGION1
All transactions 2000
1 There is a subscription-wide limit forall transaction types, that is 5x per key vault limit. For example, HSM- other
transactions per subscription are limited to 5000 transactions in 10 seconds per subscription.
Multi-Factor Authentication
Max number of Trusted IP 0 50

addresses/ranges per subscription
Remember my devices - number of 14 60

days
Max number of app passwords? 0 No Limit
Allow X attempts during MFA call 1 99
Two-way Text message Timeout 60 600

Seconds
Default one-time bypass seconds 300 1800
Lock user account after X consecutive Not Set 99

MFA denials
Reset account lockout counter after X Not Set 9999

minutes
Unlock account after X minutes Not Set 9999
Automation limits
RESOURCE MAXIMUM LIMIT
Max number of new jobs that can be submitted every 30 100

seconds per Automation Account (non Scheduled jobs)
Max number of concurrent running jobs at the same instance 200

of time per Automation Account (non Scheduled jobs)
Max number of modules that can be imported every 30 5

seconds per Automation Account
Max size of a Module 100 MB
Job Run Time - Free tier 500 minutes per subscription per calendar month
Max amount of memory given to a job 400 MB
Max number of network sockets allowed per job 1000
SQL Database limits

For SQL Database limits, see SQL Database Resource Limits.
SQL Data Warehouse limits
For SQL Data Warehouse limits, see SQL Data Warehouse Resource Limits.
See also
Understanding Azure Limits and Increases
Virtual Machine and Cloud Service Sizes for Azure
Sizes for Cloud Services
Azure SDK for .NET 3.0 release notes
This topic includes release notes for version 3.0 of the Azure SDK for .NET.
Azure SDK for .NET 3.0 release summary

Release date: 03/07/2017
No breaking changes to the Azure SDK 3.0 have been introduced in this release. There is also no upgrade process
needed to leverage this SDK with existing Cloud Service projects. To allow use of the Azure SDK 3.0 without
requiring an upgrade process, Azure SDK 3.0 installs to the same directories as Azure SDK 2.9. Most the
components did not change the major version from 2.9 but instead just updated the build number.
Visual Studio 2017 RTW

In Visual Studio 2017, this release of the Azure SDK for .NET is built in to the Azure Workload. All the tools you
need to do Azure development will be part of Visual Studio 2017 going forward. For Visual Studio 2015 the SDK
will still be available through WebPI. We have discontinued Azure SDK for .NET releases for Visual Studio 2013
now that Visual Studio 2017 has been released.
Azure Diagnostics
Changed the behavior to only store a partial connection string with the key replaced by a token for Cloud
Services diagnostics storage connection string. The actual storage key is now stored in the user profile folder so
its access can be controlled. Visual Studio will read the storage key from user profile folder for local debugging
and publishing process.
In response to the change described above, Visual Studio Online team enhanced the Azure Cloud Services
deployment task template so users could specify the storage key for setting diagnostics extension when
publishing to Azure in Continuous Integration and Deployment.
We’ve made it possible to store secure connection string and tokenization for Azure Diagnostics (WAD), to help
you solve problems with configuration across environements.
Windows Server 2016 virtual machines
Visual Studio now supports deploying Cloud Services to OS Family 5 (Windows Server 2016) virtual machines.
For existing cloud services, you can change your settings to target the new OS Family. When creating new cloud
services, if you choose to create the service using .net 4.6 or higher, it will default the service to use OS Family 5.
For more information, you can review the Guest OS Family support table.
Known issues
Azure .NET SDK 3.0 introduced an issue when removing Visual Studio 2017 in a side by side configuration with
Visual Studio 2015. If you have the Azure SDK installed for Visual Studio 2015, the Microsoft Azure Storage
Emulator and Microsoft Azure Compute Emulator will be removed if you uninstall Visual Studio 2017. This will
produce an error when creating and debugging new Cloud services projects in Visual Studio 2015. In order to
fix this issue, reinstall the Azure SDK from the Web Platform Installer. The issue will be resolved in a future
Visual Studio 2017 update. .
Azure In-Role Cache
Support for Azure In-Role Cache ended on November 30, 2016. For more details, click here.
Azure SDK for .NET 2.9 release notes
This topic includes release notes for versions 2.9 and 2.9.6 of Azure SDK for .NET.
Azure SDK for .NET 2.9.6 release summary

Release date: 11/16/2016
No breaking changes to the Azure SDK 2.9 have been introduced in this release. There is also no upgrade process
needed to leverage this SDK with existing Cloud Service projects.
Visual Studio 2017 Release Candidate
In Visual Studio 2017 RC, this release of the Azure SDK for .NET is built in in the Azure Workload. All the tools
you need to do Azure development will be part of Visual Studio 2017 RC going forward. For Visual Studio 2015
and Visual Studio 2013, the SDK will still be available through WebPI. We will be discontinuing Azure SDK for
.NET releases for Visual Studio 2013, when Visual Studio 2017 releases as a final product. Follow this link to
download Visual Studio 2017 RC: https://www.visualstudio.com/vs/visual-studio-2017-rc/
Azure Diagnostics
Changed the behavior to only store a partial connection string with the key replaced by a token for Cloud
Services diagnostics storage connection string. The actual storage key is now stored in the user profile folder so
its access can be controlled. Visual Studio will read the storage key from user profile folder for local debugging
and publishing process.
In response to the change described above, Visual Studio Online team enhanced the Azure Cloud Services
deployment task template so users could specify the storage key for setting diagnostics extension when
publishing to Azure in Continuous Integration and Deployment.
We’ve made it possible to store secure connection string and tokenization for Azure Diagnostics (WAD), to help
you solve problems with configuration across environements.
Windows Server 2016 virtual machines
Visual Studio now supports deploying Cloud Services to OS Family 5 (Windows Server 2016) virtual machines.
For existing cloud services, you can change your settings to target the new OS Family. When creating new cloud
services, if you choose to create the service using .net 4.6 or higher, it will default the service to use OS Family 5.
For more information, you can review the Guest OS Family support table.
Known issues
Azure .NET SDK 2.9.6 introduced a restriction that blocks deployment of projects using unsupported .NET
frameworks (such as .NET 4.6) to any OS Family < 5. A workaround is provided here.
Azure In-Role Cache
Support for Azure In-Role Cache ends on November 30, 2016. For more details, click here.
Azure Resource Manager Templates for Azure Stack
We’ve introduced Azure Stack as a deployment target for your Azure Resource Manager Templates.
Azure SDK for .NET 2.9 summary

Overview
This document contains the release notes for the Azure SDK for .NET 2.9 release.
For detailed information about updates in this release, see the Azure SDK 2.9 announcement post.
Azure SDK 2.9 for Visual Studio 2015 Update 2 and Visual Studio "15"
Preview
This update includes the following bug fixes:
Issue related to REST API Client Generation in in which the string "Unknown Type” would appear as the name of
the code-gen folder and/or the name of the namespace dropped into the generated code.
Issue related to Scheduled WebJobs in which the authentication information was failing to be passed to the
Scheduler provisioning process.
This update includes the following new feature:
Support for secondary App Services in the "Services" tab of the App Service provisioning dialog.
Azure Data Lake Tools for Visual Studio 2015 Update 2

This updates includes the following:
Azure Data Lake Tools for Visual Studio is now merged into the Azure SDK for .NET release. The tool is
automatically installed when you install Azure SDK.
The tool is updated frequently, go here to get the updates.
Server Explorer now enables you to view all and create some U-SQL metadata entities. For more information,
see this blog.
HDInsight Tools
HDInsight Tools for Visual Studio now supports HDInsight version 3.3, including showing Tez graphs and other
language fixes.
Azure Resource Manager

This release adds KeyVault support for Resource Manager templates.
See also
Azure SDK 2.9 announcement post
Azure SDK for .NET 2.8, 2.8.1 and 2.8.2
Overview
This article contains the release notes (that includes known issues and breaking changes) for the Azure SDK for
.NET 2.8, 2.8.1 and 2.8.2 releases.
For complete list of new features and updates made in this release, see the Azure SDK 2.8 for Visual Studio 2013
and Visual Studio 2015 announcement.

Download Azure SDK for .NET 2.8
Azure SDK for .NET 2.8 for Visual Studio 2015
Azure SDK for .NET 2.8 for Visual Studio 2013
.NET 4.5.2 support
Known issues
Azure .NET SDK 2.8 allows you to create .NET 4.5.2 Cloud Service packages. However .NET 4.5.2 framework will not
be installed on the default Guest OS images until January 2016 Guest OS release. Before that, .NET 4.5.2 framework
will be available through a separate Guest OS release version – November 2015-02. See the Azure Guest OS
Releases and SDK Compatibility Matrix page to track when the image will be released. Once the November 2015-
02 image is released you can choose to use that image by updating your Cloud Service configuration file (.cscfg)
file. In the service configuration file set the osVersion attribute of the ServiceConfiguration element to the string
"WA-GUEST-OS-4.26_201511-02". If you choose to opt in to use this image then you will no longer get automatic
updates to the Guest OS. To get the automatic updates the osVersion must be set to “*” and .NET 4.5.2 will only be
available through automatic updates in January 2016.
Azure Data Factory
Known issues
During a Data Factory Template project creation involving sample data, azure power shell script may fail if azure
power shell version installed on the machine is after 0.9.8.
In order to successfully create this type of project, you must install azure power shell version 0.9.8.
Azure Resource Manager Tools
Breaking changes
The PowerShell script provided by the Azure Resource Group project has been updated in this release to work with
the new Azure PowerShell cmdlets version 1.0. This new script will not work from with Visual Studio when using a
version of the SDK prior to 2.8.
Scripts from projects created in earlier versions of the SDK will not run from within Visual Studio when using the
2.8 SDK. All scripts will continue to work outside of Visual Studio with the appropriate version of the Azure
PowerShell cmdlets.
The 2.8 SDK requires version 1.0 of the Azure PowerShell cmdlets. All other versions of the SDK require version
0.9.8 of the Azure PowerShell cmdlets. For more information see this blog.
Web Tools Extensions
Known issues
The following known issues will be addressed in the following release.
App Service related Cloud and Server Explorer gesture for non-production environments (like Azure China or
Azure Stack customers) do not work. For customers in these impacted areas, downloading the publish profile
from the Azure portal will enable publishing ability. A future release will repair gestures such as “Attach
Debugger” and “View Streaming Logs” for Azure China and Stack customers.
Customers may see errors during App Service creation when the App Insights instance to which they are
deploying is in a region other than East US. In these scenarios, creating an App Service in the portal and
downloading the publish profile will enable publishing scenarios.
Azure HDInsight Tools
New updates
You can execute your Hive query in the cluster via HiveServer2 with almost no overhead and see the job logs in
real-time.
Using the new Hive Task Execution View you can dig into your job deeper, find more details, and identify
potential issues.
For information, see Azure SDK 2.8 for Visual Studio 2013 and Visual Studio 2015.

Known Issues for Visual Studio 2013 and Visual Studio 2015
1. Triggered WebJob publishes to slots will show and error and won’t set a schedule, but it will push the WebJob
to Azure. Customers who are in need of a Scheduled job can then use the Azure Portal to set up the schedule for
the WebJob.
2. Python customers may experience debugger issues. Service team is rolling out a fix for this but if customers are
affected, please let Microsoft know in the forums or on the announcement blog or release notes comments
section.
3. Customers in certain regions (such as South India) will experience App Service provisioning errors. This is
consistent with the portal, and customers who experience this issue can use the Azure portal to request access to
publish to these geo-regions. Once they request access to these regions using the Azure portal provisioning
should work.

Following the installation of the 2.8.2 tools, customers may experience the following issue.
If you are using Windows 10 and have not installed Internet Explorer, you may get an "Internet Explorer could
not be found" error. To resolve the issue, install Internet Explorer using the Add/Remove Windows Components
dialog.
If you observe this issue, use the Send-a-smile feature to report it.
For more information, see this post.
Other updates
For other updates, see Azure SDK 2.8 announcement post.
Also see
Support and Retirement Information for the Azure SDK for .NET and APIs
Azure SDK for .NET 2.7 and .NET 2.7.1 Release Notes
Overview
The document also contain the release notes for the Azure SDK for .NET 2.7.1 release.
Azure SDK 2.7 is only supported in Visual Studio 2015 and Visual Studio 2013. Azure SDK 2.6 is the last supported
SDK for Visual Studio 2012.
For detailed information about this release, see Azure SDK 2.7 announcement post and Azure SDK 2.7.1
announcement post.

Sign in improvements for Visual Studio 2015
Azure SDK 2.7 for Visual Studio 2015 supports the new identity management features in Visual Studio 2015. This
includes support for accounts accessing Azure via Role Based Access Control, Cloud Solution Providers,
DreamSpark and other account and subscription types.
The sign-in improvements included with Azure SDK 2.7 are only available in Visual Studio 2015. Support for Visual
Studio 2013 is included in Azure SDK 2.7.1.
Mobile SDK
Updated Mobile Apps templates to reflect newest NuGet package and setup process.
Service Bus
General bug fixes and improvements. For detail on updates and features, please refer to the release notes of the
latest Service Bus NuGet.
HDInsight Tools
In this release the following updates were made. These updates are in preview. For more information, see this blog.
Hive graphs for Hive on Tez jobs
Full Hive DML IntelliSense support
Pig template support
Storm templates for Azure services
Breaking changes
Old Storm project must be upgraded when using this version of the tools. For more information, see this blog.
Visual Studio Web Express is no longer supported. For more information, see this blog.
Azure App Service Tools
In this release the following updates were made to Web Tools Extensions. For more information see this blog.
Support for DreamSpark accounts added
Full change to Azure Tools made to support the new Azure Resource Management APIs
Support for Azure App Service added to Cloud Explorer
Known issues
Web App deployment slot nodes don’t appear under the Slots node in Server Explorer, and Web App deployment
slot child nodes don’t load under Cloud Explorer. This issue has been resolved and prepared for the next SDK
release.
Cloud Explorer for Visual Studio 2015
Azure SDK 2.7 includes Cloud Explorer for Visual Studio 2015 which enables you to view your Azure resources,
inspect their properties, and perform key developer actions from within Visual Studio.
Cloud explorer supports the following:
Resource Group and Resource Type views of your Azure resources
Search for resources by name (available in Resource Type view)
Support for subscriptions and resources that have Role Based Access Control (RBAC) applied
Integrated Action panel which shows developer-focused actions specific to selected resources. For example:
Attach remote debugger for Virtual Machines created using the Resource Manager Stack, View diagnostics data
for Virtual Machines etc.
Integrated Properties panel which shows developer-focused properties commonly needed during dev/test
Quick switching of the account to use when enumerating resources (use Settings command on toolbar)
Filtering of subscriptions to use when enumerating resources (use Settings command on toolbar)
Deep links to the Azure Portal for management of resources and resource groups
The Azure Resource Manager Tools have been updated to work with Role Based Access Control (RBAC) and new
subscription types. Included with these changes is the ability to use new storage accounts, in addition to classic
storage, to store artifacts during deployment.
If you’re using an Azure Resource Group project from a previous version of the SDK with the SDK 2.7, a new
deployment script is needed to deploy using a new storage account instead of classic storage. You will be prompted
before changes are made to your project to add the new script. The old script will be renamed and you will need to
manually make any modifications to the new script.
Storage Explorer Tools
Support for viewing Append Blobs. More info in this blog post.
Support for viewing Premium Storage accounts through Server Explorer. Server Explorer will only display page
blobs for premium storage accounts as they are the only supported type for premium storage accounts.
Azure Data Factory Tools for Visual Studio
Introducing Azure Data Factory Tools for Visual Studio. Below are the enabled features. See this blog for more
information.
Template based authoring: Select use-cased based templates, data movement templates or data processing
templates to deploy an end-to-end data integration solution and get started hands-on quickly with Data Factory.
Integration with Solution Explorer for authoring and deploying Data Factory entities: Create & deploy
pipelines and related entities as Visual Studio projects.
Integration with Diagram view for visual interaction while authoring: Visually author pipelines and
datasets with aid from the Diagram view.
Integration with Server explorer for browsing and interaction with already deployed entities: Leverage
the Server Explorer to browse already deployed data factories and corresponding entities. Import a deployed
data factory or any entity (Pipeline, Linked Service, Datasets) into your project.
JSON editing with schema validation and rich intellisense: Efficiently configure and edit JSON documents
of Data Factory entities with rich intellisense and schema validation
Multi-Environment publishing: Publish authored pipelines to dev, test or Prod environment by creating
separate config files for each environment.
Pig, Hive and .Net based Data Processing Support: Support for Pig and Hive Scripts in Data Factory project.
Support for referencing C# Project for managing .Net Activity.

The following section contains updates that were introduced with the Azure SDK for .NET 2.7.1 release.
HDInsight Tools
For more detailed explanation about HDInsight tools updates, see this blog.
Hive Job Operator View (a new feature)
To help you understand your Hive query better, the Hive Operator View feature was added. To see all the
operators inside a vertex, double click on the vertices of the job graph. To view more details of a particular
operator, hover over that operator.
Hive Error Marker (a new feature)
To enable you to view the grammar errors instantly, the Hive Error Marker feature was added. Also, error
messages were enhanced and you can now see detailed grammar errors instantly (until this release, you had
to submit a Hive script to the cluster and wait for some time before getting details about your error
message).
Storm Topology Graph (a new feature)
Visualizing is very important when you want to see if your topology is working as expected. In this release
we added visualization for Storm graphs. You can visualize the important metrics for your topology (for
example, a color indicates weather a certain Bolt is “busy” or not). You can also double click the Bolt/Spout to
view more details.
Support for HDInsight clusters that were created in the Azure Portal (a bug fix)
You can now use Visual Studio to view and submit jobs to all your HDInsight clusters no matter where the
cluster were created.
More IntelliSense Support& Faster Hive Metadata Loading (an improvement)
We have improved the IntelliSense by adding more user friendly suggestions. For example, table alias can
now also be suggested in IntelliSense so you can write your query more easily. Also, we have improved the
Hive metadata loading so it will just take several seconds to list all the databases, tables and columns of your
Hive metastore.
For more detailed explanation about HDInsight tools updates, see this blog.
Improvements in Visual Studio 2013
Azure SDK 2.7.1 enables Visual Studio 2013 to access Azure accounts and subscriptions via Role Based Access
Control, Cloud Solution Providers, and Dreamspark.
With Azure SDK 2.7.1, the new Cloud Explorer tool window is now also available in Visual Studio 2013.
Known issues
Installing the Azure SDK 2.6 or 2.7.1 for Visual Studio Community 2013 on a non-English OS will display a warning
that the English and non-English resources of Visual Studio may be mismatched. This warning may be safely
dismissed. It will only occur if the machine did not contain a prior installation of Visual Studio Community 2013
and you are installing the SDK on a non-English OS. The warning is shown after the language pack applies the RTM
resources to Visual Studio, but before it applies Update 4. Dismissing the warning will allow the language pack to
continue and complete applying the Update 4 version of the language pack content.
LightSwitch projects are not compatibile with this release. This issue will be resolved with the next SDK release.
Also see
Azure SDK 2.7.1 announcement post
Azure SDK for .NET 2.6 Release Notes
With Azure SDK 2.6 you can develop cloud service applications (PaaS) targeting .NET 4.5.2 or .NET 4.6 provided that
you manually install the target .NET Framework on the Cloud Service Role. See Install .NET on a Cloud Service Role.
Service Bus updates

Event Hubs:
Now allows targeted access control when sending events by exposing additional publisher endpoint for
Event Hubs.
Additional stability and improvement added to Event Hubs feature.
Adding support of Amqp protocol over WebSocket for messaging and Event Hubs.
HDInsight Tools for Visual Studio updates

IntelliSense enhancement: remote metadata suggestion
Now HDInsight Tools for Visual Studio supports getting remote metadata when you are editing your Hive
script. For example, you can type SELECT * FROM and all the table names will be shown. Also, the column
names will be shown after specifying a table.
HDInsight emulator support
Now HDInsight Tools for Visual Studio support connecting to HDInsight emulator, so you could develop
your Hive scripts locally without introducing any cost, then execute those scripts against your HDInsight
clusters.
For more information, refer to this manual.
HDInsight Tools for Visual Studio support for generic Hadoop clusters (Preview)
Now HDInsight Tools for Visual Studio support generic Hadoop clusters, so you can use HDInsight Tools for
Visual Studio to do the following:
connect to your cluster,
write Hive query with enhanced IntelliSense/auto-completion support,
view all the jobs in your cluster with an intuitive UI.
For more information, refer to this manual.
In-Role Cache updates

In-Role Cache was updated to use Microsoft Azure Storage SDK version 4.3. Until now, the In-Role
Cache was using Azure Storage SDK version 1.7.
Customers using Azure SDK 2.5 or below should update to Azure SDK 2.6 and move to the new version of
Azure Storage SDK.
At this time Azure Storage version 2011-08-18 is scheduled to be removed August 1, 2016. Any migrations
of In-Role Cache from Azure SDK 2.5 or below to 2.6 must be complete by this time. For more information
on the retirement of Azure Storage version 2011-08-18, see Microsoft Azure Storage Service Version
Removal Update: Extension to 2016.
IMPORTANT
We’re announcing the November 30, 2016, retirement for Azure Managed Cache Service and Azure In-Role Cache. We
recommend that you migrate to Azure Redis Cache in preparation for this retirement. For more information on dates and
migration guidance, see Which Azure Cache offering is right for me?
Azure App Service Tools

The following items were updated in the Azure SDK 2.6 release.
Azure publishing enhanced to include Azure API Apps as a deployment target.
API Apps provisioning functionality to enable users with API App creation and provisioning functionality.
Server Explorer changed to reflect new App Service node, with Web, Mobile, and API apps grouped by Resource
Group.
Add Azure API App Client gesture added to most C# projects that will enable automatic generation of Swagger-
enabled API Apps running in a user’s Azure subscription.
API Apps tooling and App Service nodes in Server Explorer are available in Visual Studio 2013 only.
Azure Resource Manager Tools updates

The Azure resource manager tools have been updated to include templates for Virtual Machines, Networking and
Storage. The JSON editing experience has been updated to include a new outline view for templates and the ability
to edit the templates using JSON snippets. Templates deployed from Visual Studio use a PowerShell script
provided with the project, so any changes made to the script will be used by Visual Studio.
Diagnostics improvements for Cloud Services

Azure SDK 2.6 brings back support for collecting diagnostics logs in the Azure compute emulator and transferring
them to development storage. Any diagnostics logs (including application trace Logs, Event Tracing for Windows
(ETW) logs, performance counters, infrastructure logs and windows event logs) generated when the application is
running in the emulator can be transferred to development storage to verify that your diagnostics logging is
working on your local machine.
The Diagnostics storage account can now be specified in the service configuration (.cscfg) file making it easier to
use different diagnostics storage accounts for different environments. There are some notable differences between
how the connection string worked in Azure SDK 2.4 and Azure SDK 2.6. For more information on how to use the
Diagnostics Storage connection string and how it impacts your projects see Configuring Diagnostics for Azure
Cloud Services.
Breaking changes
The Cloud Deployment Projects project type available in the Azure SDK 2.5 has been renamed to Azure
Resource Group.
Cloud Deployment Projects type of projects created in the Azure SDK 2.5 can be used in 2.6 but deploying the
template from Visual Studio will fail. However, deploying with the PowerShell script will still work as it did
previously. For information on how to use Cloud Deployment Projects in 2.6 read this post.
Known issues
Collecting diagnostics logs in the emulator requires a 64-bit operating system. Diagnostics logs will not be
collected when running on a 32-bit operating system. This does not affect any other emulator functionality.
Azure SDK 2.6 released on 4/29/2015 had two issues:
Universal App could not be loaded in Visual Studio 2015 when Azure SDK 2.6 was installed on the
machine.
Debugging a Cloud Service project would fail in Visual Studio 2013 and Visual Studio 2015 where
Visual Studio becomes unresponsive and crashes while displaying a dialog box with the message
"Configuring diagnostics for emulator".
An update to Azure SDK 2.6 was released on 5/18/2015. The updated version is 2.6.30508.1601; it
contains fixes for two issues described above. You can identify the build of the SDK from Control
Panel -> Programs and Features -> Microsoft Azure Tools for Microsoft Visual Studio 2013 – v 2.6.
The Version column will display the build number.
If you are still facing the above issues, install the latest version of the Azure 2.6 SDK for VS 2012, VS
2013 or VS 2015.
See Also
Azure SDK for .NET 2.5.1 Release Notes
This document contains the release notes for the Azure SDK for .NET 2.5.1 release.
Azure SDK for .NET 2.5.1 release notes

The following are new features and updates in the Azure SDK for .NET 2.5.1.
New features\scenarios related to Web Tools Extensions.
Azure Websites was renamed to Azure App Service.
Azure API Apps (Preview) support has been added so that customers can publish ASP.NET projects as API
Apps, and then use the Add > Azure API App Client gesture in C# projects to generate code based on the
structure of the deployed API App.
The Websites node in Server Explorer has been deprecated in lieu of the Azure App Service node, which
contains support for Resource Group-based grouping of Azure API Apps, Mobile Apps, and Web Apps.
Azure Mobile Apps (Preview) support has been added so that customers can create new Mobile Apps
projects, add Mobile Apps controllers, publish the projects, and remotely debug applications.
Add > Azure API App Client gesture now supports local Swagger JSON files, so Web API developers can
use third-party NuGets like Swashbuckle to generate Swagger or author it manually. This way, client
developers can use the code-generation features to consume any Swagger endpoint in C# projects.
Web App and API App publishing dialogs have been enhanced to support the Azure portal concept of
resource grouping, and selection/creation of Azure Resource Groups and App Service Plans are
represented in the new Web App and API App provisioning dialog.
Azure API App Server Explorer nodes provide links to the API Apps deep link in the Azure portal, as
well as other features like Log Streaming and Remote Debugging.
For known issues and current limitations in Azure SDK .NET 2.5.1 this section below.
New features\scenarios related to HDInsight Tools in Visual Studio are enabled in this release.
Local validation of hive scripts. Click the Validate script button in the toolbar to see if there are any errors
in your script.
Improved debugging of Hive jobs. You can now debug Hive jobs by accessing Yarn logs in Visual Studio.
If your application has performance issues, investigating YARN logs provide useful information..
(Public Preview) Keyword auto-completion and IntelliSense support for Hive. To help you author Hive
scripts, HDInsight Tools for Visual Studio added keyword auto-completion and IntelliSense support for
Hive.
Storm support. You can now use HDInsight Tools for Visual Studio to develop Storm
topologies/Spouts/Bolts in C#. You can then submit the developed topology to a Storm cluster and
see the topology/bolt/spout status. You can use system logs and customer logs to troubleshoot your
Storm topologies/Bolts/Spouts. You can also use existing JAVA assets in Storm on HDInsight.
For more information, see Get started using HDInsight Hadoop Tools for Visual Studio.
Azure SDK for .NET 2.5.1 known issues and limitations

Azure API Apps is visible as a deployment target for Mobile Apps. Web Apps should be the only destination for
Mobile Apps until a subsequent release.
Azure API App provisioning can result in success but intermittently fail to update the progress in the Azure App
Service Activity window. Workaround is to check status of the new Azure API App in the Azure portal.
File > New Project > API App > F5 experience results in an HTTP error because there is no default/index.html.
Workaround is to manually browse to the /api/values URL.
Intermittently, Server Explorer icons appear flattened. Restarting VS resolves this issue.
If an exception is thrown during Web App or API App provisioning (such as exceeded quota errors or duplicate
Azure API App gateway name), the errors show some raw JSON text.
Intermittent project-creation issues when Application Insights is checked at project creation time.
Occasionally, the generated Azure API App Client code is missing namespaces, they need to be manually
included (or automatically imported via Visual Studio cues) for code to compile.
Mobile App projects should be published to web apps, but you must pick a site you created as a Mobile App in
the Azure portal since Mobile App projects require a database.
The start page for Mobile Apps uses the term "mobile service" instead of "mobile apps"
Mobile App project creation may take up to a minute to create.
During API App provisioning (in some cases) an error comes back from the Azure API reflecting that the
permissions could not be set properly, while the API App has been properly provisioned and is ready for use.
You can manually set permissions using the Azure portal.
Application Insights is not supported on API App templates and Mobile App templates.
API App projects cannot be used in conjunction with Cloud Service projects.
API App project templates are only available in C#.
API App consumption via the "Add Azure API App Client" context menu is only supported in C#.
Best Practices for Azure App Service
This article summarizes best practices for using Azure App Service.
Colocation
When Azure resources composing a solution such as a web app and a database are located in different regions the
effects can include the following:
Increased latency in communication between resources
Monetary charges for outbound data transfer cross-region as noted on the Azure pricing page.
Colocation in the same region is best for Azure resources composing a solution such as a web app and a database
or storage account used to hold content or data. When creating resources you should make sure they are in the
same Azure region unless you have specific business or design reason for them not to be. You can move an App
Service app to the same region as your database by leveraging the App Service cloning feature currently available
for Premium App Service Plan apps.
When apps consume more memory than expected

When you notice an app consumes more memory than expected as indicated via monitoring or service
recommendations consider the App Service Auto-Healing feature. One of the options for the Auto-Healing feature
is taking custom actions based on a memory threshold. Actions span the spectrum from email notifications to
investigation via memory dump to on-the-spot mitigation by recycling the worker process. Auto-healing can be
configured via web.config and via a friendly user interface as described at in this blog post for the App Service
Support Site Extension.
When apps consume more CPU than expected

When you notice an app consumes more CPU than expected or experiences repeated CPU spikes as indicated via
monitoring or service recommendations consider scaling up or scaling out the App Service plan. If your application
is stateful, scaling up is the only option, while if your application is stateless, scaling out will give you more
flexibility and higher scale potential.
For more information about “stateful” vs “stateless” applications you can watch this video: Planning a Scalable End-
to-End Multi-Tier Application on Microsoft Azure Web App. For more information about App Service scaling and
autoscaling options read: Scale a Web App in Azure App Service.
When socket resources are exhausted

A common reason for exhausting outbound TCP connections is the use of client libraries which are not
implemented to reuse TCP connections, or in the case of a higher level protocol such as HTTP - Keep-Alive not
being leveraged. Please review the documentation for each of the libraries referenced by the apps in your App
Service Plan to ensure they are configured or accessed in your code for efficient reuse of outbound connections.
Also follow the library documentation guidance for proper creation and release or cleanup to avoid leaking
connections. While such client libraries investigations are in progress impact may be mitigated by scaling out to
multiple instances.
Node.js and outgoing http requests
When working with Node.js and many outgoing http requests, dealing with HTTP - Keep-Alive is really important.
You can use the agentkeepalive npm package to make it easier in your code.
You should always handle the http response, even if you do nothing in the handler. If you don't handle the
response properly, your application will eventually get stuck because no more sockets are available.
For example, when working with the http or https package:
var request = https.request(options, function(response) {

response.on('data', function() { /* do nothing */ });
});
If you are running on App Service on Linux on a machine with multiple cores, another best practice is to use PM2 to
start multiple Node.js processes to execute your application. You can do this by specifying a startup command to
your container.
For example, to start four instances:
pm2 start /home/site/wwwroot/app.js --no-daemon -i 4
When your app backup starts failing

The two most common reasons why app backup fails are: invalid storage settings and invalid database
configuration. These failures typically happen when there are changes to storage or database resources, or changes
for how to access these resources (e.g. credentials updated for the database selected in the backup settings).
Backups typically run on a schedule and require access to storage (for outputting the backed up files) and
databases (for copying and reading contents to be included in the backup). The result of failing to access either of
these resources would be consistent backup failure.
When backup failures happen, please review most recent results to understand which type of failure is happening.
In the case of storage access failures, please review and update the storage settings used in the backup
configuration. In the case of database access failures, please review and update your connections strings as part of
app settings; then proceed to update your backup configuration to properly include the required databases. For
more information on app backup please see the Back up a web app in Azure App Service documentation.
When new Node.js apps are deployed to Azure App Service

Azure App Service default configuration for Node.js apps is intended to best suit the needs of most common apps.
If configuration for your Node.js app would benefit from personalized tuning to improve performance or optimize
resource usage for CPU/memory/network resources, you could review our best practices and troubleshooting
steps. This documentation article describes the iisnode settings you may need to configure for your Node.js app,
describes the various scenarios or issues that your app may be facing, and shows how to address these issues: Best
practices and troubleshooting guide for Node applications on Azure App Service.
1 min to read •
Edit O nline
Troubleshoot a web app in Azure App Service using
Visual Studio
Overview
This tutorial shows how to use Visual Studio tools to help debug a web app in App Service, by running in debug
mode remotely or by viewing application logs and web server logs.
NOTE
You'll learn:
Which Azure web app management functions are available in Visual Studio.
How to use Visual Studio remote view to make quick changes in a remote web app.
How to run debug mode remotely while a project is running in Azure, both for a web app and for a WebJob.
How to create application trace logs and view them while the application is creating them.
How to view web server logs, including detailed error messages and failed request tracing.
How to send diagnostic logs to an Azure Storage account and view them there.
If you have Visual Studio Ultimate, you can also use IntelliTrace for debugging. IntelliTrace is not covered in this
tutorial.
Prerequisites
This tutorial works with the development environment, web project, and Azure web app that you set up in Get
started with Azure and ASP.NET. For the WebJobs sections, you'll need the application that you create in Get
Started with the Azure WebJobs SDK.
The code samples shown in this tutorial are for a C# MVC web application, but the troubleshooting procedures are
the same for Visual Basic and Web Forms applications.
The tutorial assumes you're using Visual Studio 2017.
The streaming logs feature only works for applications that target .NET Framework 4 or later.
Web app configuration and management

Visual Studio provides access to a subset of the web app management functions and configuration settings
available in the Azure portal. In this section, you'll see what's available by using Server Explorer. To see the latest
Azure integration features, try out Cloud Explorer also. You can open both windows from the View menu.
1. If you aren't already signed in to Azure in Visual Studio, right-click Azure and select Connect to Microsoft
Azure Subscription in Server Explorer.
An alternative is to install a management certificate that enables access to your account. If you choose to
install a certificate, right-click the Azure node in Server Explorer, and then select Manage and Filter
Subscriptions in the context menu. In the Manage Microsoft Azure Subscriptions dialog box, click the
Certificates tab, and then click Import. Follow the directions to download and then import a subscription
file (also called a .publishsettings file) for your Azure account.
NOTE
If you download a subscription file, save it to a folder outside your source code directories (for example, in the
Downloads folder), and then delete it once the import has completed. A malicious user who gains access to the
subscription file can edit, create, and delete your Azure services.
For more information about connecting to Azure resources from Visual Studio, see Manage Accounts,
Subscriptions, and Administrative Roles.
2. In Server Explorer, expand Azure and expand App Service.
3. Expand the resource group that includes the web app that you created in [Create an ASP.NET web app in
Azure][app-service-web-get-started-dotnet.md], and then right-click the web app node and click View
Settings.
The Azure Web App tab appears, and you can see there the web app management and configuration tasks
that are available in Visual Studio.
In this tutorial, you'll use the logging and tracing drop-downs. You'll also use remote debugging but you'll
use a different method to enable it.
For information about the App Settings and Connection Strings boxes in this window, see Azure Web Apps:
How Application Strings and Connection Strings Work.
If you want to perform a web app management task that can't be done in this window, click Open in
Management Portal to open a browser window to the Azure portal.
Access web app files in Server Explorer

You typically deploy a web project with the customErrors flag in the Web.config file set to On or RemoteOnly ,
which means you don't get a helpful error message when something goes wrong. For many errors, all you get is a
page like one of the following ones:
Server Error in '/' Application:
An error occurred:
The website cannot display the page

Frequently the easiest way to find the cause of the error is to enable detailed error messages, which the first of the
preceding screenshots explains how to do. That requires a change in the deployed Web.config file. You could edit
the Web.config file in the project and redeploy the project, or create a Web.config transform and deploy a debug
build, but there's a quicker way: in Solution Explorer, you can directly view and edit files in the remote web app
by using the remote view feature.
1. In Server Explorer, expand Azure, expand App Service, expand the resource group that your web app is
located in, and then expand the node for your web app.
You see nodes that give you access to the web app's content files and log files.
2. Expand the Files node, and double-click the Web.config file.
Visual Studio opens the Web.config file from the remote web app and shows [Remote] next to the file name
in the title bar.
3. Add the following line to the system.web element:
<customErrors mode="Off"></customErrors>
4. Refresh the browser that is showing the unhelpful error message, and now you get a detailed error
message, such as the following example:
(The error shown was created by adding the line shown in red to Views\Home\Index.cshtml.)
Editing the Web.config file is only one example of scenarios in which the ability to read and edit files on your Azure
web app make troubleshooting easier.
Remote debugging web apps

If the detailed error message doesn't provide enough information, and you can't re-create the error locally,
another way to troubleshoot is to run in debug mode remotely. You can set breakpoints, manipulate memory
directly, step through code, and even change the code path.
Remote debugging does not work in Express editions of Visual Studio.
This section shows how to debug remotely using the project you create in [Create an ASP.NET web app in Azure]
[app-service-web-get-started-dotnet.md].
1. Open the web project that you created in [Create an ASP.NET web app in Azure][app-service-web-get-
started-dotnet.md].
2. Open Controllers\HomeController.cs.
3. Delete the About() method and insert the following code in its place.
public ActionResult About()

{
string currentTime = DateTime.Now.ToLongTimeString();
ViewBag.Message = "The current time is " + currentTime;
return View();
}
4. Set a breakpoint on the ViewBag.Message line.

5. In Solution Explorer, right-click the project, and click Publish.
6. In the Profile drop-down list, select the same profile that you used in [Create an ASP.NET web app in Azure]
[app-service-web-get-started-dotnet.md]. Then, click Settings.
7. In the Publish dialog, click the Settings tab, and then change Configuration to Debug, and then click
Save.
8. Click Publish. After deployment finishes and your browser opens to the Azure URL of your web app, close
the browser.
9. In Server Explorer, right-click your web app, and then click Attach Debugger.
The browser automatically opens to your home page running in Azure. You might have to wait 20 seconds
or so while Azure sets up the server for debugging. This delay only happens the first time you run in debug
mode on a web app in a 48-hour period. When you start debugging again in the same period, there isn't a
delay.
NOTE
If you have any trouble starting the debugger, try to do it by using Cloud Explorer instead of Server Explorer.
10. Click About in the menu.

Visual Studio stops on the breakpoint, and the code is running in Azure, not on your local computer.
11. Hover over the currentTime variable to see the time value.
The time you see is the Azure server time, which may be in a different time zone than your local computer.
12. Enter a new value for the currentTime variable, such as "Now running in Azure".
13. Press F5 to continue running.
The About page running in Azure displays the new value that you entered into the currentTime variable.
Remote debugging WebJobs
This section shows how to debug remotely using the project and web app you create in Get Started with the Azure
WebJobs SDK.
The features shown in this section are available only in Visual Studio 2013 with Update 4 or later.
Remote debugging only works with continuous WebJobs. Scheduled and on-demand WebJobs don't support
debugging.
1. Open the web project that you created in Get Started with the Azure WebJobs SDK.
2. In the ContosoAdsWebJob project, open Functions.cs.
3. Set a breakpoint on the first statement in the GnerateThumbnail method.
4. In Solution Explorer, right-click the web project (not the WebJob project), and click Publish.
5. In the Profile drop-down list, select the same profile that you used in Get Started with the Azure WebJobs
SDK.
6. Click the Settings tab, and change Configuration to Debug, and then click Publish.
Visual Studio deploys the web and WebJob projects, and your browser opens to the Azure URL of your web
app.
7. In Server Explorer, expand Azure > App Service > your resource group > your web app > WebJobs
> Continuous, and then right-click ContosoAdsWebJob.
8. Click Attach Debugger.
The browser automatically opens to your home page running in Azure. You might have to wait 20 seconds
or so while Azure sets up the server for debugging. This delay only happens the first time you run in debug
mode on a web app in a 48-hour period. When you start debugging again in the same period, there isn't a
delay.
9. In the web browser that is opened to the Contoso Ads home page, create a new ad.
Creating an ad causes a queue message to be created, which is picked up by the WebJob and processed.
When the WebJobs SDK calls the function to process the queue message, the code hits your breakpoint.
10. When the debugger breaks at your breakpoint, you can examine and change variable values while the
program is running the cloud. In the following illustration, the debugger shows the contents of the blobInfo
object that was passed to the GenerateThumbnail method.
11. Press F5 to continue running.

The GenerateThumbnail method finishes creating the thumbnail.
12. In the browser, refresh the Index page and you see the thumbnail.
13. In Visual Studio, press SHIFT+F5 to stop debugging.
14. In Server Explorer, right-click the ContosoAdsWebJob node and click View Dashboard.
15. Sign in with your Azure credentials, and then click the WebJob name to go to the page for your WebJob.
The Dashboard shows that the GenerateThumbnail function executed recently.
(The next time you click View Dashboard, you don't have to sign in, and the browser goes directly to the
page for your WebJob.)
16. Click the function name to see details about the function execution.
If your function wrote logs, you could click ToggleOutput to see them.
Notes about remote debugging

Running in debug mode in production is not recommended. If your production web app is not scaled out to
multiple server instances, debugging prevents the web server from responding to other requests. If you do
have multiple web server instances, when you attach to the debugger, you get a random instance, and you have
no way to ensure that subsequent browser requests go to the same instance. Also, you typically don't deploy a
debug build to production, and compiler optimizations for release builds might make it impossible to show
what is happening line by line in your source code. For troubleshooting production problems, your best
resource is application tracing and web server logs.
Avoid long stops at breakpoints when remote debugging. Azure treats a process that is stopped for longer than
a few minutes as an unresponsive process, and shuts it down.
While you're debugging, the server is sending data to Visual Studio, which could affect bandwidth charges. For
information about bandwidth rates, see Azure Pricing.
Make sure that the debug attribute of the compilation element in the Web.config file is set to true. It is set
to true by default when you publish a debug build configuration.
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
If you find that the debugger doesn't step into the code that you want to debug, you might have to change the
Just My Code setting. For more information, see Restrict stepping to Just My Code.
A timer starts on the server when you enable the remote debugging feature, and after 48 hours the feature is
automatically turned off. This 48-hour limit is done for security and performance reasons. You can easily turn
the feature back on as many times as you like. We recommend leaving it disabled when you are not actively
debugging.
You can manually attach the debugger to any process, not only the web app process (w3wp.exe). For more
information about how to use debug mode in Visual Studio, see Debugging in Visual Studio.
Diagnostic logs overview

An ASP.NET application that runs in an Azure web app can create the following kinds of logs:
Application tracing logs
The application creates these logs by calling methods of the System.Diagnostics.Trace class.
Web server logs
The web server creates a log entry for every HTTP request to the web app.
Detailed error message logs
The web server creates an HTML page with some additional information for failed HTTP requests (requests that
result in status code 400 or greater).
Failed request tracing logs
The web server creates an XML file with detailed tracing information for failed HTTP requests. The web server
also provides an XSL file to format the XML in a browser.
Logging affects web app performance, so Azure gives you the ability to enable or disable each type of log as
needed. For application logs, you can specify that only logs above a certain severity level should be written. When
you create a new web app, by default all logging is disabled.
Logs are written to files in a LogFiles folder in the file system of your web app and are accessible via FTP. Web
server logs and application logs can also be written to an Azure Storage account. You can retain a greater volume
of logs in a storage account than is possible in the file system. You're limited to a maximum of 100 megabytes of
logs when you use the file system. (File system logs are only for short-term retention. Azure deletes old log files to
make room for new ones after the limit is reached.)
Create and view application trace logs

In this section, you do the following tasks:
Add tracing statements to the web project that you created in Get started with Azure and ASP.NET.
View the logs when you run the project locally.
View the logs as they are generated by the application running in Azure.
For information about how to create application logs in WebJobs, see How to work with Azure queue storage
using the WebJobs SDK - How to write logs. The following instructions for viewing logs and controlling how
they're stored in Azure apply also to application logs created by WebJobs.
Add tracing statements to the application
1. Open Controllers\HomeController.cs, and replace the Index , About , and Contact methods with the
following code in order to add Trace statements and a using statement for System.Diagnostics :
public ActionResult Index()

{
Trace.WriteLine("Entering Index method");
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
Trace.TraceInformation("Displaying the Index page at " + DateTime.Now.ToLongTimeString());
Trace.WriteLine("Leaving Index method");
return View();
}
public ActionResult About()

{
Trace.WriteLine("Entering About method");
ViewBag.Message = "Your app description page.";
Trace.TraceWarning("Transient error on the About page at " + DateTime.Now.ToShortTimeString());
Trace.WriteLine("Leaving About method");
return View();
}
public ActionResult Contact()

{
Trace.WriteLine("Entering Contact method");
ViewBag.Message = "Your contact page.";
Trace.TraceError("Fatal error on the Contact page at " + DateTime.Now.ToLongTimeString());
Trace.WriteLine("Leaving Contact method");
return View();
}
2. Add a using System.Diagnostics; statement to the top of the file.

View the tracing output locally
1. Press F5 to run the application in debug mode.
The default trace listener writes all trace output to the Output window, along with other Debug output. The
following illustration shows the output from the trace statements that you added to the Index method.
The following steps show how to view trace output in a web page, without compiling in debug mode.
2. Open the application Web.config file (the one located in the project folder) and add a <system.diagnostics>
element at the end of the file just before the closing </configuration> element:
<system.diagnostics>
<trace>
<listeners>
<add name="WebPageTraceListener"
type="System.Web.WebPageTraceListener,
System.Web,
Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</listeners>
</trace>
</system.diagnostics>
The WebPageTraceListener lets you view trace output by browsing to /trace.axd .

3. Add a trace element under <system.web> in the Web.config file, such as the following example:
<trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />
4. Press CTRL+F5 to run the application.

5. In the address bar of the browser window, add trace.axd to the URL, and then press Enter (the URL is similar to
http://localhost:53370/trace.axd).
6. On the Application Trace page, click View Details on the first line (not the BrowserLink line).
The Request Details page appears, and in the Trace Information section you see the output from the
trace statements that you added to the Index method.
By default, trace.axd is only available locally. If you wanted to make it available from a remote web app,
you could add localOnly="false" to the trace element in the Web.config file, as shown in the following
example:
<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true"

pageOutput="false" />
However, enabling trace.axd in a production web app is not recommended for security reasons. In the
following sections, you'll see an easier way to read tracing logs in an Azure web app.
View the tracing output in Azure
1. In Solution Explorer, right-click the web project and click Publish.
2. In the Publish Web dialog box, click Publish.
After Visual Studio publishes your update, it opens a browser window to your home page (assuming you
didn't clear Destination URL on the Connection tab).
3. In Server Explorer, right-click your web app and select View Streaming Logs.
The Output window shows that you are connected to the log-streaming service, and adds a notification line
each minute that goes by without a log to display.
4. In the browser window that shows your application home page, click Contact.
Within a few seconds, the output from the error-level trace you added to the Contact method appears in
the Output window.
Visual Studio is only showing error-level traces because that is the default setting when you enable the log
monitoring service. When you create a new Azure web app, all logging is disabled by default, as you saw
when you opened the settings page earlier:
However, when you selected View Streaming Logs, Visual Studio automatically changed Application
Logging(File System) to Error, which means error-level logs get reported. In order to see all of your
tracing logs, you can change this setting to Verbose. When you select a severity level lower than error, all
logs for higher severity levels are also reported. So when you select verbose, you also see information,
warning, and error logs.
5. In Server Explorer, right-click the web app, and then click View Settings as you did earlier.
6. Change Application Logging (File System) to Verbose, and then click Save.
7. In the browser window that is now showing your Contact page, click Home, then click About, and then
click Contact.
Within a few seconds, the Output window shows all of your tracing output.
In this section, you enabled and disabled logging by using Azure web app settings. You can also enable and
disable trace listeners by modifying the Web.config file. However, modifying the Web.config file causes the
app domain to recycle, while enabling logging via the web app configuration doesn't do that. If the problem
takes a long time to reproduce, or is intermittent, recycling the app domain might "fix" it and force you to
wait until it happens again. Enabling diagnostics in Azure lets you start capturing error information
immediately without recycling the app domain.
Output window features
The Microsoft Azure Logs tab of the Output Window has several buttons and a text box:
These perform the following functions:

Clear the Output window.
Enable or disable word wrap.
Start or stop monitoring logs.
Specify which logs to monitor.
Download logs.
Filter logs based on a search string or a regular expression.
Close the Output window.
If you enter a search string or regular expression, Visual Studio filters logging information at the client. That means
you can enter the criteria after the logs are displayed in the Output window and you can change filtering criteria
without having to regenerate the logs.
View web server logs

Web server logs record all HTTP activity for the web app. In order to see them in the Output window, you must
enable them for the web app and tell Visual Studio that you want to monitor them.
1. In the Azure Web App Configuration tab that you opened from Server Explorer, change Web Server
Logging to On, and then click Save.
2. In the Output Window, click the Specify which Microsoft Azure logs to monitor button.
3. In the Microsoft Azure Logging Options dialog box, select Web server logs, and then click OK.
4. In the browser window that shows the web app, click Home, then click About, and then click Contact.
The application logs generally appear first, followed by the web server logs. You might have to wait a while
for the logs to appear.
By default, when you first enable web server logs by using Visual Studio, Azure writes the logs to the file system.
As an alternative, you can use the Azure portal to specify that web server logs should be written to a blob
container in a storage account.
If you use the portal to enable web server logging to an Azure storage account, and then disable logging in Visual
Studio, when you re-enable logging in Visual Studio your storage account settings are restored.
View detailed error message logs

Detailed error logs provide some additional information about HTTP requests that result in error response codes
(400 or above). In order to see them in the Output window, you have to enable them for the web app and tell
Visual Studio that you want to monitor them.
1. In the Azure Web App Configuration tab that you opened from Server Explorer, change Detailed Error
Messages to On, and then click Save.
2. In the Output Window, click the Specify which Microsoft Azure logs to monitor button.
3. In the Microsoft Azure Logging Options dialog box, click All logs, and then click OK.
4. In the address bar of the browser window, add an extra character to the URL to cause a 404 error (for
example, http://localhost:53370/Home/Contactx ), and press Enter.
After several seconds, the detailed error log appears in the Visual Studio Output window.
Control+click the link to see the log output formatted in a browser:

Download file system logs
Any logs that you can monitor in the Output window can also be downloaded as a .zip file.
1. In the Output window, click Download Streaming Logs.
File Explorer opens to your Downloads folder with the downloaded file selected.
2. Extract the .zip file, and you see the following folder structure:
Application tracing logs are in .txt files in the LogFiles\Application folder.

Web server logs are in .log files in the LogFiles\http\RawLogs folder. You can use a tool such as Log
Parser to view and manipulate these files.
Detailed error message logs are in .html files in the LogFiles\DetailedErrors folder.
(The deployments folder is for files created by source control publishing; it doesn't have anything
related to Visual Studio publishing. The Git folder is for traces related to source control publishing
and the log file streaming service.)
View failed request tracing logs

Failed request tracing logs are useful when you need to understand the details of how IIS is handling an HTTP
request, in scenarios such as URL rewriting or authentication problems.
Azure web apps use the same failed request tracing functionality that has been available with IIS 7.0 and later. You
don't have access to the IIS settings that configure which errors get logged, however. When you enable failed
request tracing, all errors are captured.
You can enable failed request tracing by using Visual Studio, but you can't view them in Visual Studio. These logs
are XML files. The streaming log service only monitors files that are deemed readable in plain text mode: .txt, .html,
and .log files.
You can view failed request tracing logs in a browser directly via FTP or locally after using an FTP tool to download
them to your local computer. In this section, you'll view them in a browser directly.
1. In the Configuration tab of the Azure Web App window that you opened from Server Explorer, change
Failed Request Tracing to On, and then click Save.
2. In the address bar of the browser window that shows the web app, add an extra character to the URL and
click Enter to cause a 404 error.
This causes a failed request tracing log to be created, and the following steps show how to view or
download the log.
3. In Visual Studio, in the Configuration tab of the Azure Web App window, click Open in Management
Portal.
4. In the Azure portal Settings page for your web app, click Deployment credentials, and then enter a new
user name and password.
NOTE
When you log in, you have to use the full user name with the web app name prefixed to it. For example, if you enter
"myid" as a user name and the site is "myexample", you log in as "myexample\myid".
5. In a new browser window, go to the URL that is shown under FTP hostname or FTPS hostname in the
Overview page for your web app.
6. Log in using the FTP credentials that you created earlier (including the web app name prefix for the user
name).
The browser shows the root folder of the web app.
7. Open the LogFiles folder.
8. Open the folder that is named W3SVC plus a numeric value.

The folder contains XML files for any errors that have been logged after you enabled failed request tracing,
and an XSL file that a browser can use to format the XML.
9. Click the XML file for the failed request that you want to see tracing information for.
The following illustration shows part of the tracing information for a sample error.
Next Steps
You've seen how Visual Studio makes it easy to view logs created by an Azure web app. The following sections
provide links to more resources on related topics:
Azure web app troubleshooting
Debugging in Visual Studio
Remote debugging in Azure
Tracing in ASP.NET applications
Analyzing web server logs
Analyzing failed request tracing logs
Debugging Cloud Services
Azure web app troubleshooting
For more information about troubleshooting web apps in Azure App Service, see the following resources:
How to monitor web apps
Investigating Memory Leaks in Azure Web Apps with Visual Studio 2013. Microsoft ALM blog post about Visual
Studio features for analyzing managed memory issues.
Azure web apps online tools you should know about. Blog post by Amit Apple.
For help with a specific troubleshooting question, start a thread in one of the following forums:
The Azure forum on the ASP.NET site.
The Azure forum on MSDN.
StackOverflow.com.
Debugging in Visual Studio
For more information about how to use debug mode in Visual Studio, see Debugging in Visual Studio and
Debugging Tips with Visual Studio 2010.
Remote debugging in Azure
For more information about remote debugging for Azure web apps and WebJobs, see the following resources:
Introduction to Remote Debugging Azure App Service Web Apps.
Introduction to Remote Debugging Azure App Service Web Apps part 2 - Inside Remote debugging
Introduction to Remote Debugging on Azure App Service Web Apps part 3 - Multi-Instance environment and
GIT
WebJobs Debugging (video)
If your web app uses an Azure Web API or Mobile Services back-end and you need to debug that, see Debugging
.NET Backend in Visual Studio.
Tracing in ASP.NET applications
There are no thorough and up-to-date introductions to ASP.NET tracing available on the Internet. The best you can
do is get started with old introductory materials written for Web Forms because MVC didn't exist yet, and
supplement that with newer blog posts that focus on specific issues. Some good places to start are the following
resources:
Monitoring and Telemetry (Building Real-World Cloud Apps with Azure).
E-book chapter with recommendations for tracing in Azure cloud applications.
ASP.NET Tracing
Old but still a good resource for a basic introduction to the subject.
Trace Listeners
Information about trace listeners but doesn't mention the WebPageTraceListener.
Walkthrough: Integrating ASP.NET Tracing with System.Diagnostics Tracing
This article is also old, but includes some additional information that the introductory article doesn't cover.
Tracing in ASP.NET MVC Razor Views
Besides tracing in Razor views, the post also explains how to create an error filter in order to log all
unhandled exceptions in an MVC application. For information about how to log all unhandled exceptions in
a Web Forms application, see the Global.asax example in Complete Example for Error Handlers on MSDN. In
either MVC or Web Forms, if you want to log certain exceptions but let the default framework handling take
effect for them, you can catch and rethrow as in the following example:
try
{
// Your code that might cause an exception to be thrown.
}
catch (Exception ex)
{
Trace.TraceError("Exception: " + ex.ToString());
throw;
}
Streaming Diagnostics Trace Logging from the Azure Command Line (plus Glimpse!)
How to use the command line to do what this tutorial shows how to do in Visual Studio. Glimpse is a tool for
debugging ASP.NET applications.
Using Web Apps Logging and Diagnostics - with David Ebbo and Streaming Logs from Web Apps - with David
Ebbo
Videos by Scott Hanselman and David Ebbo.
For error logging, an alternative to writing your own tracing code is to use an open-source logging framework
such as ELMAH. For more information, see Scott Hanselman's blog posts about ELMAH.
Also, you don't need to use ASP.NET or System.Diagnostics tracing to get streaming logs from Azure. The Azure
web app streaming log service streams any .txt, .html, or .log file that it finds in the LogFiles folder. Therefore, you
could create your own logging system that writes to the file system of the web app, and your file is automatically
streamed and downloaded. All you have to do is write application code that creates files in the d:\home\logfiles
folder.
Analyzing web server logs
For more information about analyzing web server logs, see the following resources:
LogParser
A tool for viewing data in web server logs (.log files).
Troubleshooting IIS Performance Issues or Application Errors using LogParser
An introduction to the Log Parser tool that you can use to analyze web server logs.
Blog posts by Robert McMurray on using LogParser
The HTTP status code in IIS 7.0, IIS 7.5, and IIS 8.0
Analyzing failed request tracing logs
The Microsoft TechNet website includes a Using Failed Request Tracing section, which may be helpful for
understanding how to use these logs. However, this documentation focuses mainly on configuring failed request
tracing in IIS, which you can't do in Azure Web Apps.
Best practices and troubleshooting guide for node
applications on Azure Web Apps
In this article, you learn best practices and troubleshooting steps for node applications running on Azure Web Apps
(with iisnode).
WARNING
Use caution when using troubleshooting steps on your production site. Recommendation is to troubleshoot your app on a
non-production setup for example your staging slot and when the issue is fixed, swap your staging slot with your production
slot.
IISNODE configuration
This schema file shows all the settings that you can configure for iisnode. Some of the settings that are useful for
your application:
nodeProcessCountPerApplication
This setting controls the number of node processes that are launched per IIS application. The default value is
1. You can launch as many node.exes as your VM vCPU count by setting this to 0. The recommended value is
0 for most applications so you can use all of the vCPUs on your machine. Node.exe is single-threaded so one
node.exe consumes a maximum of 1 vCPU. To get maximum performance out of your node application, you
want to use all vCPUs.
nodeProcessCommandLine
This setting controls the path to the node.exe. You can set this value to point to your node.exe version.
maxConcurrentRequestsPerProcess
This setting controls the maximum number of concurrent requests sent by iisnode to each node.exe. On
Azure Web Apps, the default value for this is Infinite. You don't have to worry about this setting. Outside
Azure Web Apps, the default value is 1024. You can configure this depending on how many requests your
application receives and how fast your application processes each request.
maxNamedPipeConnectionRetry
This setting controls the maximum number of times iisnode retries making the connection on the named
pipe to send the request over to node.exe. This setting in combination with namedPipeConnectionRetryDelay
determines the total timeout of each request within iisnode. The default value is 200 on Azure Web Apps.
Total Timeout in seconds = (maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000
namedPipeConnectionRetryDelay
This setting controls the amount of time (in ms) iisnode waits between each retry to send the request to
node.exe over the named pipe. The default value is 250 ms. Total Timeout in seconds =
(maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000
By default, the total timeout in iisnode on Azure Web Apps is 200 * 250 ms = 50 seconds.
logDirectory
This setting controls the directory where iisnode logs stdout/stderr. The default value is iisnode, which is
relative to the main script directory (directory where main server.js is present)
debuggerExtensionDll
This setting controls what version of node-inspector iisnode uses when debugging your node application.
Currently, iisnode-inspector-0.7.3.dll and iisnode-inspector.dll are the only two valid values for this setting.
The default value is iisnode-inspector-0.7.3.dll. The iisnode-inspector-0.7.3.dll version uses node-inspector-
0.7.3 and uses websockets. You must enable websockets on your Azure webapp to use this version. See
http://www.ranjithr.com/?p=98 for more details on how to configure iisnode to use the new node-inspector.
flushResponse
The default behavior of IIS is that it buffers response data up to 4 MB before flushing, or until the end of the
response, whichever comes first. iisnode offers a configuration setting to override this behavior: to flush a
fragment of the response entity body as soon as iisnode receives it from node.exe, you need to set the
iisnode/@flushResponse attribute in web.config to 'true':
<configuration>
<system.webServer>

<iisnode flushResponse="true" />
</system.webServer>
</configuration>
Enabling flushing of every fragment of the response entity body adds performance overhead that reduces
the throughput of the system by ~5% (as of v0.1.13), so it is best to scope this setting only to endpoints that
require response streaming (for example, using the element in the web.config).
In addition to this, for streaming applications, you must also set responseBufferLimit of your iisnode handler
to 0.
<handlers>
<add name="iisnode" path="app.js" verb="\*" modules="iisnode" responseBufferLimit="0"/>
</handlers>
watchedFiles
This is a semi-colon separated list of files that are watched for changes. A change to a file causes the
application to recycle. Each entry consists of an optional directory name plus a required file name that are
relative to the directory where the main application entry point is located. Wild cards are allowed in the file
name portion only. The default value is “*.js;web.config”
recycleSignalEnabled
The default value is false. If enabled, your node application can connect to a named pipe (environment
variable IISNODE_CONTROL_PIPE) and send a “recycle” message. This causes the w3wp to recycle gracefully.
idlePageOutTimePeriod
The default value is 0, which means this feature is disabled. When set to some value greater than 0, iisnode
will page out all its child processes every ‘idlePageOutTimePeriod’ in milliseconds. See documentation to
understand what page out means. This setting is useful for applications that consume a lot of memory and
want to page out memory to disk occasionally to free up some RAM.
WARNING
Use caution when enabling the following configuration settings on production applications. The recommendation is to not
enable them on live production applications.
debugHeaderEnabled
The default value is false. If set to true, iisnode adds an HTTP response header iisnode-debug to every HTTP
response it sends the iisnode-debug header value is a URL. Individual pieces of diagnostic information can
be gleaned by looking at the URL fragment, but a much better visualization is achieved by opening the URL
in the browser.
loggingEnabled
This setting controls the logging of stdout and stderr by iisnode. Iisnode captures stdout/stderr from node
processes it launches and writes to the directory specified in the ‘logDirectory’ setting. Once this is enabled,
your application writes logs to the file system and depending on the amount of logging done by the
application, there could be performance implications.
devErrorsEnabled
The default value is false. When set to true, iisnode displays the HTTP status code and Win32 error code on
your browser. The win32 code is helpful in debugging certain types of issues.
debuggingEnabled (do not enable on live production site)
This setting controls debugging feature. Iisnode is integrated with node-inspector. By enabling this setting,
you enable debugging of your node application. Once this setting is enabled, iisnode will lay out the
necessary node-inspector files in ‘debuggerVirtualDir’ directory on the first debug request to your node
application. You can load the node-inspector by sending a request to http://yoursite/server.js/debug. You
can control the debug URL segment with ‘debuggerPathSegment’ setting. By default,
debuggerPathSegment=’debug’. You can set this to a GUID, for example, so that it is more difficult to be
discovered by others.
Check this link for more details on debugging.
Scenarios and recommendations/troubleshooting

My node application is making too many outbound calls.
Many applications would want to make outbound connections as part of their regular operation. For example, when
a request comes in, your node app would want to contact a REST API elsewhere and get some information to
process the request. You would want to use a keep alive agent when making http or https calls. For example, you
could use the agentkeepalive module as your keep alive agent when making these outbound calls. This makes sure
that the sockets are reused on your Azure webapp VM and reducing the overhead of creating new sockets for every
outbound request. Also, this makes sure that you are using less number of sockets to make many outbound
requests and therefore you don’t exceed the maxSockets that are allocated per VM. The recommendation on Azure
Web Apps is to set the agentKeepAlive maxSockets value to a total of 160 sockets per VM. This means that if you
have four node.exe running on the VM, you want to set the agentKeepAlive maxSockets to 40 per node.exe, which is
160 total per VM.
Example agentKeepALive configuration:
var keepaliveAgent = new Agent({
maxSockets: 40,
maxFreeSockets: 10,
timeout: 60000,
keepAliveTimeout: 300000
});
This example assumes you have 4 node.exe running on your VM. If you have a different number of node.exe
running on the VM, you must modify the maxSockets setting accordingly.
My node application is consuming too much CPU.
You will probably get a recommendation from Azure Web Apps on your portal about high cpu consumption. You
can also set up monitors to watch for certain metrics. When checking the CPU usage on the Azure Portal
Dashboard, check the MAX values for CPU so you don’t miss the peak values. In cases where you think your
application is consuming too much CPU and you cannot explain why, you can profile your node application to find
out.
Profiling your node application on Azure Web Apps with V8-Profiler
For example, let's say you have a hello world app that you want to profile as follows:
var http = require('http');

function WriteConsoleLog() {
for(var i=0;i<99999;++i) {
console.log('hello world');
}
}
function HandleRequest() {
WriteConsoleLog();
}
http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/html'});
HandleRequest();
res.end('Hello world!');
}).listen(process.env.PORT);
Go to your scm site https://yoursite.scm.azurewebsites.net/DebugConsole

You see a command prompt as shown below. Go into your site/wwwroot directory.
Run the command “npm install v8-profiler”.
This should install v8-profiler under node_modules directory and all of its dependencies. Now, edit your server.js to
profile your application.
var http = require('http');

var profiler = require('v8-profiler');
var fs = require('fs');
function WriteConsoleLog() {
for(var i=0;i<99999;++i) {
console.log('hello world');
}
}
function HandleRequest() {
profiler.startProfiling('HandleRequest');
WriteConsoleLog();
fs.writeFileSync('profile.cpuprofile', JSON.stringify(profiler.stopProfiling('HandleRequest')));
}
http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/html'});
HandleRequest();
res.end('Hello world!');
}).listen(process.env.PORT);
The preceding code profiles the WriteConsoleLog function and then writes the profile output to the
‘profile.cpuprofile’ file under your site wwwroot. Send a request to your application. You see a ‘profile.cpuprofile’
file created under your site wwwroot.
Download this file and open it with Chrome F12 Tools. Press F12 on Chrome, then choose the Profiles tab. Choose
the Load button. Select your profile.cpuprofile file that you downloaded. Click on the profile you just loaded.
You can see that 95% of the time was consumed by the WriteConsoleLog function. This also shows you the exact
line numbers and source files that caused the issue.
My node application is consuming too much memory
If your application is consuming too much memory, you see a notice from Azure Web Apps on your portal about
high memory consumption. You can set up monitors to watch for certain metrics. When checking the memory
usage on the Azure Portal Dashboard, be sure to check the MAX values for memory so you don’t miss the peak
values.
Leak detection and Heap Diffing for node.js
You could use node-memwatch to help you identify memory leaks. You can install memwatch just like v8-profiler
and edit your code to capture and diff heaps to identify the memory leaks in your application.
My node.exe’s are getting killed randomly
There are a few reasons why this could be happening:
1. Your application is throwing uncaught exceptions – Check d:\home\LogFiles\Application\logging-errors.txt file
for the details on the exception thrown. This file has the stack trace so you can fix your application based on this.
2. Your application is consuming too much memory which is affecting other processes from getting started. If the
total VM memory is close to 100%, your node.exe’s could be killed by the process manager to let other
processes get a chance to do some work. To fix this, either make sure your application is not leaking memory
OR if your application needs to use a great deal of memory, scale up to a larger VM with a lot more RAM.
My node application does not start
If your application is returning 500 Errors when it starts, there could be a few reasons:
1. Node.exe is not present at the correct location. Check nodeProcessCommandLine setting.
2. Main script file is not present at the correct location. Check web.config and make sure the name of the main
script file in the handlers section matches the main script file.
3. Web.config configuration is not correct – check the settings names/values.
4. Cold Start – Your application is taking too long to start. If your application takes longer than
(maxNamedPipeConnectionRetry * namedPipeConnectionRetryDelay) / 1000 seconds, iisnode returns a 500
error. Increase the values of these settings to match your application start time to prevent iisnode from timing
out and returning the 500 error.
My node application crashed
Your application is throwing uncaught exceptions – Please check d:\home\LogFiles\Application\logging-errors.txt
file for the details on the exception thrown. This file has the stack trace so you can fix your application based on this.
My node application takes too much time to start (Cold Start)
The most common reason for an application taking too long to start is a high number of files in the node_modules.
The application tries to load most of these files when starting. By default, since your files reside on the network
share on Azure Web Apps, loading many files can take time. Some solutions to make this process faster are:
1. Be sure you have a flat dependency structure and no duplicate dependencies by using npm3 to install your
modules.
2. Try to lazy load your node_modules and not load all of the modules at application start. This means that the call
to require(‘module’) should be made when you actually need it within the function you try when using the
module.
3. Azure Web Apps offers a feature called local cache. This feature copies your content from the network share to
the local disk on the VM. Since the files are local, the load time of node_modules is much faster.
IISNODE http status and substatus

This source file lists all of the possible status/substatus combinations iisnode can return in case of an error.
Enable FREB for your application to see the win32 error code (be sure you enable FREB only on non-production
sites for performance reasons).
HTTP STATUS HTTP SUBSTATUS POSSIBLE REASON?

HTTP STATUS HTTP SUBSTATUS POSSIBLE REASON?
500 1000 There was some issue dispatching the

request to IISNODE – Check if node.exe
was started. Node.exe could have
crashed when starting. Check your
web.config configuration for errors.
500 1001 - Win32Error 0x2 - App is not

responding to the URL. Check the URL
rewrite rules or check if your express
app has the correct routes defined. -
Win32Error 0x6d – named pipe is busy
– Node.exe is not accepting requests
because the pipe is busy. Check high
cpu usage. - Other errors – check if
node.exe crashed.
500 1002 Node.exe crashed – check

d:\home\LogFiles\logging-errors.txt for
stack trace.
500 1003 Pipe configuration Issue – You should

never see this but if you do, the named
pipe configuration is incorrect.
500 1004-1018 There was some error while sending the

request or processing the response
to/from node.exe. Check if node.exe
crashed. check
d:\home\LogFiles\logging-errors.txt for
stack trace.
503 1000 Not enough memory to allocate more

named pipe connections. Check why
your app is consuming so much
memory. Check
maxConcurrentRequestsPerProcess
setting value. If it's not infinite and you
have many requests, increase this value
to prevent this error.
503 1001 Request could not be dispatched to

node.exe because the application is
recycling. After the application has
recycled, requests should be served
normally.
503 1002 Check win32 error code for actual

reason – Request could not be
dispatched to a node.exe.
503 1003 Named pipe is too Busy – Check if the

node is consuming excessive CPU
There is a setting within NODE.exe called NODE_PENDING_PIPE_INSTANCES. By default, outside of Azure Web
Apps, this value is 4. This means that node.exe can only accept four requests at a time on the named pipe. On Azure
Web Apps, this value is set to 5000. This value should be good enough for most node applications running on
Azure Web Apps. You should not see 503.1003 on Azure Web Apps because of the high value for the
NODE_PENDING_PIPE_INSTANCES. |
More resources
Follow these links to learn more about node.js applications on Azure App Service.
Get started with Node.js Web Apps in Azure App Service
How to debug a Node.js web app in Azure App Service
Using Node.js Modules with Azure applications
Azure App Service Web Apps: Node.js
Node.js Developer Center
Exploring the Super Secret Kudu Debug Console
Troubleshoot HTTP errors of "502 bad gateway" and
"503 service unavailable" in your Azure web apps
"502 bad gateway" and "503 service unavailable" are common errors in your web app hosted in Azure App Service.
This article helps you troubleshoot these errors.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and the
Stack Overflow forums. Alternatively, you can also file an Azure support incident. Go to the Azure Support site and
click on Get Support.
Symptom
When you browse to the web app, it returns a HTTP "502 Bad Gateway" error or a HTTP "503 Service Unavailable"
error.
Cause
This problem is often caused by application level issues, such as:
requests taking a long time
application using high memory/CPU
application crashing due to an exception.
Troubleshooting steps to solve "502 bad gateway" and "503 service

unavailable" errors
Troubleshooting can be divided into three distinct tasks, in sequential order:
1. Observe and monitor application behavior
2. Collect data
3. Mitigate the issue
App Service Web Apps gives you various options at each step.
Track Service health
Microsoft Azure publicizes each time there is a service interruption or performance degradation. You can track the
health of the service on the Azure Portal. For more information, see Track service health.
Monitor your web app
This option enables you to find out if your application is having any issues. In your web app’s blade, click the
Requests and errors tile. The Metric blade will show you all the metrics you can add.
Some of the metrics that you might want to monitor for your web app are
Average response time
CPU time
Memory working set
Requests
For more information, see:

Monitor Web Apps in Azure App Service
Receive alert notifications
2. Collect data
Use the Azure App Service Support Portal
Web Apps provides you with the ability to troubleshoot issues related to your web app by looking at HTTP logs,
event logs, process dumps, and more. You can access all this information using our Support portal at http://<your
app name>.scm.azurewebsites.net/Support
The Azure App Service Support portal provides you with three separate tabs to support the three steps of a
common troubleshooting scenario:
1. Observe current behavior
2. Analyze by collecting diagnostics information and running the built-in analyzers
3. Mitigate
If the issue is happening right now, click Analyze > Diagnostics > Diagnose Now to create a diagnostic session
for you, which will collect HTTP logs, event viewer logs, memory dumps, PHP error logs and PHP process report.
Once the data is collected, it will also run an analysis on the data and provide you with an HTML report.
In case you want to download the data, by default, it would be stored in the D:\home\data\DaaS folder.
For more information on the Azure App Service Support portal, see New Updates to Support Site Extension for
Azure Websites.
Use the Kudu Debug Console
Web Apps comes with a debug console that you can use for debugging, exploring, uploading files, as well as JSON
endpoints for getting information about your environment. This is called the Kudu Console or the SCM Dashboard
for your web app.
You can access this dashboard by going to the link https://<Your app name>.scm.azurewebsites.net/.
Some of the things that Kudu provides are:
environment settings for your application
log stream
diagnostic dump
debug console in which you can run Powershell cmdlets and basic DOS commands.
Another useful feature of Kudu is that, in case your application is throwing first-chance exceptions, you can use
Kudu and the SysInternals tool Procdump to create memory dumps. These memory dumps are snapshots of the
process and can often help you troubleshoot more complicated issues with your web app.
For more information on features available in Kudu, see Azure Websites online tools you should know about.
Scale the web app
In Azure App Service, for increased performance and throughput, you can adjust the scale at which you are running
your application. Scaling up a web app involves two related actions: changing your App Service plan to a higher
pricing tier, and configuring certain settings after you have switched to the higher pricing tier.
For more information on scaling, see Scale a web app in Azure App Service.
Additionally, you can choose to run your application on more than one instance . This not only provides you with
more processing capability, but also gives you some amount of fault tolerance. If the process goes down on one
instance, the other instance will still continue serving requests.
You can set the scaling to be Manual or Automatic.
Use AutoHeal
AutoHeal recycles the worker process for your app based on settings you choose (like configuration changes,
requests, memory-based limits, or the time needed to execute a request). Most of the time, recycle the process is
the fastest way to recover from a problem. Though you can always restart the web app from directly within the
Azure Portal, AutoHeal will do it automatically for you. All you need to do is add some triggers in the root
web.config for your web app. Note that these settings would work in the same way even if your application is not a
.Net one.
For more information, see Auto-Healing Azure Web Sites.
Restart the web app
This is often the simplest way to recover from one-time issues. On the Azure Portal, on your web app’s blade, you
have the options to stop or restart your app.
You can also manage your web app using Azure Powershell. For more information, see Using Azure PowerShell
with Azure Resource Manager.
Troubleshoot slow web app performance issues in
Azure App Service
This article helps you troubleshoot slow web app performance issues in Azure App Service.
If you need more help at any point in this article, you can contact the Azure experts on the MSDN Azure and the
Stack Overflow forums. Alternatively, you can also file an Azure support incident. Go to the Azure Support site and
click on Get Support.
Symptom
When you browse the web app, the pages load slowly and sometimes timeout.
Cause
This problem is often caused by application level issues, such as:
network requests taking a long time
application code or database queries being inefficient
application using high memory/CPU
application crashing due to an exception
Troubleshooting steps
Troubleshooting can be divided into three distinct tasks, in sequential order:
2. Collect data
App Service Web Apps gives you various options at each step.
Track Service health
Microsoft Azure publicizes each time there is a service interruption or performance degradation. You can track the
health of the service on the Azure portal. For more information, see Track service health.
Monitor your web app
This option enables you to find out if your application is having any issues. In your web app’s blade, click the
Requests and errors tile. The Metric blade shows you all the metrics you can add.
Some of the metrics that you might want to monitor for your web app are
Average response time
CPU time
Memory working set
Requests
For more information, see:
Monitor Web Apps in Azure App Service
Receive alert notifications
Monitor web endpoint status
If you are running your web app in the Standard pricing tier, Web Apps lets you monitor two endpoints from three
geographic locations.
Endpoint monitoring configures web tests from geo-distributed locations that test response time and uptime of
web URLs. The test performs an HTTP GET operation on the web URL to determine the response time and uptime
from each location. Each configured location runs a test every five minutes.
Uptime is monitored using HTTP response codes, and response time is measured in milliseconds. A monitoring test
fails if the HTTP response code is greater than or equal to 400 or if the response takes more than 30 seconds. An
endpoint is considered available if its monitoring tests succeed from all the specified locations.
To set it up, see Monitor apps in Azure App Service.
Also, see Keeping Azure Web Sites up plus Endpoint Monitoring - with Stefan Schackow for a video on endpoint
monitoring.
Application performance monitoring using Extensions
You can also monitor your application performance by using site extensions.
Each App Service web app provides an extensible management end point that allows you to use a powerful set of
tools deployed as site extensions. Extensions include:
Source code editors like Visual Studio Team Services.
Management tools for connected resources such as a MySQL database connected to a web app.
Azure Application Insights and New Relic are two of the performance monitoring site extensions that are available.
To use New Relic, you install an agent at runtime. To use Azure Application Insights, you rebuild your code with an
SDK, and you can also install an extension that provides access to additional data. The SDK lets you write code to
monitor the usage and performance of your app in more detail.
To use Application Insights, see Monitor performance in web applications.
To use New Relic, see New Relic Application Performance Management on Azure.
2. Collect data
The Web Apps environment provides diagnostic functionality for logging information from both the web server
and the web application. The information is separated into web server diagnostics and application diagnostics.
Enable web server diagnostics
You can enable or disable the following kinds of logs:
Detailed Error Logging - Detailed error information for HTTP status codes that indicate a failure (status code
400 or greater). This may contain information that can help determine why the server returned the error code.
Failed Request Tracing - Detailed information on failed requests, including a trace of the IIS components used
to process the request and the time taken in each component. This can be useful if you are attempting to
improve web app performance or isolate what is causing a specific HTTP error.
Web Server Logging - Information about HTTP transactions using the W3C extended log file format. This is
useful when determining overall web app metrics, such as the number of requests handled or how many
requests are from a specific IP address.
Enable application diagnostics
There are several options to collect application performance data from Web Apps, profile your application live from
Visual Studio, or modify your application code to log more information and traces. You can choose the options
based on how much access you have to the application and what you observed from the monitoring tools.
U se A p p l i c a t i o n I n si g h t s P r o fi l e r
You can enable the Application Insights Profiler to start capturing detailed performance traces. You can access
traces captured up to five days ago when you need to investigate problems happened in the past. You can choose
this option as long as you have access to the web app's Application Insights resource on Azure portal.
Application Insights Profiler provides statistics on response time for each web call and traces that indicates which
line of code caused the slow responses. Sometimes the App Service app is slow because certain code is not written
in a performant way. Examples include sequential code that can be run in parallel and undesired database lock
contentions. Removing these bottlenecks in the code increases the app's performance, but they are hard to detect
without setting up elaborate traces and logs. The traces collected by Application Insights Profiler helps identifying
the lines of code that slows down the application and overcome this challenge for App Service apps.
For more information, see Profiling live Azure web apps with Application Insights.
U se R e m o t e P r o fi l i n g
In Azure App Service, Web Apps, API Apps, and WebJobs can be remotely profiled. Choose this option if you have
access to the web app resource and you know how to reproduce the issue, or if you know the exact time interval
the performance issue happens.
Remote Profiling is useful if the CPU usage of the process is high and your process is running slower than
expected, or the latency of HTTP requests are higher than normal, you can remotely profile your process and get
the CPU sampling call stacks to analyze the process activity and code hot paths.
For more information, see Remote Profiling support in Azure App Service.
Se t u p d i a g n o st i c t r a c e s m a n u a l l y
If you have access to the web application source code, Application diagnostics enables you to capture information
produced by a web application. ASP.NET applications can use the System.Diagnostics.Trace class to log
information to the application diagnostics log. However, you need to change the code and redeploy your
application. This method is recommended if your app is running on a testing environment.
For detailed instructions on how to configure your application for logging, see Enable diagnostics logging for web
apps in Azure App Service.
Use the Azure App Service support portal
Web Apps provides you with the ability to troubleshoot issues related to your web app by looking at HTTP logs,
event logs, process dumps, and more. You can access all this information using our Support portal at http://<your
app name>.scm.azurewebsites.net/Support
The Azure App Service support portal provides you with three separate tabs to support the three steps of a
common troubleshooting scenario:
1. Observe current behavior
2. Analyze by collecting diagnostics information and running the built-in analyzers
3. Mitigate
If the issue is happening right now, click Analyze > Diagnostics > Diagnose Now to create a diagnostic session
for you, which collects HTTP logs, event viewer logs, memory dumps, PHP error logs, and PHP process report.
Once the data is collected, the support portal runs an analysis on the data and provides you with an HTML report.
In case you want to download the data, by default, it would be stored in the D:\home\data\DaaS folder.
For more information on the Azure App Service support portal, see New Updates to Support Site Extension for
Azure Websites.
Use the Kudu Debug Console
Web Apps comes with a debug console that you can use for debugging, exploring, uploading files, as well as JSON
endpoints for getting information about your environment. This console is called the Kudu Console or the SCM
Dashboard for your web app.
You can access this dashboard by going to the link https://<Your app name>.scm.azurewebsites.net/.
Some of the things that Kudu provides are:
environment settings for your application
log stream
diagnostic dump
debug console in which you can run Powershell cmdlets and basic DOS commands.
Another useful feature of Kudu is that, in case your application is throwing first-chance exceptions, you can use
Kudu and the SysInternals tool Procdump to create memory dumps. These memory dumps are snapshots of the
process and can often help you troubleshoot more complicated issues with your web app.
For more information on features available in Kudu, see Azure Websites Team Services tools you should know
about.
Scale the web app
In Azure App Service, for increased performance and throughput, you can adjust the scale at which you are running
your application. Scaling up a web app involves two related actions: changing your App Service plan to a higher
pricing tier, and configuring certain settings after you have switched to the higher pricing tier.
For more information on scaling, see Scale a web app in Azure App Service.
Additionally, you can choose to run your application on more than one instance. Scaling out not only provides you
with more processing capability, but also gives you some amount of fault tolerance. If the process goes down on
one instance, the other instances continue to serve requests.
You can set the scaling to be Manual or Automatic.
Use AutoHeal
AutoHeal recycles the worker process for your app based on settings you choose (like configuration changes,
requests, memory-based limits, or the time needed to execute a request). Most of the time, recycle the process is
the fastest way to recover from a problem. Though you can always restart the web app from directly within the
Azure portal, AutoHeal does it automatically for you. All you need to do is add some triggers in the root web.config
for your web app. These settings would work in the same way even if your application is not a .Net app.
For more information, see Auto-Healing Azure Web Sites.
Restart the web app
Restarting is often the simplest way to recover from one-time issues. On the Azure portal, on your web app’s blade,
you have the options to stop or restart your app.
You can also manage your web app using Azure Powershell. For more information, see Using Azure PowerShell
with Azure Resource Manager.
Application performance FAQs for Web Apps in
Azure
This article has answers to frequently asked questions (FAQs) about application performance issues for the Web
Apps feature of Azure App Service.
If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and the Stack Overflow. You can
post your issue in these forums, or post to @AzureSupport on Twitter. You also can submit an Azure support
request. To submit a support request, on the Azure support page, select Get support.
Why is my app slow?

Multiple factors might contribute to slow app performance. For detailed troubleshooting steps, see Troubleshoot
slow web app performance.
How do I troubleshoot a high CPU-consumption scenario?

In some high CPU-consumption scenarios, your app might truly require more computing resources. In that case,
consider scaling to a higher service tier so the application gets all the resources it needs. Other times, high CPU
consumption might be caused by a bad loop or by a coding practice. Getting insight into what's triggering
increased CPU consumption is a two-part process. First, create a process dump, and then analyze the process dump.
For more information, see Capture and analyze a dump file for high CPU consumption for Web Apps.
How do I troubleshoot a high memory-consumption scenario?

In some high memory-consumption scenarios, your app might truly require more computing resources. In that
case, consider scaling to a higher service tier so the application gets all the resources it needs. Other times, a bug in
the code might cause a memory leak. A coding practice also might increase memory consumption. Getting insight
into what's triggering high memory consumption is a two-part process. First, create a process dump, and then
analyze the process dump. Crash Diagnoser from the Azure Site Extension Gallery can efficiently perform both
these steps. For more information, see Capture and analyze a dump file for intermittent high memory for Web
Apps.
How do I automate App Service web apps by using PowerShell?

You can use PowerShell cmdlets to manage and maintain App Service web apps. In our blog post Automate web
apps hosted in Azure App Service by using PowerShell, we describe how to use Azure Resource Manager-based
PowerShell cmdlets to automate common tasks. The blog post also has sample code for various web apps
management tasks. For descriptions and syntax for all App Service web apps cmdlets, see AzureRM.Websites.
How do I view my web app's event logs?

To view your web app's event logs:
1. Sign in to your Kudu website.
2. In the menu, select Debug Console > CMD.
3. Select the LogFiles folder.
4. To view event logs, select the pencil icon next to eventlog.xml.
5. To download the logs, run the PowerShell cmdlet Save-AzureWebSiteLog -Name webappname .
How do I capture a user-mode memory dump of my web app?

To capture a user-mode memory dump of your web app:
2. Select the Process Explorer menu.
3. Right-click the w3wp.exe process or your WebJob process.
4. Select Download Memory Dump > Full Dump.
How do I view process-level info for my web app?

You have two options for viewing process-level information for your web app:
In the Azure portal:
1. Open the Process Explorer for the web app.
2. To see the details, select the w3wp.exe process.
In the Kudu console:
2. Select the Process Explorer menu.
3. For the w3wp.exe process, select Properties.
When I browse to my app, I see "Error 403 - This web app is stopped."
How do I resolve this?
Three conditions can cause this error:
The web app has reached a billing limit and your site has been disabled.
The web app has been stopped in the portal.
The web app has reached a resource quota limit that might apply to a Free or Shared scale service plan.
To see what is causing the error and to resolve the issue, follow the steps in Web Apps: "Error 403 – This web app is
stopped".
Where can I learn more about quotas and limits for various App Service
plans?
For information about quotas and limits, see App Service limits.
How do I decrease the response time for the first request after idle
time?
By default, web apps are unloaded if they are idle for a set period of time. This way, the system can conserve
resources. The downside is that the response to the first request after the web app is unloaded is longer, to allow
the web app to load and start serving responses. In Basic and Standard service plans, you can turn on the Always
On setting to keep the app always loaded. This eliminates longer load times after the app is idle. To change the
Always On setting:
1. In the Azure portal, go to your web app.
2. Select Application settings.
3. For Always On, select On.
How do I turned on failed request tracing?
To turn on failed request tracing:
2. Select All Settings > Diagnostics Logs.
3. For Failed Request Tracing, select On.
4. Select Save.
5. On the web app blade, select Tools.
6. Select Visual Studio Online.
7. If the setting is not On, select On.
8. Select Go.
9. Select Web.config.
10. In system.webServer, add this configuration (to capture a specific URL):
<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*api*" />
<add path="*api*">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,
Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>
11. To troubleshoot slow-performance issues, add this configuration (if the capturing request is taking more than 30
seconds):
<system.webServer> <tracing> <traceFailedRequests> <remove path="*" /> <add path="*"> <traceAreas> <add
provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices"
verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server"
areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI"
verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:30" statusCodes="200-999" /> </add>
</traceFailedRequests> </tracing>
12. To download the failed request traces, in the portal, go to your website.
13. Select Tools > Kudu > Go.
14. In the menu, select Debug Console > CMD.
15. Select the LogFiles folder, and then select the folder with a name that starts with W3SVC.
16. To see the XML file, select the pencil icon.
I see the message "Worker Process requested recycle due to 'Percent

Memory' limit." How do I address this issue?
The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. By
default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications).
Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web
Worker role. This triggers a web app restart, so schedule accordingly.
Also note that a 64-bit environment requires a Basic or Standard service plan. Free and Shared plans always run in
a 32-bit environment.
For more information, see Configure web apps in App Service.
Why does my request time out after 240 seconds?
Azure Load Balancer has a default idle timeout setting of four minutes. This is generally a reasonable response time
limit for a web request. If your web app requires background processing, we recommend using Azure WebJobs. The
Azure web app can call WebJobs and be notified when background processing is finished. You can choose from
multiple methods for using WebJobs, including queues and triggers.
WebJobs is designed for background processing. You can do as much background processing as you want in a
WebJob. For more information about WebJobs, see Run background tasks with WebJobs.
ASP.NET Core applications that are hosted in App Service sometimes

stop responding. How do I fix this issue?
A known issue with an earlier Kestrel version might cause an ASP.NET Core 1.0 app that's hosted in App Service to
intermittently stop responding. You also might see this message: "The specified CGI Application encountered an
error and the server terminated the process."
This issue is fixed in Kestrel version 1.0.2. This version is included in the ASP.NET Core 1.0.3 update. To resolve this
issue, make sure you update your app dependencies to use Kestrel 1.0.2. Alternatively, you can use one of two
workarounds that are described in the blog post ASP.NET Core 1.0 slow perf issues in App Service web apps.
I can't find my log files in the file structure of my web app. How can I
find them?
If you use the Local Cache feature of App Service, the folder structure of the LogFiles and Data folders for your App
Service instance are affected. When Local Cache is used, subfolders are created in the storage LogFiles and Data
folders. The subfolders use the naming pattern "unique identifier" + time stamp. Each subfolder corresponds to a
VM instance in which the web app is running or has run.
To determine whether you are using Local Cache, check your App Service Application settings tab. If Local Cache
is being used, the app setting WEBSITE_LOCAL_CACHE_OPTION is set to Always .
If you are not using Local Cache and are experiencing this issue, submit a support request.
I see the message "An attempt was made to access a socket in a way
forbidden by its access permissions." How do I resolve this?
This error typically occurs if the outbound TCP connections on the VM instance are exhausted. In App Service, limits
are enforced for the maximum number of outbound connections that can be made for each VM instance. For more
information, see Cross-VM numerical limits.
This error also might occur if you try to access a local address from your application. For more information, see
Local address requests.
For more information about outbound connections in your web app, see the blog post about outgoing connections
to Azure websites.
How do I use Visual Studio to remote debug my App Service web app?
For a detailed walkthrough that shows you how to debug your web app by using Visual Studio, see Remote debug
your App Service web app.
Deployment FAQs for Web Apps in Azure
This article has answers to frequently asked questions (FAQs) about deployment issues for the Web Apps feature of
Azure App Service.
I am just getting started with App Service web apps. How do I publish
my code?
Here are some options for publishing your web app code:
Deploy by using Visual Studio. If you have the Visual Studio solution, right-click the web application project, and
then select Publish.
Deploy by using an FTP client. In the Azure portal, download the publish profile for the web app that you want to
deploy your code to. Then, upload the files to \site\wwwroot by using the same publish profile FTP credentials.
For more information, see Deploy your app to App Service.
I see an error message when I try to deploy from Visual Studio. How do
I resolve this?
If you see the following message, you might be using an older version of the SDK: “Error during deployment for
resource 'YourResourceName' in resource group 'YourResourceGroup': MissingRegistrationForLocation: The
subscription is not registered for the resource type 'components' in the location 'Central US'. Please re-register for
this provider in order to have access to this location.”
To resolve this error, upgrade to the latest SDK. If you see this message and you have the latest SDK, submit a
support request.
How do I deploy an ASP.NET application from Visual Studio to App

Service?
The tutorial Create your first ASP.NET web app in Azure in five minutes shows you how to deploy an ASP.NET web
application to a web app in App Service by using Visual Studio 2017.
What are the different types of deployment credentials?

App Service supports two types of credentials for local Git deployment and FTP/S deployment. For more
information about how to configure deployment credentials, see Configure deployment credentials for App Service.
What is the file or directory structure of my App Service web app?

For information about the file structure of your App Service app, see File structure in Azure.
How do I resolve "FTP Error 550 - There is not enough space on the
disk" when I try to FTP my files?
If you see this message, it's likely that you are running into a disk quota in the service plan for your web app. You
might need to scale up to a higher service tier based on your disk space needs. For more information about pricing
plans and resource limits, see App Service pricing.
How do I set up continuous deployment for my App Service web app?

You can set up continuous deployment from several resources, including Visual Studio Team Services, OneDrive,
GitHub, Bitbucket, Dropbox, and other Git repositories. These options are available in the portal. Continuous
deployment to App Service is a helpful tutorial that explains how to set up continuous deployment.
How do I troubleshoot issues with continuous deployment from GitHub

and Bitbucket?
For help investigating issues with continuous deployment from GitHub or Bitbucket, see Investigating continuous
deployment.
I can't FTP to my site and publish my code. How do I resolve this?

To resolve FTP issues:
1. Verify that you are entering the correct host name and credentials. For detailed information about different types
of credentials and how to use them, see Deployment credentials.
2. Verify that the FTP ports are not blocked by a firewall. The ports should have these settings:
FTP control connection port: 21
FTP data connection port: 989, 10001-10300
How do I publish my code to App Service?

The Azure Quickstart is designed to help you deploy your app by using the deployment stack and method of your
choice. To use the Quickstart, in the Azure portal, go to Settings > App Deployment.
Why does my app sometimes restart after deployment to App Service?

To learn about the circumstances under which an application deployment might result in a restart, see Deployment
vs. runtime issues. As the article describes, App Service deploys files to the wwwroot folder. It never directly restarts
your app.
How do I integrate Visual Studio Team Services code with App Service?
You have two options for using continuous deployment with Visual Studio Team Services:
Use a Git project. Connect via App Service by using the deployment options for that repo.
Use a Team Foundation Version Control (TFVC) project. Deploy by using the build agent for App Service.
Continuous code deployment for both these options depends on existing developer workflows and check-in
procedures. For more information, see these articles:
Implement continuous deployment of your app to an Azure website
Set up a Visual Studio Team Services account so it can deploy to a web app
How do I use FTP or FTPS to deploy my app to App Service?

For information about using FTP or FTPS to deploy your web app to App Service, see Deploy your app to App
Service by using FTP/S.
Open-source technologies FAQs for Web Apps in
Azure
This article has answers to frequently asked questions (FAQs) about issues with open-source technologies for the
Web Apps feature of Azure App Service.
My ClearDB database is down. How do I resolve this?

For database-related issues, contact ClearDB support.
For answers to common questions about ClearDB, see ClearDB FAQs.
Why wasn't my ClearDB database migrated during my subscription

migration?
When you perform resource migration across subscriptions, some limitations apply. A ClearDB MySQL database is
a third-party service and is not migrated during an Azure subscription migration.
If you don't manage the migration of your MySQL database before you migrate your Azure resources, your ClearDB
MySQL database might be unavailable. To avoid this, first, manually migrate your ClearDB database, and then
migrate the Azure subscription for your web app.
For more information, see FAQs for ClearDB MySQL databases with Azure App Service.
How do I turn on PHP logging to troubleshoot PHP issues?

To turn on PHP logging:
2. In the top menu, select Debug Console > CMD.
3. Select the Site folder.
4. Select the wwwroot folder.
5. Select the + icon, and then select New File.
6. Set the file name to .user.ini.
7. Select the pencil icon next to .user.ini.
8. In the file, add this code: log_errors=on
9. Select Save.
10. Select the pencil icon next to wp-config.php.
11. Change the text to the following code:
//Enable WP_DEBUG modedefine('WP_DEBUG', true);//Enable debug logging to /wp-
content/debug.logdefine('WP_DEBUG_LOG', true); //Supress errors and warnings to
screendefine('WP_DEBUG_DISPLAY', false);//Supress PHP errors to screenini_set('display_errors', 0);
12. In the Azure portal, in the web app menu, restart your web app.
For more information, see Enable WordPress error logs.
How do I log Python application errors in apps that are hosted in App
Service?
To capture Python application errors:
1. In the Azure portal, in your web app, select Settings.
2. On the Settings tab, select Application settings.
3. Under App settings, enter the following key/value pair:
Key : WSGI_LOG
Value : D:\home\site\wwwroot\logs.txt (enter your choice of file name)
You should now see errors in the logs.txt file in the wwwroot folder.
How do I change the version of the Node.js application that is hosted in

App Service?
To change the version of the Node.js application, you can use one of the following options:
In the Azure portal, use App settings.
2. On the Settings blade, select Application settings.
3. In App settings, you can include WEBSITE_NODE_DEFAULT_VERSION as the key, and the version of
Node.js you want as the value.
4. Go to your Kudu console.
5. To check the Node.js version, enter the following command:
node -v
Modify the iisnode.yml file. Changing the Node.js version in the iisnode.yml file only sets the runtime
environment that iisnode uses. Your Kudu cmd and others still use the Node.js version that is set in App
settings in the Azure portal.
To set the iisnode.yml manually, create an iisnode.yml file in your app root folder. In the file, include the
following line:
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\5.9.1\node.exe"
Set the iisnode.yml file by using package.json during source control deployment. The Azure source control
deployment process involves the following steps:
1. Moves content to the Azure web app.
2. Creates a default deployment script, if there isn’t one (deploy.cmd, .deployment files) in the web app root
folder.
3. Runs a deployment script in which it creates an iisnode.yml file if you mention the Node.js version in the
package.json file > engine "engines": {"node": "5.9.1","npm": "3.7.3"}
4. The iisnode.yml file has the following line of code:
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\5.9.1\node.exe"
I see the message "Error establishing a database connection" in my

WordPress app that's hosted in App Service. How do I troubleshoot
this?
If you see this error in your Azure WordPress app, to enable php_errors.log and debug.log, complete the steps
detailed in Enable WordPress error logs.
When the logs are enabled, reproduce the error, and then check the logs to see if you are running out of
connections:
[09-Oct-2015 00:03:13 UTC] PHP Warning: mysqli_real_connect(): (HY000/1226): User ‘abcdefghijk79' has exceeded
the ‘max_user_connections’ resource (current value: 4) in D:\home\site\wwwroot\wp-includes\wp-db.php on line
1454
If you see this error in your debug.log or php_errors.log files, your app is exceeding the number of connections. If
you’re hosting on ClearDB, verify the number of connections that are available in your service plan.
How do I debug a Node.js app that's hosted in App Service?

1. Go to your Kudu console.
2. Go to your application logs folder (D:\home\LogFiles\Application).
3. In the logging_errors.txt file, check for content.
How do I install native Python modules in an App Service web app or

API app?
Some packages might not install by using pip in Azure. The package might not be available on the Python Package
Index, or a compiler might be required (a compiler is not available on the computer that is running the web app in
App Service). For information about installing native modules in App Service web apps and API apps, see Install
Python modules in App Service.
How do I deploy a Django app to App Service by using Git and the new
version of Python?
For information about installing Django, see Deploying a Django app to App Service.
Where are the Tomcat log files located?

For Azure Marketplace and custom deployments:
Folder location: D:\home\site\wwwroot\bin\apache-tomcat-8.0.33\logs
Files of interest:
catalina.yyyy-mm-dd.log
host-manager.yyyy-mm-dd.log
localhost.yyyy-mm-dd.log
manager.yyyy-mm-dd.log
site_access_log.yyyy-mm-dd.log
For portal App settings deployments:
Folder location: D:\home\LogFiles
Files of interest:
catalina.yyyy-mm-dd.log
host-manager.yyyy-mm-dd.log
localhost.yyyy-mm-dd.log
manager.yyyy-mm-dd.log
site_access_log.yyyy-mm-dd.log
How do I troubleshoot JDBC driver connection errors?
You might see the following message in your Tomcat logs:
The web application[ROOT] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when
the web application was stopped. To prevent a memory leak,the JDBC Driver has been forcibly unregistered
To resolve the error:

1. Remove the sqljdbc*.jar file from your app/lib folder.
2. If you are using the custom Tomcat or Azure Marketplace Tomcat web server, copy this .jar file to the Tomcat lib
folder.
3. If you are enabling Java from the Azure portal (select Java 1.8 > Tomcat server), copy the sqljdbc.* jar file in
the folder that's parallel to your app. Then, add the following classpath setting to the web.config file:
<httpPlatform>
<environmentVariables>
<environmentVariablename ="JAVA_OPTS" value=" -Djava.net.preferIPv4Stack=true
-Xms128M -classpath %CLASSPATH%;[Path to the sqljdbc*.jarfile]" />
</environmentVariables>
</httpPlatform>
Why do I see errors when I attempt to copy live log files?

If you try to copy live log files for a Java app (for example, Tomcat), you might see this FTP error:
Error transferring file [filename] Copying files from remote side failed.
The process cannot access the file because it is being used by another process.
The error message might vary, depending on the FTP client.

All Java apps have this locking issue. Only Kudu supports downloading this file while the app is running.
Stopping the app allows FTP access to these files.
Another workaround is to write a WebJob that runs on a schedule and copies these files to a different directory. For
a sample project, see the CopyLogsJob project.
Where do I find the log files for Jetty?

For Marketplace and custom deployments, the log file is in the D:\home\site\wwwroot\bin\jetty-distribution-
9.1.2.v20140210\logs folder. Note that the folder location depends on the version of Jetty you are using. For
example, the path provided here is for Jetty 9.1.2. Look for jetty_YYYY_MM_DD.stderrout.log.
For portal App Setting deployments, the log file is in D:\home\LogFiles. Look for jetty_YYYY_MM_DD.stderrout.log
Can I send email from my Azure web app?

App Service doesn't have a built-in email feature. For some good alternatives for sending email from your app, see
this Stack Overflow discussion.
Why does my WordPress site redirect to another URL?

If you have recently migrated to Azure, WordPress might redirect to the old domain URL. This is caused by a setting
in the MySQL database.
WordPress Buddy+ is an Azure Site Extension that you can use to update the redirection URL directly in the
database. For more information about using WordPress Buddy+, see WordPress tools and MySQL migration with
WordPress Buddy+.
Alternatively, if you prefer to manually update the redirection URL by using SQL queries or PHPMyAdmin, see
WordPress: Redirecting to wrong URL.
How do I change my WordPress sign-in password?

If you have forgotten your WordPress sign-in password, you can use WordPress Buddy+ to update it. To reset your
password, install the WordPress Buddy+ Azure Site Extension, and then complete the steps described in WordPress
tools and MySQL migration with WordPress Buddy+.
I can't sign in to WordPress. How do I resolve this?

If you find yourself locked out of WordPress after recently installing a plugin, you might have a faulty plugin.
WordPress Buddy+ is an Azure Site Extension that can help you disable plugins in WordPress. For more
information, see WordPress tools and MySQL migration with WordPress Buddy+.
How do I migrate my WordPress database?

You have multiple options for migrating the MySQL database that's connected to your WordPress website:
Developers: Use the command prompt or PHPMyAdmin
Non-developers: Use WordPress Buddy+
How do I help make WordPress more secure?

To learn about security best practices for WordPress, see Best practices for WordPress security in Azure.
I am trying to use PHPMyAdmin, and I see the message “Access

denied.” How do I resolve this?
You might experience this issue if the MySQL in-app feature isn't running yet in this App Service instance. To
resolve the issue, try to access your website. This starts the required processes, including the MySQL in-app process.
To verify that MySQL in-app is running, in Process Explorer, ensure that mysqld.exe is listed in the processes.
After you ensure that MySQL in-app is running, try to use PHPMyAdmin.
I get an HTTP 403 error when I try to import or export my MySQL in-
app database by using PHPMyadmin. How do I resolve this?
If you are using an older version of Chrome, you might be experiencing a known bug. To resolve the issue, upgrade
to a newer version of Chrome. Also try using a different browser, like Internet Explorer or Edge, where the issue
does not occur.
Configuration and management FAQs for Web Apps
in Azure
This article has answers to frequently asked questions (FAQs) about configuration and management issues for the
Web Apps feature of Azure App Service.
Are there limitations I should be aware of if I want to move App Service

resources?
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.
How do I use a custom domain name for my web app?

For answers to common questions about using a custom domain name with your Azure web app, see our seven-
minute video Add a custom domain name. The video offers a walkthrough of how to add a custom domain name. It
describes how to use your own URL instead of the *.azurewebsites.net URL with your App Service web app. You
also can see a detailed walkthrough of how to map a custom domain name.
How do I purchase a new custom domain for my web app?

To learn how to purchase and set up a custom domain for your App Service web app, see Buy and configure a
custom domain name in App Service.
How do I upload and configure an existing SSL certificate for my web

app?
To learn how to upload and set up an existing custom SSL certificate, see Bind an existing custom SSL certificate to
an Azure web app.
How do I purchase and configure a new SSL certificate in Azure for my

web app?
To learn how to purchase and set up an SSL certificate for your App Service web app, see Add an SSL certificate to
your App Service app.
How do I move Application Insights resources?

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.
Where can I find a guidance checklist and learn more about resource
move operations?
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.
How do I set the server time zone for my web app?

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.
Why do my continuous WebJobs sometimes fail?

By default, web apps are unloaded if they are idle for a set period of time. This lets the system conserve resources.
In Basic and Standard plans, you can turn on the Always On setting to keep the web app loaded all the time. If your
web app runs continuous WebJobs, you should turn on Always On, or the WebJobs might not run reliably. For
more information, see Create a continuously running WebJob.
How do I get the outbound IP address for my web app?

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.
If your website is hosted in App Service Environment for PowerApps, to learn how to get your outbound IP address,
see Outbound network addresses.
How do I get a reserved or dedicated inbound IP address for my web

app?
To set up a dedicated or reserved IP address for inbound calls made to your Azure app website, install and
configure an IP-based 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.
Can I export my App Service certificate to use outside Azure, such as

for a website hosted elsewhere?
App Service certificates are considered Azure resources. They are not intended to use outside your Azure services.
You cannot export them to use outside Azure. For more information, see FAQs for App Service certificates and
custom domains.
Can I export my App Service certificate to use with other Azure cloud
services?
The portal provides a first-class experience for deploying an App Service certificate through Azure Key Vault to App
Service apps. However, we have been receiving requests from customers to use these certificates outside the App
Service platform, for example, with Azure Virtual Machines. To learn how to create a local PFX copy of your App
Service certificate so you can use the certificate with other Azure resources, see Create a local PFX copy of an App
Service certificate.
For more information, see FAQs for App Service certificates and custom domains.
Why do I see the message "Partially Succeeded" when I try to back up

my web app?
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.
How do I remove a header from the HTTP response?

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.
Is App Service compliant with PCI Standard 3.0 and 3.1?

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 Microsoft Azure App Service web app compliance with PCI Standard 3.0 and 3.1.
How do I use the staging environment and deployment slots?

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.
How do I access and review WebJob logs?

To review WebJob logs:
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.
I'm trying to use Hybrid Connections with SQL Server. Why do I see the
message "System.OverflowException: Arithmetic operation resulted in
an overflow"?
If you use Hybrid Connections to access SQL Server, a Microsoft .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.
How do I add or edit a URL rewrite rule?

To add or edit a URL rewrite rule:
1. Set up Internet Information Services (IIS) Manager so that it connects to your App Service web app. To learn how
to connect IIS Manager to App Service, see Remote administration of Azure websites by using IIS Manager.
2. In IIS Manager, add or edit a URL rewrite rule. To learn how to add or edit a URL rewrite rule, see Create rewrite
rules for the URL rewrite module.
How do I control inbound traffic to App Service?

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.
How do I block ports in an App Service web app?

In the App Service shared tenant environment, it is not possible to block specific ports because of the nature of the
infrastructure. TCP ports 4016, 4018, and 4020 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.
How do I capture an F12 trace?

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 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.
Why do I get an error when I try to connect an App Service web app to
a virtual network that is connected to ExpressRoute?
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.
How do I connect an App Service web app to a virtual network that has
a static routing (policy-based) gateway?
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.
In my App Service Environment, why can I create only one App Service
plan, even though I have two workers available?
To provide fault tolerance, App Service Environment requires that each worker pool needs at least one additional
compute resource. The additional compute resource cannot be assigned a workload.
For more information, see How to create an App Service Environment.
Why do I see timeouts when I try to create an App Service

Environment?
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.
Why can't I delete my App Service plan?

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.
How do I schedule a WebJob?

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}" }
For more information about scheduled WebJobs, see Create a scheduled WebJob by using a Cron expression.
How do I perform penetration testing for my App Service app?

To perform penetration testing, submit a request.
How do I configure a custom domain name for an App Service web app
that uses Traffic Manager?
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.
My App Service certificate is flagged for fraud. How do I resolve this?

During the domain verification of an App Service certificate purchase, you might see the following message:
“Your certificate has been flagged for possible fraud. The request is currently under review. If the certificate does not
become usable within 24 hours, please contact Azure Support.”
As the message indicates, this fraud verification process might take up to 24 hours to complete. During this time,
you'll continue to see the message.
If your App Service certificate continues to show this message after 24 hours, please run the following PowerShell
script. The script contacts the certificate provider directly to resolve the issue.
Login-AzureRmAccount
Set-AzureRmContext -SubscriptionId <subId>
$actionProperties = @{
"Name"= "<Customer Email Address>"
};
Invoke-AzureRmResourceAction -ResourceGroupName "<App Service Certificate Resource Group Name>" -ResourceType
Microsoft.CertificateRegistration/certificateOrders -ResourceName "<App Service Certificate Resource Name>" -
Action resendRequestEmails -Parameters $actionProperties -ApiVersion 2015-08-01 -Force
How do authentication and authorization work in App Service?

For detailed documentation for authentication and authorization in App Service, see docs for various identify
provider sign-ins:
Azure Active Directory
Facebook
Google
Microsoft Account
Twitter
How do I redirect the default *.azurewebsites.net domain to my Azure

web app's custom domain?
When you create a new website by using Web Apps in Azure, a default sitename.azurewebsites.net 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 *.azurewebsites.net 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.
How do I determine which version of .NET version is installed in App

Service?
The quickest way to find the version of Microsoft .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.
Why isn't Autoscale working as expected?

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.
Why does Autoscale sometimes scale only partially?

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.
How do I turn on HTTP compression for my content?

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.
How do I migrate from an on-premises environment to App Service?

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.

20180116-Azure Webapp Toc

Uploaded by

Copyright:

Available Formats

20180116-Azure Webapp Toc

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

20180116-Azure Webapp Toc

Uploaded by

Copyright:

Available Formats

Table of Contents

App Service on Linux

Why use Web Apps?

LANGUAGE SUPPORTED VERSIONS

Node.js 4.4, 4.5, 6.2, 6.6, 6.9-6.11, 8.0, 8.1

PHP 5.6, 7.0

.NET Core 1.0, 1.1

Console, Publishing, and Debugging

APP SERVICE (WEB CLOUD SERVICES VIRTUAL

Multiple X X X Service Fabric

Automatic OS X X Partially through

Deploy code with X X

Deploy code with X X Cloud Services

Host web or web X X X X

Host middle tier X X X X App Service web

Support for X X X X Service Fabric

Scale out to X X X X Virtual Machines

Support for SSL X X X X For App Service

Deploy code with X X X X

Network isolation X X X X See also Azure

Install any X X X Service Fabric

Can listen to ETW X X X

Scenarios and recommendations

Create the app locally

Create a new .NET Core web app.

dotnet new web

Run the app locally

Open a web browser, and navigate to the app at http://localhost:5000 .

Launch Azure Cloud Shell

Click Try It in the upper right corner of a code block.

Create a deployment user

az webapp deployment user set --user-name <username> --password <password>

Create a resource group

az group create --name myResourceGroup --location "West Europe"

Create an Azure App Service plan

az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku S1 --is-linux

Create a web app

Local git is configured with url of 'https://<username>@<app_name>.scm.azurewebsites.net/<app_name>.git'

git remote add azure <deploymentLocalGitUrl-from-create-step>

git push azure master

Counting objects: 22, done.

Browse to the app

Update and redeploy the code

await context.Response.WriteAsync("Hello Azure!");

git commit -am "updated output"

Manage your new Azure web app

az group delete --name myResourceGroup

This command may take a minute to run.

Download the sample

git clone https://github.com/Azure-Samples/php-docs-hello-world

Run the app locally

Open a web browser, and navigate to the sample app at http://localhost:8080 .

In your terminal window, press Ctrl+C to exit the web server.

Launch Azure Cloud Shell

Click Try It in the upper right corner of a code block.

Create a deployment user

az webapp deployment user set --user-name <username> --password <password>

Create a resource group

az group create --name myResourceGroup --location "West Europe"

Create an Azure App Service plan