SQL

Table of Contents
Overview
What is SQL Server on Azure VMs?
Pricing
FAQ
Get Started
Provision a VM in the Azure Portal
Provision a VM using Azure PowerShell
Connect to a VM
Migrate a SQL Server database
How to
Configure High Availability
High availability options
Always On availability group
Failover Cluster Instance
Manage
Use the SQL Server IaaS Agent Extension
Automated Patching
Configure Azure Key Vault Integration
Security Considerations
Backup and restore
Backup and Restore
Automated Backup
Use Azure Storage for Backup and Restore
Performance best practices
Configure storage
Application patterns
Reference
PowerShell
Azure CLI
T-SQL
SQL Server Drivers
REST
Resources
Azure Roadmap
MSDN forum
Pricing calculator
SQL Server Data Tools (SSDT)
SQL Server Management Studio (SSMS)
SQL Server Tools
Stack Overflow
Overview of SQL Server on Azure Virtual Machines
6/27/2017 6 min to read Edit Online
This topic describes your options for running SQL Server on Azure virtual machines (VMs), along with links to
portal images and an overview of common tasks.
NOTE
If you're already familiar with SQL Server and just want to see how to deploy a SQL Server VM, see Provision a SQL Server
virtual machine in the Azure portal.
Overview
If you are a database administrator or a developer, Azure VMs provide a way to move your on-premises SQL
Server workloads and applications to the Cloud. The following video provides a technical overview of SQL Server
Azure VMs.
The video covers the following areas:
TIME AREA
00:21 What are Azure VMs?
01:45 Security
02:50 Connectivity
03:30 Storage reliability and performance
05:20 VM sizes
05:54 High availability and SLA
07:30 Configuration support
08:00 Monitoring
08:32 Demo: Create a SQL Server 2016 VM

NOTE
The video focuses on SQL Server 2016, but Azure provides VM images for many versions of SQL Server, including 2012,
2014, and 2016.
Scenarios
There are many reasons that you might choose to host your data in Azure. If your application is moving to Azure,
it improves performance to also move the data. But there are other benefits. You automatically have access to
multiple data centers for a global presence and disaster recovery. The data is also highly secured and durable.
SQL Server running on Azure VMs is one option for storing your relational data in Azure. It is good choice for
several scenarios. For example, you might want to configure the Azure VM as similarly as possible to an on-
premises SQL Server machine. Or you might want to run additional applications and services on the same
database server. There are two main resources that can help you think through even more scenarios and
considerations:
SQL Server on Azure virtual machines provides an overview of the best scenarios for using SQL Server on
Azure VMs.
Choose a cloud SQL Server option: Azure SQL (PaaS) Database or SQL Server on Azure VMs (IaaS) provides a
detailed comparison between SQL Database and SQL Server running on a VM.
Create a new SQL VM

The following sections provide direct links to the Azure portal for the SQL Server virtual machine gallery images.
Depending on the image you select, you can either pay for SQL Server licensing costs on a per-minute basis, or
you can bring your own license (BYOL).
Find step-by-step guidance for creating a new SQL VM in the tutorial, Provision a SQL Server virtual machine in
the Azure portal. Also, review the Performance best practices for SQL Server VMs, which explains how to select
the appropriate machine size and other features available during provisioning.
Option 1: Create a SQL VM with per-minute licensing

The following table provides a matrix of the latest SQL Server images in the virtual machine gallery. Click on any
link to begin creating a new SQL VM with your specified version, edition, and operating system.
TIP
To understand the VM and SQL pricing for these images, see Pricing guidance for SQL Server Azure VMs.
VERSION OPERATING SYSTEM EDITION
SQL Server 2016 SP1 Windows Server 2016 Enterprise, Standard, Web, Express,
Developer
SQL Server 2014 SP2 Windows Server 2012 R2 Enterprise, Standard, Web, Express
SQL Server 2012 SP3 Windows Server 2012 R2 Enterprise, Standard, Web, Express
In addition to this list, other combinations of SQL Server versions and operating systems are available. Find other
images through a marketplace search in the Azure portal.
Option 2: Create a SQL VM with an existing license
You can also bring your own license (BYOL). In this scenario, you only pay for the VM without any additional
charges for SQL Server licensing. To use your own license, use the matrix of SQL Server versions, editions, and
operating systems below. In the portal, these image names are prefixed with {BYOL}.
TIP
Bringing your own license can save you money over time for continuous production workloads. For more information, see
Pricing guidance for SQL Server Azure VMs.
VERSION OPERATING SYSTEM EDITION
SQL Server 2016 SP1 Windows Server 2016 Enterprise BYOL, Standard BYOL
SQL Server 2014 SP2 Windows Server 2012 R2 Enterprise BYOL, Standard BYOL
SQL Server 2012 SP2 Windows Server 2012 R2 Enterprise BYOL, Standard BYOL
In addition to this list, other combinations of SQL Server versions and operating systems are available. Find other
images through a marketplace search in the Azure portal (search for "{BYOL} SQL Server").
IMPORTANT
To use BYOL VM images, you must have an Enterprise Agreement with License Mobility through Software Assurance on
Azure. You also need a valid license for the version/edition of SQL Server you want to use. You must provide the necessary
BYOL information to Microsoft within 10 days of provisioning your VM.
NOTE
It is not possible to change the licensing model of a pay-per-minute SQL Server VM to use your own license. In this case,
you must create a new BYOL VM and migrate your databases to the new VM.
Manage your SQL VM

After provisioning your SQL Server VM, there are several optional management tasks. In many aspects, you
configure and manage SQL Server exactly like you would manage an on-premises SQL Server instance.
However, some tasks are specific to Azure. The following sections highlight some of these areas with links to
more information.
Connect to the VM
One of the most basic management steps is to connect to your SQL Server VM through tools, such as SQL Server
Management Studio (SSMS). For instructions on how to connect to your new SQL Server VM, see Connect to a
SQL Server Virtual Machine on Azure.
Migrate your data
If you have an existing database, you'll want to move that to the newly provisioned SQL VM. For a list of
migration options and guidance, see Migrating a Database to SQL Server on an Azure VM.
Configure high availability
If you require high availability, consider configuring SQL Server Availability Groups. This involves multiple Azure
VMs in a virtual network. The Azure portal has a template that sets up this configuration for you. For more
information, see Configure an AlwaysOn availability group in Azure Resource Manager virtual machines. If you
want to manually configure your Availability Group and associated listener, see Configure AlwaysOn Availability
Groups in Azure VM.
For other high availability considerations, see High Availability and Disaster Recovery for SQL Server in Azure
Virtual Machines.
Back up your data
Azure VMs can take advantage of Automated Backup, which regularly creates backups of your database to blob
storage. You can also manually use this technique. For more information, see Use Azure Storage for SQL Server
Backup and Restore. For an overview of all backup and restore options, see Backup and Restore for SQL Server in
Azure Virtual Machines.
Automate updates
Azure VMs can use Automated Patching to schedule a maintenance window for installing important windows
and SQL Server updates automatically.
Customer experience improvement program (CEIP)
The Customer Experience Improvement Program (CEIP) is enabled by default. This periodically sends reports to
Microsoft to help improve SQL Server. There is no management task required with CEIP unless you want to
disable it after provisioning. You can customize or disable the CEIP by connecting to the VM with remote
desktop. Then run the SQL Server Error and Usage Reporting utility. Follow the instructions to disable
reporting.
For more information, see the CEIP section of the Accept License Terms topic.
Next steps
For questions about pricing, see Pricing guidance for SQL Server Azure VMs and the Azure pricing page. Select
your target edition of SQL Server in the OS/Software list. Then view the prices for differently sized virtual
machines.
More question? First, see the SQL Server on Azure Virtual Machines FAQ. But also add your questions or
comments to the bottom of any SQL VM topics to interact with Microsoft and the community.
Pricing guidance for SQL Server Azure VMs
This topic provides pricing guidance for SQL Server virtual machines in Azure. There are several options that affect
cost, and it is important to pick the right image that balances costs with business requirements.
Free-licensed SQL Server editions

If you want to develop, test, or build a proof of concept, then use the free-licensed SQL Server Developer edition.
This edition has everything in SQL Server Enterprise edition, thus you can use it to build whatever application you
want. Its just not allowed to run in production. A SQL Server Developer VM will only charge for the cost of the VM,
not for SQL Server licensing.
If you want to run a lightweight workload in production (<4 cores, <1 GB memory, <10 GB/database), then use the
free-licensed SQL Server Express edition. A SQL Express VM will only charge for the cost of the VM, not SQL
licensing.
For these development/test or lightweight production workloads, you can also save money by choosing a smaller
VM size that matches these workloads. The DS1v2 might be a good choice for these workloads.
To create a SQL Server 2016 Azure VM with one of these images, see the following links:
SQL Server 2016 Developer Azure VM
SQL Server 2016 Express Azure VM
Paid SQL Server editions

If you have a non-lightweight production workload, use one of the following SQL Server editions:
SQL SERVER EDITION WORKLOAD
Web Small web sites
Standard Small to medium workloads
Enterprise Large or mission-critical workloads
You have two options to pay for SQL Server licensing for these editions: pay per usage or bring your own license.
Pay per usage
Paying the SQL Server license per usage means that the per-minute cost of running the Azure VM includes the
cost of the SQL Server license. You can see the pricing for the different SQL Server editions (Web, Standard,
Enterprise) in the Azure VM pricing page. The cost is the same for all versions of SQL Server (2008 R2 to 2016). As
with SQL Server licensing in general, the per-minute licensing cost depends on the number of VM cores.
Paying the SQL Server licensing per usage is recommended for:
Temporary or periodic workloads. For example, an app that needs to support an event for a couple of months
every year, or business analysis on Mondays.
Workloads with unknown lifetime or scale. For example, an app that may not be required in a few months, or
which may require more, or less compute power, depending on demand.
To create a SQL Server 2016 Azure VM with one of these pay-per-usage images, see the following links:
SQL Server 2016 Web Azure VM
SQL Server 2016 Standard Azure VM
SQL Server 2016 Enterprise Azure VM
IMPORTANT
When you create a SQL Server virtual machine in the Azure portal, the estimated monthly cost displayed on the Choose a
size blade does not include SQL Server licensing costs. This is the cost of the VM alone.
For the free-licensed Express and Developer editions of SQL Server, this is the total estimated cost. But for Web, Standard,
and Enterprise, find the additional SQL licensing costs on the Windows Virtual Machines pricing page. On the pricing page,
select your target edition of SQL Server.
Bring your own license (BYOL )

Bringing your own SQL Server license through License Mobility, also referred to as BYOL, means using an
existing SQL Server Volume License with Software Assurance in an Azure VM. A SQL Server VM using BYOL will
only charge for the cost of running the VM, not for SQL Server licensing, given that you have already acquired
licenses and Software Assurance through a Volume Licensing program.
Bringing your own SQL licensing through License Mobility is recommended for:
Continuous workloads. For example, an app that needs to support business operations 24x7.
Workloads with known lifetime and scale. For example, an app that will be required for the whole year and
which demand has been forecasted.
To use BYOL with a SQL Server VM, you must have a license for SQL Server Standard or Enterprise and Software
Assurance, which is a required option through some Volume Licensing programs and an optional purchase with
others. The pricing levels provided through Volume Licensing programs varies, based on the type of agreement
and the quantity and or commitment to SQL Server. But as a rule of thumb, bringing your own license for
continuous production workloads has the following benefits:
BYOL BENEFIT DESCRIPTION
Cost savings Bringing your own SQL Server license is more cost effective
than paying it per usage if a workload will run continuously
SQL Server Standard or Enterprise for more than 10 months.
Long-term savings On average, it is 30% cheaper per year to buy or renew a SQL
Server license for the first 3 years. Furthermore, after 3 years,
you dont need to renew the license anymore, just pay for
Software Assurance. At that point, it is 200% cheaper.
Free passive secondary replica Another benefit of bringing your own license is the free
licensing for one passive secondary replica per SQL Server for
high availability purposes. This cuts in half the licensing cost of
a highly available SQL Server deployment (e.g. using Always
On Availability Groups). The rights to run the passive
secondary are provided through the Fail-Over Servers
Software Assurance benefit.
To create a SQL Server 2016 Azure VM with one of these bring-your-own-license images, see the VMs prefixed
with "{BYOL}":
SQL Server 2016 Enterprise Azure VM
SQL Server 2016 Standard Azure VM
NOTE
Please let us know within 10 days how many SQL Server licenses youll use in Azure. The links to the previous images have
instructions on how to do this.
Avoid unecessary costs

If you are using any workloads that do not run continuously, consider shutting down the virtual machine during
the inactive periods. You only pay for what you use.
For example, if you are simply trying out SQL Server on an Azure VM, you would not want to incur charges by
accidentally leaving it running for weeks. One solution is to use the automatic shutdown feature.
Automatic shutdown is part of a larger set of similar features provided by Azure DevTest Labs.
For other workflows, consider automatically shutting down and restarting Azure VMs with a scripting solution,such
as Azure Automation.
IMPORTANT
Shutting down and deallocating your VM is the only way to avoid charges. Simply stopping or using power options to shut
down the VM still incurs usage charges.
Next steps
For general Azure pricing guidance, see Prevent unexpected costs with Azure billing and cost management.
For the latest Virtual Machines pricing, including SQL Server, see the Azure VM pricing page.
Review other SQL Server Virtual Machine topics at SQL Server on Azure Virtual Machines Overview.
Frequently asked questions for SQL Server on Azure
Virtual Machines
This topic provides answers to some of the most common questions about running SQL Server on Azure Virtual
Machines.
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.
Frequently Asked Questions

1. How do I create an Azure virtual machine with SQL Server?
The easiest solution is to create a Virtual Machine that includes SQL Server. For a tutorial on signing up for
Azure and creating a SQL VM from the portal, see Provision a SQL Server virtual machine in the Azure
Portal. You can select a virtual machine image that uses pay-per-minute SQL Server licensing, or you can
use an image that allows you to bring your own SQL Server license. You also have the option of manually
installing SQL Server on a VM and reusing an on-premises license. If you bring your own license, you must
have License Mobility through Software Assurance on Azure. For more information, see Pricing guidance for
SQL Server Azure VMs.
2. What is the difference between SQL VMs and the SQL Database service?
Conceptually, running SQL Server on an Azure virtual machine is not that different from running SQL Server
in a remote datacenter. In contrast, SQL Database offers database-as-a-service. With SQL Database, you do
not have access to the machines that host your databases. For a full comparison, see Choose a cloud SQL
Server option: Azure SQL (PaaS) Database or SQL Server on Azure VMs (IaaS).
3. How can I migrate my on-premises SQL Server database to the Cloud?
First create an Azure virtual machine with a SQL Server instance. Then migrate your on-premises databases
to that instance. For data migration strategies, see Migrate a SQL Server database to SQL Server in an Azure
VM.
4. Can I install a second instance of SQL Server on the same VM? Can I change installed features of
the default instance?
Yes. The SQL Server installation media is located in a folder on the C drive. Run Setup.exe from that
location to add new SQL Server instances or to change other installed features of SQL Server on the
machine. Note that some features, such as Automated Backup, Automated Patching, and Azure Key Vault
Integration, only operate against the default instance.
5. Can I uninstall the default instance of SQL Server?
Yes. But there are some considerations. As stated in the previous answer, features that rely on the SQL
Server IaaS Agent Extension only operate on the default instance. If you uninstall the default instance, the
extension continues to look for it and may generate event log errors. These errors are from the following
two sources: Microsoft SQL Server Credential Management and Microsoft SQL Server IaaS Agent.
One of the errors might be similar to the following:
A network-related or instance-specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible.
If you do decide to uninstall the default instance, also uninstall the SQL Server IaaS Agent Extension as well.
6. How do I upgrade to a new version/edition of the SQL Server in an Azure VM?
Currently, there is no in-place upgrade for SQL Server running in an Azure VM. Create a new Azure virtual
machine with the desired SQL Server version/edition, and then migrate your databases to the new server
using standard data migration techniques.
7. How can I install my licensed copy of SQL Server on an Azure VM?
There are two ways to do this. You can provision one of the virtual machine images that supports licenses.
Another option is to copy the SQL Server installation media to a Windows Server VM, and then install SQL
Server on the VM. For licensing reasons, you must have License Mobility through Software Assurance on
Azure. For more information, see Pricing guidance for SQL Server Azure VMs.
8. Can I change a VM to use my own SQL Server license if it was created from one of the pay-as-you-
go gallery images?
No. You can not switch from pay-per-minute licensing to using your own license. Create a new Azure virtual
machine using one of the BYOL images, and then migrate your databases to the new server using standard
data migration techniques.
9. Are SQL Server Failover Cluster Instances (FCI) supported on Azure VMs?
Yes. You can create a Windows Failover Cluster on Windows Server 2016 and use Storage Spaces Direct
(S2D) for the cluster storage. Alternatively, you can use third-party clustering or storage solutions as
described in High availability and disaster recovery for SQL Server in Azure Virtual Machines.
10. Do I have to pay to license SQL Server on an Azure VM if it is only being used for standby/failover?
You do not have to pay to license one SQL Server participating as a passive secondary replica in an HA
deployment, if you have Software Assurance and use License Mobility as described in Virtual Machine
Licensing FAQ.
11. How are updates and service packs applied on a SQL Server VM?
Virtual machines give you control over the host machine, including when and how you apply updates. For
the operating system, you can manually apply windows updates, or you can enable a scheduling service
called Automated Patching. Automated Patching installs any updates that are marked important, including
SQL Server updates in that category. Other optional updates to SQL Server must be installed manually.
12. Is it possible to set up configurations not shown in the virtual machine gallery (For example
Windows 2008 R2 + SQL Server 2012)?
No. For virtual machine gallery images that include SQL Server, you must select one of the provided images.
13. How do I install SQL Data tools on my Azure VM?
Download and install the SQL Data tools from Microsoft SQL Server Data Tools - Business Intelligence for
Visual Studio 2013.
Resources
For an overview of SQL Server on Azure Virtual Machines, watch the video Azure VM is the best platform for SQL
Server 2016. You can also get a good introduction in the topic, SQL Server on Azure Virtual Machines overview.
Other resources include:
Provision a SQL Server virtual machine in the Azure Portal
Migrating a Database to SQL Server on an Azure VM
High Availability and Disaster Recovery for SQL Server in Azure Virtual Machines
Performance best practices for SQL Server in Azure Virtual Machines
Application Patterns and Development Strategies for SQL Server in Azure Virtual Machines
Provision a SQL Server virtual machine in the Azure
Portal
This end-to-end tutorial shows you how to use the Azure Portal to provision a virtual machine running SQL
Server.
The Azure virtual machine (VM) gallery includes several images that contain Microsoft SQL Server. With a few
clicks, you can select one of the SQL VM images from the gallery and provision it in your Azure environment.
In this tutorial, you will:
Select a SQL VM image from the gallery
Configure and create the VM
Open the VM with Remote Desktop
Connect to SQL Server remotely
Select a SQL VM image from the gallery

1. Log in to the Azure portal using your account.
NOTE
If you do not have an Azure account, visit Azure free trial.
2. On the Azure portal, click New. The portal opens the New blade. The SQL Server VM resources are in the
Compute group of the Marketplace.
3. In the New blade, click Compute and then click See all.
4. In the Filter text box type SQL Server, and press the ENTER key.
5. Review the available SQL Server images. Each image identifies a SQL Server version and an operating
system.
6. Select the image for SQL Server 2016 SP1 Developer on Windows Server 2016.
TIP
The Developer edition is used in this tutorial because it is a full-featured edition of SQL Server that is free for
development testing purposes. You pay only for the cost of running the VM.
NOTE
SQL VM images include the licensing costs for SQL Server into the per-minute pricing of the VM you create
(except for the Developer and Express editions). SQL Server Developer is free for development/testing (not
production) and SQL Express is free for lightweight workloads (less than 1GB memory, less than 10 GB storage).
There is another option to bring-your-own-license (BYOL) and pay only for the VM. Those image names are
prefixed with {BYOL}. For more information on these options, see Pricing guidance for SQL Server Azure VMs.
7. Under Select a deployment model, verify that Resource Manager is selected. Resource Manager is the
recommended deployment model for new virtual machines. Click Create.
Configure the VM
There are five blades for configuring a SQL Server virtual machine.
STEP DESCRIPTION
Basics Configure basic settings
Size Choose virtual machine size
Settings Configure optional features
SQL Server settings Configure SQL server settings
Summary Review the summary
1. Configure basic settings

On the Basics blade, provide the following information:
Enter a unique virtual machine Name.
Specify a User name for the local administrator account on the VM. This account is also added to the SQL
Server sysadmin fixed server role.
Provide a strong Password.
If you have multiple subscriptions, verify that the subscription is correct for the new VM.
In the Resource group box, type a name for a new resource group. Alternatively, to use an existing
resource group click Use existing. A resource group is a collection of related resources in Azure (virtual
machines, storage accounts, virtual networks, etc.).
NOTE
Using a new resource group is helpful if you are just testing or learning about SQL Server deployments in Azure.
After you finish with your test, delete the resource group to automatically delete the VM and all resources
associated with that resource group. For more information about resource groups, see Azure Resource Manager
Overview.
Select a Location for this deployment.

Click OK to save the settings.
2. Choose virtual machine size

On the Size step, choose a virtual machine size in the Choose a size blade. The blade initially displays
recommended machine sizes based on the image you selected.
IMPORTANT
The estimated monthly cost displayed on the Choose a size blade does not include SQL Server licensing costs. This is the
cost of the VM alone. For the Express and Developer editions of SQL Server, this is the total estimated cost. For other
editions, see the Windows Virtual Machines pricing page and select your target edition of SQL Server. Also see the Pricing
guidance for SQL Server Azure VMs.
For production workloads, we recommend selecting a virtual machine size that supports Premium Storage. If
you do not require that level of performance, use the View all button, which shows all machine size options. For
example, you might use a smaller machine size for a development or test environment.
NOTE
For more information about virtual machine sizes see, Sizes for virtual machines. For considerations about SQL Server VM
sizes, see Performance best practices for SQL Server in Azure Virtual Machines.
Choose your machine size, and then click Select.
3. Configure optional features

On the Settings blade, configure Azure storage, networking, and monitoring for the virtual machine.
Under Storage, specify a Disk type of either Standard or Premium (SSD). Premium storage is recommended
for production workloads.
NOTE
If you select Premium (SSD) for a machine size that does not support Premium Storage, your machine size changes
automatically.
Under Storage account, you can accept the automatically provisioned storage account name. You can also
click on Storage account to choose an existing account and configure the storage account type. By default,
Azure creates a new storage account with locally redundant storage. For more information about storage
options, see Azure Storage replication.
Under Network, you can accept the automatically populated values. You can also click on each feature to
manually configure the Virtual network, Subnet, Public IP address, and Network Security Group. For the
purposes of this tutorial, keep the default values.
Azure enables Monitoring by default with the same storage account designated for the VM. You can change
these settings here.
Under Availability set, specify an availability set. For the purposes of this tutorial, you can select none. If you
plan to set up SQL AlwaysOn Availability Groups, configure the availability to avoid recreating the virtual
machine. For more information, see Manage the Availability of Virtual Machines.
When you are done configuring these settings, click OK.
4. Configure SQL server settings

On the SQL Server settings blade, configure specific settings and optimizations for SQL Server. The settings that
you can configure for SQL Server include the following.
SETTING
Connectivity
Authentication
Storage configuration
Automated Patching
Automated Backup
Azure Key Vault Integration
R Services
Connectivity
Under SQL connectivity, specify the type of access you want to the SQL Server instance on this VM. For the
purposes of this tutorial, select Public (internet) to allow connections to SQL Server from machines or services
on the internet. With this option selected, Azure automatically configures the firewall and the network security
group to allow traffic on port 1433.
To connect to SQL Server via the internet, you also must enable SQL Server Authentication, which is described in
the next section.
NOTE
It is possible to add more restrictions for the network communications to your SQL Server VM. You can do this by editing
the Network Security Group after the VM is created. For more information, see What is a Network Security Group (NSG)?
If you would prefer to not enable connections to the Database Engine via the internet, choose one of the
following options:
Local (inside VM only) to allow connections to SQL Server only from within the VM.
Private (within Virtual Network) to allow connections to SQL Server from machines or services in the
same virtual network.
NOTE
The virtual machine image for SQL Server Express edition does not automatically enable the TCP/IP protocol. This is true
even for the Public and Private connectivity options. For Express edition, you must use SQL Server Configuration Manager
to manually enable the TCP/IP protocol after creating the VM.
In general, improve security by choosing the most restrictive connectivity that your scenario allows. But all the
options are securable through Network Security Group rules and SQL/Windows Authentication.
Port defaults to 1433. You can specify a different port number. For more information, see Connect to a SQL
Server Virtual Machine (Resource Manager) | Microsoft Azure.
Authentication
If you require SQL Server Authentication, click Enable under SQL authentication.
NOTE
If you plan to access SQL Server over the internet (i.e. the Public connectivity option), you must enable SQL authentication
here. Public access to the SQL Server requires the use of SQL Authentication.
If you enable SQL Server Authentication, specify a Login name and Password. This user name is configured as
a SQL Server Authentication login and member of the sysadmin fixed server role. See Choose an Authentication
Mode for more information about Authentication Modes.
If you do not enable SQL Server Authentication, then you can use the local Administrator account on the VM to
connect to the SQL Server instance.
Click Storage configuration to specify the storage requirements.
NOTE
If you select Standard storage, this option is not available. Automatic storage optimization is available only for Premium
Storage.
You can specify requirements as input/output operations per second (IOPs), throughput in MB/s, and total
storage size. Configure these values by using the sliding scales. The portal automatically calculates the number of
disks based on these requirements.
By default, Azure optimizes the storage for 5000 IOPs, 200 MBs, and 1 TB of storage space. You can change these
storage settings based on workload. Under Storage optimized for, select one of the following options:
General is the default setting and supports most workloads.
Transactional processing optimizes the storage for traditional database OLTP workloads.
Data warehousing optimizes the storage for analytic and reporting workloads.
NOTE
The upper limits on the sliders vary depending on your selected virtual machine size.
Automated patching
Automated patching is enabled by default. Automated patching allows Azure to automatically patch SQL
Server and the operating system. Specify a day of the week, time, and duration for a maintenance window. Azure
performs patching in this maintenance window. The maintenance window schedule uses the VM locale for time.
If you do not want Azure to automatically patch SQL Server and the operating system, click Disable.
For more information, see Automated Patching for SQL Server in Azure Virtual Machines.
Automated backup
Enable automatic database backups for all databases under Automated backup. Automated backup is disabled
by default.
When you enable SQL automated backup, you can configure the following:
Retention period (days) for backups
Storage account to use for backups
Encryption option and password for backups
Backup system databases
Configure backup schedule
To encrypt the backup, click Enable. Then specify the Password. Azure creates a certificate to encrypt the
backups and uses the specified password to protect that certificate.
For more information, see Automated Backup for SQL Server in Azure Virtual Machines.
Azure Key Vault integration
To store security secrets in Azure for encryption, click Azure key vault integration and click Enable.
The following table lists the parameters required to configure Azure Key Vault Integration.
PARAMETER DESCRIPTION EXAMPLE
Key Vault URL The location of the key vault. https://contosokeyvault.vault.azure.net

/
Principal name Azure Active Directory service principal fde2b411-33d5-4e11-

name. This name is also referred to as af04eb07b669ccf2
the Client ID.
Principal secret Azure Active Directory service principal 9VTJSQwzlFepD8XODnzy8n2V01Jd8d

secret. This secret is also referred to as Ajwm/azF1XDKM=
the Client Secret.
Credential name Credential name: AKV Integration mycred1

creates a credential within SQL Server,
allowing the VM to have access to the
key vault. Choose a name for this
credential.
For more information, see Configure Azure Key Vault Integration for SQL Server on Azure VMs.
When you are finished configuring SQL Server settings, click OK.
R services
You have the option to enable SQL Server R Services. This enables you to use advanced analytics with SQL
Server 2016. Click Enable on the SQL Server Settings blade.
5. Review the summary

On the Summary blade, review the summary and click OK to create SQL Server, resource group, and resources
specified for this VM.
You can monitor the deployment from the azure portal. The Notifications button at the top of the screen shows
basic status of the deployment.
NOTE
To provide you with an idea on deployment times, I deployed a SQL VM to the East US region with default settings. This
test deployment took a total of 26 minutes to complete. But you might experience a faster or slower deployment time
based on your region and selected settings.
Open the VM with Remote Desktop

Use the following steps to connect to the virtual machine with Remote Desktop:
1. After the Azure VM is built, the icon for the VM appears on your Azure dashboard. You can also find it by
browsing your existing virtual machines. Click on your new SQL virtual machine. A Virtual machine blade
displays your virtual machine details.
2. At the top of the Virtual machine blade, click Connect.
3. The browser downloads an RDP file for the VM. Open the RDP file.
4. The Remote Desktop Connection notifies you that the publisher of this remote connection cannot be
identified. Click Connect to continue.
5. In the Windows Security dialog, click Use another account.
6. For User name type <user name>, where is the user name that you specified when you configured the VM.
You have to add an initial backslash before the name.
7. Type the Password that you previously configured for this VM, and then click OK to connect.
8. If another Remote Desktop Connection dialog asks you whether to connect, click Yes.
After you connect to the SQL Server virtual machine, you can launch SQL Server Management Studio and
connect with Windows Authentication using your local administrator credentials. If you enabled SQL Server
Authentication, you can also connect with SQL Authentication using the SQL login and password you configured
during provisioning.
Access to the machine enables you to directly change machine and SQL Server settings based on your
requirements. For example, you could configure the firewall settings or change SQL Server configuration
settings.
Connect to SQL Server remotely

In this tutorial, we selected Public access for the virtual machine and SQL Server Authentication. These
settings automatically configured the virtual machine to allow SQL Server connections from any client over the
internet (assuming they have the correct SQL login).
NOTE
If you did not select Public during provisioning, then extra steps are required to access your SQL Server instance over the
internet. For more information, see Connect to a SQL Server Virtual Machine.
The following sections show how to connect to your SQL Server instance on your VM from a different computer
over the internet.
Configure a DNS Label for the public IP address
To connect to the SQL Server Database Engine from the Internet, first configure a DNS Label for your public
IP address.
NOTE
DNS Labels are not required if you plan to only connect to the SQL Server instance within the same Virtual Network
or only locally.
To create a DNS Label, first select Virtual machines in the portal. Select your SQL Server VM to bring up its
properties.
1. In the virtual machine blade, select your Public IP address.
2. In the properties for your Public IP address, expand Configuration.
3. Enter a DNS Label name. This name is an A Record that can be used to connect to your SQL Server VM by
name instead of by IP Address directly.
4. Click the Save button.
Connect to the Database Engine from another computer

1. On a computer connected to the internet, open SQL Server Management Studio (SSMS).
2. In the Connect to Server or Connect to Database Engine dialog box, edit the Server name value.
Enter the full DNS name of the virtual machine (determined in the previous task).
3. In the Authentication box, select SQL Server Authentication.
4. In the Login box, type the name of a valid SQL login.
5. In the Password box, type the password of the login.
6. Click Connect.
Next Steps
For other information about using SQL Server in Azure, see SQL Server on Azure Virtual Machines and the
Frequently Asked Questions.
For a video overview of SQL Server on Azure Virtual Machines, watch Azure VM is the best platform for SQL
Server 2016.
Explore the Learning Path for SQL Server on Azure virtual machines.
Provision a SQL Server virtual machine using Azure
PowerShell (Resource Manager)
Overview
This tutorial shows you how to create a single Azure virtual machine using the Azure Resource Manager
deployment model using Azure PowerShell cmdlets. In this tutorial, we will create a single virtual machine using a
single disk drive from an image in the SQL Gallery. We will create new providers for the storage, network, and
compute resources that will be used by the virtual machine. If you have existing providers for any of these
resources, you can use those providers instead.
If you need the classic version of this topic, see Provision a SQL Server virtual machine using Azure PowerShell
Classic.
Prerequisites
For this tutorial you'll need:
An Azure account and subscription before you start. If you don't have one, sign up for a free trial.
Azure PowerShell), minimum version of 1.4.0 or later (this tutorial written using version 1.5.0).
To retrieve your version, type Get-Module Azure -ListAvailable.
Configure your subscription

Open Windows PowerShell and establish access to your Azure account by running the following cmdlet. You will
be presented with a sign in screen to enter your credentials. Use the same email and password that you use to sign
in to the Azure portal.
Add-AzureRmAccount
After successfully signing in you will see some information on screen that includes the SubscriptionId with which
you signed in. This is the subscription in which the resources for this tutorial will be created unless you change to a
different subscription. If you have multiple SubscriptionIds, run the following cmdlet to return a list of all of your
SubscriptionIds:
Get-AzureRmSubscription
To change to another SubscriptionID, run the following cmdlet with your desired SubscriptionId.
Select-AzureRmSubscription -SubscriptionId xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Define image variables

To simplify usability and understanding of the completed script from this tutorial, we will start by defining a
number of variables. Change the parameter values as you see fit, but beware of naming restrictions related to
name lengths and special characters when modifying the values provided.
Location and Resource Group
Use two variables to define the data region and the resource group into which you will create the other resources
for the virtual machine.
Modify as desired and then execute the following cmdlets to initialize these variables.
$Location = "SouthCentralUS"
$ResourceGroupName = "sqlvm1"
Storage properties
Use the following variables to define the storage account and the type of storage to be used by the virtual machine.
Modify as desired and then execute the following cmdlet to initialize these variables. Note that in this example, we
are using Premium Storage, which is recommended for production workloads. For details on this guidance and
other recommendations, see Performance best practices for SQL Server in Azure Virtual Machines.
$StorageName = $ResourceGroupName + "storage"

$StorageSku = "Premium_LRS"
Network properties
Use the following variables to define the network interface, the TCP/IP allocation method, the virtual network
name, the virtual subnet name, the range of IP addresses for the virtual network, the range of IP addresses for the
subnet, and the public domain name label to be used by the network in the virtual machine.
Modify as desired and then execute the following cmdlet to initialize these variables.
$InterfaceName = $ResourceGroupName + "ServerInterface"

$TCPIPAllocationMethod = "Dynamic"
$VNetName = $ResourceGroupName + "VNet"
$SubnetName = "Default"
$VNetAddressPrefix = "10.0.0.0/16"
$VNetSubnetAddressPrefix = "10.0.0.0/24"
$DomainName = "sqlvm1"
Virtual machine properties

Use the following variables to define the virtual machine name, the computer name, the virtual machine size, and
the operating system disk name for the virtual machine.
$VMName = $ResourceGroupName + "VM"

$ComputerName = $ResourceGroupName + "Server"
$VMSize = "Standard_DS13"
$OSDiskName = $VMName + "OSDisk"
Image properties
Use the following variables to define the image to use for the virtual machine. In this example, the SQL Server 2016
Enterprise image is used.
$PublisherName = "MicrosoftSQLServer"
$OfferName = "SQL2016-WS2016"
$Sku = "Enterprise"
$Version = "latest"
Note that you can get a full list of SQL Server image offerings with the Get-AzureRmVMImageOffer command:
Get-AzureRmVMImageOffer -Location 'East US' -Publisher 'MicrosoftSQLServer'
And you can see the Skus available for an offering with the Get-AzureRmVMImageSku command. The following
command shows all Skus available for the SQL2014SP1-WS2012R2 offer.
Get-AzureRmVMImageSku -Location 'East US' -Publisher 'MicrosoftSQLServer' -Offer 'SQL2014SP1-WS2012R2' |

Select Skus
Create a resource group

With the Resource Manager deployment model, the first object that you create is the resource group. We will use
the New-AzureRmResourceGroup cmdlet to create an Azure resource group and its resources with the resource
group name and location defined by the variables that you previously initialized.
Execute the following cmdlet to create your new resource group.
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location
Create a storage account

The virtual machine requires storage resources for the operating system disk and for the SQL Server data and log
files. For simplicity, we will create a single disk for both. You can attach additional disks later using the Add-Azure
Disk cmdlet in order to place your SQL Server data and log files on dedicated disks. We will use the New-
AzureRmStorageAccount cmdlet to create a standard storage account in your new resource group and with the
storage account name, storage Sku name, and location defined using the variables that you previously initialized.
Execute the following cmdlet to create your new storage account.
$StorageAccount = New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageName -SkuName

$StorageSku -Kind "Storage" -Location $Location
Create network resources

The virtual machine requires a number of network resources for network connectivity.
Each virtual machine requires a virtual network.
A virtual network must have at least one subnet defined.
A network interface must be defined with either a public or a private IP address.
Create a virtual network subnet configuration
We will start by creating a subnet configuration for our virtual network. For our tutorial, we will create a default
subnet using the New-AzureRmVirtualNetworkSubnetConfig cmdlet. We will create our virtual network subnet
configuration with the subnet name and address prefix defined using the variables that you previously initialized.
NOTE
You can define additional properties of the virtual network subnet configuration using this cmdlet, but that is beyond the
scope of this tutorial.
Execute the following cmdlet to create your virtual subnet configuration.
$SubnetConfig = New-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -AddressPrefix

$VNetSubnetAddressPrefix
Create a virtual network

Next, we will create our virtual network using the New-AzureRmVirtualNetwork cmdlet. We will create our virtual
network in your new resource group, with the name, location, and address prefix defined using the variables that
you previously initialized, and using the subnet configuration that you defined in the previous step.
Execute the following cmdlet to create your virtual network.
$VNet = New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName -Location $Location -

AddressPrefix $VNetAddressPrefix -Subnet $SubnetConfig
Create the public IP address

Now that we have our virtual network defined, we need to configure an IP address for connectivity to the virtual
machine. For this tutorial, we will create a public IP address using dynamic IP addressing to support Internet
connectivity. We will use the New-AzureRmPublicIpAddress cmdlet to create the public IP address in the resource
group created prevously and with the name, location, allocation method, and DNS domain name label defined
using the variables that you previously initialized.
NOTE
You can define additional properties of the public IP address using this cmdlet, but that is beyond the scope of this initial
tutorial. You could also create a private address or an address with a static address, but that is also beyond the scope of this
tutorial.
Execute the following cmdlet to create your public IP address.
$PublicIp = New-AzureRmPublicIpAddress -Name $InterfaceName -ResourceGroupName $ResourceGroupName -Location

$Location -AllocationMethod $TCPIPAllocationMethod -DomainNameLabel $DomainName
Create the network interface

We are now ready to create the network interface that our virtual machine will use. We will use the New-
AzureRmNetworkInterface cmdlet to create our network interface in the resource group created earlier and with
the name, location, subnet and public IP address previously defined.
Execute the following cmdlet to create your network interface.
$Interface = New-AzureRmNetworkInterface -Name $InterfaceName -ResourceGroupName $ResourceGroupName -Location

$Location -SubnetId $VNet.Subnets[0].Id -PublicIpAddressId $PublicIp.Id
Configure a VM object
Now that we have storage and network resources defined, we are ready to define compute resources for the virtual
machine. For our tutorial, we will specify the virtual machine size and various operating system properties, specify
the network interface that we previously created, define blob storage, and then specify the operating system disk.
Create the VM object
We will start by specifying the virtual machine size. For this tutorial, we are specifying a DS13. We will use the
New-AzureRmVMConfig cmdlet to create a configurable virtual machine object with the name and size defined
using the variables that you previously initialized.
Execute the following cmdlet to create the virtual machine object.
$VirtualMachine = New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize
Create a credential object to hold the name and password for the local administrator credentials
Before we can set the operating system properties for the virtual machine, we need to supply the credentials for
the local administrator account as a secure string. To accomplish this, we will use the Get-Credential cmdlet.
Execute the following cmdlet and, in the Windows PowerShell credential request window, type the name and
password to use for the local administrator account in the Windows virtual machine.
$Credential = Get-Credential -Message "Type the name and password of the local administrator account."
Set the operating system properties for the virtual machine

Now we are ready to set the virtual machine's operating system properties. We will use the Set-
AzureRmVMOperatingSystem cmdlet to set the type of operating system as Windows, require the virtual machine
agent to be installed, specify that the cmdlet enables auto update and set the virtual machine name, the computer
name, and the credential using the variables that you previously initialized.
Execute the following cmdlet to set the operating system properties for your virtual machine.
$VirtualMachine = Set-AzureRmVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $ComputerName -

Credential $Credential -ProvisionVMAgent -EnableAutoUpdate
Add the network interface to the virtual machine

Next, we will add the network interface that we created previously to the virtual machine. We will use the Add-
AzureRmVMNetworkInterface cmdlet to add the network interface using the network interface variable that you
defined earlier.
Execute the following cmdlet to set the network interface for your virtual machine.
$VirtualMachine = Add-AzureRmVMNetworkInterface -VM $VirtualMachine -Id $Interface.Id
Set the blob storage location for the disk to be used by the virtual machine
Next, we will set the blob storage location for the disk to be used by the virtual machine using the variables that
you defined earlier.
Execute the following cmdlet to set the blob storage location.
$OSDiskUri = $StorageAccount.PrimaryEndpoints.Blob.ToString() + "vhds/" + $OSDiskName + ".vhd"
Set the operating system disk properties for the virtual machine
Next, we will set the operating system disk properties for the virtual machine. We will use the Set-
AzureRmVMOSDisk cmdlet to specify that the operating system for the virtual machine will come from an image,
to set caching to read only (because SQL Server is being installed on the same disk) and define the virtual machine
name and the operating system disk defined using the variables that we defined earlier.
Execute the following cmdlet to set the operating system disk properties for your virtual machine.
$VirtualMachine = Set-AzureRmVMOSDisk -VM $VirtualMachine -Name $OSDiskName -VhdUri $OSDiskUri -Caching

ReadOnly -CreateOption FromImage
Specify the platform image for the virtual machine

Our last configuration step is to specify the platform image for our virtual machine. For our tutorial, we are using
the latest SQL Server 2016 CTP image. We will use the Set-AzureRmVMSourceImage cmdlet to use this image as
defined by the variables that you defined earlier.
Execute the following cmdlet to specify the platform image for your virtual machine.
$VirtualMachine = Set-AzureRmVMSourceImage -VM $VirtualMachine -PublisherName $PublisherName -Offer $OfferName

-Skus $Sku -Version $Version
Create the SQL VM

Now that you have finished the configuration steps, you are ready to create the virtual machine. We will use the
New-AzureRmVM cmdlet to create the virtual machine using the variables that we have defined.
Execute the following cmdlet to create your virtual machine.
New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $Location -VM $VirtualMachine
The virtual machine is created. Notice that a standard storage account is created for boot diagnostics because the
specified storage account for the virtual machine's disk is a premium storage account.
You can now view this machine in the Azure Portal to see its public IP address and its fully qualified domain name.
Example script
The following script contains the complete PowerShell script for this tutorial. It assumes that you have already
setup the Azure subscription to use with the Add-AzureRmAccount and Select-AzureRmSubscription
commands.
# Variables
## Global
$Location = "SouthCentralUS"
$ResourceGroupName = "sqlvm1"
## Storage
$StorageName = $ResourceGroupName + "storage"
$StorageSku = "Premium_LRS"
## Network
$InterfaceName = $ResourceGroupName + "ServerInterface"
$VNetName = $ResourceGroupName + "VNet"
$SubnetName = "Default"
$VNetAddressPrefix = "10.0.0.0/16"
$VNetSubnetAddressPrefix = "10.0.0.0/24"
$TCPIPAllocationMethod = "Dynamic"
$DomainName = "sqlvm1"
##Compute
$VMName = $ResourceGroupName + "VM"
$ComputerName = $ResourceGroupName + "Server"
$VMSize = "Standard_DS13"
$OSDiskName = $VMName + "OSDisk"
##Image
$PublisherName = "MicrosoftSQLServer"
$OfferName = "SQL2016-WS2016"
$Sku = "Enterprise"
$Version = "latest"
# Resource Group
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location
# Storage
$StorageAccount = New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageName -SkuName
$StorageSku -Kind "Storage" -Location $Location
# Network
$SubnetConfig = New-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -AddressPrefix
$VNetSubnetAddressPrefix
$VNet = New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName -Location $Location -
AddressPrefix $VNetAddressPrefix -Subnet $SubnetConfig
$PublicIp = New-AzureRmPublicIpAddress -Name $InterfaceName -ResourceGroupName $ResourceGroupName -Location
$Location -AllocationMethod $TCPIPAllocationMethod -DomainNameLabel $DomainName
$Interface = New-AzureRmNetworkInterface -Name $InterfaceName -ResourceGroupName $ResourceGroupName -Location
$Location -SubnetId $VNet.Subnets[0].Id -PublicIpAddressId $PublicIp.Id
# Compute
$VirtualMachine = New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize
$Credential = Get-Credential -Message "Type the name and password of the local administrator account."
$VirtualMachine = Set-AzureRmVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $ComputerName -
Credential $Credential -ProvisionVMAgent -EnableAutoUpdate #-TimeZone = $TimeZone
$VirtualMachine = Add-AzureRmVMNetworkInterface -VM $VirtualMachine -Id $Interface.Id
$OSDiskUri = $StorageAccount.PrimaryEndpoints.Blob.ToString() + "vhds/" + $OSDiskName + ".vhd"
$VirtualMachine = Set-AzureRmVMOSDisk -VM $VirtualMachine -Name $OSDiskName -VhdUri $OSDiskUri -Caching
ReadOnly -CreateOption FromImage
# Image
$VirtualMachine = Set-AzureRmVMSourceImage -VM $VirtualMachine -PublisherName $PublisherName -Offer $OfferName
-Skus $Sku -Version $Version
## Create the VM in Azure

New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $Location -VM $VirtualMachine
Next steps
After the virtual machine is created, you are ready to connect to the virtual machine using RDP and setup
connectivity. For more information, see Connect to a SQL Server Virtual Machine on Azure (Resource Manager).
Connect to a SQL Server Virtual Machine on Azure
(Resource Manager)
Overview
This topic describes how to connect to your SQL Server instance running on an Azure virtual machine. It covers
some general connectivity scenarios and then provides detailed steps for configuring SQL Server connectivity in
an Azure VM.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which Microsoft recommends for new deployments instead
of the classic deployment model.
To view the classic version of this article, see Connect to a SQL Server Virtual Machine on Azure Classic.
If you would rather have a full walk-through of both provisioning and connectivity, see Provisioning a SQL Server
Virtual Machine on Azure.
Connection scenarios
The way a client connects to SQL Server running on a Virtual Machine differs depending on the location of the
client and the machine/networking configuration. These scenarios include:
Connect to SQL Server over the internet
Connect to SQL Server in the same virtual network
Connect to SQL Server over the Internet
If you want to connect to your SQL Server database engine from the Internet, there are several steps required,
such as configuring the firewall, enabling SQL Authentication, and configuring your network security group you
must have a Network Security Group rule to allow TCP traffic on port 1433.
If you use the portal to provision a SQL Server virtual machine image with the resource manager, these steps are
done for you when you select Public for the SQL connectivity option:
If this was not one during provisioning, then you can manually configure SQL Server and your virtual machines by
following the steps in this article to manually configure connectivity.
NOTE
The virtual machine image for SQL Server Express edition does not automatically enable the TCP/IP protocol. For Express
edition, you must use SQL Server Configuration Manager to manually enable the TCP/IP protocol after creating the VM.
Once this is done, any client with internet access can connect to the SQL Server instance by specifying either the
public IP address of the virtual machine or the DNS label assigned to that IP address. If the SQL Server port is
1433, you do not need to specify it in the connection string.
"Server=sqlvmlabel.eastus.cloudapp.azure.com;Integrated Security=false;User ID=<login_name>;Password=

<your_password>"
Although this enables connectivity for clients over the internet, this does not imply that anyone can connect to
your SQL Server. Outside clients have to the correct username and password. For additional security, you can
avoid the well-known port 1433. For example, if you configured SQL Server to listen on port 1500 and established
proper firewall and network security group rules, you could connect by appending the port number to the Server
name as in the following example:
"Server=sqlvmlabel.eastus.cloudapp.azure.com,1500;Integrated Security=false;User ID=<login_name>;Password=

<your_password>"
NOTE
It is important to note that when you use this technique to communicate with SQL Server, all outgoing data from the Azure
datacenter is subject to normal pricing on outbound data transfers.
Connect to SQL Server in the same virtual network

Virtual Network enables additional scenarios. You can connect VMs in the same virtual network, even if those VMs
exist in different resource groups. And with a site-to-site VPN, you can create a hybrid architecture that connects
VMs with on-premises networks and machines.
Virtual networks also enables you to join your Azure VMs to a domain. This is the only way to use Windows
Authentication to SQL Server. The other connection scenarios require SQL Authentication with user names and
passwords.
If you use the portal to provision a SQL Server virtual machine image with the resource manager, the proper
firewall rules for communication on the virtual network are setup when you select Private for the SQL
connectivity option. If this was not one during provisioning, then you can manually configure SQL Server and your
virtual machines by following the steps in this article to manually configure connectivity. But if you are planning to
configure a domain environment and Windows Authentication, you do not need to use the steps in this article to
configure SQL Authentication and logins. You also do not need to configure Network Security Group rules for
access over the internet.
NOTE
The virtual machine image for SQL Server Express edition does not automatically enable the TCP/IP protocol. For Express
edition, you must use SQL Server Configuration Manager to manually enable the TCP/IP protocol after creating the VM.
Assuming that you have configured DNS in your virtual network, you can connect to your SQL Server instance by
specifying the SQL Server VM computer name in the connection string. The following example also assumes that
Windows Authentication has also been configured and that the user has been granted access to the SQL Server
instance.
"Server=mysqlvm;Integrated Security=true"
Note that in this scenario, you could also specify the IP address of the VM.
Steps for manually configuring SQL Server connectivity in an Azure

VM
The following steps demonstrate how to manually setup connectivity to the SQL Server instance and then
optionally connect over the internet using SQL Server Management Studio (SSMS). Note that many of these steps
are done for you when you select the appropriate SQL Server connectivity options in the portal.
Before you can connect to the instance of SQL Server from another VM or the internet, you must complete the
following tasks as described in the sections that follow:
Open TCP ports in the Windows firewall
Configure SQL Server to listen on the TCP protocol
Configure SQL Server for mixed mode authentication
Create SQL Server authentication logins
Configure a Network Security Group inbound rule
Open TCP ports in the Windows firewall for the default instance of the Database Engine
1. Connect to the virtual machine with Remote Desktop. For detailed instructions on connecting to the VM, see
Open a SQL VM with Remote Desktop.
2. Once logged in, at the Start screen, type WF.msc, and then hit ENTER.
3. In the Windows Firewall with Advanced Security, in the left pane, right-click Inbound Rules, and then
click New Rule in the action pane.
4. In the New Inbound Rule Wizard dialog box, under Rule Type, select Port, and then click Next.
5. In the Protocol and Ports dialog, use the default TCP. In the Specific local ports box, then type the port
number of the instance of the Database Engine (1433 for the default instance or your choice for the private
port in the endpoint step).
6. Click Next.
7. In the Action dialog box, select Allow the connection, and then click Next.
Security Note: Selecting Allow the connection if it is secure can provide additional security. Select this
option if you want to configure additional security options in your environment.
8. In the Profile dialog box, select Public, Private, and Domain. Then click Next.
Security Note: Selecting Public allows access over the internet. Whenever possible, select a more
restrictive profile.
9. In the Name dialog box, type a name and description for this rule, and then click Finish.
Open additional ports for other components as needed. For more information, see Configuring the Windows
Firewall to Allow SQL Server Access.
Configure SQL Server to listen on the TCP protocol
1. While connected to the virtual machine, on the Start page, type SQL Server Configuration Manager and
hit ENTER.
2. In SQL Server Configuration Manager, in the console pane, expand SQL Server Network Configuration.
3. In the console pane, click Protocols for MSSQLSERVER (he default instance name.) In the details pane,
right-click TCP and click Enable if it is not already enabled.
4. In the console pane, click SQL Server Services. In the details pane, right-click SQL Server (instance name)
(the default instance is SQL Server (MSSQLSERVER)), and then click Restart, to stop and restart the
instance of SQL Server.
5. Close SQL Server Configuration Manager.

For more information about enabling protocols for the SQL Server Database Engine, see Enable or Disable a
Server Network Protocol.
Configure SQL Server for mixed mode authentication
The SQL Server Database Engine cannot use Windows Authentication without domain environment. To connect to
the Database Engine from another computer, configure SQL Server for mixed mode authentication. Mixed mode
authentication allows both SQL Server Authentication and Windows Authentication.
NOTE
Configuring mixed mode authentication might not be necessary if you have configured an Azure Virtual Network with a
configured domain environment.
1. While connected to the virtual machine, on the Start page, type SQL Server Management Studio and click
the selected icon.
The first time you open Management Studio it must create the users Management Studio environment.
This may take a few moments.
2. Management Studio presents the Connect to Server dialog box. In the Server name box, type the name
of the virtual machine to connect to the Database Engine with the Object Explorer (Instead of the virtual
machine name you can also use (local) or a single period as the Server name). Select Windows
Authentication, and leave your_VM_name\your_local_administrator in the User name box. Click
Connect.
3. In SQL Server Management Studio Object Explorer, right-click the name of the instance of SQL Server (the
virtual machine name), and then click Properties.
4. On the Security page, under Server authentication, select SQL Server and Windows Authentication
mode, and then click OK.
5. In the SQL Server Management Studio dialog box, click OK to acknowledge the requirement to restart SQL
Server.
6. In Object Explorer, right-click your server, and then click Restart. (If SQL Server Agent is running, it must
also be restarted.)
7. In the SQL Server Management Studio dialog box, click Yes to agree that you want to restart SQL Server.
Create SQL Server authentication logins
To connect to the Database Engine from another computer, you must create at least one SQL Server
authentication login.
1. In SQL Server Management Studio Object Explorer, expand the folder of the server instance in which you want
to create the new login.
2. Right-click the Security folder, point to New, and select Login....
3. In the Login - New dialog box, on the General page, enter the name of the new user in the Login name box.
4. Select SQL Server authentication.
5. In the Password box, enter a password for the new user. Enter that password again into the Confirm
Password box.
6. Select the password enforcement options required (Enforce password policy, Enforce password
expiration, and User must change password at next login). If you are using this login for yourself, you do
not need to require a password change at the next login.
7. From the Default database list, select a default database for the login. master is the default for this
option. If you have not yet created a user database, leave this set to master.
8. If this is the first login you are creating, you may want to designate this login as a SQL Server administrator.
If so, on the Server Roles page, check sysadmin.
NOTE
Members of the sysadmin fixed server role have complete control of the Database Engine. You should carefully
restrict membership in this role.
9. Click OK.
For more information about SQL Server logins, see Create a Login.
Configure a Network Security Group inbound rule for the VM
If you want to be able to connect to SQL Server over the internet, you have to configure an inbound rule on the
Network Security Group for the port that your SQL Server instance is listening. By default, this is TCP port 1433.
1. In the portal, select Virtual machines, and then select your SQL Server VM.
2. Then select the Nework interfaces.
3. Then select the Network Interface for your VM.

4. Click the Network security group link.
5. In the properties of the Network Security Group, expand Inbound security rules.
6. Click the Add button.
7. Provide a Name of "SQLServerPublicTraffic".
8. Change Protocol to TCP.
9. Specify a Destination port range of 1433 (or the port that your SQL Server Instance is listening on).
10. Verify that Action is set to Allow. The security rule dialog should look similar to the following screenshot.
11. Click OK to save the rule for your VM.

NOTE
It is possible to have a second Network Security Group associated with your subnet (this is separate from the network
security group on the VM). This is not done for you by default; however, if you created a network security group on your
subnet, you must open port 1433 on both the subnet's and the VM's Network Security Group.

To connect to the SQL Server Database Engine from the Internet, first configure a DNS Label for your public IP
address.
NOTE
DNS Labels are not required if you plan to only connect to the SQL Server instance within the same Virtual Network or only
locally.
To create a DNS Label, first select Virtual machines in the portal. Select your SQL Server VM to bring up its
properties.
1. In the virtual machine blade, select your Public IP address.
2. In the properties for your Public IP address, expand Configuration.

3. Enter a DNS Label name. This name is an A Record that can be used to connect to your SQL Server VM by
name instead of by IP Address directly.
4. Click the Save button.
1. On a computer connected to the internet, open SQL Server Management Studio (SSMS).
2. In the Connect to Server or Connect to Database Engine dialog box, edit the Server name value. Enter the
full DNS name of the virtual machine (determined in the previous task).
3. In the Authentication box, select SQL Server Authentication.
4. In the Login box, type the name of a valid SQL login.
5. In the Password box, type the password of the login.
6. Click Connect.
Next Steps
To see provisioning instructions along with these connectivity steps, see Provisioning a SQL Server Virtual
Machine on Azure.
Explore the Learning Path for SQL Server on Azure virtual machines.
For other topics related to running SQL Server in Azure VMs, see SQL Server on Azure Virtual Machines.
Migrate a SQL Server database to SQL Server in an
Azure VM
There are a number of methods to migrate an on-premises SQL Server user database to SQL Server in an Azure
VM. This article will briefly discuss various methods and recommend the best method for various scenarios.
NOTE
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.
What are the primary migration methods?

The primary migration methods are:
Perform on-premises backup using compression and manually copy the backup file into the Azure virtual
machine
Perform a backup to URL and restore into the Azure virtual machine from the URL
Detach and then copy the data and log files to Azure blob storage and then attach to SQL Server in Azure VM
from URL
Convert on-premises physical machine to Hyper-V VHD, upload to Azure Blob storage, and then deploy as new
VM using uploaded VHD
Ship hard drive using Windows Import/Export Service
If you have an AlwaysOn deployment on-premises, use the Add Azure Replica Wizard to create a replica in
Azure and then failover, pointing users to the Azure database instance
Use SQL Server transactional replication to configure the Azure SQL Server instance as a subscriber and then
disable replication, pointing users to the Azure database instance
TIP
You can also use these same techniques to move databases between SQL Server VMs in Azure. For example, there is no
supported way to upgrade a SQL Server gallery-image VM from one version/edition to another. In this case, you should
create a new SQL Server VM with the new version/edition, and then use one of the migration techniques in this article to
move your databases.
Choosing your migration method

For optimum data transfer performance, migrate the database files into the Azure VM using a compressed backup
file.
To minimize downtime during the database migration process, use either the AlwaysOn option or the
transactional replication option.
If it is not possible to use the above methods, manually migrate your database. Using this method, you will
generally start with a database backup followed by a copy of the database backup into Azure and then perform a
database restore. You can also copy the database files themselves into Azure and then attach them. There are
several methods by which you can accomplish this manual process of migrating a database into an Azure VM.
NOTE
When you upgrade to SQL Server 2014 or SQL Server 2016 from older versions of SQL Server, you should consider
whether changes are needed. We recommend that you address all dependencies on features not supported by the new
version of SQL Server as part of your migration project. For more information on the supported editions and scenarios, see
Upgrade to SQL Server.
The following table lists each of the primary migration methods and discusses when the use of each method is
most appropriate.
SOURCE DATABASE
SOURCE DATABASE DESTINATION BACKUP SIZE
METHOD VERSION DATABASE VERSION CONSTRAINT NOTES
Perform on-premises SQL Server 2005 or SQL Server 2005 or Azure VM storage This is a very simple
backup using greater greater limit and well-tested
compression and technique for moving
manually copy the databases across
backup file into the machines.
Azure virtual machine
Perform a backup to SQL Server 2012 SP1 SQL Server 2012 SP1 < 12.8 TB for SQL This method is just
URL and restore into CU2 or greater CU2 or greater Server 2016, another way to move
the Azure virtual otherwise < 1 TB the backup file to the
machine from the VM using Azure
URL storage.
Detach and then SQL Server 2005 or SQL Server 2014 or Azure VM storage Use this method
copy the data and log greater greater limit when you plan to
files to Azure blob store these files using
storage and then the Azure Blob
attach to SQL Server storage service and
in Azure virtual attach them to SQL
machine from URL Server running in an
Azure VM, particularly
with very large
databases
Convert on-premises SQL Server 2005 or SQL Server 2005 or Azure VM storage Use when bringing
machine to Hyper-V greater greater limit your own SQL Server
VHDs, upload to license, when
Azure Blob storage, migrating a database
and then deploy a that you will run on
new virtual machine an older version of
using uploaded VHD SQL Server, or when
migrating system and
user databases
together as part of
the migration of
database dependent
on other user
databases and/or
system databases.
SOURCE DATABASE
SOURCE DATABASE DESTINATION BACKUP SIZE
METHOD VERSION DATABASE VERSION CONSTRAINT NOTES
Ship hard drive using SQL Server 2005 or SQL Server 2005 or Azure VM storage Use the Windows
Windows greater greater limit Import/Export Service
Import/Export Service when manual copy
method is too slow,
such as with very
large databases
Use the Add Azure SQL Server 2012 or SQL Server 2012 or Azure VM storage Minimizes downtime,
Replica Wizard greater greater limit use when you have
an AlwaysOn on-
premises deployment
Use SQL Server SQL Server 2005 or SQL Server 2005 or Azure VM storage Use when you need
transactional greater greater limit to minimize
replication downtime and do not
have an AlwaysOn
on-premises
deployment
Backup and restore

Back up your database with compression, copy the backup to the VM, and then restore the database. If your
backup file is larger than 1 TB, you must stripe it because the maximum size of a VM disk is 1 TB. Use the
following general steps to migrate a user database using this manual method:
1. Perform a full database backup to an on-premises location.
2. Create or upload a virtual machine with the version of SQL Server desired.
3. Setup connectivity based on your requirements. See Connect to a SQL Server Virtual Machine on Azure
(Resource Manager).
4. Copy your backup file(s) to your VM using remote desktop, Windows Explorer or the copy command from a
command prompt.
Backup to URL and restore

Instead of backing up to a local file, you can use the backup to URL and then restore from URL to the VM. With
SQL Server 2016, striped backup sets are supported, are recommended for performance, and required to exceed
the size limits per blob. For very large databases, the use of the Windows Import/Export Service is recommended.
Detach and attach from URL

Detach your database and log files and transfer them to Azure Blob storage. Then attach the database from the
URL on your Azure VM. Use this if you want the physical database files to reside in Blob storage. This might be
useful for very large databases. Use the following general steps to migrate a user database using this manual
method:
1. Detach the database files from the on-premises database instance.
2. Copy the detached database files into Azure blob storage using the AZCopy command-line utility.
3. Attach the database files from the Azure URL to the SQL Server instance in the Azure VM.
Convert to VM and upload to URL and deploy as new VM

Use this method to migrate all system and user databases in an on-premises SQL Server instance to Azure virtual
machine. Use the following general steps to migrate an entire SQL Server instance using this manual method:
1. Convert physical or virtual machines to Hyper-V VHDs by using Microsoft Virtual Machine Converter.
2. Upload VHD files to Azure Storage by using the Add-AzureVHD cmdlet.
3. Deploy a new virtual machine by using the uploaded VHD.
NOTE
To migrate an entire application, consider using Azure Site Recovery].
Ship hard drive

Use the Windows Import/Export Service method to transfer large amounts of file data to Azure Blob storage in
situations where uploading over the network is prohibitively expensive or not feasible. With this service, you send
one or more hard drives containing that data to an Azure data center, where your data will be uploaded to your
storage account.
Next Steps
For more information about running SQL Server on Azure Virtual Machines, see SQL Server on Azure Virtual
Machines overview.
For instructions on creating an Azure SQL Server Virtual Machine from a captured image, see Tips & Tricks on
cloning Azure SQL virtual machines from captured images on the CSS SQL Server Engineers blog.
High availability and disaster recovery for SQL
Server in Azure Virtual Machines
Microsoft Azure virtual machines (VMs) with SQL Server can help lower the cost of a high availability and disaster
recovery (HADR) database solution. Most SQL Server HADR solutions are supported in Azure virtual machines,
both as Azure-only and as hybrid solutions. In an Azure-only solution, the entire HADR system runs in Azure. In a
hybrid configuration, part of the solution runs in Azure and the other part runs on-premises in your organization.
The flexibility of the Azure environment enables you to move partially or completely to Azure to satisfy the budget
and HADR requirements of your SQL Server database systems.
NOTE
Understanding the need for an HADR solution

It is up to you to ensure that your database system possesses the HADR capabilities that the service-level
agreement (SLA) requires. The fact that Azure provides high availability mechanisms, such as service healing for
cloud services and failure recovery detection for Virtual Machines, does not itself guarantee you can meet the
desired SLA. These mechanisms protect the high availability of the VMs but not the high availability of SQL Server
running inside the VMs. It is possible for the SQL Server instance to fail while the VM is online and healthy.
Moreover, even the high availability mechanisms provided by Azure allow for downtime of the VMs due to events
such as recovery from software or hardware failures and operating system upgrades.
In addition, Geo Redundant Storage (GRS) in Azure, which is implemented with a feature called geo-replication,
may not be an adequate disaster recovery solution for your databases. Because geo-replication sends data
asynchronously, recent updates can be lost in the event of disaster. More information regarding geo-replication
limitations are covered in the Geo-replication not supported for data and log files on separate disks section.
HADR deployment architectures

SQL Server HADR technologies that are supported in Azure include:
Always On Availability Groups
Always On Failover Cluster Instances
Log Shipping
SQL Server Backup and Restore with Azure Blob Storage Service
Database Mirroring - Deprecated in SQL Server 2016
It is possible to combine the technologies together to implement a SQL Server solution that has both high
availability and disaster recovery capabilities. Depending on the technology you use, a hybrid deployment may
require a VPN tunnel with the Azure virtual network. The sections below show you some of the example
deployment architectures.
Azure-only: High availability solutions

You can have a high availability solution for SQL Server at a database level with Always On Availability Groups -
called availability groups. You can also create a high availability solution at an instance level with Always On
Failover Cluster Instances - failover cluster instances. For additional redundancy, you can create redundancy at
both levels by creating availability groups on failover cluster instances.
TECHNOLOGY EXAMPLE ARCHITECTURES
Availability groups Availability replicas running in Azure VMs in the same region
provide high availability. You need to configure a domain
controller VM, because Windows failover clustering requires
an Active Directory domain.
For more information, see Configure Availability Groups in

Azure (GUI).
Failover cluster instances Failover Cluster Instances (FCI), which require shared storage,
can be created in 3 different ways.
1. A two-node failover cluster running in Azure VMs with

attached storage using Windows Server 2016 Storage Spaces
Direct (S2D) to provide a software-based virtual SAN.

storage supported by a third-party clustering solution. For a
specific example that uses SIOS DataKeeper, see High
availability for a file share using failover clustering and 3rd
party software SIOS DataKeeper.

remote iSCSI Target shared block storage via ExpressRoute.
For example, NetApp Private Storage (NPS) exposes an iSCSI
target via ExpressRoute with Equinix to Azure VMs.
For third-party shared storage and data replication solutions,

you should contact the vendor for any issues related to
accessing data on failover.
Note that using FCI on top of Azure File storage is not

supported yet, because this solution does not utilize Premium
Storage. We are working to support this soon.
Azure-only: Disaster recovery solutions

You can have a disaster recovery solution for your SQL Server databases in Azure using availability groups,
database mirroring, or backup and restore with storage blobs.

Availability Groups Availability replicas running across multiple datacenters in

Azure VMs for disaster recovery. This cross-region solution
protects against complete site outage.
Within a region, all replicas should be within the same cloud

service and the same VNet. Because each region will have a
separate VNet, these solutions require VNet to VNet
connectivity. For more information, see Configure a VNet-to-
VNet connection using the Azure portal. For detailed
instructions, see Configure a SQL Server Availability Group on
Azure Virtual Machines in Different Regions.
Database Mirroring Principal and mirror and servers running in different

datacenters for disaster recovery. You must deploy using
server certificates because an active directory domain cannot
span multiple datacenters.
Backup and Restore with Azure Blob Storage Service Production databases backed up directly to blob storage in a
different datacenter for disaster recovery.
For more information, see Backup and Restore for SQL Server
in Azure Virtual Machines.
Hybrid IT: Disaster recovery solutions

You can have a disaster recovery solution for your SQL Server databases in a hybrid-IT environment using
availability groups, database mirroring, log shipping, and backup and restore with Azure blog storage.
Availability Groups Some availability replicas running in Azure VMs and other
replicas running on-premises for cross-site disaster recovery.
The production site can be either on-premises or in an Azure
datacenter.
Because all availability replicas must be in the same failover

cluster, the cluster must span both networks (a multi-subnet
failover cluster). This configuration requires a VPN connection
between Azure and the on-premises network.
For successful disaster recovery of your databases, you should

also install a replica domain controller at the disaster recovery
site.
It is possible to use the Add Replica Wizard in SSMS to add an

Azure replica to an existing Always On Availability Group. For
more information, see Tutorial: Extend your Always On
Availability Group to Azure.
Database Mirroring One partner running in an Azure VM and the other running
on-premises for cross-site disaster recovery using server
certificates. Partners do not need to be in the same Active
Directory domain, and no VPN connection is required.
Another database mirroring scenario involves one partner

running in an Azure VM and the other running on-premises
in the same Active Directory domain for cross-site disaster
recovery. A VPN connection between the Azure virtual
network and the on-premises network is required.

site.
Log Shipping One server running in an Azure VM and the other running
on-premises for cross-site disaster recovery. Log shipping
depends on Windows file sharing, so a VPN connection
between the Azure virtual network and the on-premises
network is required.

site.
Backup and Restore with Azure Blob Storage Service On-premises production databases backed up directly to
Azure blob storage for disaster recovery.
For more information, see Backup and Restore for SQL Server
Important considerations for SQL Server HADR in Azure

Azure VMs, storage, and networking have different operational characteristics than an on-premises, non-
virtualized IT infrastructure. A successful implementation of a HADR SQL Server solution in Azure requires that
you understand these differences and design your solution to accommodate them.
High availability nodes in an availability set
Availability sets in Azure enable you to place the high availability nodes into separate Fault Domains (FDs) and
Update Domains (UDs). For Azure VMs to be placed in the same availability set, you must deploy them in the same
cloud service. Only nodes in the same cloud service can participate in the same availability set. For more
information, see Manage the Availability of Virtual Machines.
Failover cluster behavior in Azure networking
The non-RFC-compliant DHCP service in Azure can cause the creation of certain failover cluster configurations to
fail, due to the cluster network name being assigned a duplicate IP address, such as the same IP address as one of
the cluster nodes. This is an issue when you implement Availability Groups, which depends on the Windows
failover cluster feature.
Consider the scenario when a two-node cluster is created and brought online:
1. The cluster comes online, then NODE1 requests a dynamically assigned IP address for the cluster network
name.
2. No IP address other than NODE1s own IP address is given by the DHCP service, since the DHCP service
recognizes that the request comes from NODE1 itself.
3. Windows detects that a duplicate address is assigned both to NODE1 and to the failover cluster network name,
and the default cluster group fails to come online.
4. The default cluster group moves to NODE2, which treats NODE1s IP address as the cluster IP address and
brings the default cluster group online.
5. When NODE2 attempts to establish connectivity with NODE1, packets directed at NODE1 never leave NODE2
because it resolves NODE1s IP address to itself. NODE2 cannot establish connectivity with NODE1, then loses
quorum and shuts down the cluster.
6. In the meantime, NODE1 can send packets to NODE2, but NODE2 cannot reply. NODE1 loses quorum and
shuts down the cluster.
This scenario can be avoided by assigning an unused static IP address, such as a link-local IP address like
169.254.1.1, to the cluster network name in order to bring the cluster network name online. To simplify this
process, see Configuring Windows failover cluster in Azure for availability groups.
For more information, see Configure availability groups in Azure (GUI).
Availability group listener support
Availability group listeners are supported on Azure VMs running Windows Server 2008 R2, Windows Server 2012,
Windows Server 2012 R2, and Windows Server 2016. This support is made possible by the use of load-balanced
endpoints enabled on the Azure VMs that are availability group nodes. You must follow special configuration steps
for the listeners to work for both client applications that are running in Azure as well as those running on-
premises.
There are two main options for setting up your listener: external (public) or internal. The external (public) listener
uses an internet facing load balancer and is associated with a public Virtual IP (VIP) that is accessible over the
internet. An internal listener uses an internal load balancer and only supports clients within the same Virtual
Network. For either load balancer type, you must enable Direct Server Return.
If the Availability Group spans multiple Azure subnets (such as a deployment that crosses Azure regions), the client
connection string must include "MultisubnetFailover=True". This results in parallel connection attempts to the
replicas in the different subnets. For instructions on setting up a listener, see
Configure an ILB listener for availability groups in Azure.
Configure an external listener for availability groups in Azure.
You can still connect to each availability replica separately by connecting directly to the service instance. Also, since
availability groups are backward compatible with database mirroring clients, you can connect to the availability
replicas like database mirroring partners as long as the replicas are configured similar to database mirroring:
One primary replica and one secondary replica
The secondary replica is configured as non-readable (Readable Secondary option set to No)
An example client connection string that corresponds to this database mirroring-like configuration using ADO.NET
or SQL Server Native Client is below:
Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;
For more information on client connectivity, see:

Using Connection String Keywords with SQL Server Native Client
Connect Clients to a Database Mirroring Session (SQL Server)
Connecting to Availability Group Listener in Hybrid IT
Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)
Using Database-Mirroring Connection Strings with Availability Groups
Network latency in hybrid IT
You should deploy your HADR solution with the assumption that there may be periods of time with high network
latency between your on-premises network and Azure. When deploying replicas to Azure, you should use
asynchronous commit instead of synchronous commit for the synchronization mode. When deploying database
mirroring servers both on-premises and in Azure, use the high-performance mode instead of the high-safety
mode.
Geo -replication support
Geo-replication in Azure disks does not support the data file and log file of the same database to be stored on
separate disks. GRS replicates changes on each disk independently and asynchronously. This mechanism
guarantees the write order within a single disk on the geo-replicated copy, but not across geo-replicated copies of
multiple disks. If you configure a database to store its data file and its log file on separate disks, the recovered
disks after a disaster may contain a more up-to-date copy of the data file than the log file, which breaks the write-
ahead log in SQL Server and the ACID properties of transactions. If you do not have the option to disable geo-
replication on the storage account, you should keep all data and log files for a given database on the same disk. If
you must use more than one disk due to the size of the database, you need to deploy one of the disaster recovery
solutions listed above to ensure data redundancy.
Next steps
If you need to create an Azure virtual machine with SQL Server, see Provisioning a SQL Server Virtual Machine on
Azure.
To get the best performance from SQL Server running on an Azure VM, see the guidance in Performance Best
Practices for SQL Server in Azure Virtual Machines.
Other resources
Install a new Active Directory forest in Azure
Create Failover Cluster for availability groups in Azure VM
Introducing SQL Server Always On availability groups
on Azure virtual machines
This article introduces SQL Server availability groups on Azure Virtual Machines.
Always On availability groups on Azure Virtual Machines are similar to Always On availability groups on premises.
For more information, see Always On Availability Groups (SQL Server).
The diagram illustrates the parts of a complete SQL Server Availability Group in Azure Virtual Machines.
The key difference for an Availability Group in Azure Virtual Machines is that the Azure virtual machines, require a
load balancer. The load balancer holds the IP addresses for the availability group listener. If you have more than
one availability group each group requires a listener. One load balancer can support multiple listeners.
When you are ready to build a SQL Server availability aroup on Azure Virtual Machines, refer to these tutorials.
Automatically create an availability group from a template

Configure Always On availability group in Azure VM automatically - Resource Manager
Manually create an availability group in Azure portal

You can also create the virtual machines yourself without the template. First, complete the prerequisites, then
create the availability group. See the following topics:
Configure prerequisites for SQL Server Always On availability groups on Azure Virtual Machines
Create Always On Availability Group to improve availability and disaster recovery
Next steps
Configure a SQL Server Always On Availability Group on Azure Virtual Machines in Different Regions.
Configure Always On availability groups in Azure
Virtual Machines automatically: Resource Manager
This tutorial shows you how to create a SQL Server availability group that uses Azure Resource Manager virtual
machines. The tutorial uses Azure blades to configure a template. You can review the default settings, type
required settings, and update the blades in the portal as you walk through this tutorial.
The complete tutorial creates a SQL Server availability group on Azure Virtual Machines that include the following
elements:
A virtual network that has multiple subnets, including a frontend and a backend subnet
Two domain controllers that have an Active Directory domain
Two virtual machines that run SQL Server and are deployed to the backend subnet and joined to the Active
Directory domain
A three-node failover cluster with the Node Majority quorum model
An availability group that has two synchronous-commit replicas of an availability database
The following illustration represents the complete solution.
All resources in this solution belong to a single resource group.

Before you start this tutorial, confirm the following:
You already have an Azure account. If you don't have one, sign up for a trial account.
You already know how to use the GUI to provision a SQL Server virtual machine from the virtual machine
gallery. For more information, see Provisioning a SQL Server virtual machine on Azure.
You already have a solid understanding of availability groups. For more information, see Always On availability
groups (SQL Server).
NOTE
If you are interested in using availability groups with SharePoint, also see Configure SQL Server 2012 Always On availability
groups for SharePoint 2013.
In this tutorial, use the Azure portal to:

Choose the Always On template from the portal.
Review the template settings and update a few configuration settings for your environment.
Monitor Azure as it creates the entire environment.
Connect to a domain controller and then to a server that runs SQL Server.
This tutorial walks you through building the solution from the Azure portal. If you are interested in creating this
solution from a template, choose the appropriate template from Microsoft Azure GitHub templates. The Create an
availability group with SQL Server 2014 replica virtual machines template creates the same solution as this
tutorial.
Provision the cluster from the gallery

Azure provides a gallery image for the entire solution. To locate the template:
1. Sign in to the Azure portal by using your account.
2. In the Azure portal, click +New to open the New blade.
3. On the New blade, search for AlwaysOn.
4. In the search results, locate SQL Server AlwaysOn Cluster.

5. On Select a deployment model, choose Resource Manager.
Basics
Click Basics and configure the following settings:
Administrator user name is a user account that has domain administrator permissions and is a member of
the SQL Server sysadmin fixed server role on both instances of SQL Server. For this tutorial, use
DomainAdmin.
Password is the password for the domain administrator account. Use a complex password. Confirm the
password.
Subscription is the subscription that Azure bills to run all deployed resources for the availability group. If your
account has multiple subscriptions, you can specify a different subscription.
Resource group is the name for the group to which all Azure resources that are created by this template
belong. For this tutorial, use SQL-HA-RG. For more information, see Azure Resource Manager overview.
Location is the Azure region where the tutorial creates the resources. Choose an Azure region.
The following screenshot is a completed Basics blade:
Click OK.
Domain and network settings
This Azure gallery template creates a domain and domain controllers. It also creates a network and two subnets.
The template cannot create servers in an existing domain or virtual network. The next step configures the domain
and network settings.
On the Domain and network settings blade, review the preset values for the domain and network settings:
Forest root domain name is the domain name for the Active Directory domain that hosts the cluster. For the
tutorial, use contoso.com.
Virtual Network name is the network name for the Azure virtual network. For the tutorial, use autohaVNET.
Domain Controller subnet name is the name of a portion of the virtual network that hosts the domain
controller. Use subnet-1. This subnet uses address prefix 10.0.0.0/24.
SQL Server subnet name is the name of a portion of the virtual network that hosts the servers that run SQL
Server and the file share witness. Use subnet-2. This subnet uses address prefix 10.0.1.0/26.
To learn more about virtual networks in Azure, see Virtual network overview.
The Domain and network settings should look like the following screenshot:
If necessary, you can change these values. For this tutorial, use the preset values.
Review the settings, and then click OK.
Availability group settings
On Availability group settings, review the preset values for the availability group and the listener.
Availability group name is the clustered resource name for the availability group. For this tutorial, use
Contoso-ag.
Availability group listener name is used by the cluster and the internal load balancer. Clients that connect to
SQL Server can use this name to connect to the appropriate replica of the database. For this tutorial, use
Contoso-listener.
Availability group listener port specifies the TCP port of the SQL Server listener. For this tutorial, use the
default port, 1433.
If necessary, you can change these values. For this tutorial, use the preset values.
Click OK.
Virtual machine size, storage settings
On VM size, storage settings, choose a SQL Server virtual machine size, and review the other settings.
SQL Server virtual machine size is the size for both virtual machines that run SQL Server. Choose an
appropriate virtual machine size for your workload. If you are building this environment for the tutorial, use
DS2. For production workloads, choose a virtual machine size that can support the workload. Many production
workloads require DS4 or larger. The template builds two virtual machines of this size and installs SQL Server
on each one. For more information, see Sizes for virtual machines.
NOTE
Azure installs the Enterprise Edition of SQL Server. The cost depends on the edition and the virtual machine size. For detailed
information about current costs, see virtual machines pricing.
Domain controller virtual machine size is the virtual machine size for the domain controllers. For this
tutorial use D2.
File Share Witness virtual machine size is the virtual machine size for the file share witness. For this tutorial,
use A1.
SQL Storage account is the name of the storage account that holds the SQL Server data and operating system
disks. For this tutorial, use alwaysonsql01.
DC Storage account is the name of the storage account for the domain controllers. For this tutorial, use
alwaysondc01.
SQL Server data disk size in TB is the size of the SQL Server data disk in TB. Specify a number from 1 through
4. For this tutorial, use 1.
Storage optimization sets specific storage configuration settings for the SQL Server virtual machines
based on the workload type. All SQL Server virtual machines in this scenario use premium storage with
Azure disk host cache set to read-only. In addition, you can optimize SQL Server settings for the workload
by choosing one of these three settings:
General workload sets no specific configuration settings.
Transactional processing sets trace flag 1117 and 1118.
Data warehousing sets trace flag 1117 and 610.
For this tutorial, use General workload.
A note about storage
Additional optimizations depend on the size of the SQL Server data disks. For each terabyte of data disk, Azure
adds an additional 1 TB premium storage. When a server requires 2 TB or more, the template creates a storage
pool on each SQL Server virtual machine. A storage pool is a form of storage virtualization where multiple discs
are configured to provide higher capacity, resiliency, and performance. The template then creates a storage space
on the storage pool and presents a single data disk to the operating system. The template designates this disk as
the data disk for SQL Server. The template tunes the storage pool for SQL Server by using the following settings:
Stripe size is the interleave setting for the virtual disk. Transactional workloads use 64 KB. Data warehousing
workloads use 256 KB.
Resiliency is simple (no resiliency).
NOTE
Azure premium storage is locally redundant and keeps three copies of the data within a single region, so additional resiliency
at the storage pool is not required.
Column count equals the number of disks in the storage pool.

For additional information about storage space and storage pools, see:
Storage Spaces Overview
Windows Server Backup and Storage Pools
For more information about SQL Server configuration best practices, see Performance best practices for SQL
Server in Azure virtual machines.
SQL Server settings
On SQL Server settings, review and modify the SQL Server virtual machine name prefix, SQL Server version, SQL
Server service account and password, and the SQL auto-patching maintenance schedule.
SQL Server Name Prefix is used to create a name for each SQL Server virtual machine. For this tutorial, use
sqlserver. The template names the SQL Server virtual machines sqlserver-0 and sqlserver-1.
SQL Server version is the version of SQL Server. For this tutorial use SQL Server 2014. You can also choose
SQL Server 2012 or SQL Server 2016.
SQL Server service account user name is the domain account name for the SQL Server service. For this
tutorial, use sqlservice.
Password is the password for the SQL Server service account. Use a complex password. Confirm the password.
SQL Auto Patching maintenance schedule identifies the day of the week that Azure automatically patches
the SQL Servers. For this tutorial, type Sunday.
SQL Auto Patching maintenance start hour is the time of day for the Azure region when automatic patching
begins.
NOTE
The patching window for each virtual machine is staggered by one hour. Only one virtual machine is patched at a time to
prevent disruption of services.

Summary
On the summary page, Azure validates the settings. You can also download the template. Review the summary.
Click OK.
Buy
This final blade contains terms of use, and privacy policy. Review this information. When you are ready for
Azure to start to create the virtual machines and all the other required resources for the availability group, click
Create.
The Azure portal creates the resource group and all the resources.
Monitor deployment
Monitor the deployment progress from the Azure portal. An icon that represents the deployment is automatically
pinned to the Azure portal dashboard.
Connect to SQL Server

The new instances of SQL Server are running on virtual machines that have internet-connected IP addresses. You
can remote desktop (RDP) directly to each SQL Server virtual machine.
To RDP to a SQL Server, follow these steps:
1. From the Azure portal dashboard, verify that the deployment has succeeded.
2. Click Resources.
3. In the Resources blade, click sqlserver-0, which is the computer name of one of the virtual machines that's
running SQL Server.
4. On the blade for sqlserver-0, click Connect. Your browser asks if you want to open or save the remote
connection object. Click Open.
5. Remote desktop connection might warn you that the publisher of this remote connection cant be identified.
Click Connect.
6. Windows security prompts you to enter your credentials to connect to the IP address of the primary domain
controller. Click Use another account. For User name, type contoso\DomainAdmin. You configured this
account when you set the administrator user name in the template. Use the complex password that you chose
when you configured the template.
7. Remote desktop might warn you that the remote computer could not be authenticated due to problems with
its security certificate. It shows you the security certificate name. If you followed the tutorial, the name is
sqlserver-0.contoso.com. Click Yes.
You are now connected with RDP to the SQL Server virtual machine. You can open SQL Server Management
Studio, connect to the default instance of SQL Server, and verify that the availability group is configured.
Complete the prerequisites for creating Always On
availability groups on Azure virtual machines
This tutorial shows how to complete the prerequisites for creating a SQL Server Always On availability group on
Azure virtual machines (VMs). When you've finished the prerequisites, you have a domain controller, two SQL
Server VMs, and a witness server in a single resource group.
Time estimate: It might take a couple of hours to complete the prerequisites. Much of this time is spent creating
virtual machines.
The following diagram illustrates what you build in the tutorial.
Review availability group documentation

This tutorial assumes that you have a basic understanding of SQL Server Always On availability groups. If you're
not familiar with this technology, see Overview of Always On Availability Groups (SQL Server).
Create an Azure account

You need an Azure account. You can open a free Azure account or activate Visual Studio subscriber benefits.
Create a resource group

1. Sign in to the Azure portal.
2. Click + to create a new object in the portal.
3. Type resource group in the Marketplace search window.
4. Click Resource group.

5. Click Create.
6. On the Resource group blade, under Resource group name, type a name for the resource group. For
example, type sql-ha-rg.
7. If you have multiple Azure subscriptions, verify that the subscription is the Azure subscription that you want to
create the availability group in.
8. Select a location. The location is the Azure region where you want to create the availability group. For this
tutorial, we're going to build all resources in one Azure location.
9. Verify that Pin to dashboard is checked. This optional setting places a shortcut for the resource group on
the Azure portal dashboard.
10. Click Create to create the resource group.
Azure creates the resource group and pins a shortcut to the resource group in the portal.
Create the network and subnets

The next step is to create the networks and subnets in the Azure resource group.
The solution uses one virtual network with two subnets. The Virtual network overview provides more information
about networks in Azure.
To create the virtual network:
1. In the Azure portal, in your resource group, click + Add. Azure opens the Everything blade.
2. Search for virtual network.

3. Click Virtual network.
4. On the Virtual network blade, click the Resource Manager deployment model, and then click Create.
The following table shows the settings for the virtual network:
FIELD VALUE
Name autoHAVNET
Address space 10.33.0.0/24
Subnet name Admin
Subnet address range 10.33.0.0/29
Subscription Specify the subscription that you intend to use.

Subscription is blank if you only have one subscription.
Resource group Choose Use existing and pick the name of the resource
group.
Location Specify the Azure location.
Your address space and subnet address range might be different from the table. Depending on your
subscription, the portal suggests an available address space and corresponding subnet address range. If no
sufficient address space is available, use a different subscription.
The example uses the subnet name Admin. This subnet is for the domain controllers.
5. Click Create.
Azure returns you to the portal dashboard and notifies you when the new network is created.
Create a second subnet
The new virtual network has one subnet, named Admin. The domain controllers use this subnet. The SQL Server
VMs use a second subnet named SQL. To configure this subnet:
1. On your dashboard, click the resource group that you created, SQL-HA-RG. Locate the network in the
resource group under Resources.
If SQL-HA-RG isn't visible, find it by clicking Resource Groups and filtering by the resource group name.
2. Click autoHAVNET on the list of resources. Azure opens the network configuration blade.
3. On the autoHAVNET virtual network blade, under Settings , click Subnets.
Note the subnet that you already created.
4. Create a second subnet. Click + Subnet.

5. On the Add subnet blade, configure the subnet by typing sqlsubnet under Name. Azure automatically
specifies a valid Address range. Verify that this address range has at least 10 addresses in it. In a production
environment, you might require more addresses.
6. Click OK.
The following table summarizes the network configuration settings:
FIELD VALUE
Name autoHAVNET
Address space This value depends on the available address spaces in your
subscription. A typical value is 10.0.0.0/16.
Subnet name admin
Subnet address range This value depends on the available address ranges in your
Subnet name sqlsubnet
Subnet address range This value depends on the available address ranges in your
Subscription Specify the subscription that you intend to use.
Resource Group SQL-HA-RG
Location Specify the same location that you chose for the resource
group.
Create availability sets

Before you create virtual machines, you need to create availability sets. Availability sets reduce the downtime for
planned or unplanned maintenance events. An Azure availability set is a logical group of resources that Azure
places on physical fault domains and update domains. A fault domain ensures that the members of the availability
set have separate power and network resources. An update domain ensures that members of the availability set
aren't brought down for maintenance at the same time. For more information, see Manage the availability of
virtual machines.
You need two availability sets. One is for the domain controllers. The second is for the SQL Server VMs.
To create an availability set, go to the resource group and click Add. Filter the results by typing availability set.
Click Availability Set in the results, and then click Create.
Configure two availability sets according to the parameters in the following table:
FIELD DOMAIN CONTROLLER AVAILABILITY SET SQL SERVER AVAILABILITY SET
Name adavailabilityset sqlavailabilityset
Resource group SQL-HA-RG SQL-HA-RG
Fault domains 3 3
Update domains 5 3
After you create the availability sets, return to the resource group in the Azure portal.
Create domain controllers

After you've created the network, subnets, availability sets, and an Internet-facing load balancer, you're ready to
create the virtual machines for the domain controllers.
Create virtual machines for the domain controllers
To create and configure the domain controllers, return to the SQL-HA-RG resource group.
1. Click Add. The Everything blade opens.
2. Type Windows Server 2016 Datacenter.
3. Click Windows Server 2016 Datacenter. In the Windows Server 2016 Datacenter blade, verify that the
deployment model is Resource Manager, and then click Create. Azure opens the Create virtual machine
blade.
Repeat the preceding steps to create two virtual machines. Name the two virtual machines:
ad-primary-dc
ad-secondary-dc
NOTE
The ad-secondary-dc virtual machine is optional, to provide high availability for Active Directory Domain Services.
The following table shows the settings for these two machines:
FIELD VALUE
Name First domain controller: ad-primary-dc.

Second domain controller ad-secondary-dc.
VM disk type SSD
User name DomainAdmin
Password Contoso!0000
Subscription Your subscription

FIELD VALUE
Resource group SQL-HA-RG
Location Your location
Size DS1_V2
Storage Use managed disks - Yes
Virtual network autoHAVNET
Subnet admin
Public IP address Same name as the VM
Network security group Same name as the VM
Availability set adavailabilityset

Fault domains:2
Update domains:2
Diagnostics Enabled
Diagnostics storage account Automatically created
IMPORTANT
You can only place a VM in an availability set when you create it. You can't change the availability set after a VM is created.
See Manage the availability of virtual machines.
Azure creates the virtual machines.

After the virtual machines are created, configure the domain controller.
Configure the domain controller
In the following steps, configure the ad-primary-dc machine as a domain controller for corp.contoso.com.
1. In the portal, open the SQL-HA-RG resource group and select the ad-primary-dc machine. On the ad-
primary-dc blade, click Connect to open an RDP file for remote desktop access.
2. Sign in with your configured administrator account (\DomainAdmin) and password (Contoso!0000).
3. By default, the Server Manager dashboard should be displayed.
4. Click the Add roles and features link on the dashboard.
5. Select Next until you get to the Server Roles section.
6. Select the Active Directory Domain Services and DNS Server roles. When you're prompted, add any
additional features that are required by these roles.
NOTE
Windows warns you that there is no static IP address. If you're testing the configuration, click Continue. For
production scenarios, set the IP address to static in the Azure portal, or use PowerShell to set the static IP address of
the domain controller machine.
7. Click Next until you reach the Confirmation section. Select the Restart the destination server
automatically if required check box.
8. Click Install.
9. After the features finish installing, return to the Server Manager dashboard.
10. Select the new AD DS option on the left-hand pane.
11. Click the More link on the yellow warning bar.
12. In the Action column of the All Server Task Details dialog, click Promote this server to a domain
controller.
13. In the Active Directory Domain Services Configuration Wizard, use the following values:
PAGE SETTING
Deployment Configuration Add a new forest

Root domain name = corp.contoso.com
Domain Controller Options DSRM Password = Contoso!0000

Confirm Password = Contoso!0000
14. Click Next to go through the other pages in the wizard. On the Prerequisites Check page, verify that you see
the following message: All prerequisite checks passed successfully. You can review any applicable warning
messages, but it's possible to continue with the installation.
15. Click Install. The ad-primary-dc virtual machine automatically reboots.
Note the IP address of the primary domain controller
Use the primary domain controller for DNS. Note the primary domain controller IP address.
One way to get the primary domain controller IP address is through the Azure portal.
1. On the Azure portal, open the resource group.
2. Click the primary domain controller.
3. On the primary domain controller blade, click Network interfaces.
Note the private IP address for this server.
Configure the virtual network DNS
After you create the first domain controller and enable DNS on the first server, configure the virtual network to use
this server for DNS.
1. In the Azure portal, click on the virtual network.
2. Under Settings, click DNS Server.
3. Click Custom, and type the private IP address of the primary domain controller.
4. Click Save.
Configure the second domain controller
After the primary domain controller reboots, you can configure the second domain controller. This optional step is
for high availability. Follow these steps to configure the second domain controller:
1. In the portal, open the SQL-HA-RG resource group and select the ad-secondary-dc machine. On the ad-
secondary-dc blade, click Connect to open an RDP file for remote desktop access.
2. Sign in to the VM by using your configured administrator account (BUILTIN\DomainAdmin) and password
(Contoso!0000).
3. Change the preferred DNS server address to the address of the domain controller.
4. In Network and Sharing Center, click the network interface.
5. Click Properties.
6. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
7. Select Use the following DNS server addresses and specify the address of the primary domain controller in
Preferred DNS server.
8. Click OK, and then Close to commit the changes. You are now able to join the VM to corp.contoso.com.
IMPORTANT
If you lose the connection to your remote desktop after changing the DNS setting, go to the Azure portal and restart
the virtual machine.
9. From the remote desktop to the secondary domain controller, open Server Manager Dashboard.
11. Select Next until you get to the Server Roles section.
12. Select the Active Directory Domain Services and DNS Server roles. When you're prompted, add any
additional features that are required by these roles.
13. After the features finish installing, return to the Server Manager dashboard.
14. Select the new AD DS option on the left-hand pane.
15. Click the More link on the yellow warning bar.
16. In the Action column of the All Server Task Details dialog, click Promote this server to a domain
controller.
17. Under Deployment Configuration, select Add a domain controller to an existing domain.
18. Click Select.

19. Connect by using the administrator account (CORP.CONTOSO.COM\domainadmin) and password
(Contoso!0000).
20. In Select a domain from the forest, click your domain, and then click OK.
21. In Domain Controller Options, use the default values and set a DSRM password.
NOTE
The DNS Options page might warn you that a delegation for this DNS server can't be created. You can ignore this
warning in non-production environments.
22. Click Next until the dialog reaches the Prerequisites check. Then click Install.
After the server finishes the configuration changes, restart the server.
Add the Private IP Address to the second domain controller to the VPN DNS Server
In the Azure portal, under virtual network, change the DNS Server to include the IP address of the secondary
domain controller. This allows the DNS service redundancy.
Configure the domain accounts
In the next steps, you configure the Active Directory accounts. The following table shows the accounts:
SQLSERVER-0 SQLSERVER-1
SQL SERVER AND SQL AGENT SQL SERVER AND SQL AGENT
INSTALLATION ACCOUNT SERVICE ACCOUNT SERVICE ACCOUNT
First Name Install SQLSvc1 SQLSvc2

SQLSERVER-0 SQLSERVER-1
SQL SERVER AND SQL AGENT SQL SERVER AND SQL AGENT
INSTALLATION ACCOUNT SERVICE ACCOUNT SERVICE ACCOUNT
User SamAccountName Install SQLSvc1 SQLSvc2
Use the following steps to create each account.

1. Sign in to the ad-primary-dc machine.
2. In Server Manager, select Tools, and then click Active Directory Administrative Center.
3. Select corp (local) from the left pane.
4. On the right Tasks pane, select New, and then click User.
TIP
Set a complex password for each account.
For non-production environments, set the user account to never expire.
5. Click OK to create the user.

6. Repeat the preceding steps for each of the three accounts.
Grant the required permissions to the installation account
1. In the Active Directory Administrative Center, select corp (local) in the left pane. Then in the right-hand
Tasks pane, click Properties.
2. Select Extensions, and then click the Advanced button on the Security tab.
3. In the Advanced Security Settings for corp dialog, click Add.
4. Click Select a principal, search for CORP\Install, and then click OK.
5. Select the Read all properties check box.
6. Select the Create Computer objects check box.
7. Click OK, and then click OK again. Close the corp properties window.
Now that you've finished configuring Active Directory and the user objects, create two SQL Server VMs and a
witness server VM. Then join all three to the domain.
Create SQL Server VMs

Create three additional virtual machines. The solution requires two virtual machines with SQL Server instances. A
third virtual machine will function as a witness. Windows Server 2016 can use a cloud witness, however for
consistency with previous operating systems this document uses a virtual machine for a witness.
Before you proceed consider the following deisign decisions.
Storage - Azure Managed Disks
For the virtual machine storage, use Azure Managed Disks. Microsoft recommends Managed Disks for SQL
Server virtual machines. Managed Disks handles storage behind the scenes. In addition, when virtual
machines with Managed Disks are in the same availability set, Azure distributes the storage resources to
provide appropriate redundancy. For additional information, see Azure Managed Disks Overview. For
specifics about managed disks in an availability set, see Use Managed Disks for VMs in an availability set.
Network - Private IP addresses in production
For the virtual machines, this tutorial uses public IP addresses. This enables remote connection directly to
the virtual machine over the internet - it makes configuration steps easier. In production environments,
Microsoft recommends only private IP addresses in order to reduce the vulnerability footprint of the SQL
Server instance VM resource.
Create and configure the SQL Server VMs
Next, create three VMs--two SQL Server VMs and a VM for an additional cluster node. To create each of the VMs,
go back to the SQL-HA-RG resource group, click Add, search for the appropriate gallery item, click Virtual
Machine, and then click From Gallery. Use the information in the following table to help you create the VMs:
PAGE VM1 VM2 VM3
Select the appropriate Windows Server 2016 SQL Server 2016 SP1 SQL Server 2016 SP1
gallery item Datacenter Enterprise on Windows Enterprise on Windows
Server 2016 Server 2016
Virtual machine Name = cluster-fsw Name = sqlserver-0 Name = sqlserver-1

configuration Basics User Name = User Name = User Name =
DomainAdmin DomainAdmin DomainAdmin
Password = Contoso!0000 Password = Contoso!0000 Password = Contoso!0000
Subscription = Your Subscription = Your Subscription = Your
subscription subscription subscription
Resource group = SQL- Resource group = SQL- Resource group = SQL-
HA-RG HA-RG HA-RG
Location = Your azure Location = Your azure Location = Your azure
location location location
Virtual machine SIZE = DS1_V2 (1 core, 3.5 SIZE = DS2_V2 (2 cores, 7 SIZE = DS2_V2 (2 cores, 7
configuration Size GB) GB) GB)
The size must support SSD
storage (Premium disk
support. ))
Virtual machine Storage: Use managed Storage: Use managed Storage: Use managed
configuration Settings disks. disks. disks.
Virtual network = Virtual network = Virtual network =
autoHAVNET autoHAVNET autoHAVNET
Subnet = Subnet = Subnet =
sqlsubnet(10.1.1.0/24) sqlsubnet(10.1.1.0/24) sqlsubnet(10.1.1.0/24)
Public IP address Public IP address Public IP address
automatically generated. automatically generated. automatically generated.
Network security group = Network security group = Network security group =
None None None
Monitoring Diagnostics = Monitoring Diagnostics = Monitoring Diagnostics =
Enabled Enabled Enabled
Diagnostics storage Diagnostics storage Diagnostics storage
account = Use an account = Use an account = Use an
automatically generated automatically generated automatically generated
storage account storage account storage account
Availability set = Availability set = Availability set =
sqlAvailabilitySet sqlAvailabilitySet sqlAvailabilitySet
PAGE VM1 VM2 VM3
Virtual machine Not applicable SQL connectivity = Private SQL connectivity = Private
configuration SQL Server (within Virtual Network) (within Virtual Network)
settings Port = 1433 Port = 1433
SQL Authentication = SQL Authentication =
Disable Disable
Storage configuration = Storage configuration =
General General
Automated patching = Automated patching =
Sunday at 2:00 Sunday at 2:00
Automated backup = Automated backup =
Disabled Disabled
Azure Key Vault Azure Key Vault
integration = Disabled integration = Disabled
NOTE
The machine sizes suggested here are meant for testing availability groups in Azure VMs. For the best performance on
production workloads, see the recommendations for SQL Server machine sizes and configuration in Performance best
practices for SQL Server in Azure virtual machines.
After the three VMs are fully provisioned, you need to join them to the corp.contoso.com domain and grant
CORP\Install administrative rights to the machines.
Join the servers to the domain
You're now able to join the VMs to corp.contoso.com. Do the following for both the SQL Server VMs and the file
share witness server:
1. Remotely connect to the virtual machine with BUILTIN\DomainAdmin.
2. In Server Manager, click Local Server.
3. Click the WORKGROUP link.
4. In the Computer Name section, click Change.
5. Select the Domain check box and type corp.contoso.com in the text box. Click OK.
6. In the Windows Security popup dialog, specify the credentials for the default domain administrator account
(CORP\DomainAdmin) and the password (Contoso!0000).
7. When you see the "Welcome to the corp.contoso.com domain" message, click OK.
8. Click Close, and then click Restart Now in the popup dialog.
Add the Corp\Install user as an administrator on each cluster VM
After each virtual machine restarts as a member of the domain, add CORP\Install as a member of the local
administrators group.
1. Wait until the VM is restarted, then launch the RDP file again from the primary domain controller to sign in
to sqlserver-0 by using the CORP\DomainAdmin account.
TIP
Make sure that you sign in with the domain administrator account. In the previous steps, you were using the BUILT
IN administrator account. Now that the server is in the domain, use the domain account. In your RDP session, specify
DOMAIN\username.
2. In Server Manager, select Tools, and then click Computer Management.

3. In the Computer Management window, expand Local Users and Groups, and then select Groups.
4. Double-click the Administrators group.
5. In the Administrators Properties dialog, click the Add button.
6. Enter the user CORP\Install, and then click OK.
7. Click OK to close the Administrator Properties dialog.
8. Repeat the previous steps on sqlserver-1 and cluster-fsw.
Set the SQL Server service accounts
On each SQL Server VM, set the SQL Server service account. Use the accounts that you created when you
configured the domain accounts.
1. Open SQL Server Configuration Manager.
2. Right-click the SQL Server service, and then click Properties.
3. Set the account and password.
4. Repeat these steps on the other SQL Server VM.
For SQL Server availability groups, each SQL Server VM needs to run as a domain account.
Create a sign-in on each SQL Server VM for the installation account
Use the installation account (CORP\install) to configure the availability group. This account needs to be a member
of the sysadmin fixed server role on each SQL Server VM. The following steps create a sign-in for the installation
account:
1. Connect to the server through the Remote Desktop Protocol (RDP) by using the
<MachineName>\DomainAdmin account.
2. Open SQL Server Management Studio and connect to the local instance of SQL Server.
3. In Object Explorer, click Security.
4. Right-click Logins. Click New Login.
5. In Login - New, click Search.
6. Click Locations.
7. Enter the domain administrator network credentials.
8. Use the installation account.
9. Set the sign-in to be a member of the sysadmin fixed server role.
10. Click OK.
Repeat the preceding steps on the other SQL Server VM.
Add Failover Clustering features to both SQL Server VMs

To add Failover Clustering features, do the following on both SQL Server VMs:
1. Connect to the SQL Server virtual machine through the Remote Desktop Protocol (RDP) by using the
CORP\install account. Open Server Manager Dashboard.
3. Select Next until you get to the Server Features section.
4. In Features, select Failover Clustering.
5. Add any additional required features.
6. Click Install to add the features.
Repeat the steps on the other SQL Server VM.
The solution requires the following TCP ports to be open in the firewall:
Conf igure the f ir ewall on each SQ L Server VM
SQL Server VM:

Port 1433 for a default instance of SQL Server.
Azure load balancer probe:
Any available port. Examples frequently use 59999.
Database mirroring endpoint:
Any available port. Examples frequently use 5022.
The firewall ports need to be open on both SQL Server VMs.
The method of opening the ports depends on the firewall solution that you use. The next section explains how to
open the ports in Windows Firewall. Open the required ports on each of your SQL Server VMs.
Open a TCP port in the firewall
1. On the first SQL Server Start screen, launch Windows Firewall with Advanced Security.
2. On the left pane, select Inbound Rules. On the right pane, click New Rule.
3. For Rule Type, choose Port.
4. For the port, specify TCP and type the appropriate port numbers. See the following example:
5. Click Next.
6. On the Action page, keep Allow the connection selected, and then click Next.
7. On the Profile page, accept the default settings, and then click Next.
8. On the Name page, specify a rule name (such as Azure LB Probe) in the Name text box, and then click Finish.
Repeat these steps on the second SQL Server VM.
Next steps
Create a SQL Server Always On availability group on Azure virtual machines
Configure Always On Availability Group in Azure VM
manually
This tutorial shows how to create a SQL Server Always On Availability Group on Azure Virtual Machines. The
complete tutorial creates an Availability Group with a database replica on two SQL Servers.
Time estimate: Takes about 30 minutes to complete once the prerequisites are met.
The diagram illustrates what you build in the tutorial.
Prerequisites
The tutorial assumes you have a basic understanding of SQL Server Always On Availability Groups. If you need
more information, see Overview of Always On Availability Groups (SQL Server).
The following table lists the prerequisites that you need to complete before starting this tutorial:
REQUIREMENT DESCRIPTION
Two SQL Servers - In an Azure availability set

- In a single domain
- With Failover Clustering feature
installed
Windows Server File share for cluster witness
SQL Server service account Domain account
SQL Server Agent service account Domain account

REQUIREMENT DESCRIPTION
Firewall ports open - SQL Server: 1433 for default instance

- Database mirroring endpoint: 5022 or
any available port
- Azure load balancer probe: 59999 or
any available port
Add Failover Clustering Feature Both SQL Servers require this feature
Installation domain account - Local administrator on each SQL

Server
- Member of SQL Server sysadmin fixed
server role for each instance of SQL
Server
Before you begin the tutorial, you need to Complete prerequisites for creating Always On Availability Groups in
Azure Virtual Machines. If these prerequisites are completed already, you can jump to Create Cluster.
Create the cluster

After the prerequisites are completed, the first step is to create a Windows Server Failover Cluster that includes two
SQL Severs and a witness server.
1. RDP to the first SQL Server using a domain account that is an administrator on both SQL Servers and the
witness server.
TIP
If you followed the prerequisites document, you created an account called CORP\Install. Use this account.
2. In the Server Manager dashboard, select Tools, and then click Failover Cluster Manager.
3. In the left pane, right-click Failover Cluster Manager, and then click Create a Cluster.
4. In the Create Cluster Wizard, create a one-node cluster by stepping through the pages with the settings in
the following table:
PAGE SETTINGS
Before You Begin Use defaults

PAGE SETTINGS
Select Servers Type the first SQL Server name in Enter server name and
click Add.
Validation Warning Select No. I do not require support from Microsoft for
this cluster, and therefore do not want to run the
validation tests. When I click Next, continue Creating
the cluster.
Access Point for Administering the Cluster Type a cluster name, for example SQLAGCluster1 in
Cluster Name.
Confirmation Use defaults unless you are using Storage Spaces. See the
note following this table.
Set the cluster IP address

1. In Failover Cluster Manager, scroll down to Cluster Core Resources and expand the cluster details. You
should see both the Name and the IP Address resources in the Failed state. The IP address resource
cannot be brought online because the cluster is assigned the same IP address as the machine itself,
therefore it is a duplicate address.
2. Right-click the failed IP Address resource, and then click Properties.
3. Select Static IP Address and specify an available address from subnet where the SQL Server is in the
Address text box. Then, click OK.
4. In the Cluster Core Resources section, right-click cluster name and click Bring Online. Then, wait until both
resources are online. When the cluster name resource comes online, it updates the DC server with a new AD
computer account. Use this AD account to run the Availability Group clustered service later.
Add the other SQL Server to cluster
Add the other SQL Server to the cluster.
1. In the browser tree, right-click the cluster and click Add Node.
2. In the Add Node Wizard, click Next. In the Select Servers page, add the second SQL Server. Type the
server name in Enter server name and then click Add. When you are done, click Next.
3. In the Validation Warning page, click No (in a production scenario you should perform the validation
tests). Then, click Next.
4. In the Confirmation page if you are using Storage Spaces, clear the checkbox labeled Add all eligible
storage to the cluster.
WARNING
If you are using Storage Spaces and do not uncheck Add all eligible storage to the cluster, Windows detaches the
virtual disks during the clustering process. As a result, they do not appear in Disk Manager or Explorer until the
storage spaces are removed from the cluster and reattached using PowerShell. Storage Spaces groups multiple disks
in to storage pools. For more information, see Storage Spaces.
5. Click Next.
6. Click Finish.
Failover Cluster Manager shows that your cluster has a new node and lists it in the Nodes container.
7. Log out of the remote desktop session.
Add a cluster quorum file share
In this example the Windows cluster uses a file share to create a cluster quorum. This tutorial uses a Node and File
Share Majority quorum. For more information, see Understanding Quorum Configurations in a Failover Cluster.
1. Connect to the file share witness member server with a remote desktop session.
2. On Server Manager, click Tools. Open Computer Management.
3. Click Shared Folders.
4. Right-click Shares, and click New Share....
Use Create a Shared Folder Wizard to create a share.

5. On Folder Path, click Browse and locate or create a path for the shared folder. Click Next.
6. In Name, Description, and Settings verify the share name and path. Click Next.
7. On Shared Folder Permissions set Customize permissions. Click Custom....
8. On Customize Permissions, click Add....
9. Make sure that the account used to create the cluster has full control.
10. Click OK.

11. In Shared Folder Permissions, click Finish. Click Finish again.
12. Log out of the server
Configure cluster quorum
Next, set the cluster quorum.
1. Connect to the first cluster node with remote desktop.
2. In Failover Cluster Manager, right-click the cluster, point to More Actions, and click Configure Cluster
Quorum Settings....
3. In Configure Cluster Quorum Wizard, click Next.

4. In Select Quorum Configuration Option, choose Select the quorum witness, and click Next.
5. On Select Quorum Witness, click Configure a file share witness.
TIP
Windows Server 2016 supports a cloud witness. If you choose this type of witness, you do not need a file share
witness. For more information, see Deploy a cloud witness for a Failover Cluster. This tutorial uses a file share witness,
which is supported by previous operating systems.
6. On Configure File Share Witness, type the path for the share you created. Click Next.
7. Verify the settings on Confirmation. Click Next.
8. Click Finish.
The cluster core resources are configured with a file share witness.
Enable Availability Groups

Next, enable the AlwaysOn Availability Groups feature. Do these steps on both SQL Servers.
1. From the Start screen, launch SQL Server Configuration Manager.
2. In the browser tree, click SQL Server Services, then right-click the SQL Server (MSSQLSERVER) service and
click Properties.
3. Click the AlwaysOn High Availability tab, then select Enable AlwaysOn Availability Groups, as follows:
4. Click Apply. Click OK in the pop-up dialog.
5. Restart the SQL Server service.
Repeat these steps on the other SQL Server.
Create a database on the first SQL Server

1. Launch the RDP file to the first SQL Server with a domain account that is a member of sysadmin fixed server
role.
2. Open SQL Server Management Studio and connect to the first SQL Server.
3. In Object Explorer, right-click Databases and click New Database.
4. In Database name, type MyDB1, then click OK.
Create a backup share
1. On the first SQL Server in Server Manager, click Tools. Open Computer Management.
2. Click Shared Folders.
3. Right-click Shares, and click New Share....
Use Create a Shared Folder Wizard to create a share.

4. On Folder Path, click Browse and locate or create a path for the database backup shared folder. Click Next.
5. In Name, Description, and Settings verify the share name and path. Click Next.
6. On Shared Folder Permissions set Customize permissions. Click Custom....
7. On Customize Permissions, click Add....
8. Make sure that the SQL Server and SQL Server Agent service accounts for both servers have full control.
9. Click OK.
10. In Shared Folder Permissions, click Finish. Click Finish again.
Take a full backup of the database
You need to back up the new database to initialize the log chain. If you do not take a backup of the new database, it
cannot be included in an Availability Group.
1. In Object Explorer, right-click the database, point to Tasks..., click Back Up.
2. Click OK to take a full backup to the default backup location.
Create the Availability Group

You are now ready to configure an Availability Group using the following steps:
Create a database on the first SQL Server.
Take both a full backup and a transaction log backup of the database
Restore the full and log backups to the second SQL Server with the NORECOVERY option
Create the Availability Group (AG1) with synchronous commit, automatic failover, and readable secondary
replicas
Create the Availability Group:
1. On remote desktop session to the first SQL Server. In Object Explorer in SSMS, right-click AlwaysOn
High Availability and click New Availability Group Wizard.
2. In the Introduction page, click Next. In the Specify Availability Group Name page, type a name for the
Availability Group, for example AG1, in Availability group name. Click Next.
3. In the Select Databases page, select your database and click Next.
NOTE
The database meets the prerequisites for an Availability Group because you have taken at least one full backup on
the intended primary replica.
4. In the Specify Replicas page, click Add Replica.
5. The Connect to Server dialog pops up. Type the name of the second server in Server name. Click
Connect.
Back in the Specify Replicas page, you should now see the second server listed in Availability Replicas.
Configure the replicas as follows.
6. Click Endpoints to see the database mirroring endpoint for this Availability Group. Use the same port that
you used when you set the firewall rule for database mirroring endpoints.
7. In the Select Initial Data Synchronization page, select Full and specify a shared network location. For the
location, use the backup share that you created. In the example it was, \\<First SQL Server>\Backup\. Click
Next.
NOTE
Full synchronization takes a full backup of the database on the first instance of SQL Server and restores it to the
second instance. For large databases, full synchronization is not recommended because it may take a long time. You
can reduce this time by manually taking a backup of the database and restoring it with NO RECOVERY . If the
database is already restored with NO RECOVERY on the second SQL Server before configuring the Availability Group,
choose Join only. If you want to take the backup after configuring the Availability Group, choose Skip initial data
synchronization.
8. In the Validation page, click Next. This page should look similar to the following image:
NOTE
There is a warning for the listener configuration because you have not configured an Availability Group listener. You
can ignore this warning because on Azure virtual machines you create the listener after creating the Azure load
balancer.
9. In the Summary page, click Finish, then wait while the wizard configures the new Availability Group. In the
Progress page, you can click More details to view the detailed progress. Once the wizard is finished,
inspect the Results page to verify that the Availability Group is successfully created.
10. Click Close to exit the wizard.
Check the Availability Group
1. In Object Explorer, expand AlwaysOn High Availability, then expand Availability Groups. You should
now see the new Availability Group in this container. Right-click the Availability Group and click Show
Dashboard.
Your AlwaysOn Dashboard should look similar to this.

You can see the replicas, the failover mode of each replica and the synchronization state.
2. In Failover Cluster Manager, click your cluster. Select Roles. The Availability Group name you used is a
role on the cluster. That Availability Group does not have an IP address for client connections, because you
did not configure a listener. You will configure the listener after you create an Azure load balancer.
WARNING
Do not try to fail over the Availability Group from the Failover Cluster Manager. All failover operations should be
performed from within AlwaysOn Dashboard in SSMS. For more information, see Restrictions on Using The Failover
Cluster Manager with Availability Groups.
At this point, you have an Availability Group with replicas on two instances of SQL Server. You can move the
Availability Group between instances. You cannot connect to the Availability Group yet because you do not have a
listener. In Azure virtual machines, the listener requires a load balancer. The next step is to create the load balancer
in Azure.
Create an Azure load balancer

On Azure virtual machines, a SQL Server Availability Group requires a load balancer. The load balancer holds the IP
address for the Availability Group listener. This section summarizes how to create the load balancer in the Azure
portal.
1. In the Azure portal, go to the resource group where your SQL Servers are and click + Add.
2. Search for Load Balancer. Choose the load balancer published by Microsoft.
3. Click Create.
4. Configure the following parameters for the load balancer.
SETTING FIELD
Name Use a text name for the load balancer, for example sqlLB.
Type Internal
Virtual network Use the name of the Azure virtual network.
Subnet Use the name of the subnet that the virtual machine is in.
IP address assignment Static
IP address Use an available address from subnet.
Subscription Use the same subscription as the virtual machine.
Location Use the same location as the virtual machine.
The Azure portal blade should look like this:

5. Click Create, to create the load balancer.
To configure the load balancer, you need to create a backend pool, a probe, and set the load balancing rules. Do
these in the Azure portal.
Add backend pool
1. In the Azure portal, go to your availability group. You might need to refresh the view to see the newly
created load balancer.
2. Click the load balancer, click Backend pools, and click +Add. Set the backend pool as follows:
SETTING DESCRIPTION EXAMPLE
Name Type a text name SQLLBBE
Associated to Pick from list Availability set
Availability set Use a name of the availability set sqlAvailabilitySet

that your SQL Server VMs are in
Virtual machines The two Azure SQL Server VM names sqlserver-0, sqlserver-1
3. Type the name for the back end pool.

4. Click + Add a virtual machine.
5. For the availability set, choose the availability set that the SQL Servers are in.
6. For virtual machines, include both of the SQL Servers. Do not include the file share witness server.
7. Click OK to create the backend pool.
Set the probe
1. Click the load balancer, click Health probes, and click +Add.
2. Set the health probe as follows:
Name Text SQLAlwaysOnEndPointProbe
Protocol Choose TCP TCP
Port Any unused port 59999
Interval The amount of time between probe 5

attempts in seconds
Unhealthy threshold The number of consecutive probe 2

failures that must occur for a virtual
machine to be considered unhealthy
3. Click OK to set the health probe.

Set the load balancing rules
1. Click the load balancer, click Load balancing rules, and click +Add.
2. Set the load balancing rules as follows.
Name Text SQLAlwaysOnEndPointListener
Frontend IP address Choose an address Use the address that you created
when you created the load balancer.
Protocol Choose TCP TCP
Port Use the port for the SQL Server 1433

instance
Backend Port This field is not used when Floating 1433

IP is set for direct server return
Probe The name you specified for the probe SQLAlwaysOnEndPointProbe
Session Persistence Drop down list None
Idle Timeout Minutes to keep a TCP connection 4

open
Floating IP (direct server return) Enabled
WARNING
Direct server return is set during creation. It cannot be changed.
3. Click OK to set the load balancing rules.
Configure the listener

The next thing to do is to configure an Availability Group listener on the failover cluster.
NOTE
This tutorial shows how to create a single listener - with one ILB IP address. To create one or more listeners using one or
more IP addresses, see Create Availability Group listener and load balancer | Azure.
The availability group listener is an IP address and network name that the SQL Server availability group listens on.
To create the availability group listener, do the following:
1. Get the name of the cluster network resource.
a. Use RDP to connect to the Azure virtual machine that hosts the primary replica.
b. Open Failover Cluster Manager.
c. Select the Networks node, and note the cluster network name. Use this name in the $ClusterNetworkName
variable in the PowerShell script. In the following image the cluster network name is Cluster Network 1:
2. Add the client access point.

The client access point is the network name that applications use to connect to the databases in an
availability group. Create the client access point in Failover Cluster Manager.
a. Expand the cluster name, and then click Roles.
b. In the Roles pane, right-click the availability group name, and then select Add Resource > Client Access
Point.
c. In the Name box, create a name for this new listener. The name for the new listener is the network name
that applications use to connect to databases in the SQL Server availability group.
d. To finish creating the listener, click Next twice, and then click Finish. Do not bring the listener or resource
online at this point.
3. Configure the IP resource for the availability group.
a. Click the Resources tab, and then expand the client access point you created.
The client access point is offline.
b. Right-click the IP resource, and then click properties. Note the name of the IP address, and use it in the
$IPResourceName variable in the PowerShell script.
c. Under IP Address, click Static IP Address. Set the IP address as the same address that you used when
you set the load balancer address on the Azure portal.
4. Make the SQL Server availability group resource dependent on the client access point.
a. In Failover Cluster Manager, click Roles, and then click your availability group.
b. On the Resources tab, under Other Resources, right-click the availability resource group, and then click
Properties.
c. On the dependencies tab, add the name of the client access point (the listener) resource.
d. Click OK.
5. Make the client access point resource dependent on the IP address.
b. On the Resources tab, right-click the client access point resource under Server Name, and then click
Properties.
c. Click the Dependencies tab. Verify that the IP address is a dependency. If it is not, set a dependency on
the IP address. If there are multiple resources listed, verify that the IP addresses have OR, not AND,
dependencies. Click OK.
d. Right-click the listener name, and then click Bring Online.
TIP
You can validate that the dependencies are correctly configured. In Failover Cluster Manager, go to Roles, right-click
the availability group, click More Actions, and then click Show Dependency Report. When the dependencies are
correctly configured, the availability group is dependent on the network name, and the network name is dependent
on the IP address.
6. Set the cluster parameters in PowerShell.

a. Copy the following PowerShell script to one of your SQL Server instances. Update the variables for your
environment.
$ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on

Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP Address resource name
$ILBIP = <n.n.n.n> # the IP Address of the Internal Load Balancer (ILB). This is the static IP
address for the load balancer you configured in the Azure portal.
[int]$ProbePort = <nnnnn>
Import-Module FailoverClusters
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple

@{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkNa
me";"EnableDhcp"=0}
b. Set the cluster parameters by running the PowerShell script on one of the cluster nodes.
NOTE
If your SQL Server instances are in separate regions, you need to run the PowerShell script twice. The first time, use
the $ILBIP and $ProbePort from the first region. The second time, use the $ILBIP and $ProbePort from the
second region. The cluster network name and the cluster IP resource name are the same.
Set listener port
In SQL Server Management Studio, set the listener port.
1. Launch SQL Server Management Studio and connect to the primary replica.
2. Navigate to AlwaysOn High Availability | Availability Groups | Availability Group Listeners.
3. You should now see the listener name that you created in Failover Cluster Manager. Right-click the listener
name and click Properties.
4. In the Port box, specify the port number for the Availability Group listener by using the $EndpointPort you
used earlier (1433 was the default), then click OK.
You now have a SQL Server Availability Group in Azure virtual machines running in Resource Manager mode.
Test connection to listener

To test the connection:
1. RDP to a SQL Server that is in the same virtual network, but does not own the replica. You can use the other
SQL Server in the cluster.
2. Use sqlcmd utility to test the connection. For example, the following script establishes a sqlcmd connection
to the primary replica through the listener with Windows authentication:
sqlcmd -S <listenerName> -E
If the listener is using a port other than the default port (1433), specify the port in the connection string. For
example, the following sqlcmd command connects to a listener at port 1435:
sqlcmd -S <listenerName>,1435 -E
The SQLCMD connection automatically connects to whichever instance of SQL Server hosts the primary replica.
TIP
Make sure that the port you specify is open on the firewall of both SQL Servers. Both servers require an inbound rule for the
TCP port that you use. For more information, see Add or Edit Firewall Rule.
Next steps
Add an IP address to a load balancer for a second availability group.
Configure a load balancer for an Always On
availability group in Azure
This article explains how to create a load balancer for a SQL Server Always On availability group in Azure virtual
machines that are running with Azure Resource Manager. An availability group requires a load balancer when the
SQL Server instances are on Azure virtual machines. The load balancer stores the IP address for the availability
group listener. If an availability group spans multiple regions, each region needs a load balancer.
To complete this task, you need to have a SQL Server availability group deployed on Azure virtual machines that are
running with Resource Manager. Both SQL Server virtual machines must belong to the same availability set. You
can use the Microsoft template to automatically create the availability group in Resource Manager. This template
automatically creates an internal load balancer for you.
If you prefer, you can manually configure an availability group.
This article requires that your availability groups are already configured.
Related topics include:
Configure Always On availability groups in Azure VM (GUI)
Configure a VNet-to-VNet connection by using Azure Resource Manager and PowerShell
By walking through this article, you create and configure a load balancer in the Azure portal. After the process is
complete, you configure the cluster to use the IP address from the load balancer for the availability group listener.
Create and configure the load balancer in the Azure portal

In this portion of the task, do the following:
1. In the Azure portal, create the load balancer and configure the IP address.
2. Configure the back-end pool.
3. Create the probe.
4. Set the load balancing rules.
NOTE
If the SQL Server instances are in multiple resource groups and regions, perform each step twice, once in each resource group.
Step 1: Create the load balancer and configure the IP address

First, create the load balancer.
1. In the Azure portal, open the resource group that contains the SQL Server virtual machines.
2. In the resource group, click Add.
3. Search for load balancer and then, in the search results, select Load Balancer, which is published by
Microsoft.
4. On the Load Balancer blade, click Create.
5. In the Create load balancer dialog box, configure the load balancer as follows:
SETTING VALUE
Name A text name representing the load balancer. For example,

sqlLB.
Type Internal: Most implementations use an internal load

balancer, which allows applications within the same virtual
network to connect to the availability group.
External: Allows applications to connect to the availability
group through a public Internet connection.
Virtual network Select the virtual network that the SQL Server intances are
in.
Subnet Select the subnet that the SQL Server instances are in.
IP address assignment Static
Private IP address Specify an available IP address from the subnet. Use this IP
address when you create a listener on the cluster. In a
PowerShell script, later in this article, use this address for
the $ILBIP variable.
Subscription If you have multiple subscriptions, this field might appear.

Select the subscription that you want to associate with this
resource. It is normally the same subscription as all the
resources for the availability group.
Resource group Select the resource group that the SQL Server instances
are in.
Location Select the Azure location that the SQL Server instances are
in.
6. Click Create.
Azure creates the load balancer. The load balancer belongs to a specific network, subnet, resource group, and
location. After Azure completes the task, verify the load balancer settings in Azure.
Step 2: Configure the back-end pool
Azure calls the back-end address pool backend pool. In this case, the back-end pool is the addresses of the two SQL
Server instances in your availability group.
1. In your resource group, click the load balancer that you created.
2. On Settings, click Backend pools.
3. On Backend pools, click Add to create a back-end address pool.
4. On Add backend pool, under Name, type a name for the back-end pool.
5. Under Virtual machines, click Add a virtual machine.
6. Under Choose virtual machines, click Choose an availability set, and then specify the availability set that
the SQL Server virtual machines belong to.
7. After you have chosen the availability set, click Choose the virtual machines, select the two virtual
machines that host the SQL Server instances in the availability group, and then click Select.
8. Click OK to close the blades for Choose virtual machines, and Add backend pool.
Azure updates the settings for the back-end address pool. Now your availability set has a pool of two SQL Server
instances.
Step 3: Create a probe
The probe defines how Azure verifies which of the SQL Server instances currently owns the availability group
listener. Azure probes the service based on the IP address on a port that you define when you create the probe.
1. On the load balancer Settings blade, click Health probes.
2. On the Health probes blade, click Add.
3. Configure the probe on the Add probe blade. Use the following values to configure the probe:
SETTING VALUE
Name A text name representing the probe. For example,

SQLAlwaysOnEndPointProbe.
Protocol TCP
Port You can use any available port. For example, 59999.
Interval 5
Unhealthy threshold 2
4. Click OK.
NOTE
Make sure that the port you specify is open on the firewall of both SQL Server instances. Both instances require an inbound
rule for the TCP port that you use. For more information, see Add or Edit Firewall Rule.
Azure creates the probe and then uses it to test which SQL Server instance has the listener for the availability group.
Step 4: Set the load balancing rules
The load balancing rules configure how the load balancer routes traffic to the SQL Server instances. For this load
balancer, you enable direct server return because only one of the two SQL Server instances owns the availability
group listener resource at a time.
1. On the load balancer Settings blade, click Load balancing rules.
2. On the Load balancing rules blade, click Add.
3. On the Add load balancing rules blade, configure the load balancing rule. Use the following settings:
SETTING VALUE
Name A text name representing the load balancing rules. For

example, SQLAlwaysOnEndPointListener.
Protocol TCP
Port 1433
SETTING VALUE
Backend Port 1433. This value is ignored because this rule uses Floating
IP (direct server return).
Probe Use the name of the probe that you created for this load
balancer.
Session persistence None
Idle timeout (minutes) 4
NOTE
You might have to scroll down the blade to view all the settings.
4. Click OK.
5. Azure configures the load balancing rule. Now the load balancer is configured to route traffic to the SQL Server
instance that hosts the listener for the availability group.
At this point, the resource group has a load balancer that connects to both SQL Server machines. The load balancer
also contains an IP address for the SQL Server Always On availability group listener, so that either machine can
respond to requests for the availability groups.
NOTE
If your SQL Server instances are in two separate regions, repeat the steps in the other region. Each region requires a load
balancer.
Configure the cluster to use the load balancer IP address

The next step is to configure the listener on the cluster, and bring the listener online. Do the following:
1. Create the availability group listener on the failover cluster.
2. Bring the listener online.
Step 5: Create the availability group listener on the failover cluster
In this step, you manually create the availability group listener in Failover Cluster Manager and SQL Server
Management Studio.
Point.
c. Under IP Address, click Static IP Address. Set the IP address as the same address that you used when you
set the load balancer address on the Azure portal.
Properties.
d. Click OK.
Properties.
c. Click the Dependencies tab. Verify that the IP address is a dependency. If it is not, set a dependency on the
IP address. If there are multiple resources listed, verify that the IP addresses have OR, not AND,
TIP
on the IP address.

environment.

$ILBIP = <n.n.n.n> # the IP Address of the Internal Load Balancer (ILB). This is the static IP address
for the load balancer you configured in the Azure portal.

@{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkNam
e";"EnableDhcp"=0}
NOTE
Verify the configuration of the listener
If the cluster resources and dependencies are correctly configured, you should be able to view the listener in SQL
Server Management Studio. To set the listener port, do the following:
1. Start SQL Server Management Studio, and then connect to the primary replica.
2. Go to AlwaysOn High Availability > Availability Groups > Availability Group Listeners.
You should now see the listener name that you created in Failover Cluster Manager.
3. Right-click the listener name, and then click Properties.
4. In the Port box, specify the port number for the availability group listener by using the $EndpointPort you
used earlier (1433 was the default), and then click OK.
You now have an availability group in Azure virtual machines running in Resource Manager mode.
Test the connection to the listener

Test the connection by doing the following:
1. RDP to a SQL Server instance that is in the same virtual network, but does not own the replica. This server
can be the other SQL Server instance in the cluster.
sqlcmd -S <listenerName> -E
The SQLCMD connection automatically connects to the SQL Server instance that hosts the primary replica.
Create an IP address for an additional availability group

Each availability group uses a separate listener. Each listener has its own IP address. Use the same load balancer to
hold the IP address for additional listeners. After you create an availability group, add the IP address to the load
balancer, and then configure the listener.
To add an IP address to a load balancer with the Azure portal, do the following:
1. In the Azure portal, open the resource group that contains the load balancer, and then click the load balancer.
2. Under SETTINGS, click Frontend IP pool, and then click Add.
3. Under Add frontend IP address, assign a name for the front end.
4. Verify that the Virtual network and the Subnet are the same as the SQL Server instances.
5. Set the IP address for the listener.
TIP
You can set the IP address to static and type an address that is not currently used in the subnet. Alternatively, you
can set the IP address to dynamic and save the new front-end IP pool. When you do so, the Azure portal
automatically assigns an available IP address to the pool. You can then reopen the front-end IP pool and change the
assignment to static.
6. Save the IP address for the listener.

7. Add a health probe by using the following settings:
SETTING VALUE
Name A name to identify the probe.
Protocol TCP
Port An unused TCP port, which must be available on all virtual

machines. It cannot be used for any other purpose. No two
listeners can use the same probe port.
Interval The amount of time between probe attempts. Use the

default (5).
Unhealthy threshold The number of consecutive thresholds that should fail

before a virtual machine is considered unhealthy.
8. Click OK to save the probe.

9. Create a load balancing rule. Click Load balancing rules, and then click Add.
10. Configure the new load balancing rule by using the following settings:
SETTING VALUE
Name A name to identify the load balancing rule.
Frontend IP address Select the IP address you created.
Protocol TCP
Port Use the port that the SQL Server instances are using. A
default instance uses port 1433, unless you changed it.
Backend port Use the same value as Port.
Backend pool The pool that contains the virtual machines with the SQL
Server instances.
Health probe Choose the probe you created.
Session persistence None
Idle timeout (minutes) Default (4)
Configure the availability group to use the new IP address

To finish configuring the cluster, repeat the steps that you followed when you made the first availability group. That
is, configure the cluster to use the new IP address.
After you have added an IP address for the listener, configure the additional availability group by doing the
following:
1. Verify that the probe port for the new IP address is open on both SQL Server virtual machines.
2. In Cluster Manager, add the client access point.
IMPORTANT
When you create the IP address, use the IP address that you added to the load balancer.
After you configure the availability group to use the new IP address, configure the connection to the listener.
Next steps
Configure a SQL Server Always On availability group on Azure virtual machines in different regions
Configure one or more Always On availability group
listeners - Resource Manager
This topic shows how to:

Create an internal load balancer for SQL Server availability groups using PowerShell cmdlets.
Add additional IP addresses to a load balancer for more than one availability group.
An availability group listener is a virtual network name that clients connect to for database access. On Azure virtual
machines, a load balancer holds the IP address for the listener. The load balancer routes traffic to the instance of
SQL Server that is listening on the probe port. Usually, an availability group uses an internal load balancer. An
Azure internal load balancer can host one or many IP addresses. Each IP address uses a specific probe port. This
document shows how to use PowerShell to create a load balancer, or add IP addresses to an existing load balancer
for SQL Server availability groups.
The ability to assign multiple IP addresses to an internal load balancer is new to Azure and is only available in
Resource Manager model. To complete this task, you need to have a SQL Server availability group deployed on
Azure virtual machines in Resource Manager model. Both SQL Server virtual machines must belong to the same
availability set. You can use the Microsoft template to automatically create the availability group in Azure Resource
Manager. This template automatically creates the availability group, including the internal load balancer for you. If
you prefer, you can manually configure an Always On availability group.
This topic requires that your availability groups are already configured.
Related topics include:
Configure AlwaysOn Availability Groups in Azure VM (GUI)
Configure a VNet-to-VNet connection by using Azure Resource Manager and PowerShell
Start your PowerShell session

First you need to have the latest Azure PowerShell installed and running. For detailed information, see How to
install and configure Azure PowerShell.
NOTE
The examples in this topic use Azure Resource Manager deployment model, so examples use the Azure Resource Manager
cmdlets.
Run the Add-AzureRmAccount cmdlet and you will be presented with a sign in screen to enter your credentials.
Use the same credentials that you use to sign in to the Azure portal.
Add-AzureRmAccount
If you have multiple subscriptions use the Set-AzureRmContext cmdlet to select which subscription your
PowerShell session should use. To see what subscription the current PowerShell session is using, run Get-
AzureRmContext. To see all your subscriptions, run Get-AzureRmSubscription.
Set-AzureRmContext -SubscriptionId '4cac86b0-1e56-bbbb-aaaa-000000000000'
Configure the Windows Firewall

Configure the Windows Firewall to allow SQL Server access. The firewall rules allow TCP connections to the ports
use by the SQL Server instance, and the listener probe. For detailed instructions, see Configure a Windows Firewall
for Database Engine Access. Create an inbound rule for the SQL Server port and for the probe port.
Example Script: Create an internal load balancer with PowerShell

NOTE
If you created your availability group with the Microsoft template, the internal load balancer was already created.
The following PowerShell script creates an internal load balancer, configures the load balancing rules, and sets an
IP address for the load balancer. To run the script, open Windows PowerShell ISE, and paste the script in the Script
pane. Use Login-AzureRMAccount to log in to PowerShell. If you have multiple Azure subscriptions, use
Select-AzureRmSubscription to set the subscription.
# Login-AzureRmAccount
# Select-AzureRmSubscription -SubscriptionId <xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>
$ResourceGroupName = "<Resource Group Name>" # Resource group name

$VNetName = "<Virtual Network Name>" # Virtual network name
$SubnetName = "<Subnet Name>" # Subnet name
$ILBName = "<Load Balancer Name>" # ILB name
$Location = "<Azure Region>" # Azure location
$VMNames = "<VM1>","<VM2>" # Virtual machine names
$ILBIP = "<n.n.n.n>" # IP address

[int]$ListenerPort = "<nnnn>" # AG listener port
[int]$ProbePort = "<nnnn>" # Probe port
$LBProbeName ="ILBPROBE_$ListenerPort" # The Load balancer Probe Object Name

$LBConfigRuleName = "ILBCR_$ListenerPort" # The Load Balancer Rule Object Name
$FrontEndConfigurationName = "FE_SQLAGILB_1" # Object name for the front-end configuration

$BackEndConfigurationName ="BE_SQLAGILB_1" # Object name for the back-end configuration
$VNet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName
$Subnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name $SubnetName
$FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationName -PrivateIpAddress $ILBIP

-SubnetId $Subnet.id
$BEConfig = New-AzureRMLoadBalancerBackendAddressPoolConfig -Name $BackEndConfigurationName
$SQLHealthProbe = New-AzureRmLoadBalancerProbeConfig -Name $LBProbeName -Protocol tcp -Port $ProbePort -

IntervalInSeconds 15 -ProbeCount 2
$ILBRule = New-AzureRmLoadBalancerRuleConfig -Name $LBConfigRuleName -FrontendIpConfiguration $FEConfig -

BackendAddressPool $BEConfig -Probe $SQLHealthProbe -Protocol tcp -FrontendPort $ListenerPort -BackendPort
$ListenerPort -LoadDistribution Default -EnableFloatingIP
$ILB= New-AzureRmLoadBalancer -Location $Location -Name $ILBName -ResourceGroupName $ResourceGroupName -

FrontendIpConfiguration $FEConfig -BackendAddressPool $BEConfig -LoadBalancingRule $ILBRule -Probe
$SQLHealthProbe
$bepool = Get-AzureRmLoadBalancerBackendAddressPoolConfig -Name $BackEndConfigurationName -LoadBalancer $ILB
foreach($VMName in $VMNames)
{
$VM = Get-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $VMName
$NICName = ($vm.NetworkProfile.NetworkInterfaces.Id.split('/') | select -last 1)
$NIC = Get-AzureRmNetworkInterface -name $NICName -ResourceGroupName $ResourceGroupName
$NIC.IpConfigurations[0].LoadBalancerBackendAddressPools = $BEPool
Set-AzureRmNetworkInterface -NetworkInterface $NIC
start-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $VM.Name
}
Example script: Add an IP address to an existing load balancer with

PowerShell
To use more than one availability group, add an additional IP address to the load balancer. Each IP address requires
its own load balancing rule, probe port, and front port.
The front-end port is the port that applications use to connect to the SQL Server instance. IP addresses for different
availability groups can use the same front-end port.
NOTE
For SQL Server availability groups, each IP address requires a specific probe port. For example, if one IP address on a load
balancer uses probe port 59999, no other IP addresses on that load balancer can use probe port 59999.
For information about load balancer limits, see Private front end IP per load balancer under Networking
Limits - Azure Resource Manager.
For information about availability group limits, see Restrictions (Availability Groups).
The following script adds a new IP address to an existing load balancer. The ILB uses the listener port for the load
balancing front-end port. This port can be the port that SQL Server is listening on. For default instances of SQL
Server, the port is 1433. The load balancing rule for an availability group requires a floating IP (direct server return)
so the back-end port is the same as the front-end port. Update the variables for your environment.
# Login-AzureRmAccount
# Select-AzureRmSubscription -SubscriptionId <xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>
$ResourceGroupName = "<ResourceGroup>" # Resource group name

$VNetName = "<VirtualNetwork>" # Virtual network name
$SubnetName = "<Subnet>" # Subnet name
$ILBName = "<ILBName>" # ILB name
$ILBIP = "<n.n.n.n>" # IP address

[int]$ListenerPort = "<nnnn>" # AG listener port
[int]$ProbePort = "<nnnnn>" # Probe port
$ILB = Get-AzureRmLoadBalancer -Name $ILBName -ResourceGroupName $ResourceGroupName
$count = $ILB.FrontendIpConfigurations.Count+1
$FrontEndConfigurationName ="FE_SQLAGILB_$count"
$LBProbeName = "ILBPROBE_$count"
$LBConfigrulename = "ILBCR_$count"
$VNet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName

$Subnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name $SubnetName
$ILB | Add-AzureRmLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationName -PrivateIpAddress $ILBIP -

SubnetId $Subnet.Id
$ILB | Add-AzureRmLoadBalancerProbeConfig -Name $LBProbeName -Protocol Tcp -Port $Probeport -ProbeCount 2 -

IntervalInSeconds 15 | Set-AzureRmLoadBalancer
$ILB = Get-AzureRmLoadBalancer -Name $ILBname -ResourceGroupName $ResourceGroupName
$FEConfig = get-AzureRMLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationName -LoadBalancer $ILB
$SQLHealthProbe = Get-AzureRmLoadBalancerProbeConfig -Name $LBProbeName -LoadBalancer $ILB
$BEConfig = Get-AzureRmLoadBalancerBackendAddressPoolConfig -Name $ILB.BackendAddressPools[0].Name -

LoadBalancer $ILB
$ILB | Add-AzureRmLoadBalancerRuleConfig -Name $LBConfigRuleName -FrontendIpConfiguration $FEConfig -

BackendAddressPool $BEConfig -Probe $SQLHealthProbe -Protocol tcp -FrontendPort $ListenerPort -BackendPort
$ListenerPort -LoadDistribution Default -EnableFloatingIP | Set-AzureRmLoadBalancer
Configure the listener


Point.
c. Under IP Address, click Static IP Address. Set the IP address as the same address that you used when
you set the load balancer address on the Azure portal.
Properties.
d. Click OK.
Properties.
c. Click the Dependencies tab. Verify that the IP address is a dependency. If it is not, set a dependency on
the IP address. If there are multiple resources listed, verify that the IP addresses have OR, not AND,
TIP
on the IP address.

environment.

$ILBIP = <n.n.n.n> # the IP Address of the Internal Load Balancer (ILB). This is the static IP address
for the load balancer you configured in the Azure portal.

@{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkNam
e";"EnableDhcp"=0}
NOTE
Set the listener port in SQL Server Management Studio
1. Launch SQL Server Management Studio and connect to the primary replica.
2. Navigate to AlwaysOn High Availability | Availability Groups | Availability Group Listeners.
3. You should now see the listener name that you created in Failover Cluster Manager. Right-click the listener
name and click Properties.
4. In the Port box, specify the port number for the availability group listener by using the $EndpointPort you
used earlier (1433 was the default), then click OK.
Test the connection to the listener

To test the connection:
1. RDP to a SQL Server that is in the same virtual network, but does not own the replica. This can be the other
SQL Server in the cluster.
sqlmd -S <listenerName> -E
If the listener is using a port other than the default port (1433), specify the port in the connection string. For
example, the following sqlcmd command connects to a listener at port 1435:
sqlcmd -S <listenerName>,1435 -E
The SQLCMD connection automatically connects to whichever instance of SQL Server hosts the primary replica.
NOTE
Make sure that the port you specify is open on the firewall of both SQL Servers. Both servers require an inbound rule for the
TCP port that you use. See Add or Edit Firewall Rule for more information.
Guidelines and limitations

Note the following guidelines on availability group listener in Azure using internal load balancer:
With an internal load balancer, you only access the listener from within the same virtual network.
For more information

For more information, see Configure Always On availability group in Azure VM manually.
PowerShell cmdlets
Use the following PowerShell cmdlets to create an internal load balancer for Azure virtual machines.
New-AzureRmLoadBalancer creates a load balancer.
New-AzureRMLoadBalancerFrontendIpConfig creates a front-end IP configuration for a load balancer.
New-AzureRmLoadBalancerRuleConfig creates a rule configuration for a load balancer.
New-AzureRmLoadBalancerBackendAddressPoolConfig creates a backend address pool configuration for a load
balancer.
New-AzureRmLoadBalancerProbeConfig creates a probe configuration for a load balancer.
Remove-AzureRmLoadBalancer removes a load balancer from an Azure resource group.
Configure an Always On availability group on Azure
virtual machines in different regions
This article explains how to configure a SQL Server Always On availability group replica on Azure virtual machines
in a remote Azure location. Use this configuration to support disaster recovery.
This article applies to Azure Virtual Machines in Resource Manager mode.
The following image shows a common deployment of an availability group on Azure virtual machines:
In this deployment, all virtual machines are in one Azure region. The availability group replicas can have
synchronous commit with automatic failover on SQL-1 and SQL-2. To build this architecture, see Availability Group
template or tutorial.
This architecture is vulnerable to downtime if the Azure region becomes inaccessible. To overcome this
vulnerability, add a replica in a different Azure region. The following diagram shows how the new architecture
would look:
The preceding diagram shows a new virtual machine called SQL-3. SQL-3 is in a different Azure region. SQL-3 is
added to the Windows Server Failover Cluster. SQL-3 can host an availability group replica. Finally, notice that the
Azure region for SQL-3 has a new Azure load balancer.
NOTE
An Azure availability set is required when more than one virtual machine is in the same region. If only one virtual machine is
in the region, then the availability set is not required. You can only place a virtual machine in an availability set at creation
time. If the virtual machine is already in an availability set, you can add a virtual machine for an additional replica later.
In this architecture, the replica in the remote region is normally configured with asynchronous commit availability
mode and manual failover mode.
When availability group replicas are on Azure virtual machines in different Azure regions, each region requires:
A virtual network gateway
A virtual network gateway connection
The following diagram shows how the networks communicate between data centers.
IMPORTANT
This architecture incurs outbound data charges for data replicated between Azure regions. See Bandwidth Pricing.
Create remote replica

To create a replica in a remote data center, do the following steps:
1. Create a virtual network in the new region.
2. Configure a VNet-to-VNet connection using the Azure portal.
NOTE
In some cases, you may have to use PowerShell to create the VNet-to-VNet connection. For example, if you use
different Azure accounts you cannot configure the connection in the portal. In this case see, Configure a VNet-to-
VNet connection using the Azure portal.
3. Create a domain controller in the new region.

This domain controller provides authentication if the domain controller in the primary site is not available.
4. Create a SQL Server virtual machine in the new region.
5. Create an Azure load balancer in the network on the new region.
This load balancer must:
Be in the same network and subnet as the new virtual machine.
Have a static IP address for the availability group listener.
Include a backend pool consisting of only the virtual machines in the same region as the load balancer.
Use a TCP port probe specific to the IP address.
Have a load balancing rule specific to the SQL Server in the same region.
6. Add Failover Clustering feature to the new SQL Server.
7. Join the new SQL Server to the domain.
8. Set the new SQL Server service account to use a domain account.
9. Add the new SQL Server to the Windows Server Failover Cluster.
10. Create an IP address resource on the cluster.
You can create the IP address resource in Failover Cluster Manager. Right-click the availability group role,
click Add Resource, More Resources, and click IP Address.
Configure this IP address as follows:

Use the network from the remote data center.
Assign the IP address from the new Azure load balancer.
11. On the new SQL Server in SQL Server Configuration Manager, enable Always On Availability Groups.
12. Open firewall ports on the new SQL Server.
The port numbers you need to open depend on your environment. Open ports for the mirroring endpoint
and Azure load balancer health probe.
13. Add a replica to the availability group on the new SQL Server.
For a replica in a remote Azure region, set it for asynchronous replication with manual failover.
14. Add the IP address resource as a dependency for the listener client access point (network name) cluster.
The following screenshot shows a properly configured IP address cluster resource:
IMPORTANT
The cluster resource group includes both IP addresses. Both IP addresses are dependencies for the listener client
access point. Use the OR operator in the cluster dependency configuration.

Run the PowerShell script with the cluster network name, IP address, and probe port that you configured on the
load balancer in the new region.
$ClusterNetworkName = "<MyClusterNetworkName>" # The cluster name for the network in the new region (Use Get-
ClusterNetwork on Windows Server 2012 of higher to find the name).
$IPResourceName = "<IPResourceName>" # The cluster name for the new IP Address resource.
$ILBIP = <n.n.n.n> # The IP Address of the Internal Load Balancer (ILB) in the new region. This is the
static IP address for the load balancer you configured in the Azure portal.
[int]$ProbePort = <nnnnn> # The probe port you set on the ILB.

@{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"En
ableDhcp"=0}
Set connection for multiple subnets

The replica in the remote data center is part of the availability group but it is in a different subnet. If this replica
becomes the primary replica, application connection time-outs may occur. This behavior is the same as an on-
premises availability group in a multi-subnet deployment. To allow connections from client applications, either
update the client connection or configure name resolution caching on the cluster network name resource.
Preferably, update the client connection strings to set MultiSubnetFailover=Yes . See Connecting With
MultiSubnetFailover.
If you cannot modify the connection strings, you can configure name resolution caching. See Connection Timeouts
in Multi-subnet Availability Group.
Fail over to remote region

To test listener connectivity to the remote region, you can fail over the replica to the remote region. While the
replica is asynchronous, failover is vulnerable to potential data loss. To fail over without data loss, change the
availability mode to synchronous and set the failover mode to automatic. Use the following steps:
1. In Object Explorer, connect to the instance of SQL Server that hosts the primary replica.
2. Under AlwaysOn Availability Groups, Availability Groups, right-click your availability group and click
Properties.
3. On the General page, under Availability Replicas, set the secondary replica in the DR site to use
Synchronous Commit availability mode and Automatic failover mode.
4. If you have a secondary replica in same site as your primary replica for high availability, set this replica to
Asynchronous Commit and Manual.
5. Click OK.
6. In Object Explorer, right-click the availability group, and click Show Dashboard.
7. On the dashboard, verify that the replica on the DR site is synchronized.
8. In Object Explorer, right-click the availability group, and click Failover.... SQL Server Management Studios
opens a wizard to fail over SQL Server.
9. Click Next, and select the SQL Server instance in the DR site. Click Next again.
10. Connect to the SQL Server instance in the DR site and click Next.
11. On the Summary page, verify the settings and click Finish.
After testing connectivity, move the primary replica back to your primary data center and set the availability mode
back to their normal operating settings. The following table shows the normal operational settings for the
architecture described in this document:
LOCATION SERVER INSTANCE ROLE AVAILABILITY MODE FAILOVER MODE
Primary data center SQL-1 Primary Synchronous Automatic
Primary data center SQL-2 Secondary Synchronous Automatic
Secondary or remote SQL-3 Secondary Asynchronous Manual

data center
More information about planned and forced manual failover

For more information, see the following topics:
Perform a Planned Manual Failover of an Availability Group (SQL Server)
Perform a Forced Manual Failover of an Availability Group (SQL Server)
Additional Links
Always On Availability Groups
Azure Virtual Machines
Azure Load Balancers
Azure Availability Sets
Configure SQL Server Failover Cluster Instance on
This article explains how to create a SQL Server Failover Cluster Instance (FCI) on Azure virtual machines in
Resource Manager model. This solution uses Windows Server 2016 Datacenter edition Storage Spaces Direct (S2D)
as a software-based virtual SAN that synchronizes the storage (data disks) between the nodes (Azure VMs) in a
Windows Cluster. S2D is new in Windows Server 2016.
The following diagram shows the complete solution on Azure virtual machines:
The preceding diagram shows:

Two Azure virtual machines in a Windows Failover Cluster. When a virtual machine is in a failover cluster it is
also called a cluster node, or nodes.
Each virtual machine has two or more data disks.
S2D synchronizes the data on the data disk and presents the synchronized storage as a storage pool.
The storage pool presents a cluster shared volume (CSV) to the failover cluster.
The SQL Server FCI cluster role uses the CSV for the data drives.
An Azure load balancer to hold the IP address for the SQL Server FCI.
An Azure availability set holds all the resources.
NOTE
All Azure resources are in the diagram are in the same resource group.
For details about S2D, see Windows Server 2016 Datacenter edition Storage Spaces Direct (S2D).
S2D supports two types of architectures - converged and hyper-converged. The architecture in this document is
hyper-converged. A hyper-converged infrastructure places the storage on the same servers that host the clustered
application. In this architecture, the storage is on each SQL Server FCI node.
Example Azure template
You can create the entire solution in Azure from a template. An example of a template is available in the GitHub
Azure Quickstart Templates. This example is not designed or tested for any specific workload. You can run the
template to create a SQL Server FCI with S2D storage connected to your domain. You can evaluate the template,
and modify it for your purposes.
Before you begin

There are a few things you need to know and a couple of things that you need in place before you proceed.
What to know
You should have an operational understanding of the following technologies:
Windows cluster technologies
SQL Server Failover Cluster Instances.
Also, you should have a general understanding of the following technologies:
Hyper-converged solution using Storage Spaces Direct in Windows Server 2016
Azure resource groups
What to have
Before following the instructions in this article, you should already have:
A Microsoft Azure subscription.
A Windows domain on Azure virtual machines.
An account with permission to create objects in the Azure virtual machine.
An Azure virtual network and subnet with sufficient IP address space for the following components:
Both virtual machines.
The failover cluster IP address.
An IP address for each FCI.
DNS configured on the Azure Network, pointing to the domain controllers.
With these prerequisites in place, you can proceed with building your failover cluster. The first step is to create the
virtual machines.
Step 1: Create virtual machines

1. Log in to the Azure portal with your subscription.
2. Create an Azure availability set.
The availability set groups virtual machines across fault domains and update domains. The availability set
makes sure that your application is not affected by single points of failure, like the network switch or the
power unit of a rack of servers.
If you have not created the resource group for your virtual machines, do it when you create an Azure
availability set. If you're using the Azure portal to create the availability set, do the following steps:
In the Azure portal, click + to open the Azure Marketplace. Search for Availability set.
Click Availability set.
Click Create.
On the Create availability set blade, set the following values:
Name: A name for the availability set.
Subscription: Your Azure subscription.
Resource group: If you want to use an existing group, click Use existing and select the group
from the drop-down list. Otherwise choose Create New and type a name for the group.
Location: Set the location where you plan to create your virtual machines.
Fault domains: Use the default (3).
Update domains: Use the default (5).
Click Create to create the availability set.
3. Create the virtual machines in the availability set.
Provision two SQL Server virtual machines in the Azure availability set. For instructions, see Provision a SQL
Server virtual machine in the Azure portal.
Place both virtual machines:
In the same Azure resource group that your availability set is in.
On the same network as your domain controller.
On a subnet with sufficient IP address space for both virtual machines, and all FCIs that you may
eventually use on this cluster.
In the Azure availability set.
IMPORTANT
You cannot set or change availability set after a virtual machine has been created.
Choose an image from the Azure Marketplace. You can use a Marketplace image with that includes
Windows Server and SQL Server, or just the Windows Server. For details, see Overview of SQL Server on
The official SQL Server images in the Azure Gallery include an installed SQL Server instance, plus the SQL
Server installation software, and the required key.
Choose the right image according to how you want to pay for the SQL Server license:
Pay per usage licensing: The per-minute cost of these images includes the SQL Server licensing:
SQL Server 2016 Enterprise on Windows Server Datacenter 2016
SQL Server 2016 Standard on Windows Server Datacenter 2016
SQL Server 2016 Developer on Windows Server Datacenter 2016
Bring-your-own-license (BYOL)
{BYOL} SQL Server 2016 Enterprise on Windows Server Datacenter 2016
{BYOL} SQL Server 2016 Standard on Windows Server Datacenter 2016
IMPORTANT
After you create the virtual machine, remove the pre-installed standalone SQL Server instance. You will use the pre-
installed SQL Server media to create the SQL Server FCI after you configure the failover cluster and S2D.
Alternatively, you can use Azure Marketplace images with just the operating system. Choose a Windows
Server 2016 Datacenter image and install the SQL Server FCI after you configure the failover cluster and
S2D. This image does not contain SQL Server installation media. Place the installation media in a location
where you can run the SQL Server installation for each server.
4. After Azure creates your virtual machines, connect to each virtual machine with RDP.
When you first connect to a virtual machine with RDP, the computer asks if you want to allow this PC to be
discoverable on the network. Click Yes.
5. If you are using one of the SQL Server-based virtual machine images, remove the SQL Server instance.
In Programs and Features, right-click Microsoft SQL Server 2016 (64-bit) and click
Uninstall/Change.
Click Remove.
Select the default instance.
Remove all features under Database Engine Services. Do not remove Shared Features. See the
following picture:
Click Next, and then click Remove.

6. Open the firewall ports.
On each virtual machine, open the following ports on the Windows Firewall.
PURPOSE TCP PORT NOTES
SQL Server 1433 Normal port for default instances of

SQL Server. If you used an image
from the gallery, this port is
automatically opened.
Health probe 59999 Any open TCP port. In a later step,

configure the load balancer health
probe and the cluster to use this
port.
7. Add storage to the virtual machine. For detailed information, see add storage.
Both virtual machines need at least two data disks.
Attach raw disks - not NTFS formatted disks.
NOTE
If you attach NTFS-formatted disks, you can only enable S2D with no disk eligibility check.
Attach a minimum of two Premium Storage (SSD disks) to each VM. We recommend at least P30 (1 TB)
disks.
Set host caching to Read-only.
The storage capacity you use in production environments depends on your workload. The values described
in this article are for demonstration and testing.
8. Add the virtual machines to your pre-existing domain.
After the virtual machines are created and configured, you can configure the failover cluster.
Step 2: Configure the Windows Failover Cluster with S2D

The next step is to configure the failover cluster with S2D. In this step, you will do the following substeps:
1. Add Windows Failover Clustering feature
2. Validate the cluster
3. Create the failover cluster
4. Create the cloud witness
5. Add storage
Add Windows Failover Clustering feature
1. To begin, connect to the first virtual machine with RDP using a domain account that is a member of local
administrators, and has permissions to create objects in Active Directory. Use this account for the rest of the
configuration.
2. Add Failover Clustering feature to each virtual machine.
To install Failover Clustering feature from the UI, do the following steps on both virtual machines.
In Server Manager, click Manage, and then click Add Roles and Features.
In Add Roles and Features Wizard, click Next until you get to Select Features.
In Select Features, click Failover Clustering. Include all required features and the management tools.
Click Add Features.
Click Next and then click Finish to install the features.
To install the Failover Clustering feature with PowerShell, run the following script from an administrator
PowerShell session on one of the virtual machines.
$nodes = ("<node1>","<node2>")
Invoke-Command $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -
IncludeManagementTools}
For reference, the next steps follow the instructions under Step 3 of Hyper-converged solution using Storage
Spaces Direct in Windows Server 2016.
Validate the cluster
This guide refers to instructions under validate cluster.
Validate the cluster in the UI or with PowerShell.
To validate the cluster with the UI, do the following steps from one of the virtual machines.
1. In Server Manager, click Tools, then click Failover Cluster Manager.
2. In Failover Cluster Manager, click Action, then click Validate Configuration....
3. Click Next.
4. On Select Servers or a Cluster, type the name of both virtual machines.
5. On Testing options, choose Run only tests I select. Click Next.
6. On Test selection, include all tests except Storage. See the following picture:
7. Click Next.
8. On Confirmation, click Next.
The Validate a Configuration Wizard runs the validation tests.
To validate the cluster with PowerShell, run the following script from an administrator PowerShell session on one
of the virtual machines.
Test-Cluster Node ("<node1>","<node2>") Include "Storage Spaces Direct", "Inventory", "Network", "System
Configuration"
After you validate the cluster, create the failover cluster.

Create the failover cluster
This guide refers to Create the failover cluster.
To create the failover cluster, you need:
The names of the virtual machines that become the cluster nodes.
A name for the failover cluster
An IP address for the failover cluster. You can use an IP address that is not used on the same Azure virtual
network and subnet as the cluster nodes.
The following PowerShell creates a failover cluster. Update the script with the names of the nodes (the virtual
machine names) and an available IP address from the Azure VNET:
New-Cluster -Name <FailoverCluster-Name> -Node ("<node1>","<node2>") StaticAddress <n.n.n.n> -NoStorage
Create a cloud witness

Cloud Witness is a new type of cluster quorum witness stored in an Azure Storage Blob. This removes the need of a
separate VM hosting a witness share.
1. Create a cloud witness for the failover cluster.
2. Create a blob container.
3. Save the access keys and the container URL.
4. Configure the failover cluster cluster quorum witness. See, [Configure the quorum witness in the user
interface].(http://technet.microsoft.com/windows-server-docs/failover-clustering/deploy-cloud-witness#to-
configure-cloud-witness-as-a-quorum-witness) in the UI.
Add storage
The disks for S2D need to be empty and without partitions or other data. To clean disks follow the steps in this
guide.
1. Enable Store Spaces Direct (S2D).
The following PowerShell enables storage spaces direct.
Enable-ClusterS2D
In Failover Cluster Manager, you can now see the storage pool.
2. Create a volume.
One of the features of S2D is that it automatically creates a storage pool when you enable it. You are now
ready to create a volume. The PowerShell commandlet New-Volume automates the volume creation process,
including formatting, adding to the cluster, and creating a cluster shared volume (CSV). The following
example creates an 800 gigabyte (GB) CSV.
New-Volume -StoragePoolFriendlyName S2D* -FriendlyName VDisk01 -FileSystem CSVFS_REFS -Size 800GB
After this command completes, an 800 GB volume is mounted as a cluster resource. The volume is at
C:\ClusterStorage\Volume1\ .
The following diagram shows a cluster shared volume with S2D:

Step 3: Test failover cluster failover
In Failover Cluster Manager, verify that you can move the storage resource to the other cluster node. If you can
connect to the failover cluster with Failover Cluster Manager and move the storage from one node to the other,
you are ready to configure the FCI.
Step 4: Create SQL Server FCI

After you have configured the failover cluster and all cluster components including storage, you can create the SQL
Server FCI.
1. Connect to the first virtual machine with RDP.
2. In Failover Cluster Manager, make sure all cluster core resources are on the first virtual machine. If
necessary, move all resources to this virtual machine.
3. Locate the installation media. If the virtual machine uses one of the Azure Marketplace images, the media is
located at C:\SQLServer_<version number>_Full . Click Setup.
4. In the SQL Server Installation Center, click Installation.
5. Click New SQL Server failover cluster installation. Follow the instructions in the wizard to install the SQL
Server FCI.
The FCI data directories need to be on clustered storage. With S2D, it's not a shared disk, but a mount point
to a volume on each server. S2D synchronizes the volume between both nodes. The volume is presented to
the cluster as a cluster shared volume. Use the CSV mount point for the data directories.
6. After you complete the wizard, Setup will install a SQL Server FCI on the first node.
7. After Setup successfully installs the FCI on the first node, connect to the second node with RDP.
8. Open the SQL Server Installation Center. Click Installation.
9. Click Add node to a SQL Server failover cluster. Follow the instructions in the wizard to install SQL server
and add this server to the FCI.
NOTE
If you used an Azure Marketplace gallery image with SQL Server, SQL Server tools were included with the image. If
you did not use this image, install the SQL Server tools separately. See Download SQL Server Management Studio
(SSMS).
Step 5: Create Azure load balancer

On Azure virtual machines, clusters use a load balancer to hold an IP address that needs to be on one cluster node
at a time. In this solution, the load balancer holds the IP address for the SQL Server FCI.
Create and configure an Azure load balancer.
Create the load balancer in the Azure portal
To create the load balancer:
1. In the Azure portal, go to the Resource Group with the virtual machines.
2. Click + Add. Search the Marketplace for Load Balancer. Click Load Balancer.
3. Click Create.
4. Configure the load balancer with:
Name: A name that identifies the load balancer.
Type: The load balancer can be either public or private. A private load balancer can be accessed from
within the same VNET. Most Azure applications can use a private load balancer. If your application needs
access to SQL Server directly over the Internet, use a public load balancer.
Virtual Network: The same network as the virtual machines.
Subnet: The same subnet as the virtual machines.
Private IP address: The same IP address that you assigned to the SQL Server FCI cluster network
resource.
subscription: Your Azure subscription.
Resource Group: Use the same resource group as your virtual machines.
Location: Use the same Azure location as your virtual machines. See the following picture:
Configure the load balancer backend pool

1. Return to the Azure Resource Group with the virtual machines and locate the new load balancer. You may
have to refresh the view on the Resource Group. Click the load balancer.
2. On the load balancer blade, click Backend pools.
3. Click + Add to add a backend pool.
4. Type a name for the backend pool.
5. Click Add a virtual machine.
6. On the Choose virtual machines blade, click Choose an availability set.
7. Choose the availability set that you placed the SQL Server virtual machines in.
8. On the Choose virtual machines blade, click Choose the virtual machines.
Your Azure portal should look like the following picture:
9. Click Select on the Choose virtual machines blade.

10. Click OK twice.
Configure a load balancer health probe
1. On the load balancer blade, click Health probes.
2. Click + Add.
3. On the Add health probe blade, Set the health probe parameters:
Name: A name for the health probe.
Protocol: TCP.
Port: Set to an available TCP port. This port requires an open firewall port. Use the same port you set for
the health probe at the firewall.
Interval: 5 Seconds.
Unhealthy threshold: 2 consecutive failures.
4. Click OK.
Set load balancing rules
1. On the load balancer blade, click Load balancing rules.
2. Click + Add.
3. Set the load balancing rules parameters:
Name: A name for the load balancing rules.
Frontend IP address: Use the IP address for the SQL Server FCI cluster network resource.
Port: Set for the SQL Server FCI TCP port. The default instance port is 1433.
Backend port: This value uses the same port as the Port value when you enable Floating IP (direct
server return).
Backend pool: Use the backend pool name that you configured earlier.
Health probe: Use the health probe that you configured earlier.
Session persistence: None.
Idle timeout (minutes): 4.
Floating IP (direct server return): Enabled
4. Click OK.
Step 6: Configure cluster for probe

Set the cluster probe port parameter in PowerShell.
To set the cluster probe port parameter, update variables in the following script from your environment.
$ClusterNetworkName = "<Cluster Network Name>" # the cluster network name (Use Get-ClusterNetwork on Windows
Server 2012 of higher to find the name).
$IPResourceName = "IP Address Resource Name" # the IP Address cluster resource name.
$ILBIP = "<10.0.0.x>" # the IP Address of the Internal Load Balancer (ILB). This is the static IP address for
the load balancer you configured in the Azure portal.
[int]$ProbePort = <59999>

@{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"En
ableDhcp"=0}
Step 7: Test FCI failover

Test failover of the FCI to validate cluster functionality. Do the following steps:
1. Connect to one of the SQL Server FCI cluster nodes with RDP.
2. Open Failover Cluster Manager. Click Roles. Notice which node owns the SQL Server FCI role.
3. Right-click the SQL Server FCI role.
4. Click Move and click Best Possible Node.
Failover Cluster Manager shows the role and its resources go offline. The resources then move and come online
on the other node.
Test connectivity
To test connectivity, log in to another virtual machine in the same virtual network. Open SQL Server Management
Studio and connect to the SQL Server FCI name.
NOTE
If necessary, you can download SQL Server Management Studio.
Limitations
On Azure virtual machines, Microsoft Distributed Transaction Coordinator (DTC) is not supported on FCIs because
the RPC port is not supported by the load balancer.
See Also
Setup S2D with remote desktop (Azure)
Hyper-converged solution with storage spaces direct.
Storage Space Direct Overview
SQL Server support for S2D
Automate management tasks on Azure Virtual
Machines with the SQL Server Agent Extension
(Resource Manager)
The SQL Server IaaS Agent Extension (SQLIaaSExtension) runs on Azure virtual machines to automate
administration tasks. This topic provides an overview of the services supported by the extension as well as
instructions for installation, status, and removal.
NOTE
To view the classic version of this article, see SQL Server Agent Extension for SQL Server VMs Classic.
Supported services
The SQL Server IaaS Agent Extension supports the following administration tasks:
ADMINISTRATION FEATURE DESCRIPTION
SQL Automated Backup Automates the scheduling of backups for all databases for the
default instance of SQL Server in the VM. For more
information, see Automated backup for SQL Server in Azure
Virtual Machines (Resource Manager).
SQL Automated Patching Configures a maintenance window during which updates to

your VM can take place, so you can avoid updates during
peak times for your workload. For more information, see
Automated patching for SQL Server in Azure Virtual Machines
(Resource Manager).
Azure Key Vault Integration Enables you to automatically install and configure Azure Key
Vault on your SQL Server VM. For more information, see
Configure Azure Key Vault Integration for SQL Server on
Azure VMs (Resource Manager).
Once installed and running, the SQL Server IaaS Agent Extension makes these administration features available
on the SQL Server panel of the virtual machine in the Azure Portal and through Azure PowerShell for SQL Server
marketplace images, and through Azure PowerShell for manual installations of the extension.
Prerequisites
Requirements to use the SQL Server IaaS Agent Extension on your VM:
Operating System:
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
SQL Server versions:
SQL Server 2012
SQL Server 2014
SQL Server 2016
Azure PowerShell:
Download and configure the latest Azure PowerShell commands
Installation
The SQL Server IaaS Agent Extension is automatically installed when you provision one of the SQL Server virtual
machine gallery images.
It is also possible to install the SQL Server IaaS Agent Extension on an OS-only Windows Server virtual machine.
This is only supported if you have also manually installed SQL Server on that machine. Then install the extension
manually by using the Set-AzureVMSqlServerExtension PowerShell cmdlet. For example, the following
command installs the extension on an OS-only Windows Server VM and names it "SQLIaaSExtension".
Set-AzureRmVMSqlServerExtension -ResourceGroupName "resourcegroupname" -VMName "vmname" -Name

"SQLIaasExtension" -Version "1.2" -Location "East US 2"
NOTE
If you manually install the SQL Server IaaS Agent Extension, you can not manage the SQL Server configuration settings
through the Azure portal. In this scenario, you must make all changes with PowerShell.
If you update to the latest version of the SQL IaaS Agent Extension, you must restart your virtual machine after
updating the extension.
Status
One way to verify that the extension is installed is to view the agent status in the Azure Portal. Select All settings
in the virtual machine blade, and then click on Extensions. You should see the SQLIaaSExtension extension
listed.
You can also use the Get-AzureVMSqlServerExtension Azure Powershell cmdlet.
Get-AzureRmVMSqlServerExtension -VMName "vmname" -ResourceGroupName "resourcegroupname"
The previous command confirms the agent is installed and provides general status information. You can also get
specific status information about Automated Backup and Patching with the following commands.
$sqlext = Get-AzureRmVMSqlServerExtension -VMName "vmname" -ResourceGroupName "resourcegroupname"

$sqlext.AutoPatchingSettings
$sqlext.AutoBackupSettings
Removal
In the Azure Portal, you can uninstall the extension by clicking the ellipsis on the Extensions blade of your virtual
machine properties. Then click Delete.
You can also use the Remove-AzureRmVMSqlServerExtension Powershell cmdlet.
Remove-AzureRmVMSqlServerExtension -ResourceGroupName "resourcegroupname" -VMName "vmname" -Name

"SQLIaasExtension"
Next Steps
Begin using one of the services supported by the extension. For more details, see the topics referenced in the
Supported services section of this article.
For more information about running SQL Server on Azure Virtual Machines, see SQL Server on Azure Virtual
Machines overview.
Automated Patching for SQL Server in Azure Virtual
Machines (Resource Manager)
Automated Patching establishes a maintenance window for an Azure Virtual Machine running SQL Server.
Automated Updates can only be installed during this maintenance window. For SQL Server, this rescriction
ensures that system updates and any associated restarts occur at the best possible time for the database.
Automated Patching depends on the SQL Server IaaS Agent Extension.
NOTE
article covers using the Resource Manager deployment model, which Microsoft recommends for new deployments instead of
the classic deployment model.
To view the classic version of this article, see Automated Patching for SQL Server in Azure Virtual Machines Classic.
Prerequisites
To use Automated Patching, consider the following prerequisites:
Operating System:
Windows Server 2012
Windows Server 2016
SQL Server version:
SQL Server 2012
SQL Server 2014
SQL Server 2016
Azure PowerShell:
Install the latest Azure PowerShell commands if you plan to configure Automated Patching with PowerShell.
NOTE
Automated Patching relies on the SQL Server IaaS Agent Extension. Current SQL virtual machine gallery images add this
extension by default. For more information, see SQL Server IaaS Agent Extension.
Settings
The following table describes the options that can be configured for Automated Patching. The actual configuration
steps vary depending on whether you use the Azure portal or Azure Windows PowerShell commands.
SETTING POSSIBLE VALUES DESCRIPTION
Automated Patching Enable/Disable (Disabled) Enables or disables Automated

Patching for an Azure virtual machine.
Maintenance schedule Everyday, Monday, Tuesday, The schedule for downloading and
Wednesday, Thursday, Friday, Saturday, installing Windows, SQL Server, and
Sunday Microsoft updates for your virtual
machine.
Maintenance start hour 0-24 The local start time to update the
virtual machine.
Maintenance window duration 30-180 The number of minutes permitted to

complete the download and installation
of updates.
Patch Category Important The category of updates to download

and install.
Configuration in the Portal

You can use the Azure portal to configure Automated Patching during provisioning or for existing VMs.
New VMs
Use the Azure portal to configure Automated Patching when you create a new SQL Server Virtual Machine in the
Resource Manager deployment model.
In the SQL Server settings blade, select Automated patching. The following Azure portal screenshot shows the
SQL Automated Patching blade.
For context, see the complete topic on provisioning a SQL Server virtual machine in Azure.
Existing VMs
For existing SQL Server virtual machines, select your SQL Server virtual machine. Then select the SQL Server
configuration section of the Settings blade.
In the SQL Server configuration blade, click the Edit button in the Automated patching section.
When finished, click the OK button on the bottom of the SQL Server configuration blade to save your changes.
If you are enabling Automated Patching for the first time, Azure configures the SQL Server IaaS Agent in the
background. During this time, the Azure portal might not show that Automated Patching is configured. Wait
several minutes for the agent to be installed, configured. After that the Azure portal reflects the new settings.
NOTE
You can also configure Automated Patching using a template. For more information, see Azure quickstart template for
Automated Patching.
Configuration with PowerShell

After provisioning your SQL VM, use PowerShell to configure Automated Patching.
In the following example, PowerShell is used to configure Automated Patching on an existing SQL Server VM. The
AzureRM.Compute\New-AzureVMSqlServerAutoPatchingConfig command configures a new maintenance
window for automatic updates.
$vmname = "vmname"
$resourcegroupname = "resourcegroupname"
$aps = AzureRM.Compute\New-AzureVMSqlServerAutoPatchingConfig -Enable -DayOfWeek "Thursday" -
MaintenanceWindowStartingHour 11 -MaintenanceWindowDuration 120 -PatchCategory "Important"
Set-AzureRmVMSqlServerExtension -AutoPatchingSettings $aps -VMName $vmname -ResourceGroupName

$resourcegroupname
Based on this example, the following table describes the practical effect on the target Azure VM:
PARAMETER EFFECT
DayOfWeek Patches installed every Thursday.
MaintenanceWindowStartingHour Begin updates at 11:00am.
MaintenanceWindowsDuration Patches must be installed within 120 minutes. Based on the

start time, they must complete by 1:00pm.
PatchCategory The only possible setting for this parameter is Important.
It could take several minutes to install and configure the SQL Server IaaS Agent.
To disable Automated Patching, run the same script without the -Enable parameter to the
AzureRM.Compute\New-AzureVMSqlServerAutoPatchingConfig. The absence of the -Enable parameter
signals the command to disable the feature.
Next steps
For information about other available automation tasks, see SQL Server IaaS Agent Extension.
For more information about running SQL Server on Azure VMs, see SQL Server on Azure Virtual Machines
overview.
Configure Azure Key Vault Integration for SQL
Server on Azure Virtual Machines (Resource
Manager)
Overview
There are multiple SQL Server encryption features, such as transparent data encryption (TDE), column level
encryption (CLE), and backup encryption. These forms of encryption require you to manage and store the
cryptographic keys you use for encryption. The Azure Key Vault (AKV) service is designed to improve the security
and management of these keys in a secure and highly available location. The SQL Server Connector enables SQL
Server to use these keys from Azure Key Vault.
If you running SQL Server with on-premises machines, there are steps you can follow to access Azure Key Vault
from your on-premises SQL Server machine. But for SQL Server in Azure VMs, you can save time by using the
Azure Key Vault Integration feature.
When this feature is enabled, it automatically installs the SQL Server Connector, configures the EKM provider to
access Azure Key Vault, and creates the credential to allow you to access your vault. If you looked at the steps in
the previously mentioned on-premises documentation, you can see that this feature automates steps 2 and 3. The
only thing you would still need to do manually is to create the key vault and keys. From there, the entire setup of
your SQL VM is automated. Once this feature has completed this setup, you can execute T-SQL statements to
begin encrypting your databases or backups as you normally would.
Prepare for AKV Integration

To use Azure Key Vault Integration to configure your SQL Server VM, there are several prerequisites:
1. Install Azure Powershell
2. Create an Azure Active Directory
3. Create a key vault
The following sections describe these prerequisites and the information you need to collect to later run the
PowerShell cmdlets.
Install Azure PowerShell
Make sure you have installed the latest Azure PowerShell SDK. For more information, see How to install and
configure Azure PowerShell.
Create an Azure Active Directory
First, you need to have an Azure Active Directory (AAD) in your subscription. Among many benefits, this allows you
to grant permission to your key vault for certain users and applications.
Next, register an application with AAD. This will give you a Service Principal account that has access to your key
vault which your VM will need. In the Azure Key Vault article, you can find these steps in the Register an application
with Azure Active Directory section, or you can see the steps with screen shots in the Get an identity for the
application section of this blog post. Before completing these steps, note that you need to collect the following
information during this registration that is needed later when you enable Azure Key Vault Integration on your SQL
VM.
After the application is added, find the CLIENT ID on the CONFIGURE tab.
The client ID is assigned later to the $spName (Service Principal name) parameter in the PowerShell script
to enable Azure Key Vault Integration.
Also, during these steps when you create your key, copy the secret for your key as is shown in the following
screenshot. This key secret is assigned later to the $spSecret (Service Principal secret) parameter in the
PowerShell script.
You must authorize this new client ID to have the following access permissions: encrypt, decrypt, wrapKey,
unwrapKey, sign, and verify. This is done with the Set-AzureRmKeyVaultAccessPolicy cmdlet. For more
information see Authorize the application to use the key or secret.
Create a key vault
In order to use Azure Key Vault to store the keys you will use for encryption in your VM, you need access to a key
vault. If you have not already set up your key vault, create one by following the steps in the Getting Started with
Azure Key Vault topic. Before completing these steps, note that there is some information you need to collect
during this set up that is needed later when you enable Azure Key Vault Integration on your SQL VM.
When you get to the Create a key vault step, note the returned vaultUri property, which is the key vault URL. In
the example provided in that step, shown below, the key vault name is ContosoKeyVault, therefore the key vault
URL would be https://contosokeyvault.vault.azure.net/.
New-AzureRmKeyVault -VaultName 'ContosoKeyVault' -ResourceGroupName 'ContosoResourceGroup' -Location 'East

Asia'
The key vault URL is assigned later to the $akvURL parameter in the PowerShell script to enable Azure Key Vault
Integration.
Enabling and configuring AKV integration

You can enable AKV integration during provisioning or configure it for existing VMs.
New VMs
If you are provisioning a new SQL Server virtual machine with Resource Manager, the Azure portal provides a step
to enable Azure Key Vault integration. The Azure Key Vault feature is available only for the Enterprise, Developer
and Evaluation Editions of SQL Server.
For a detailed walkthrough of provisioning, see Provision a SQL Server virtual machine in the Azure Portal.
Existing VMs
In the SQL Server configuration blade, click the Edit button in the Automated Key Vault integration section.
NOTE
You can also configure AKV integration using a template. For more information, see Azure quickstart template for Azure Key
Vault integration.
Next steps
After enabling Azure Key Vault Integration, you can enable SQL Server encryption on your SQL VM. First, you will
need to create an asymmetric key inside your key vault and a symmetric key within SQL Server on your VM. Then,
you will be able to execute T-SQL statements to enable encryption for your databases and backups.
There are several forms of encryption you can take advantage of:
Transparent Data Encryption (TDE)
Encrypted backups
Column Level Encryption (CLE)
The following Transact-SQL scripts provide examples for each of these areas.
Prerequisites for examples
Each example is based on the two prerequisites: an asymmetric key from your key vault called CONTOSO_KEY
and a credential created by the AKV Integration feature called Azure_EKM_TDE_cred. The following Transact-SQL
commands setup these prerequisites for running the examples.
USE master;
GO
sp_configure [show advanced options], 1;

GO
RECONFIGURE;
GO
-- Enable EKM provider

sp_configure [EKM provider enabled], 1;
GO
RECONFIGURE;
--create provider
CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov
FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key
Vault\Microsoft.AzureKeyVaultService.EKM.dll';
GO
--create credential
CREATE CREDENTIAL sysadmin_ekm_cred
WITH IDENTITY = 'keytestvault', --keyvault
SECRET = '<<SECRET>>'
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;
--must have sysadmin

ALTER LOGIN [TDE_Login]
ADD CREDENTIAL sysadmin_ekm_cred;
CREATE ASYMMETRIC KEY CONTOSO_KEY

FROM PROVIDER [AzureKeyVault_EKM_Prov]
WITH PROVIDER_KEY_NAME = 'keytestvault', --key name
CREATION_DISPOSITION = OPEN_EXISTING;
Transparent Data Encryption (TDE)

1. Create a SQL Server login to be used by the Database Engine for TDE, then add the credential to it.
USE master;
-- Create a SQL Server login associated with the asymmetric key
-- for the Database engine to use when it loads a database
-- encrypted by TDE.
CREATE LOGIN TDE_Login
FROM ASYMMETRIC KEY CONTOSO_KEY;
GO
-- Alter the TDE Login to add the credential for use by the
-- Database Engine to access the key vault
ALTER LOGIN TDE_Login
ADD CREDENTIAL Azure_EKM_TDE_cred;
GO
2. Create the database encryption key that will be used for TDE.
USE ContosoDatabase;
GO
CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;
GO
-- Alter the database to enable transparent data encryption.

ALTER DATABASE ContosoDatabase
SET ENCRYPTION ON;
GO
Encrypted backups
1. Create a SQL Server login to be used by the Database Engine for encrypting backups, and add the credential
to it.
USE master;
-- Create a SQL Server login associated with the asymmetric key
-- for the Database engine to use when it is encrypting the backup.
CREATE LOGIN Backup_Login
FROM ASYMMETRIC KEY CONTOSO_KEY;
GO
-- Alter the Encrypted Backup Login to add the credential for use by
-- the Database Engine to access the key vault
ALTER LOGIN Backup_Login
ADD CREDENTIAL Azure_EKM_Backup_cred ;
GO
2. Backup the database specifying encryption with the asymmetric key stored in the key vault.
USE master;
BACKUP DATABASE [DATABASE_TO_BACKUP]
TO DISK = N'[PATH TO BACKUP FILE]'
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD,
ENCRYPTION(ALGORITHM = AES_256, SERVER ASYMMETRIC KEY = [CONTOSO_KEY]);
GO
Column Level Encryption (CLE)

This script creates a symmetric key protected by the asymmetric key in the key vault, and then uses the symmetric
key to encrypt data in the database.
CREATE SYMMETRIC KEY DATA_ENCRYPTION_KEY
WITH ALGORITHM=AES_256
ENCRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;
DECLARE @DATA VARBINARY(MAX);
--Open the symmetric key for use in this session

OPEN SYMMETRIC KEY DATA_ENCRYPTION_KEY
DECRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;
--Encrypt syntax
SELECT @DATA = ENCRYPTBYKEY(KEY_GUID('DATA_ENCRYPTION_KEY'), CONVERT(VARBINARY,'Plain text data to encrypt'));
-- Decrypt syntax
SELECT CONVERT(VARCHAR, DECRYPTBYKEY(@DATA));
--Close the symmetric key

CLOSE SYMMETRIC KEY DATA_ENCRYPTION_KEY;
Additional resources
For more information on how to use these encryption features, see Using EKM with SQL Server Encryption
Features.
Note that the steps in this article assume that you already have SQL Server running on an Azure virtual machine. If
not, see Provision a SQL Server virtual machine in Azure. For other guidance on running SQL Server on Azure
VMs, see SQL Server on Azure Virtual Machines overview.
Security Considerations for SQL Server in Azure
Virtual Machines
This topic includes overall security guidelines that help establish secure access to SQL Server instances in an Azure
virtual machine (VM).
Azure complies with several industry regulations and standards that can enable you to build a compliant solution
with SQL Server running in a virtual machine. For information about regulatory compliance with Azure, see Azure
Trust Center.
NOTE
Control access to the SQL VM

When you create your SQL Server virtual machine, consider how to carefully control who has access to the
machine and to SQL Server. In general, you should do the following:
Restrict access to SQL Server to only the applications and clients that need it.
Follow best practices for managing user accounts and passwords.
The following sections provide suggestions on thinking through these points.
Secure connections
When you create a SQL Server virtual machine with a gallery image, the SQL Server Connectivity option gives
you the choice of Local (inside VM), Private (within Virtual Network), or Public (Internet).
For the best security, choose the most restrictive option for your scenario. For example, if you are running an
application that accesses SQL Server on the same VM, then Local is the most secure choice. If you are running an
Azure application that requires access to the SQL Server, then Private secures communication to SQL Server only
within the specified Azure Virtual Network. If you require Public (internest) access to the SQL Server VM, then
make sure to follow other best practices in this topic to reduce your attack surface area.
The selected options in the portal use inbound security rules on the VMs Network Security Group (NSG) to allow or
deny network traffic to your virtual machine. You can modify or create new inbound NSG rules to allow traffic to
the SQL Server port (default 1433). You can also specify specific IP addresses that are allowed to communicate over
this port.
In addition to NSG rules to restrict network traffic, you can also use the Windows Firewall on the virtual machine.
If you are using endpoints with the classic deployment model, remove any endpoints on the virtual machine if you
do not use them. For instructions on using ACLs with endpoints, see Manage the ACL on an endpoint. This is not
necessary for VMs that use the Resource Manager.
Finally, consider enabling encrypted connections for the instance of the SQL Server Database Engine in your Azure
virtual machine. Configure SQL server instance with a signed certificate. For more information, see Enable
Encrypted Connections to the Database Engine and Connection String Syntax.
Use a non-default port

By default, SQL Server listens on a well-known port, 1433. For increased security, configure SQL Server to listen on
a non-default port, such as 1401. If you provision a SQL Server gallery image in the Azure portal, you can specify
this port in the SQL Server settings blade.
To configure this after provisioning, you have two options:
For Resource Manager VMs, you can select SQL Server configuration from the VM overview blade. This
provides an option to change the port.
For Classic VMs or for SQL Server VMs that were not provisioned with the portal, you can manually
configure the port by connecting remotely to the VM. For the configuration steps, see Configure a Server to
Listen on a Specific TCP Port. If you use this manual technique, you also need to add a Windows Firewall rule
to allow incoming traffic on that TCP port.
IMPORTANT
Specifying a non-default port is a good idea if your SQL Server port is open to public internet connections.
When SQL Server is listening on a non-default port, you must specify the port when you connect. For example,
consider a scenario where the server IP address is 13.55.255.255 and SQL Server is listening on port 1401. To
connect to SQL Server, you would specify 13.55.255.255,1401 in the connection string.
Manage accounts
You don't want attackers to easily guess account names or passwords. Use the following tips to help:
Create a unique local administrator account that is not named Administrator.
Use complex strong passwords for all your accounts. For more information about how to create a strong
password, see Create a strong password article.
By default, Azure selects Windows Authentication during SQL Server Virtual Machine setup. Therefore, the
SA login is disabled and a password is assigned by setup. We recommend that the SA login should not be
used or enabled. If you must have a SQL login, use one of the following strategies:
Create a SQL account with a unique name that has sysadmin membership. You can do this from the
portal by enabling SQL Authentication during provisioning.
TIP
If you do not enable SQL Authentication during provisioning, you must manually change the authentication
mode to SQL Server and Windows Authentication Mode. For more information, see Change Server
Authentication Mode.
If you must use the SA login, enable the login after provisioning and assign a new strong password.
Follow on-premises best practices
In addition to the practices described in this topic, we recommend that you review and implement the traditional
on-premises security practices where applicable. For more information, see Security Considerations for a SQL
Server Installation
Next Steps
If you are also interested in best practices around performance, see Performance Best Practices for SQL Server in
Azure Virtual Machines.
For other topics related to running SQL Server in Azure VMs, see SQL Server on Azure Virtual Machines overview.
Backup and Restore for SQL Server in Azure Virtual
Machines
Overview
Azure Storage maintains 3 copies of every Azure VM disk to guarantee protection against data loss or physical
data corruption. Thus, unlike on-premises, you don't need to worry about these. However, you should still backup
your SQL Server databases to protect against application or user errors (e.g inserting wrong data or deleting a
table) and being able to restore to a point in time.
NOTE
For SQL Server running in Azure VMs, you can use native backup and restore techniques using attached disks for
the destination of the backup files. However, there is a limit to the number of disks you can attach to an Azure
virtual machine, based on the size of the virtual machine. There is also the overhead of disk management to
consider.
Beginning with SQL Server 2014, you can back up and restore to Microsoft Azure Blob storage. SQL Server 2016
also provides enhancements for this option. In addition, for database files stored in Microsoft Azure Blob storage,
SQL Server 2016 provides an option for nearly instantaneous backups and for rapid restores using Azure
snapshots. This article provides an overview of these options, and additional information can be found at SQL
Server Backup and Restore with Microsoft Azure Blob Storage Service.
NOTE
For a discussion of the options for backing up very large databases, see Multi-Terabyte SQL Server Database Backup
Strategies for Azure Virtual Machines.
The sections below include information specific to the different versions of SQL Server supported in an Azure
virtual machine.
SQL Server Virtual Machines

When your SQL Server instance is running on an Azure Virtual Machine, your database files already reside on data
disks in Azure. These disks live in Azure Blob storage. So the reasons for backing up your database and the
approaches you take change slightly. Consider the following.
You no longer need to perform database backups to provide protection against hardware or media failure
because Microsoft Azure provides this protection as part of the Microsoft Azure service.
You still need to perform database backups to provide protection against user errors, or for archival purposes,
regulatory reasons, or administrative purposes.
You can store the backup file directly in Azure. For more information, see the following sections that provide
guidance for the different versions of SQL Server.
SQL Server 2016
Microsoft SQL Server 2016 supports backup and restore with Azure blobs features found in SQL Server 2014. But
it also includes the following enhancements:
2016 ENHANCEMENT DETAILS
Striping When backing up to Microsoft Azure blob storage, SQL Server

2016 supports backing up to multiple blobs to enable backing
up large databases, up to a maximum of 12.8 TB.
Snapshot Backup Through the use of Azure snapshots, SQL Server File-
Snapshot Backup provides nearly instantaneous backups and
rapid restores for database files stored using the Azure Blob
storage service. This capability enables you to simplify your
backup and restore policies. File-snapshot backup also
supports point in time restore. For more information, see
Snapshot Backups for Database Files in Azure.
Managed Backup Scheduling SQL Server Managed Backup to Azure now supports custom
schedules. For more information, see SQL Server Managed
Backup to Microsoft Azure.
For a tutorial of the capabilities of SQL Server 2016 when using Azure Blob storage, see Tutorial: Using the
Microsoft Azure Blob storage service with SQL Server 2016 databases.
SQL Server 2014

SQL Server 2014 includes the following enhancements:
1. Backup and Restore to Azure:
SQL Server Backup to URL now has support in SQL Server Management Studio. The option to back up to
Azure is now available when using Backup or Restore task, or maintenance plan wizard in SQL Server
Management Studio. For more information, see SQL Server Backup to URL.
SQL Server Managed Backup to Azure has new functionality that enables automated backup
management. This is especially useful for automating backup management for SQL Server 2014
instances running on an Azure Machine. For more information, see SQL Server Managed Backup to
Microsoft Azure.
Automated Backup provides additional automation to automatically enable SQL Server Managed
Backup to Azure on all existing and new databases for a SQL Server VM in Azure. For more information,
see Automated Backup for SQL Server in Azure Virtual Machines.
For an overview of all the options for SQL Server 2014 Backup to Azure, see SQL Server Backup and
Restore with Microsoft Azure Blob Storage Service.
2. Encryption: SQL Server 2014 supports encrypting data when creating a backup. It supports several encryption
algorithms and the use osf a certificate or asymmetric key. For more information, see Backup Encryption.
SQL Server 2012

For detailed information on SQL Server Backup and Restore in SQL Server 2012, see Backup and Restore of SQL
Server Databases (SQL Server 2012).
Starting in SQL Server 2012 SP1 Cumulative Update 2, you can back up to and restore from the Azure Blob
Storage service. This enhancement can be used to back up SQL Server databases on a SQL Server running on an
Azure Virtual Machine or an on-premises instance. For more information, see SQL Server Backup and Restore with
Azure Blob Storage Service.
Some of the benefits of using the Azure Blob storage service include the ability to bypass the 16 disk limit for
attached disks, ease of management, the direct availability of the backup file to another instance of SQL Server
instance running on an Azure virtual machine, or an on-premises instance for migration or disaster recovery
purposes. For a full list of benefits to using an Azure blob storage service for SQL Server backups, see the Benefits
section in SQL Server Backup and Restore with Azure Blob Storage Service.
For Best Practice recommendations and troubleshooting information, see Backup and Restore Best Practices
(Azure Blob Storage Service).
SQL Server 2008

For SQL Server Backup and Restore in SQL Server 2008 R2, see Backing up and Restoring Databases in SQL
Server (SQL Server 2008 R2).
For SQL Server Backup and Restore in SQL Server 2008, see Backing up and Restoring Databases in SQL Server
(SQL Server 2008).
Next steps
If you are planning your deployment of SQL Server in an Azure VM, you can find provisioning guidance in the
following tutorial: Provisioning a SQL Server Virtual Machine on Azure with Azure Resource Manager.
Although backup and restore can be used to migrate your data, there are potentially easier data migration paths to
SQL Server on an Azure VM. For a full discussion of migration options and recommendations, see Migrating a
Database to SQL Server on an Azure VM.
Review other resources for running SQL Server in Azure Virtual Machines.
Automated Backup for SQL Server 2014 Virtual
Machines (Resource Manager)
Automated Backup automatically configures Managed Backup to Microsoft Azure for all existing and new
databases on an Azure VM running SQL Server 2014 Standard or Enterprise. This enables you to configure regular
database backups that utilize durable Azure blob storage. Automated Backup depends on the SQL Server IaaS
Agent Extension.
NOTE
Prerequisites
To use Automated Backup, consider the following prerequisites:
Operating System:
Windows Server 2012
Windows Server 2016
SQL Server version/edition:
SQL Server 2014 Standard
SQL Server 2014 Enterprise
IMPORTANT
Automated Backup works with SQL Server 2014. If you are using SQL Server 2016, you can use Automated Backup v2 to
back up your databases. For more information, see Automated Backup v2 for SQL Server 2016 Azure Virtual Machines.
Database configuration:
Target databases must use the full recovery model. For more information about the impact of the full recovery
model on backups, see Backup Under the Full Recovery Model.
Target databases must be on the default SQL Server instance. The SQL Server IaaS Extension does not support
named instances.
Azure deployment model:
Resource Manager
Azure PowerShell:
Install the latest Azure PowerShell commands if you plan to configure Automated Backup with PowerShell.
NOTE
Automated Backup relies on the SQL Server IaaS Agent Extension. Current SQL virtual machine gallery images add this
extension by default. For more information, see SQL Server IaaS Agent Extension.
Settings
The following table describes the options that can be configured for Automated Backup. The actual configuration
steps vary depending on whether you use the Azure portal or Azure Windows PowerShell commands.
SETTING RANGE (DEFAULT) DESCRIPTION
Automated Backup Enable/Disable (Disabled) Enables or disables Automated Backup

for an Azure VM running SQL Server
2014 Standard or Enterprise.
Retention Period 1-30 days (30 days) The number of days to retain a backup.
Storage Account Azure storage account An Azure storage account to use for
storing Automated Backup files in blob
storage. A container is created at this
location to store all backup files. The
backup file naming convention includes
the date, time, and machine name.
Encryption Enable/Disable (Disabled) Enables or disables encryption. When

encryption is enabled, the certificates
used to restore the backup are located
in the specified storage account in the
same automaticbackup container
using the same naming convention. If
the password changes, a new certificate
is generated with that password, but
the old certificate remains to restore
prior backups.
Password Password text A password for encryption keys. This is

only required if encryption is enabled.
In order to restore an encrypted
backup, you must have the correct
password and related certificate that
was used at the time the backup was
taken.
Configuration in the Portal

You can use the Azure portal to configure Automated Backup during provisioning or for existing SQL Server 2014
VMs.
New VMs
Use the Azure portal to configure Automated Backup when you create a new SQL Server 2014 Virtual Machine in
the Resource Manager deployment model.
In the SQL Server settings blade, select Automated backup. The following Azure portal screenshot shows the
SQL Automated Backup blade.
For context, see the complete topic on provisioning a SQL Server virtual machine in Azure.
Existing VMs
In the SQL Server configuration blade, click the Edit button in the Automated backup section.
If you are enabling Automated Backup for the first time, Azure configures the SQL Server IaaS Agent in the
background. During this time, the Azure portal might not show that Automated Backup is configured. Wait several
minutes for the agent to be installed, configured. After that the Azure portal will reflect the new settings.
NOTE
You can also configure Automated Backup using a template. For more information, see Azure quickstart template for
Automated Backup.
Configuration with PowerShell

You can use PowerShell to configure Automated Backup. Before you begin, you must:
Download and install the latest Azure PowerShell.
Open Windows PowerShell and associate it with your account. You can do this by following the steps in the
Configure your subscription section of the provisioning topic.
Install the SQL IaaS Extension
If you provisioned a SQL Server virtual machine from the Azure portal, the SQL Server IaaS Extension should
already be installed. You can determine if it is installed for your VM by calling Get-AzureRmVM command and
examining the Extensions property.
$vmname = "vmname"
$resourcegroupname = "resourcegroupname"
(Get-AzureRmVM -Name $vmname -ResourceGroupName $resourcegroupname).Extensions
If the SQL Server IaaS Agent extension is installed, you should see it listed as SqlIaaSAgent or
SQLIaaSExtension. ProvisioningState for the extension should also show Succeeded.
If it is not installed or failed to be provisioned, you can install it with the following command. In addition to the VM
name and resource group, you must also specify the region ($region) that your VM is located in.
$region = EASTUS2
Set-AzureRmVMSqlServerExtension -VMName $vmname `
-ResourceGroupName $resourcegroupname -Name "SQLIaasExtension" `
-Version "1.2" -Location $region
Verify current settings

If you enabled automated backup during provisioning, you can use PowerShell to check your current
configuration. Run the Get-AzureRmVMSqlServerExtension command and examine the AutoBackupSettings
property:
(Get-AzureRmVMSqlServerExtension -VMName $vmname -ResourceGroupName $resourcegroupname).AutoBackupSettings
You should get output similar to the following:

Enable : False
EnableEncryption : False
RetentionPeriod : -1
StorageUrl : NOTSET
StorageAccessKey :
Password :
BackupSystemDbs : False
BackupScheduleType :
FullBackupFrequency :
FullBackupStartTime :
FullBackupWindowHours :
LogBackupFrequency :
If your output shows that Enable is set to False, then you have to enable automated backup. The good news is
that you enable and configure Automated Backup in the same way. See the next section for this information.
NOTE
If you check the settings immediately after making a change, it is possible that you will get back the old configuration values.
Wait a few minutes and check the settings again to make sure that your changes were applied.
Configure Automated Backup

You can use PowerShell to enable Automated Backup as well as to modify its configuration and behavior at any
time.
First, select or create a storage account for the backup files. The following script selects a storage account or
creates it if it does not exist.
$storage_accountname = yourstorageaccount
$storage_resourcegroupname = $resourcegroupname
$storage = Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname `

-Name $storage_accountname -ErrorAction SilentlyContinue
If (-Not $storage)
{ $storage = New-AzureRmStorageAccount -ResourceGroupName $storage_resourcegroupname `
-Name $storage_accountname -SkuName Standard_GRS -Location $region }
NOTE
Automated Backup does not support storing backups in premium storage, but it can take backups from VM disks which use
Premium Storage.
Then use the New-AzureRmVMSqlServerAutoBackupConfig command to enable and configure the

Automated Backup settings to store backups in the Azure storage account. In this example, the backups are set to
be retained for 10 days. The second command, Set-AzureRmVMSqlServerExtension, updates the specified
Azure VM with these settings.
$autobackupconfig = New-AzureRmVMSqlServerAutoBackupConfig -Enable `

-RetentionPeriodInDays 10 -StorageContext $storage.Context `
-ResourceGroupName $storage_resourcegroupname
Set-AzureRmVMSqlServerExtension -AutoBackupSettings $autobackupconfig `

-VMName $vmname -ResourceGroupName $resourcegroupname
It could take several minutes to install and configure the SQL Server IaaS Agent.
NOTE
There are other settings for New-AzureRmVMSqlServerAutoBackupConfig that apply only to SQL Server 2016 and
Automated Backup v2. SQL Server 2014 does not support the following settings: BackupSystemDbs,
BackupScheduleType, FullBackupFrequency, FullBackupStartHour, FullBackupWindowInHours, and
LogBackupFrequencyInMinutes. If you attempt to configure these settings on a SQL Server 2014 virtual machine, there is
no error, but the settings do not get applied. If you want to use these settings on a SQL Server 2016 virtual machine, see
Automated Backup v2 for SQL Server 2016 Azure Virtual Machines.
To enable encryption, modify the previous script to pass the EnableEncryption parameter along with a password
(secure string) for the CertificatePassword parameter. The following script enables the Automated Backup
settings in the previous example and adds encryption.
$password = "P@ssw0rd"
$encryptionpassword = $password | ConvertTo-SecureString -AsPlainText -Force

-EnableEncryption -CertificatePassword $encryptionpassword `
-RetentionPeriodInDays 10 -StorageContext $storage.Context `

To confirm your settings are applied, verify the Automated Backup configuration.
Disable Automated Backup
To disable Automated Backup, run the same script without the -Enable parameter to the New-
AzureRmVMSqlServerAutoBackupConfig command. The absence of the -Enable parameter signals the
command to disable the feature. As with installation, it can take several minutes to disable Automated Backup.
$autobackupconfig = New-AzureRmVMSqlServerAutoBackupConfig -ResourceGroupName $storage_resourcegroupname

Example script
The following script provides a set of variables that you can customize to enable and configure Automated Backup
for your VM. In your case, you might need to customize the script based on your requirements. For example, you
would have to make changes if you wanted to disable the backup of system databases or enable encryption.
$vmname = "yourvmname"
$resourcegroupname = "vmresourcegroupname"
$region = Azure region name such as EASTUS2
$storage_accountname = storageaccountname
$storage_resourcegroupname = $resourcegroupname
$retentionperiod = 10
# ResourceGroupName is the resource group which is hosting the VM where you are deploying the SQL IaaS
Extension
Set-AzureRmVMSqlServerExtension -VMName $vmname `

-ResourceGroupName $resourcegroupname -Name "SQLIaasExtension" `
-Version "1.2" -Location $region
# Creates/use a storage account to store the backups
$storage = Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname `

-Name $storage_accountname -ErrorAction SilentlyContinue
If (-Not $storage)
{ $storage = New-AzureRmStorageAccount -ResourceGroupName $storage_resourcegroupname `
-Name $storage_accountname -SkuName Standard_GRS -Location $region }
# Configure Automated Backup settings

-RetentionPeriodInDays $retentionperiod -StorageContext $storage.Context `
# Apply the Automated Backup settings to the VM

Next steps
Automated Backup configures Managed Backup on Azure VMs. So it is important to review the documentation for
Managed Backup to understand the behavior and implications.
You can find additional backup and restore guidance for SQL Server on Azure VMs in the following topic: Backup
and Restore for SQL Server in Azure Virtual Machines.
For information about other available automation tasks, see SQL Server IaaS Agent Extension.
For more information about running SQL Server on Azure VMs, see SQL Server on Azure Virtual Machines
overview.
Use Azure Storage for SQL Server Backup and
Restore
Overview
Starting with SQL Server 2012 SP1 CU2, you can now write SQL Server backups directly to the Azure Blob storage
service. You can use this functionality to back up to and restore from the Azure Blob service with an on-premises
SQL Server database or a SQL Server database in an Azure virtual machine. Backup to cloud offers benefits of
availability, limitless geo-replicated off-site storage, and ease of migration of data to and from the cloud. You can
issue BACKUP or RESTORE statements by using Transact-SQL or SMO.
SQL Server 2016 introduces new capabilities; you can use file-snapshot backup to perform nearly instantaneous
backups and incredibly quick restores.
This topic explains why you might choose to use Azure storage for SQL backups and then describes the
components involved. You can use the resources provided at the end of the article to access walkthroughs and
additional information to start using this service with your SQL Server backups.
Benefits of Using the Azure Blob Service for SQL Server Backups
There are several challenges that you face when backing up SQL Server. These challenges include storage
management, risk of storage failure, access to off-site storage, and hardware configuration. Many of these
challenges are addressed by using the Azure Blob store service for SQL Server backups. Consider the following
benefits:
Ease of use: Storing your backups in Azure blobs can be a convenient, flexible, and easy to access off-site
option. Creating off-site storage for your SQL Server backups can be as easy as modifying your existing
scripts/jobs to use the BACKUP TO URL syntax. Off-site storage should typically be far enough from the
production database location to prevent a single disaster that might impact both the off-site and production
database locations. By choosing to geo-replicate your Azure blobs, you have an extra layer of protection in the
event of a disaster that could affect the whole region.
Backup archive: The Azure Blob Storage service offers a better alternative to the often used tape option to
archive backups. Tape storage might require physical transportation to an off-site facility and measures to
protect the media. Storing your backups in Azure Blob Storage provides an instant, highly available, and a
durable archiving option.
Managed hardware: There is no overhead of hardware management with Azure services. Azure services
manage the hardware and provide geo-replication for redundancy and protection against hardware failures.
Unlimited storage: By enabling a direct backup to Azure blobs, you have access to virtually unlimited storage.
Alternatively, backing up to an Azure virtual machine disk has limits based on machine size. There is a limit to
the number of disks you can attach to an Azure virtual machine for backups. This limit is 16 disks for an extra
large instance and fewer for smaller instances.
Backup availability: Backups stored in Azure blobs are available from anywhere and at any time and can easily
be accessed for restores to either an on-premises SQL Server or another SQL Server running in an Azure Virtual
Machine, without the need for database attach/detach or downloading and attaching the VHD.
Cost: Pay only for the service that is used. Can be cost-effective as an off-site and backup archive option. See the
Azure pricing calculator, and the Azure Pricing article for more information.
Storage snapshots: When database files are stored in an Azure blob and you are using SQL Server 2016, you
can use file-snapshot backup to perform nearly instantaneous backups and incredibly quick restores.
For more details, see SQL Server Backup and Restore with Azure Blob Storage Service.
The following two sections introduce the Azure Blob storage service, including the required SQL Server
components. It is important to understand the components and their interaction to successfully use backup and
restore from the Azure Blob storage service.
Azure Blob Storage Service Components

The following Azure components are used when backing up to the Azure Blob storage service.
COMPONENT DESCRIPTION
Storage Account The storage account is the starting point for all storage
services. To access an Azure Blob Storage service, first create
an Azure Storage account. For more information about Azure
Blob storage service, see How to use the Azure Blob Storage
Service
Container A container provides a grouping of a set of blobs, and can

store an unlimited number of Blobs. To write a SQL Server
backup to an Azure Blob service, you must have at least the
root container created.
Blob A file of any type and size. Blobs are addressable using the
following URL format: https://[storage
account].blob.core.windows.net/[container]/[blob]. For
more information about page Blobs, see Understanding Block
and Page Blobs
SQL Server Components

The following SQL Server components are used when backing up to the Azure Blob storage service.
COMPONENT DESCRIPTION
URL A URL specifies a Uniform Resource Identifier (URI) to a unique

backup file. The URL is used to provide the location and name
of the SQL Server backup file. The URL must point to an actual
blob, not just a container. If the blob does not exist, it is
created. If an existing blob is specified, BACKUP fails, unless
the > WITH FORMAT option is specified. The following is an
example of the URL you would specify in the BACKUP
command:
http[s]://[storageaccount].blob.core.windows.net/[contai
ner]/[FILENAME.bak]. HTTPS is recommended but not
required.
Credential The information that is required to connect and authenticate

to Azure Blob storage service is stored as a Credential. In
order for SQL Server to write backups to an Azure Blob or
restore from it, a SQL Server credential must be created. For
more information, see SQL Server Credential.
NOTE
If you choose to copy and upload a backup file to the Azure Blob storage service, you must use a page blob type as your
storage option if you are planning to use this file for restore operations. RESTORE from a block blob type will fail with an
error.
Next steps
1. Create an Azure account if you don't already have one. If you are evaluating Azure, consider the free trial.
2. Then go through one of the following tutorials that walk you through creating a storage account and
performing a restore.
SQL Server 2014: Tutorial: SQL Server 2014 Backup and Restore to Microsoft Azure Blob Storage
Service.
SQL Server 2016: Tutorial: Using the Microsoft Azure Blob storage service with SQL Server 2016
databases
3. Review additional documentation starting with SQL Server Backup and Restore with Microsoft Azure Blob
Storage Service.
If you have any problems, review the topic SQL Server Backup to URL Best Practices and Troubleshooting.
For other SQL Server backup and restore options, see Backup and Restore for SQL Server in Azure Virtual
Machines.
Performance best practices for SQL Server in Azure
Virtual Machines
Overview
This topic provides best practices for optimizing SQL Server performance in Microsoft Azure Virtual Machine.
While running SQL Server in Azure Virtual Machines, we recommend that you continue using the same database
performance tuning options that are applicable to SQL Server in on-premises server environment. However, the
performance of a relational database in a public cloud depends on many factors such as the size of a virtual
machine, and the configuration of the data disks.
When creating SQL Server images, consider provisioning your VMs in the Azure portal. SQL Server VMs
provisioned in the Portal with Resource Manager implement all these best practices, including the storage
configuration.
This article is focused on getting the best performance for SQL Server on Azure VMs. If your workload is less
demanding, you might not require every optimization listed below. Consider your performance needs and
workload patterns as you evaluate these recommendations.
NOTE
article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager
model.
Quick check list

The following is a quick check list for optimal performance of SQL Server on Azure Virtual Machines:
AREA OPTIMIZATIONS
VM size DS3 or higher for SQL Enterprise edition.
DS2 or higher for SQL Standard and Web editions.
Storage Use Premium Storage. Standard storage is only

recommended for dev/test.
Keep the storage account and SQL Server VM in the same

region.
Disable Azure geo-redundant storage (geo-replication) on

the storage account.
AREA OPTIMIZATIONS
Disks Use a minimum of 2 P30 disks (1 for log files; 1 for data files
and TempDB).
Avoid using operating system or temporary disks for

database storage or logging.
Enable read caching on the disk(s) hosting the data files and
TempDB.
Do not enable caching on disk(s) hosting the log file.
Important: Stop the SQL Server service when changing the

cache settings for an Azure VM disk.
Stripe multiple Azure data disks to get increased IO

throughput.
Format with documented allocation sizes.
I/O Enable database page compression.
Enable instant file initialization for data files.
Limit or disable autogrow on the database.
Disable autoshrink on the database.
Move all databases to data disks, including system databases.
Move SQL Server error log and trace file directories to data
disks.
Setup default backup and database file locations.
Enable locked pages.
Apply SQL Server performance fixes.
Feature specific Back up directly to blob storage.
For more information on how and why to make these optimizations, please review the details and guidance
provided in following sections.
VM size guidance
For performance sensitive applications, its recommended that you use the following virtual machines sizes:
SQL Server Enterprise Edition: DS3 or higher
SQL Server Standard and Web Editions: DS2 or higher
Storage guidance
DS-series (along with DSv2-series and GS-series) VMs support Premium Storage. Premium Storage is
recommended for all production workloads.
WARNING
Standard Storage has varying latencies and bandwidth and is only recommended for dev/test workloads. Production
workloads should use Premium Storage.
In addition, we recommend that you create your Azure storage account in the same data center as your SQL
Server virtual machines to reduce transfer delays. When creating a storage account, disable geo-replication as
consistent write order across multiple disks is not guaranteed. Instead, consider configuring a SQL Server disaster
recovery technology between two Azure data centers. For more information, see High Availability and Disaster
Recovery for SQL Server in Azure Virtual Machines.
Disks guidance
There are three main disk types on an Azure VM:
OS disk: When you create an Azure Virtual Machine, the platform will attach at least one disk (labeled as the C
drive) to the VM for your operating system disk. This disk is a VHD stored as a page blob in storage.
Temporary disk: Azure Virtual Machines contain another disk called the temporary disk (labeled as the D:
drive). This is a disk on the node that can be used for scratch space.
Data disks: You can also attach additional disks to your virtual machine as data disks, and these will be stored
in storage as page blobs.
The following sections describe recommendations for using these different disks.
Operating system disk
An operating system disk is a VHD that you can boot and mount as a running version of an operating system and
is labeled as C drive.
Default caching policy on the operating system disk is Read/Write. For performance sensitive applications, we
recommend that you use data disks instead of the operating system disk. See the section on Data Disks below.
Temporary disk
The temporary storage drive, labeled as the D: drive, is not persisted to Azure blob storage. Do not store your
user database files or user transaction log files on the D: drive.
For D-series, Dv2-series, and G-series VMs, the temporary drive on these VMs is SSD-based. If your workload
makes heavy use of TempDB (e.g. for temporary objects or complex joins), storing TempDB on the D drive could
result in higher TempDB throughput and lower TempDB latency.
For VMs that support Premium Storage (DS-series, DSv2-series, and GS-series), we recommend storing TempDB
on a disk that supports Premium Storage with read caching enabled. There is one exception to this
recommendation; if your TempDB usage is write-intensive, you can achieve higher performance by storing
TempDB on the local D drive, which is also SSD-based on these machine sizes.
Data disks
Use data disks for data and log files: At a minimum, use 2 Premium Storage P30 disks where one disk
contains the log file(s) and the other contains the data and TempDB file(s). Each Premium Storage disk
provides a number of IOPs and bandwidth (MB/s) depending on its size, as described in the following
article: Using Premium Storage for Disks.
Disk Striping: For more throughput, you can add additional data disks and use Disk Striping. To
determine the number of data disks, you need to analyze the number of IOPS and bandwidth required for
your log file(s), and for your data and TempDB file(s). Notice that different VM sizes have different limits
on the number of IOPs and bandwidth supported, see the tables on IOPS per VM size. Use the following
guidelines:
For Windows 8/Windows Server 2012 or later, use Storage Spaces with the following guidelines:
1. Set the interleave (stripe size) to 64 KB (65536 bytes) for OLTP workloads and 256 KB (262144
bytes) for data warehousing workloads to avoid performance impact due to partition
misalignment. This must be set with PowerShell.
2. Set column count = number of physical disks. Use PowerShell when configuring more than 8
disks (not Server Manager UI).
For example, the following PowerShell creates a new storage pool with the interleave size to 64 KB
and the number of columns to 2:
$PoolCount = Get-PhysicalDisk -CanPool $True

$PhysicalDisks = Get-PhysicalDisk | Where-Object {$_.FriendlyName -like "*2" -or
$_.FriendlyName -like "*3"}
New-StoragePool -FriendlyName "DataFiles" -StorageSubsystemFriendlyName "Storage Spaces*" -

PhysicalDisks $PhysicalDisks | New-VirtualDisk -FriendlyName "DataFiles" -Interleave 65536 -
NumberOfColumns 2 -ResiliencySettingName simple UseMaximumSize |Initialize-Disk -
PartitionStyle GPT -PassThru |New-Partition -AssignDriveLetter -UseMaximumSize |Format-Volume -
FileSystem NTFS -NewFileSystemLabel "DataDisks" -AllocationUnitSize 65536 -Confirm:$false
For Windows 2008 R2 or earlier, you can use dynamic disks (OS striped volumes) and the stripe
size is always 64 KB. Note that this option is deprecated as of Windows 8/Windows Server 2012.
For information, see the support statement at Virtual Disk Service is transitioning to Windows
Storage Management API.
If your workload is not log intensive and does not need dedicated IOPs, you can configure just one
storage pool. Otherwise, create two storage pools, one for the log file(s) and another storage pool
for the data file(s) and TempDB. Determine the number of disks associated with each storage pool
based on your load expectations. Keep in mind that different VM sizes allow different numbers of
attached data disks. For more information, see Sizes for Virtual Machines.
If you are not using Premium Storage (dev/test scenarios), the recommendation is to add the
maximum number of data disks supported by your VM size and use Disk Striping.
Caching policy: For Premium Storage data disks, enable read caching on the data disks hosting your data
files and TempDB only. If you are not using Premium Storage, do not enable any caching on any data
disks. For instructions on configuring disk caching, see the following topics: Set-AzureOSDisk and Set-
AzureDataDisk.
WARNING
Stop the SQL Server service when changing the cache setting of Azure VM disks to avoid the possibility of any
database corruption.
NTFS allocation unit size: When formatting the data disk, it is recommended that you use a 64-KB
allocation unit size for data and log files as well as TempDB.
Disk management best practices: When removing a data disk or changing its cache type, stop the SQL
Server service during the change. When the caching settings are changed on the OS disk, Azure stops the
VM, changes the cache type, and restarts the VM. When the cache settings of a data disk are changed, the
VM is not stopped, but the data disk is detached from the VM during the change and then reattached.
WARNING
Failure to stop the SQL Server service during these operations can cause database corruption.
I/O guidance
The best results with Premium Storage are achieved when you parallelize your application and requests.
Premium Storage is designed for scenarios where the IO queue depth is greater than 1, so you will see
little or no performance gains for single-threaded serial requests (even if they are storage intensive). For
example, this could impact the single-threaded test results of performance analysis tools, such as SQLIO.
Consider using database page compression as it can help improve performance of I/O intensive
workloads. However, the data compression might increase the CPU consumption on the database server.
Consider enabling instant file initialization to reduce the time that is required for initial file allocation. To
take advantage of instant file initialization, you grant the SQL Server (MSSQLSERVER) service account with
SE_MANAGE_VOLUME_NAME and add it to the Perform Volume Maintenance Tasks security policy. If
you are using a SQL Server platform image for Azure, the default service account (NT
Service\MSSQLSERVER) isnt added to the Perform Volume Maintenance Tasks security policy. In other
words, instant file initialization is not enabled in a SQL Server Azure platform image. After adding the SQL
Server service account to the Perform Volume Maintenance Tasks security policy, restart the SQL
Server service. There could be security considerations for using this feature. For more information, see
Database File Initialization.
autogrow is considered to be merely a contingency for unexpected growth. Do not manage your data and
log growth on a day-to-day basis with autogrow. If autogrow is used, pre-grow the file using the Size
switch.
Make sure autoshrink is disabled to avoid unnecessary overhead that can negatively affect performance.
Move all databases to data disks, including system databases. For more information, see Move System
Databases.
Move SQL Server error log and trace file directories to data disks. This can be done in SQL Server
Configuration Manager by right-clicking your SQL Server instance and selecting properties. The error log
and trace file settings can be changed in the Startup Parameters tab. The Dump Directory is specified in
the Advanced tab. The following screenshot shows where to look for the error log startup parameter.
Setup default backup and database file locations. Use the recommendations in this topic, and make the
changes in the Server properties window. For instructions, see View or Change the Default Locations for
Data and Log Files (SQL Server Management Studio). The following screenshot demonstrates where to
make these changes.
Enable locked pages to reduce IO and any paging activities. For more information, see Enable the Lock
Pages in Memory Option (Windows).
If you are running SQL Server 2012, install Service Pack 1 Cumulative Update 10. This update contains the
fix for poor performance on I/O when you execute select into temporary table statement in SQL Server
2012. For information, see this knowledge base article.
Consider compressing any data files when transferring in/out of Azure.
Feature specific guidance

Some deployments may achieve additional performance benefits using more advanced configuration techniques.
The following list highlights some SQL Server features that can help you to achieve better performance:
Backup to Azure storage: When performing backups for SQL Server running in Azure virtual machines,
you can use SQL Server Backup to URL. This feature is available starting with SQL Server 2012 SP1 CU2
and recommended for backing up to the attached data disks. When you backup/restore to/from Azure
storage, follow the recommendations provided at SQL Server Backup to URL Best Practices and
Troubleshooting and Restoring from Backups Stored in Azure Storage. You can also automate these
backups using Automated Backup for SQL Server in Azure Virtual Machines.
Prior to SQL Server 2012, you can use SQL Server Backup to Azure Tool. This tool can help to increase
backup throughput using multiple backup stripe targets.
SQL Server Data Files in Azure: This new feature, SQL Server Data Files in Azure, is available starting
with SQL Server 2014. Running SQL Server with data files in Azure demonstrates comparable
performance characteristics as using Azure data disks.
Next Steps
For security best practices, see Security Considerations for SQL Server in Azure Virtual Machines.
Review other SQL Server Virtual Machine topics at SQL Server on Azure Virtual Machines Overview.
Storage configuration for SQL Server VMs
When you configure a SQL Server virtual machine image in Azure, the Portal helps to automate your storage
configuration. This includes attaching storage to the VM, making that storage accessible to SQL Server, and
configuring it to optimize for your specific performance requirements.
This topic explains how Azure configures storage for your SQL Server VMs both during provisioning and for
existing VMs. This configuration is based on the performance best practices for Azure VMs running SQL Server.
NOTE
article covers using the Resource Manager deployment model, which Microsoft recommends for new deployments instead of
the classic deployment model.
Prerequisites
To use the automated storage configuration settings, your virtual machine requires the following characteristics:
Provisioned with a SQL Server gallery image.
Uses the Resource Manager deployment model.
Uses Premium Storage.
New VMs
The following sections describe how to configure storage for new SQL Server virtual machines.
Azure Portal
When provisioning an Azure VM using a SQL Server gallery image, you can choose to automatically configure the
storage for your new VM. You specify the storage size, performance limits, and workload type. The following
screenshot shows the Storage configuration blade used during SQL VM provisioning.
Based on your choices, Azure performs the following storage configuration tasks after creating the VM:
Creates and attaches premium storage data disks to the virtual machine.
Configures the data disks to be accessible to SQL Server.
Configures the data disks into a storage pool based on the specified size and performance (IOPS and
throughput) requirements.
Associates the storage pool with a new drive on the virtual machine.
Optimizes this new drive based on your specified workload type (Data warehousing, Transactional processing,
or General).
For further details on how Azure configures storage settings, see the Storage configuration section. For a full
walkthrough of how to create a SQL Server VM in the Azure Portal, see the provisioning tutorial.
Resource Manage templates
If you use the following Resource Manager templates, two premium data disks are attached by default, with no
storage pool configuration. However, you can customize these templates to change the number of premium data
disks that are attached to the virtual machine.
Create VM with Automated Backup
Create VM with Automated Patching
Create VM with AKV Integration
Existing VMs
For existing SQL Server VMs, you can modify some storage settings in the Azure portal. Select your VM, go to the
Settings area, and then select SQL Server Configuration. The SQL Server Configuration blade shows the current
storage usage of your VM. All drives that exist on your VM are displayed in this chart. For each drive, the storage
space displays in four sections:
SQL data
SQL log
Other (non-SQL storage)
Available
To configure the storage to add a new drive or extend an existing drive, click the Edit link above the chart.
The configuration options that you see varies depending on whether you have used this feature before. When using
for the first time, you can specify your storage requirements for a new drive. If you previously used this feature to
create a drive, you can choose to extend that drives storage.
Use for the first time
If it is your first time using this feature, you can specify the storage size and performance limits for a new drive. This
experience is similar to what you would see at provisioning time. The main difference is that you are not permitted
to specify the workload type. This restriction prevents disrupting any existing SQL Server configurations on the
virtual machine.
Azure creates a new drive based on your specifications. In this scenario, Azure performs the following storage
configuration tasks:
Creates and attaches premium storage data disks to the virtual machine.
Configures the data disks to be accessible to SQL Server.
Configures the data disks into a storage pool based on the specified size and performance (IOPS and
throughput) requirements.
Associates the storage pool with a new drive on the virtual machine.
For further details on how Azure configures storage settings, see the Storage configuration section.
Add a new drive
If you have already configured storage on your SQL Server VM, expanding storage brings up two new options. The
first option is to add a new drive, which can increase the performance level of your VM.
However, after adding the drive, you must perform some extra manual configuration to achieve the performance
increase.
Extend the drive
The other option for expanding storage is to extend the existing drive. This option increases the available storage
for your drive, but it does not increase performance. With storage pools, you cannot alter the number of columns
after the storage pool is created. The number of columns determines the number of parallel writes, which can be
striped across the data disks. Therefore, any added data disks cannot increase performance. They can only provide
more storage for the data being written. This limitation also means that, when extending the drive, the number of
columns determines the minimum number of data disks that you can add. So if you create a storage pool with four
data disks, the number of columns is also four. Any time you extend the storage, you must add at least four data
disks.
This section provides a reference for the storage configuration changes that Azure automatically performs during
SQL VM provisioning or configuration in the Azure Portal.
If you have selected fewer than two TBs of storage for your VM, Azure does not create a storage pool.
If you have selected at least two TBs of storage for your VM, Azure configures a storage pool. The next section of
this topic provides the details of the storage pool configuration.
Automatic storage configuration always uses premium storage P30 data disks. Consequently, there is a 1:1
mapping between your selected number of Terabytes and the number of data disks attached to your VM.
For pricing information, see the Storage pricing page on the Disk Storage tab.
Creation of the storage pool
Azure uses the following settings to create the storage pool on SQL Server VMs.
SETTING VALUE
Stripe size 256 KB (Data warehousing); 64 KB (Transactional)
Disk sizes 1 TB each
Cache Read
Allocation size 64 KB NTFS allocation unit size
Instant file initialization Enabled
Lock pages in memory Enabled
Recovery Simple recovery (no resiliency)
Number of columns Number of data disks1
TempDB location Stored on data disks2
1 After the storage pool is created, you cannot alter the number of columns in the storage pool.
2 This setting only applies to the first drive you create using the storage configuration feature.
Workload optimization settings

The following table describes the three workload type options available and their corresponding optimizations:
WORKLOAD TYPE DESCRIPTION OPTIMIZATIONS
General Default setting that supports most None

workloads
Transactional processing Optimizes the storage for traditional Trace Flag 1117
database OLTP workloads Trace Flag 1118
Data warehousing Optimizes the storage for analytic and Trace Flag 610
reporting workloads Trace Flag 1117
NOTE
You can only specify the workload type when you provision a SQL virtual machine by selecting it in the storage configuration
step.
Next steps
Application Patterns and Development Strategies for
SQL Server in Azure Virtual Machines
NOTE
Summary:
Determining which application pattern or patterns to use for your SQL-Server-based applications in Azure
environment is an important design decision and it requires a solid understanding of how SQL Server and each
infrastructure component of Azure work together. With SQL Server in Azure Infrastructure Services, you can easily
migrate, maintain, and monitor your existing SQL Server applications built-on Windows Server to virtual machines
in Azure.
The goal of this article is to provide solution architects and developers a foundation for good application
architecture and design, which they can follow when migrating existing applications to Azure as well as developing
new applications in Azure.
For each application pattern, you will find an on-premises scenario, its respective cloud-enabled solution, and the
related technical recommendations. In addition, the article discusses Azure-specific development strategies so that
you can design your applications correctly. Due to the many possible application patterns, its recommended that
architects and developers should choose the most appropriate pattern for their applications and users.
Technical Contributors: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishnan
Technical Reviewers: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra,
Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman, Xin Jin
Introduction
You can develop many types of n-tier applications by separating the components of the different application layers
on different machines as well as in separate components. For example, you can place the client application and
business rules components in one machine, front-end web tier and data access tier components in another
machine, and a back-end database tier in another machine. This kind of structuring helps isolate each tier from
each other. If you change where data comes from, you dont need to change the client or web application but only
the data access tier components.
A typical n-tier application includes the presentation tier, the business tier, and the data tier:
TIER DESCRIPTION
Presentation The presentation tier (web tier, front-end tier) is the layer in
which users interact with an application.
Business The business tier (middle tier) is the layer that the
presentation tier and the data tier use to communicate with
each other and includes the core functionality of the system.
TIER DESCRIPTION
Data The data tier is basically the server that stores an application's
data (for example, a server running SQL Server).
Application layers describe the logical groupings of the functionality and components in an application; whereas
tiers describe the physical distribution of the functionality and components on separate physical servers,
computers, networks, or remote locations. The layers of an application may reside on the same physical computer
(the same tier) or may be distributed over separate computers (n-tier), and the components in each layer
communicate with components in other layers through well-defined interfaces. You can think of the term tier as
referring to physical distribution patterns such as two-tier, three-tier, and n-tier. A 2-tier application pattern
contains two application tiers: application server and database server. The direct communication happens between
the application server and the database server. The application server contains both web-tier and business-tier
components. In 3-tier application pattern, there are three application tiers: web server, application server, which
contains the business logic tier and/or business tier data access components, and the database server. The
communication between the web server and the database server happens over the application server. For detailed
information on application layers and tiers, see Microsoft Application Architecture Guide.
Before you start reading this article, you should have knowledge on the fundamental concepts of SQL Server and
Azure. For information, see SQL Server Books Online, SQL Server in Azure Virtual Machines and Azure.com.
This article describes several application patterns that can be suitable for your simple applications as well as the
highly complex enterprise applications. Before detailing each pattern, we recommend that you should familiarize
yourself with the available data storage services in Azure, such as Azure Storage, Azure SQL Database, and SQL
Server in an Azure Virtual Machine. To make the best design decisions for your applications, understand when to
use which data storage service clearly.
Choose SQL Server in an Azure Virtual Machine, when:
You need control on SQL Server and Windows. For example, this might include the SQL Server version, special
hotfixes, performance configuration, etc.
You need a full compatibility with SQL Server on-premises and want to move existing applications to Azure as-
is.
You want to leverage the capabilities of the Azure environment but Azure SQL Database does not support all
the features that your application requires. This could include the following areas:
Database size: At the time this article was updated, SQL Database supports a database of up to 1 TB of
data. If your application requires more than 1 TB of data and you dont want to implement custom
sharding solutions, its recommended that you use SQL Server in an Azure Virtual Machine. For the latest
information, see Scaling Out Azure SQL Databases and Azure SQL Database Service Tiers and
Performance Levels.
HIPAA compliance: Healthcare customers and Independent Software Vendors (ISVs) might choose SQL
Server in Azure Virtual Machines instead of Azure SQL Database because SQL Server in an Azure Virtual
Machine is covered by HIPAA Business Associate Agreement (BAA). For information on compliance, see
Microsoft Azure Trust Center: Compliance.
Instance-level features: At this time, SQL Database doesnt support features that live outside of the
database (such as Linked Servers, Agent jobs, FileStream, Service Broker, etc.). For more information, see
Azure SQL Database Guidelines and Limitations.
1-tier (simple): single virtual machine

In this application pattern, you deploy your SQL Server application and database to a standalone virtual machine in
Azure. The same virtual machine contains your client/web application, business components, data access layer, and
the database server. The presentation, business, and data access code are logically separated but are physically
located in a single-server machine. Most customers start with this application pattern and then, they scale out by
adding more web roles or virtual machines to their system.
This application pattern is useful when:
You want to perform a simple migration to Azure platform to evaluate whether the platform answers your
applications requirements or not.
You want to keep all the application tiers hosted in the same virtual machine in the same Azure data center to
reduce the latency between tiers.
You want to quickly provision development and test environments for short periods of time.
You want to perform stress testing for varying workload levels but at the same time you do not want to own
and maintain many physical machines all the time.
The following diagram demonstrates a simple on-premises scenario and how you can deploy its cloud enabled
solution in a single virtual machine in Azure.
Deploying the business layer (business logic and data access components) on the same physical tier as the
presentation layer can maximize application performance, unless you must use a separate tier due to scalability or
security concerns.
Since this is a very common pattern to start with, you might find the following article on migration useful for
moving your data to your SQL Server VM: Migrating a Database to SQL Server on an Azure VM.
3-tier (simple): multiple virtual machines

In this application pattern, you deploy a 3-tier application in Azure by placing each application tier in a different
virtual machine. This provides a flexible environment for an easy scale-up and scale-out scenarios. When one
virtual machine contains your client/web application, the other one hosts your business components, and the other
one hosts the database server.
You want to perform a migration of complex database applications to Azure Virtual Machines.
You want different application tiers to be hosted in different regions. For example, you might have shared
databases that are deployed to multiple regions for reporting purposes.
You want to move enterprise applications from on-premises virtualized platforms to Azure Virtual Machines.
For a detailed discussion on enterprise applications, see What is an Enterprise Application.
The following diagram demonstrates how you can place a simple 3-tier application in Azure by placing each
application tier in a different virtual machine.
In this application pattern, there is only one virtual machine (VM) in each tier. If you have multiple VMs in Azure, we
recommend that you set up a virtual network. Azure Virtual Network creates a trusted security boundary and also
allows VMs to communicate among themselves over the private IP address. In addition, always make sure that all
Internet connections only go to the presentation tier. When following this application pattern, manage the network
security group rules to control access. For more information, see Allow external access to your VM using the Azure
portal.
In the diagram, Internet Protocols can be TCP, UDP, HTTP, or HTTPS.
NOTE
Setting up a virtual network in Azure is free of charge. However, you are charged for the VPN gateway that connects to on-
premises. This charge is based on the amount of time that connection is provisioned and available.
2-tier and 3-tier with presentation tier scale-out

In this application pattern, you deploy 2-tier or 3-tier database application to Azure Virtual Machines by placing
each application tier in a different virtual machine. In addition, you scale out the presentation tier due to increased
volume of incoming client requests.
You want to scale out the presentation tier due to increased volume of incoming client requests.
You want to own an infrastructure environment that can scale up and down on demand.
The following diagram demonstrates how you can place the application tiers in multiple virtual machines in Azure
by scaling out the presentation tier due to increased volume of incoming client requests. As seen in the diagram,
Azure Load Balancer is responsible for distributing traffic across multiple virtual machines and also determining
which web server to connect to. Having multiple instances of the web servers behind a load balancer ensures the
high availability of the presentation tier.
Best practices for 2-tier, 3-tier, or n-tier patterns that have multiple VMs in one tier
Its recommended that you place the virtual machines that belong to the same tier in the same cloud service and in
the same the availability set. For example, place a set of web servers in CloudService1 and AvailabilitySet1 and a
set of database servers in CloudService2 and AvailabilitySet2. An availability set in Azure enables you to place
the high availability nodes into separate fault domains and upgrade domains.
To leverage multiple VM instances of a tier, you need to configure Azure Load Balancer between application tiers.
To configure Load Balancer in each tier, create a load-balanced endpoint on each tiers VMs separately. For a
specific tier, first create VMs in the same cloud service. This ensures that they have the same public Virtual IP
address. Next, create an endpoint on one of the virtual machines on that tier. Then, assign the same endpoint to the
other virtual machines on that tier for load balancing. By creating a load-balanced set, you distribute traffic across
multiple virtual machines and also allow the Load Balancer to determine which node to connect when a backend
VM node fails. For example, having multiple instances of the web servers behind a load balancer ensures the high
availability of the presentation tier.
As a best practice, always make sure that all internet connections first go to the presentation tier. The presentation
layer accesses the business tier, and then the business tier accesses the data tier. For more information on how to
allow access to the presentation layer, see Allow external access to your VM using the Azure portal.
Note that the Load Balancer in Azure works similar to load balancers in an on-premises environment. For more
information, see Load balancing for Azure infrastructure services.
In addition, we recommend that you set up a private network for your virtual machines by using Azure Virtual
Network. This allows them to communicate among themselves over the private IP address. For more information,
see Azure Virtual Network.
2-tier and 3-tier with business tier scale-out

In this application pattern, you deploy 2-tier or 3-tier database application to Azure Virtual Machines by placing
each application tier in a different virtual machine. In addition, you might want to distribute the application server
components to multiple virtual machines due to the complexity of your application.
You want to distribute the application server components to multiple virtual machines due to the complexity of
your application.
You want to move business logic heavy on-premises LOB (line-of-business) applications to Azure Virtual
Machines. LOB applications are a set of critical computer applications that are vital to running an enterprise,
such as accounting, human resources (HR), payroll, supply chain management, and resource planning
applications.
The following diagram demonstrates an on-premises scenario and its cloud enabled solution. In this scenario, you
place the application tiers in multiple virtual machines in Azure by scaling out the business tier, which contains the
business logic tier and data access components. As seen in the diagram, Azure Load Balancer is responsible for
distributing traffic across multiple virtual machines and also determining which web server to connect to. Having
multiple instances of the application servers behind a load balancer ensures the high availability of the business
tier. For more information, see Best practices for 2-tier, 3-tier, or n-tier application patterns that have multiple
virtual machines in one tier.
2-tier and 3-tier with presentation and business tiers scale-out and
HADR
In this application pattern, you deploy 2-tier or 3-tier database application to Azure Virtual Machines by
distributing the presentation tier (web server) and the business tier (application server) components to multiple
virtual machines. In addition, you implement high-availability and disaster recovery solutions for your databases in
Azure virtual machines.
You want to move enterprise applications from virtualized platforms on-premises to Azure by implementing
SQL Server high availability and disaster recovery capabilities.
You want to scale out the presentation tier and the business tier due to increased volume of incoming client
requests and the complexity of your application.
scale out the presentation tier and the business tier components in multiple virtual machines in Azure. In addition,
you implement high availability and disaster recovery (HADR) techniques for SQL Server databases in Azure.
Running multiple copies of an application in different VMs make sure that you are load balancing requests across
them. When you have multiple virtual machines, you need to make sure that all your VMs are accessible and
running at one point in time. If you configure load balancing, Azure Load Balancer tracks the health of VMs and
directs incoming calls to the healthy functioning VM nodes properly. For information on how to set up load
balancing of the virtual machines, see Load balancing for Azure infrastructure services. Having multiple instances
of web and application servers behind a load balancer ensures the high availability of the presentation and
business tiers.
Best practices for application patterns requiring SQL HADR

When you set up SQL Server high availability and disaster recovery solutions in Azure Virtual Machines, setting up
a virtual network for your virtual machines using Azure Virtual Network is mandatory. Virtual machines within a
Virtual Network will have a stable private IP address even after a service downtime, thus you can avoid the update
time required for DNS name resolution. In addition, the virtual network allows you to extend your on-premises
network to Azure and creates a trusted security boundary. For example, if your application has corporate domain
restrictions (such as, Windows authentication, Active Directory), setting up Azure Virtual Network is necessary.
Most of customers, who are running production code on Azure, are keeping both primary and secondary replicas
in Azure.
For comprehensive information and tutorials on high availability and disaster recovery techniques, see High
Availability and Disaster Recovery for SQL Server in Azure Virtual Machines.
2-tier and 3-tier using Azure VMs and Cloud Services

In this application pattern, you deploy 2-tier or 3-tier application to Azure by using both Azure Cloud Services (web
and worker roles - Platform as a Service (PaaS)) and Azure Virtual Machines (Infrastructure as a Service (IaaS)).
Using Azure Cloud Services for the presentation tier/business tier and SQL Server in Azure Virtual Machines for the
data tier is beneficial for most applications running on Azure. The reason is that having a compute instance running
on Cloud Services provides an easy management, deployment, monitoring, and scale-out.
With Cloud Services, Azure maintains the infrastructure for you, performs routine maintenance, patches the
operating systems, and attempts to recover from service and hardware failures. When your application needs
scale-out, automatic, and manual scale-out options are available for your cloud service project by increasing or
decreasing the number of instances or virtual machines that are used by your application. In addition, you can use
on-premises Visual Studio to deploy your application to a cloud service project in Azure.
In summary, if you dont want to own extensive administrative tasks for the presentation/business tier and your
application does not require any complex configuration of software or the operating system, use Azure Cloud
Services. If Azure SQL Database does not support all the features you are looking for, use SQL Server in an Azure
Virtual Machine for the data tier. Running an application on Azure Cloud Services and storing data in Azure Virtual
Machines combines the benefits of both services. For a detailed comparison, see the section in this topic on
Comparing development strategies in Azure.
In this application pattern, the presentation tier includes a web role, which is a Cloud Services component running
in the Azure execution environment and it is customized for web application programming as supported by IIS and
ASP.NET. The business or backend tier includes a worker role, which is a Cloud Services component running in the
Azure execution environment and it is useful for generalized development, and may perform background
processing for a web role. The database tier resides in a SQL Server virtual machine in Azure. The communication
between the presentation tier and the database tier happens directly or over the business tier worker role
components.
You want to move enterprise applications from virtualized platforms on-premises to Azure by implementing
SQL Server high availability and disaster recovery capabilities.
Azure SQL Database does not support all the features that your application or database needs.
place the presentation tier in web roles, the business tier in worker roles but the data tier in virtual machines in
Azure. Running multiple copies of the presentation tier in different web roles ensures to load balance requests
across them. When you combine Azure Cloud Services with Azure Virtual Machines, we recommend that you set
up Azure Virtual Network as well. With Azure Virtual Network, you can have stable and persistent private IP
addresses within the same cloud service in the cloud. Once you define a virtual network for your virtual machines
and cloud services, they can start communicating among themselves over the private IP address. In addition,
having virtual machines and Azure web/worker roles in the same Azure Virtual Network provides low latency and
more secure connectivity. For more information, see What is a cloud service.
As seen in the diagram, Azure Load Balancer distributes traffic across multiple virtual machines and also
determines which web server or application server to connect to. Having multiple instances of the web and
application servers behind a load balancer ensures the high availability of the presentation tier and the business
tier. For more information, see Best practices for application patterns requiring SQL HADR.
Another approach to implement this application pattern is to use a consolidated web role that contains both
presentation tier and business tier components as shown in the following diagram. This application pattern is
useful for applications that require stateful design. Since Azure provides stateless compute nodes on web and
worker roles, we recommend that you implement a logic to store session state using one of the following
technologies: Azure Caching, Azure Table Storage or Azure SQL Database.
Pattern with Azure VMs, Azure SQL Database, and Azure App Service
(Web Apps)
The primary goal of this application pattern is to show you how to combine Azure infrastructure as a service (IaaS)
components with Azure platform-as-a-service components (PaaS) in your solution. This pattern is focused on
Azure SQL Database for relational data storage. It does not include SQL Server in an Azure virtual machine, which
is part of the Azure infrastructure as a service offering.
In this application pattern, you deploy a database application to Azure by placing the presentation and business
tiers in the same virtual machine and accessing a database in Azure SQL Database (SQL Database) servers. You can
implement the presentation tier by using traditional IIS-based web solutions. Or, you can implement a combined
presentation and business tier by using Azure Web Apps.
You already have an existing SQL Database server configured in Azure and you want to test your application
quickly.
You want to test the capabilities of Azure environment.
Your business logic and data access components can be self-contained within a web application.
place the application tiers in a single virtual machine in Azure and access data in Azure SQL Database.
If you choose to implement a combined web and application tier by using Azure Web Apps, we recommend that
you keep the middle-tier or application tier as dynamic-link libraries (DLLs) in the context of a web application.
In addition, review the recommendations given in the Comparing web development strategies in Azure section at
the end of this article to learn more about programming techniques.
N-tier hybrid application pattern

In n-tier hybrid application pattern, you implement your application in multiple tiers distributed between on-
premises and Azure. Therefore, you create a flexible and reusable hybrid system, which you can modify or add a
specific tier without changing the other tiers. To extend your corporate network to the cloud, you use Azure Virtual
Network service.
This hybrid application pattern is useful when:
You want to build applications that run partly in the cloud and partly on-premises.
You want to migrate some or all elements of an existing on-premises application to the cloud.
You want to move enterprise applications from on-premises virtualized platforms to Azure.
You want a cost effective way to take backups for enterprise database applications.
The following diagram demonstrates an n-tier hybrid application pattern that spans across on-premises and Azure.
As shown in the diagram, on-premises infrastructure includes Active Directory Domain Services domain controller
to support user authentication and authorization. Note that the diagram demonstrates a scenario, where some
parts of the data tier live in an on-premises data center whereas some parts of the data tier live in Azure.
Depending on your applications needs, you can implement several other hybrid scenarios. For example, you might
keep the presentation tier and the business tier in an on-premises environment but the data tier in Azure.
In Azure, you can use Active Directory as a standalone cloud directory for your organization, or you can also
integrate existing on-premises Active Directory with Azure Active Directory. As seen in the diagram, the business
tier components can access to multiple data sources, such as to SQL Server in Azure via a private internal IP
address, to on-premises SQL Server via Azure Virtual Network, or to SQL Database using the .NET Framework data
provider technologies. In this diagram, Azure SQL Database is an optional data storage service.
In n-tier hybrid application pattern, you can implement the following workflow in the order specified:
1. Identify enterprise database applications that need to be moved up to cloud by using the Microsoft Assessment
and Planning (MAP) Toolkit. The MAP Toolkit gathers inventory and performance data from computers you are
considering for virtualization and provides recommendations on capacity and assessment planning.
2. Plan the resources and configuration needed in the Azure platform, such as storage accounts and virtual
machines.
3. Set up network connectivity between the corporate network on-premises and Azure Virtual Network. To set
up the connection between the corporate network on-premises and a virtual machine in Azure, use one of
the following two methods:
a. Establish a connection between on-premises and Azure via public end points on a virtual machine in
Azure. This method provides an easy setup and enables you to use SQL Server authentication in your
virtual machine. In addition, set up your network security group rules to control public traffic to the VM.
For more information, see Allow external access to your VM using the Azure portal.
b. Establish a connection between on-premises and Azure via Azure Virtual Private network (VPN)
tunnel. This method allows you to extend domain policies to a virtual machine in Azure. In addition,
you can set up firewall rules and use Windows authentication in your virtual machine. Currently,
Azure supports secure site-to-site VPN and point-to-site VPN connections:
With secure site-to-site connection, you can establish network connectivity between your on-
premises network and your virtual network in Azure. It is recommended for connecting your on-
premises data center environment to Azure.
With secure point-to-site connection, you can establish network connectivity between your virtual
network in Azure and your individual computers running anywhere. It is mostly recommended for
development and test purposes.
For information on how to connect to SQL Server in Azure, see Connect to a SQL Server Virtual
Machine on Azure.
4. Set up scheduled jobs and alerts that back up on-premises data in a virtual machine disk in Azure. For more
information, see SQL Server Backup and Restore with Azure Blob Storage Service and Backup and Restore for
SQL Server in Azure Virtual Machines.
5. Depending on your applications needs, you can implement one of the following three common scenarios:
a. You can keep your web server, application server, and insensitive data in a database server in Azure
whereas you keep the sensitive data on-premises.
b. You can keep your web server and application server on-premises whereas the database server in a
virtual machine in Azure.
c. You can keep your database server, web server, and application server on-premises whereas you keep
the database replicas in virtual machines in Azure. This setting allows the on-premises web servers or
reporting applications to access the database replicas in Azure. Therefore, you can achieve to lower the
workload in an on-premises database. We recommend that you implement this scenario for heavy read
workloads and developmental purposes. For information on creating database replicas in Azure, see
AlwaysOn Availability Groups at High Availability and Disaster Recovery for SQL Server in Azure Virtual
Machines.
Comparing web development strategies in Azure

To implement and deploy a multi-tier SQL Server-based application in Azure, you can use one of the following two
programming methods:
Set up a traditional web server (IIS - Internet Information Services) in Azure and access databases in SQL Server
Implement and deploy a cloud service to Azure. Then, make sure that this cloud service can access databases in
SQL Server in Azure Virtual machines. A cloud service can include multiple web and worker roles.
The following table provides a comparison of traditional web development with Azure Cloud Services and Azure
Web Apps with respect to SQL Server in Azure Virtual Machines. The table includes Azure Web Apps as it is
possible to use SQL Server in Azure VM as a data source for Azure Web Apps via its public virtual IP address or
DNS name.
TRADITIONAL WEB
DEVELOPMENT IN AZURE WEB HOSTING WITH AZURE
VIRTUAL MACHINES CLOUD SERVICES IN AZURE WEB APPS
Application Migration Existing applications as-is. Applications need web and Existing applications as-is
from on-premises worker roles. but suited for self-contained
web applications and web
services that require quick
scalability.
Development and Visual Studio, WebMatrix, Visual Studio, Azure SDK, Visual Studio, WebMatrix,
Deployment Visual Web Developer, TFS, PowerShell. Each cloud Visual Web Developer, FTP,
WebDeploy, FTP, TFS, IIS service has two GIT, BitBucket, CodePlex,
Manager, PowerShell. environments to which you DropBox, GitHub, Mercurial,
can deploy your service TFS, Web Deploy,
package and configuration: PowerShell.
staging and production. You
can deploy a cloud service to
the staging environment to
test it before you promote it
to production.
TRADITIONAL WEB
Administration and Setup You are responsible for You are responsible for You are responsible for
administrative tasks on the administrative tasks on the administrative tasks on the
application, data, firewall application, data, firewall application and data only.
rules, virtual network, and rules, and virtual network.
operating system.
TRADITIONAL WEB
High Availability and We recommend that you Azure manages the failures High Availability is inherited
Disaster Recovery (HADR) place virtual machines in the resulting from the from Azure worker roles,
same availability set and in underlying hardware or Azure blob storage, and
the same cloud service. operating system software. Azure SQL Database. For
Keeping your VMs in the We recommend that you example, Azure Storage
same availability set allows implement multiple maintains three replicas of all
Azure to place the high instances of a web or worker blob, table, and queue data.
availability nodes into role to ensure the high At any one time, Azure SQL
separate fault domains and availability of your Database keeps three
upgrade domains. Similarly, application. For information, replicas of data running
keeping your VMs in the see Cloud Services, Virtual one primary replica and two
same cloud service enables Machines, and Virtual secondary replicas. For more
load balancing and VMs can Network Service Level information, see Azure
communicate directly with Agreement and Disaster Storage and Azure SQL
one another over the local recovery and high availability Database.
network within an Azure for Azure applications
data center. When using SQL Server in
You are responsible for Azure VM as a data source
You are responsible for backing up your own data for Azure Web Apps, keep in
implementing a high and application. mind that Azure Web Apps
availability and disaster does not support Azure
recovery solution for SQL For databases residing in a Virtual Network. In other
Server in Azure Virtual SQL Server database in an words, all connections from
Machines to avoid any Azure VM, you are Azure Web Apps to SQL
downtime. For supported responsible for Server VMs in Azure must
HADR technologies, see implementing a high go through public end
High Availability and availability and disaster points of virtual machines.
Disaster Recovery for SQL recovery solution to avoid This might cause some
Server in Azure Virtual any downtime. For limitations for high
Machines. supported HDAR availability and disaster
technologies, see High recovery scenarios. For
You are responsible for Availability and Disaster example, the client
backing up your own data Recovery for SQL Server in application on Azure Web
and application. Azure Virtual Machines. Apps connecting to SQL
Server VM with database
Azure can move your virtual SQL Server Database mirroring would not be able
machines if the host Mirroring: Use with Azure to connect to the new
machine in the data center Cloud Services (web/worker primary server as database
fails due to hardware issues. roles). SQL Server VMs and a mirroring requires that you
In addition, there could be cloud service project can be set up Azure Virtual Network
planned downtime of your in the same Azure Virtual between SQL Server host
VM when the host machine Network. If SQL Server VM is VMs in Azure. Therefore,
is updated for security or not in the same Virtual using SQL Server Database
software updates. Therefore, Network, you need to create Mirroring with Azure Web
we recommend that you a SQL Server Alias to route Apps is not supported
maintain at least two VMs in communication to the currently.
each application tier to instance of SQL Server. In
ensure the continuous addition, the alias name SQL Server AlwaysOn
availability. Azure does not must match the SQL Server Availability Groups: You
provide SLA for a single name. can set up AlwaysOn
virtual machine. For more Availability Groups when
information, see Azure using Azure Web Apps with
resiliency technical guidance. SQL Server VMs in Azure.
But you need to configure
AlwaysOn Availability Group
Listener to route the
communication to the
primary replica via public
load-balanced endpoints.
TRADITIONAL WEB
cross-premises You can use Azure Virtual You can use Azure Virtual Azure Virtual Network is
Connectivity Network to connect to on- Network to connect to on- supported. For more
premises. premises. information, see Web Apps
Virtual Network Integration.
Scalability Scale-up is available by Scale-up is available by using Scale up and down: You
increasing the virtual multiple web and worker can increase/decrease the
machine sizes or adding roles. For more information size of the instance (VM)
more disks. For more about virtual machine sizes reserved for your web site.
information about virtual for web roles and worker
machine sizes, see Virtual roles, see Configure Sizes for Scale out: You can add more
Machine Sizes for Azure. Cloud Services. reserved instances (VMs) for
your web site.
For Database Server: When using Cloud
Scale-out is available via Services, you can define You can set up AutoScale
database partitioning multiple roles to distribute on the portal as well as the
techniques and SQL Server processing and also achieve schedule times. For more
AlwaysOn Availability flexible scaling of your information, see How to
groups. application. Each cloud Scale Web Apps.
service includes one or more
For heavy read workloads, web roles and/or worker
you can use AlwaysOn roles, each with its own
Availability Groups on application files and
multiple secondary nodes as configuration. You can scale-
well as SQL Server up a cloud service by
Replication. increasing the number of
role instances (virtual
For heavy write workloads, machines) deployed for a
you can implement role and scale-down a cloud
horizontal partitioning data service by decreasing the
across multiple physical number of role instances.
servers to provide For detailed information, see
application scale-out. Azure Execution Models.
In addition, you can Scale-out is available via

implement a scale-out by built-in Azure high
using SQL Server with Data availability support through
Dependent Routing. With Cloud Services, Virtual
Data Dependent Routing Machines, and Virtual
(DDR), you need to Network Service Level
implement the partitioning Agreement and Load
mechanism in the client Balancer.
application, typically in the
business tier layer, to route For a multi-tier application,
the database requests to we recommend that you
multiple SQL Server nodes. connect web/worker roles
The business tier contains application to database
mappings to how the data is server VMs via Azure Virtual
partitioned and which node Network. In addition, Azure
contains the data. provides load balancing for
VMs in the same cloud
You can scale applications service, spreading user
that are running virtual requests across them. Virtual
machines. For more machines connected in this
information, see How to way can communicate
Scale an Application. directly with one another
over the local network within
Important Note: The an Azure data center.
AutoScale feature in Azure
allows you to automatically You can set up AutoScale
on the Azure portal as well
increase or decrease the on the Azure portal as well
TRADITIONAL WEB
Virtual Machines that are as the schedule times. For
DEVELOPMENT IN AZURE more information, see How WEB HOSTING WITH AZURE
used by your
VIRTUAL application.
MACHINES CLOUD SERVICES IN AZURE WEB APPS
This feature guarantees that to configure auto scaling for
the end-user experience is a Cloud Service in the portal.
not affected negatively
during peak periods, and
VMs are shut down when
the demand is low. Its
recommended that you do
not set the AutoScale option
for your cloud service if it
includes SQL Server VMs.
The reason is that the
AutoScale feature lets Azure
to turn on a virtual machine
when the CPU usage in that
VM is higher than some
threshold, and to turn off a
virtual machine when the
CPU usage goes lower than
it. The AutoScale feature is
useful for stateless
applications, such as web
servers, where any VM can
manage the workload
without any references to
any previous state. However,
the AutoScale feature is not
useful for stateful
applications, such as SQL
Server, where only one
instance allows writing to
the database.
For more information on choosing between these programming methods, see Azure Web Apps, Cloud Services,
and VMs: When to use which.
Next Steps
For more information on running SQL Server in Azure Virtual machines, see SQL Server on Azure Virtual Machines
Overview.

SQL

Uploaded by

Document Information

Original Title

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

SQL

Uploaded by

Copyright:

Available Formats

Table of Contents

The video covers the following areas:

00:21 What are Azure VMs?

03:30 Storage reliability and performance

05:54 High availability and SLA

07:30 Configuration support

08:32 Demo: Create a SQL Server 2016 VM

Create a new SQL VM

Option 1: Create a SQL VM with per-minute licensing

VERSION OPERATING SYSTEM EDITION

VERSION OPERATING SYSTEM EDITION

Manage your SQL VM

Free-licensed SQL Server editions

Paid SQL Server editions

SQL SERVER EDITION WORKLOAD

Web Small web sites

Standard Small to medium workloads

Enterprise Large or mission-critical workloads

Bring your own license (BYOL )

Avoid unecessary costs

Frequently Asked Questions

Select a SQL VM image from the gallery

Basics Configure basic settings

Size Choose virtual machine size

Settings Configure optional features

SQL Server settings Configure SQL server settings

Summary Review the summary

1. Configure basic settings

Select a Location for this deployment.

2. Choose virtual machine size

Choose your machine size, and then click Select.

3. Configure optional features

4. Configure SQL server settings

Azure Key Vault Integration

PARAMETER DESCRIPTION EXAMPLE

Key Vault URL The location of the key vault. https://contosokeyvault.vault.azure.net

Principal name Azure Active Directory service principal fde2b411-33d5-4e11-

Principal secret Azure Active Directory service principal 9VTJSQwzlFepD8XODnzy8n2V01Jd8d

Credential name Credential name: AKV Integration mycred1

5. Review the summary

Open the VM with Remote Desktop

Connect to SQL Server remotely

Connect to the Database Engine from another computer

Configure your subscription

Select-AzureRmSubscription -SubscriptionId xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Define image variables

$StorageName = $ResourceGroupName + "storage"

$InterfaceName = $ResourceGroupName + "ServerInterface"

Virtual machine properties

$VMName = $ResourceGroupName + "VM"

Get-AzureRmVMImageOffer -Location 'East US' -Publisher 'MicrosoftSQLServer'

Get-AzureRmVMImageSku -Location 'East US' -Publisher 'MicrosoftSQLServer' -Offer 'SQL2014SP1-WS2012R2' |

Create a resource group

New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location

Create a storage account

$StorageAccount = New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageName -SkuName

Create network resources

Execute the following cmdlet to create your virtual subnet configuration.

$SubnetConfig = New-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -AddressPrefix

Create a virtual network

$VNet = New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName -Location $Location -

Create the public IP address

Execute the following cmdlet to create your public IP address.