Category Archives: Cloud

Azure SQL Database: how to manage connectivity with vNet Service Endpoints

To have more control over accesses performed on SQL Azure Database, last month, Microsoft has publicly released the option to enable Virtual Network (vNet) Service Endpoints for SQL Database. This article will explain the working principle, with resulting benefits, and it will show its configuration.

Characteristics and principles of operation

The vNet Service Endpoints for the Azure SQL Database let you isolate the logical Microsoft SQL Servers in the cloud, guaranteeing access only from one or more subnets that are defined in their own Azure Virtual Network. This feature ensures that all traffic generated by own vNet to Azure SQL Database will always remain within the network backbone of Azure. This is a feature available in all regions of Azure and there are no additional costs for using it.

Figure 1 – Summary of architecture

On the firewall of the Azure SQL Database remains the ability to enable communication from the Azure services and to filter access based on a range of Public IP address.

Figure 2 – Azure SQL Server firewall settings

By enabling the setting 'Allow access to Azure services ' you are granted to access to SQL Server from all public IP address of Azure and from all Azure subnets, including those not of your own. Going to apply additional filters based on the public IP is difficult to manage and require the configuration of static public IP addresses on the Azure resources.

With the introduction of Virtual Network (vNet) Service Endpoints for SQL Server you can have more control over potential communications and less effort for resource management. The operating principle of the vNet Service Endpoints does not extend to the on-premises world even when there is connectivity with Azure (VPN or ExpressRoute), but to allow access from on-premises systems you must continue to use firewall rules to limit connectivity only to the public IP of your membership.

The Virtual Network (vNet) Service Endpoints are available, with the same principle of operation, also for Azure Storage and for Azure SQL Data Warehouse (currently in preview).

How to configure

Enabling vNet Service Endpoints require the activation on the subnet of the virtual network of Azure, from which you plan to connect to SQL Server, of the SQL Server Endpoint (Microsoft.SQL).

Figure 3 – Enabling SQL Server Service Endpoint on the subnet

Figure 4 – SQL Server Service Endpoint successfully enabled on the subnet

Next you must add on the SQL Database side the virtual network, with the Service Endpoint enabled , in the section Firewall and virtual networks.

Figure 5 – Added Virtual Network with Service Endpoints of SQL Server enabled

Each Virtual Network Rule is applied to Azure SQL Database server level and not at the individual database level.

This configuration means that by connecting to DB hosted by the Azure SQL Server from a machine attested on a vNet with Service Endpoints enabled, will be used as the source IP an address in the address space of the vNet. This aspect has to be considered, in existing configurations, to avoid that when you enable SQL Server Service Endpoint on the subnet, blocks access to SQL Server. For this purpose it is possible to avoid it allowing temporarily access with the setting "Allow access to Azure services", or by defining the vNet in firewall rule of SQL Server before enabling the Service Endpoint on the subnet. This requires using the flag IgnoreMissingServiceEndpoint or select the following flag present in the Azure portal:

Figure 6 – Added Virtual Network without Service Endpoints of SQL Server enabled


The Virtual Network (vNet) Service Endpoints are able to expand the virtual networks of Azure and its identity to certain Azure services, as Azure SQL Server, through a direct connection. This increases the security level of the services in the Microsoft cloud, optimize routing to access resources from the Azure vNet and lessens the management effort, all with a few easy steps.

How to create a Docker environment in Azure using VM Extension

Docker is a software platform that allows you to create, manage and execute isolated applications in containers. A container is nothing more than a methodology for creating software packages in a format that allows it to be run independently and isolated on a shared operating system. Unlike the virtual machine containers do not include a complete operating system, but only the libraries and settings needed to run the software. Therefore there are a series of advantages in terms of size, speed, portability and resource management.

Figure 1 – Diagram of containers


In the world of Microsoft Azure there are different configuration and use possibilities about Docker containers that I list synthetically:

  • VM Extension: through a specific Extension you can implement Docker inside a virtual machine.
  • Azure Container Service: deploys quickly into a cluster environment Azure Docker Swarm, DC/OS or Kubernetes ready for production. This is the most complete solution for the orchestration of containers.
  • Docker EE for Azure: is a template available on the Azure Marketplace, a collaboration between Microsoft and Docker, which makes it possible to provision a clustered Docker Enterprise Edition integration with Azure VM Scale Sets, the Azure Load balancers and the Azure Storage.
  • Rancheros: is a Linux distribution designed to run containers available as template within the Marketplace Azure Docker.
  • Web App for Containers: you have the option of using containers, making the deployment in the Azure App Service managed platform as a Web App running in a Linux environment.
  • Azure Container Instances (currently in preview): is definitely the easiest and quickest way to run a container Docker in the Azure platform, without the need to create virtual machines, ideal in scenarios where containers blocks.
  • Azure Service Fabric: supports the containers in both the Windows and Linux. The platform contains natively support for Docker Wrote (currently in preview), allowing you to orchestrate applications based on containers in the Azure Service Fabric.
  • DC/OS on Azure: This is a managed cloud service that provides an environment for the deployment of workloads in cluster using DC/OS platform (Datacenter Operating System).

All these possibilities enable, according to the needs and to the scenario that you must implement, choosing the most appropriate deployment methodology in the container for execution environment Azure Docker.

In this article we will create a Docker environment in a Virtual Machine using the Docker Extension. Starting from a virtual machine in Azure, you can add the Docker Extension which installs and configures the daemon Docker, the client Docker and Docker Wrote.

This extension is supported for the following Linux distributions:

  • Ubuntu 13 or higher.
  • CentOS 7.1 or higher.
  • Red Hat Enterprise Linux (RHEL) 7.1 or higher.
  • CoreOS 899 or higher.

Adding the extension from the Azure Portal can be done via the following steps. The section Extensions Select the virtual machine button Add:

Figure 2 – Adding Extensions to the VM from the Azure Portal


Then shows the list of Extensions available, you stand onExtension Docker and press the button Create.

Figure 3 – Selection of Extension Docker


To enable secure communication with the Docker system implemented in your Azure environment you should use certificates and keys issued by a trusted CA. If you do not have a CA to generate these certificates you can follow the instructions in section Create a CA, Server and client keys with OpenSSL present in the official documentation of Docker.


Figure 4 – Communication scheme docker by encrypted protocol TLS


The Extension wizard requires first to enter the communications port of the Engine Docker (2376 is the default port). Also the CA's certificate is requested, your Server certificate and Server Key, in base64-encoded format:

Figure 5 – Parameters required by the wizard to add the Docker VM Extension


Adding the Extension Docker takes several minutes at the end of which the virtual machine will be installing the latest stable version of Docker Engine and daemon Docker will listen on the specified port using certificates entered in the wizard.

Figure 6 – Details of the Extension Docker


In case you need to allow Docker communication from outside the vNet where is attested the VM with Docker you must configure appropriate rules in Network Security Group used:

Figure 7 – Configuration example NSG to allow communication Docker (door 2376)


At this point the Docker environment is ready to be used and from a remote client you can start the communication:

Figure 8 – Docker command run from a remote client to retrieve information



The Azure Docker VM extension is ideal to implement easily, in a reliably and securely mode, a dev or production Docker environment on a single virtual machine. Microsoft Azure offers a wide range of possibilities in the choice of implementation related to the Docker platform, with a lot of flexibility by letting you choose the most appropriate solution for your needs.

Azure Multi-Factor Authentication: Introduction to Solution

To help secure access to critical data and applications may be necessary to provide multifactor authentication which generally requires the use of at least two of the following test methods:


  • Something you know (typically a password).
  • Something that you own (a unique device and not easily duplicable, such as a phone).
  • A biometric recognition system that aims to identify a person based on one or more biological or behavioral characteristics (Biometrics).


Microsoft allows you to adopt a two-factor authentication solution using theAzure Multi-Factor Authentication (MFA) which provides for the adoption of a second method of verifying during the authentication process. Using this solution can be configured the following additional authentication factors:


  • Phone call: a call is made to the phone registered to users. In this case the user will be prompted to answer the call and to verify that you can access by pressing the button # or entering a PIN code.
  • Text message (SMS): is sent to the user's mobile phone an SMS that contains a pin code of 6 figures who must be entered during the authentication process.
  • Notified by Mobile App: the user's smartphone is sent through Mobile App a challenge that must be approved by the user to complete the authentication process.
  • Verification code via Mobile App: in this user's smartphone Mobile App generates a code of 6 digits each 30 seconds. The user would then put the latest code at the time that authenticates.
  • Party OATH token: There is the possibility to configure Azure Multi-Factor Authentication to accept verification methods provided by third-party solution.


The Azure Multi-Factor Authentication (MFA) provides for two possible deployment models:


  • MFA as a solution entirely in the Cloud.
  • MFA system installed and configured on-premises systems.


To locate the most appropriate deployment model you need to consider several aspects: What I'm putting in security, where are the users who need access to your solution and what features I really need.


What you are trying to protect?

This is the first question you should ask yourself whose answer we can already point to a specific deployment template. If indeed there is a need to enable the dual factor authentication for IIS applications that are not published by Azure App Proxy or remote access solutions (VPN or Remote Desktop Gateway) You must use the server Azure MFA implemented on-premises systems.


Figure 1 – What is secured by MFA


Where the users are located?

Another important aspect to consider is where the users are located on the basis of the Identity model adopted, come mostra la figura 2.


Figure 2 – Location of users


What features are needed?

Depending on the type of deployment selected (MFA in the cloud or local MFA) different capabilities that we could opt for a choice rather than another, come mostra la figura 3.


Figure 3 Available in two models – MFA


Requirements for the use of MFA

In order to use the Azure Multi-Factor Authentication (MFA) You must have access to a subscription Azure. If you want to test your service you can possibly use a trial subscription of Azure.


The hardware requirements as regards Multi-Factor Authentication Server Azure are minimal (200 MB disk space and 1 GB RAM), While the following software features:


  • Operating System: Windows Server 2008 R2 or higher
  • Microsoft .NET 4.0 Framework
  • IIS 7.0 or higher if you want to install the User Portal or the Web Service SDK


Each server MFA must be able to communicate on port 443 outbound to the following web address:


  • HTTPS://
  • HTTPS://
  • HTTPS://


Also if there are firewall policy to block outbound to the door 443 You must open the IP address range are documented in section "Azure Multi-Factor Authentication Server firewall requirements"the Microsoft's official documentation.


Azure Multi-Factor Authentication in the cloud

Enabling MFA cloud scenario is very simple and is done per user. To do so you need to access the service Azure Active Directory, figura 4, from the Azure Portal:


Figure 4 – Step 1: enabling MFA to the cloud


After selecting the Directory, in the "Users and groups" select "Multi-Factor Authentication":


Figure 5 – Step 2: enabling MFA to the cloud


You will be redirected to another website where selecting the specific user, figura 6, You can enable the MFA:


Figure 6 – Step 3: enabling MFA to the cloud


At this point the user is mail-enabled MFA. The same thing can also be done by selecting multiple users simultaneously and by the same portal you can configure various settings of Azure Multi-Factor Authentication. For more details about I invite you to consult Microsoft's official documentation.


The same thing can be accomplished by using the cmdlets PowerShell for Azure to which allow us to easily make enabling MFA to more users with just a few lines of code, as shown in the following example:


$users = “”,””,””

foreach ($user $users)


$St = New-Object-TypeName Microsoft StrongAuthenticationRequirement. Online. Administration.

$St. Relyingparty = “*”

$St. State = "Enabled"

$is = @($St)

$User-StrongAuthenticationRequirements-MsolUser-UserPrincipalName $sta set



Azure Multi-Factor Authentication on-premises

On-premises deployment of Azure Multi-Factor Authentication Server requires you to download the setup installer direct from the Azure Portal. If you want to dismiss Azure Multi-Factor Authentication as a standalone service with user authentication and billing options you need to create a new Classic Azure Portal Multi-Factor Auth Provider (This feature will soon be available on the new Azure Portal).


Figure 7 — Creating new Multi-Factor Auth Providers


By selecting the button Manage you will be redirected towards the Azure Portal Multi-Factor Authentication, figura 8, from where can I donwload the setup and build the service activation credentials.


Figure 8 – Multi-Factor Authentication Server downloads and generation credentials


If you want to use the bundled license to Enterprise Mobility Suite, Azure to Premium or Enterprise Cloud Suite is not necessary to create a Multi-Factor Auth Provider but simply log into the Azure Portal Multi-Factor Authentication to directly download the setup.


After coming into possession of the setup you can install the Azure MFA Server. During setup you will be asked only the installation path, figura 9.


Figure 9 – Setup Azure MFA Server


Figure 10 – Setup Azure MFA Server


At this point you must run on Multi-Factor Authentication Server you just installed that will guide us in the activation process.


Figure 11 – Applying Multi-Factor Authentication Server


Figure 12 – Step 1: How to activate Multi-Factor Authentication Server


On the following screen you must enter the logon credentials that are generated by the Azure Portal Multi-Factor Authentication (see Figure 8).


Figure 13 – Step 2: How to activate Multi-Factor Authentication Server


After completing the first server Configuration Wizard cannot start Azure MFA, figura 14, to enable replication across multiple servers highly available service and configure the MFA Azure.


Figure 14 Multi-server MFA – Configuration Wizard


In the scenario where the Multi-Factor Authentication Server is enabled on multiple systems, the servers communicate with each other via RPC calls MFA Azure and to make sure that everything happens safely must authenticate with each other. This authentication process can occur either through specific security group membership in Active Directory (named Phone Factor Admins) is through the use of SSL certificates.


Now that you have configured the server Azure MFA there is the ability to easily import users from Active Directory, figura 15, and enable the desired authentication dual factor.


Figure 15 -Import users from Active Directory


In the scenario of use of Azure Multi-Factor Authentication (MFA) Server is good to specify that user data is saved on-premises systems and no data is stored permanently on the cloud. In fact, when a user places the process of multi-factor authentication the server Azure MFA sends the following data to the Azure Cloud service MFA to verify and reporting purposes:


  • Unique ID of the user (username or internal MFA server ID)
  • Name and surname (Optional)
  • Email Address (Optional)
  • Phone number (in the case of a telephone call or send SMS)
  • Token device (When using authentication via mobile app)
  • Authentication method
  • Authentication result
  • Name and IP address of the server Azure MFA
  • Client IP (If available)
  • Result verification (success or denied) and motivation if deny


In addition to targeted different import users from Active Directory on which you want to enable the dual factor authentication you can integrate with the Active Directory Directory service server Azure MFA and set up a targeted and scheduled import of users according to certain criteria. For details please visit the official documentation Directory integration between Active Directory and server Azure MFA.


Solution Licensing models

Azure Multi-Factor Authentication is available as standalone service, with user authentication and billing options, or in bundle with Azure Ad Premium, Enterprise Mobility Suite and Enterprise Cloud Suite. Azure Multi-Factor Authentication is available through a Microsoft Enterprise agreement, the Open Volume License program, the program Cloud Solution Provider and a Direct contract, as annual per user model. The service is also available with a model based on consumption per-user and per-authentication, billed every month according to the Azure monetary commitmen.


For more information on costs of the solution you can consult the following document: Prices of Multi-Factor Authentication.



Azure Multi-Factor Authentication is a simple solution to use, scalable and reliable that offers the possibility of introducing a second method of validation so that users are able to access more securely to your data and applications, both present on-premises cloud environments. For those interested in trying out the service can easily activate a subscription Azure for free by going to Free Trial of Azure.

Windows Server 2016: Configuring the Failover Cluster Witness in the Cloud

In the article Windows Server 2016: What's New in Failover Clustering all were thorough main innovations introduced with Windows Server 2016 in the failover clustering. In this article we will detail the configuration of the cluster witness in Microsoft Azure cloud, analyzing the possible scenarios and the benefits of this new feature.


Possible scenarios supported by Witness Cloud

Among the supported scenarios that lend themselves more to this type of configuration are:

  • Multi-site stretched cluster.
  • Failover Cluster that does not require shared storage (SQL Always On, Exchange DAGs, etc).
  • Failover Cluster composed of nodes hosted on Microsoft Azure, other public or private cloud.
  • Scale-out type cluster File Server.
  • Cluster made actually small branch-office.


Cloud Witness configuration

We begin by specifying that a requirement to configure the cluster to use the Cloud Witness is that all nodes that make up the cluster has an internet access to Azure. Cloud Witness in fact uses the HTTPS protocol (door 443) to establish a connection with the Azure blob Storage Service Account.


Configuring the subscription requires a Witness Azure Cloud in which to configure a Storage Account that will be used as Witness and Cloud on which are written the blob file used for the arbitration of the cluster.


From the Azure portal you must create a storage account type Genaral Purpose. For this purpose is incorrect, create it with a performance level standard as they are not necessary for high performance that is provided with the use of SSDS. After selecting the most suitable location and replication policies you can proceed with the process of creating.


Figure 1 – Storage Account creation


After you create your storage account you must retrieve its required access key for authentication, which will be required in configuration steps.


Figure 2 – Account Storage access keys


At this point you can change the settings of the cluster Quorum from Failover Cluster Manager by following the steps below:


Figure 3 – Failover Cluster Quorum Settings Configuration Manager


Figure 4 – Witness Quorum selection


Figure 5 – Selection of Cloud Witness


Figure 6 – Storage Account name and access key


After successful configuration will be present among the various cluster resources also Cloud Witness:


Figure 7 – Cloud Resource Witness


Azure Storage Account is created a container named msft-cloud-witness, within which there will be a single blob file that has as its name the ID I joined the cluster. This means that you can use the same Microsoft Azure Storage Account to set up the different Cloud cluster Witness, where there will be a blob file for each cluster.


Figure 8 – Container inside of the Storage Account and its contents


Advantages of using Cloud Witness

The use of Cloud Witness gets the following benefits:

  • Eliminates the need to have an additional separate data center for certain cluster configurations by using Microsoft Azure.
  • Cancels the administrative effort required to maintain an additional virtual machine cluster witness role.
  • Given the small amount of data written to the Storage Account service charge is ridiculous.
  • The same Microsoft Azure Storage Account can be used as a witness to different clusters.



In the Windows Server failover cluster 2016 proves ready for integration with the cloud. With the introduction of cloud cluster systems more easily is possible Witness substantially reducing overall costs for implementing, the management effort and increasing flexibility of architecture cluster.

Windows Server 2016: What's New in Failover Clustering

Very frequently in order to ensure the high availability and business continuity for critical applications and services you need to implement a Failover Cluster running Microsoft. In this article we'll delve into the main innovations introduced with Windows Server 2016 in the failover clustering and analyse the advantages in adopting the latest technology.

Cluster Operating System Rolling Upgrade

In Windows Server 2016 introduces an important feature that allows you to upgrade the nodes of a Hyper-V cluster or Scale-Out File Server from Windows Server 2012 R2 to Windows Server 2016 without any disruption and avoiding to stop it hosted workloads.

The upgrade process involves these steps:

  • Put the node that you want to update paused and move all the virtual machine or the other workloads on the other nodes in the cluster
  • Remove the node from the cluster and perform a clean installation of Windows Server 2016
  • Add the node Windows Server 2016 the existing cluster. By this time the Mixed mode cluster with both Windows Server nodes 2012 R2 and nodes Windows Server 2016. In this connection it is well to specify that the cluster will continue to provide the services in Windows Server 2012 R2 and will not be yet available features introduced in Windows Server 2016. At this stage you can add and remove nodes is Windows Server 2012 R2 and nodes Windows Server 2016
  • Upgrading of all the cluster nodes in the same way as previously described
  • Only when all cluster nodes have been upgraded to Windows Server 2016 You can change the functional level to Windows Server cluster 2016. This operation is not reversible and to complete it you must use the PowerShell Update-ClusterFunctionalLevel. After you run this command you can reap all the benefits introduced in Windows Server 2016 stated below

Cloud Witness

Windows Server 2016 introduces the ability to configure the cluster witness directly in Microsoft Azure cloud. Cloud Witness, just like the tall types of witness, will provide a vote by participating in the calculation of quorum arbitrary.

Figure 1 – Cloud Witness in Failover Cluster Manager

Configuring the Cloud Witness involves two simple steps:

  • Creating a subscription to an Azure Storage Account that you will use Azure Cloud Witness
  • Configuring the Cloud Witness in one of the following ways


Failover Cluster Manager

Figure 2 – Cloud Witness Configuration Step 1

Figure 3 – Cloud Witness Configuration Step 2


Figure 4 – Cloud Witness Configuration Step 3

The use of Cloud Witness gets the following benefits:

  • Leverages Microsoft Azure eliminating the need for an additional separate data center for certain cluster configurations
  • Working directly with a Microsoft Azure Blob Storage canceling this way the administrative effort required to keep a virtual machine in a public cloud
  • The same Microsoft Azure Storage Account can be used for multiple clusters
  • View the mole little data that is written to the Storage Account service charge is ridiculous

Site-Aware Failover Clusters

Windows Server 2016 introduces the concept of clustered failover site-aware and is able to gather groups of nodes in a cluster based on the geographical location configuration stretched (site). During the lifetime of a cluster site-aware placement policies, the heartbeat between nodes and failover operations and calculation of the quorum are designed and improved for this particular cluster environment configuration. For more details about I invite you to consult the article Site-aware Failover Clusters in Windows Server 2016.

Multi-domain and workgroup Cluster

In Windows Server 2012 R2 and in previous versions of Windows, all nodes in a cluster must necessarily belong to the same Active Directory domain. With Windows Server 2016 removes these barriers and provides the ability to create a Failover Cluster without Active Directory dependencies.

In Windows Server 2016 supports the following configurations:

  • Single-domain Cluster: clusters where all nodes are in the same domain
  • Multi-domain Cluster: cluster composed of nodes joined to different Active Directory domains
  • Workgroup Cluster: cluster with nodes in WFWG (not joined to a domain)

In this regard it is good to specify what are the supported workloads and its limitations to Multi-domain and Workgroup cluster:

Cluster Workload



Sql Server


Recommended SQL Server authentication.

File Server

Supported, but not recommended

Kerberos authentication (not available in these environments) is the recommended authentication protocol Server Message Block traffic (SMB).


Supported, but not recommended

Does not support Live Migration, but only the Quick Migration.

Message Queuing (MSMQ)

Not supported

Message Queuing save property in AD DS.

Diagnostic in Failover Clustering

In Windows Server 2016 the following innovations have been introduced to facilitate troubleshooting if problems arise cluster environment:

SMB Multichannel and Multi-NIC Cluster Network

In Windows Server 2016 There are several new features in the network regarding the clustered environment that help ease configuration and get better performance.

The main benefits introduced in Windows Server 2016 can be summarised in the following points:

  • SMB Multichannel is enabled by default
  • Failover cluster can recognize automatically the NIC attested on the same subnet as the same switch
  • A single resource IP Address is configured for each Access Point Cluster (Zip code) Network Name (NN)
  • The network with Link-Local IPv6 addresses only (FE80) are recognized as private networks (cluster only)
  • The cluster validation does not report more warning messages in case there are more NIC attested on the same subnet

For more information I refer you to the Microsoft documentation: Simplified SMB Multichannel and Multi-NIC Cluster Networks.


Windows Server 2016 introduces major changes in the Failover Clustering making the solution more flexible and opening up new configuration scenarios. Furthermore the upgrade process allows us to easily update existing clusters to take advantage of all the benefits introduced by Windows Server 2016 for different workloads.