Recent Updates to setting up SQL Server Availability Groups in Azure VM with AAD Domain Services

First published on MSDN on Oct 30, 2017

Authored by Rajesh Setlem

Reviewed by: Dimitri Furman, Kun Cheng

This blog is an extension to the


that was published in February 2017 . In these eight months there has been some notable improvements to AAD Domain Services (AAD DS) and Azure Virtual Network (VNET) capabilities. Now, it’s even more easier and convenient to leverage AAD DS for setting up SQL Server Availability Groups (AG) in Azure VMs.

As a recap, following scenarios were covered in the blog linked above:

Scenario 1:

Enabling AAD Domain Services in Classic Virtual Network, deploying two SQL Server 2016 Classic VMs (Windows Server 2012), and then setting up AG

Scenario 2:

Leveraging AAD Domain Services enabled in Classic Virtual Network from an ARM virtual network by adding an ARM based SQL Server 2016 VM as a replica to the existing AG.

Summary of recent improvements to AAD DS and new VNET capability:

  1. AAD DS is generally available in many Azure regions now. Check


    to find out availability by region (AAD DS is under Security + Identity).

  2. General availability of AAD DS support for Azure Resource Manager (ARM) based VNET. This was eagerly expected by customers. You can read more about it



  3. General availability of AAD DS in the new Azure Portal (

  4. Public preview for Global VNET Peering. VNET peering is a powerful feature allowing you to peer virtual networks in Azure. Peering VNETs in the same region is generally available, and the ability to peer VNETs across different Azure regions is in preview. You can read more about it



With these improvements, scenarios covered in previous blog can be done in a different way. A new scenario is enabled as well.

Scenario 1:

This can be implemented in ARM only mode with no need to create any classic resources. Good news is it can be done in new Azure Portal (

Scenario 2:

Since AAD DS can be enabled on ARM VNET now, you can peer it with another ARM VNET, or with a Classic VNET if there is a specific need.

Scenario 3:

This is a new scenario possible with Global VNET Peering to connect an Azure region designated as your DR with your primary Azure region. Asynchronous AG replica in your Azure DR region would connect to primary replica over VNET Peering and provide failover capabilities in the event of disaster. We tried this setup and it works just as expected.

Go ahead and explore these new capabilities and scenarios and let us know if you have any questions or comments.

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.