Exchange Server: Using a Microsoft Azure VM as a DAG witness server

Using a Microsoft Azure virtual machine (VM) as a database availability group (DAG) witness server requires three separate physical locations:

• Two datacenters for mailbox servers.
• A third location for the DAG witness server.

Organizations with only two physical locations now can also take advantage of automatic datacenter failover by using a Microsoft Azure VM to act as the DAG's witness server. This article focuses on the placement of the DAG witness on Microsoft Azure and assumes that both of the following statements are true:

• You're familiar with site resilience concepts.
• You have a fully functional DAG infrastructure spanning two datacenters.

If you don't already have your DAG infrastructure configured, we recommend that you first review the following articles:

• High availability and site resilience
• Database availability groups
• Plan for high availability and site resilience

Changes to Microsoft Azure

This configuration requires a multi-site VPN. It has always been possible to connect your organization's network to Microsoft Azure using a site-to-site VPN connection. However, in the past, Azure supported only a single site-to-site VPN. Since configuring a DAG and its witness across three datacenters required multiple site-to-site VPNs, placement of the DAG witness on an Azure VM wasn't initially possible.

In June 2014, Microsoft Azure introduced multi-site VPN support, which enabled organizations to connect multiple datacenters to the same Azure virtual network. This change also made it possible for organizations with two datacenters to use Microsoft Azure as a third location to place their DAG witness servers. To learn more about the multi-site VPN feature in Azure, see Configure a Multi-Site VPN.

Microsoft Azure file server witness

The following diagram is an overview of using a Microsoft Azure file server VM as a DAG witness. You need an Azure virtual network, a multi-site VPN that connects your datacenters to your Azure virtual network, and a domain controller and a file server deployed on Azure virtual machines.

DAG witness server on Microsoft Azure

The first thing you need to do in order to use a Microsoft Azure VM for your DAG witness is to get a subscription. See How to buy Azure for the best way to acquire an Azure subscription.

After you have your Azure subscription, you need to do the following steps in order:

1. Prepare the Microsoft Azure virtual network
2. Configure a multi-site VPN
3. Configure virtual machines
4. Configure the DAG witness

Prerequisites

• Two datacenters that are capable of supporting an Exchange high availability and site resilience deployment. See Plan for high availability and site resilience for more information.

• A public IP address that isn't behind NAT for the VPN gateways in each site.

• A VPN device in each site that is compatible with Microsoft Azure. For more information, see About VPN Devices for Virtual Network.

• Familiarity with DAG concepts and management.

• Familiarity with Windows PowerShell.

Phase 1: Prepare the Microsoft Azure virtual network

Configuring the Microsoft Azure network is the most crucial part of the deployment process. At the end of this phase, you get a fully functional Azure virtual network that's connected to your two datacenters via a multi-site VPN.

Register DNS servers

Because this configuration requires name resolution between the on-premises servers and Azure VMs, you need to configure Azure to use your own DNS servers. Name resolution for resources in Azure virtual networks article provides an overview of name resolution in Azure.

Do the following to register your DNS servers:

1. In the Azure portal, go to networks, and then select NEW.

2. Select NETWORK SERVICES > VIRTUAL NETWORK > REGISTER DNS SERVER.

3. Type the name and IP address for your DNS server. The name specified here's a logical name used in the management portal and doesn't have to match the actual name of your DNS server.

4. Repeat steps 1 through 3 for any other DNS servers you want to add.

   Note

   The DNS servers you register are not used in a round robin fashion. Azure VMs will use the first DNS server listed and will only use any additional servers if the first one is not available.

5. Repeat steps 1 through 3 to add the IP address to use for the domain controller you deploy on Microsoft Azure.

Create local (on-premises) network objects in Azure

Next, do the following to create logical network objects that represent your datacenters in Microsoft Azure:

1. In the Azure portal, and then go to networks, and then select NEW.

2. Select NETWORK SERVICES > VIRTUAL NETWORK > ADD LOCAL NETWORK.

3. Type the name for your first datacenter site and the IP address of the VPN device on that site. This IP address must be a static public IP address that isn't behind NAT.

4. On the next screen, specify the IP subnets for your first site.

5. Repeat steps 1 through 4 for your second site.

Create the Azure virtual network

Now, do the following steps to create an Azure virtual network that's used by the VMs:

1. In the Azure portal, go to networks, and then select NEW.

2. Select NETWORK SERVICES > VIRTUAL NETWORK > CUSTOM CREATE.

3. On the Virtual Network Details page, specify a name for the virtual network, and select a geographic location for the network.

4. In the DNS Servers and VPN Connectivity page, verify that the DNS servers you previously registered are listed as the DNS servers.

5. Select the Configure a site-to-site VPN check box under SITE-TO-SITE CONNECTIVITY.

   Important

   Do not select Use ExpressRoute because this will prevent the necessary configuration changes required to set up a multi-site VPN.

6. Under LOCAL NETWORK, select one of the two on-premises networks you configured.

7. In the Virtual Network Address Spaces page, specify the IP address range to use for your Azure virtual network.

Checkpoint: Review the network configuration

At this point, when you go to networks, you should see the virtual network you configured under VIRTUAL NETWORKS, your local sites under LOCAL NETWORKS, and your registered DNS servers under DNS SERVERS.

Phase 2: Configure a multi-site VPN

Use the following steps to establish the VPN gateways to your on-premises sites:

1. Establish a VPN gateway to one of your sites by using the Azure portal.
2. Export the virtual network configuration settings.
3. Modify the configuration file for multi-site VPN.
4. Import the updated Azure network configuration.
5. Record the Azure gateway IP address and preshared keys.
6. Configure on-premises VPN devices.

For more information about configuring a multi-site VPN, see Configure a Multi-Site VPN.

Establish a VPN gateway to your first site

When you create your virtual gateway, you already specified that it's connected to your first on-premises site. When you go into the virtual network dashboard, you see that the gateway hasn't been created.

To establish the VPN gateway on the Azure side, see VPN Gateway.

Export virtual network configuration settings

The Azure management portal doesn't currently allow you to configure a multi-site VPN. For this configuration, you need to export the virtual network configuration settings to an XML file and then modify that file. Follow the instructions at Export Virtual Network Settings to a Network Configuration File to export your settings.

Modify the network configuration settings for the multi-site VPN

Open the file you exported in any XML editor. The gateway connections to your on-premises sites are listed in the "ConnectionsToLocalNetwork" section. Search for that term in the XML file to locate the section. This section in the configuration file looks like the following example (the example site name you created for your local site is "Site A").

<ConnectionsToLocalNetwork>
    <LocalNetworkSiteRef name="Site A">
        <Connection type="IPsec" />
</LocalNetworkSiteRef>

To configure your second site, add another "LocalNetworkSiteRef" section under the "ConnectionsToLocalNetwork" section. The section in the updated configuration file looks like the following example (the example site name for your second local site is "Site B").

<ConnectionsToLocalNetwork>
    <LocalNetworkSiteRef name="Site A">
        <Connection type="IPsec" />
    <LocalNetworkSiteRef name="Site B">
        <Connection type="IPsec" />
</LocalNetworkSiteRef>

Save the updated configuration settings file.

Import virtual network configuration settings

The second site reference you added to the configuration file triggers Microsoft Azure to create a new tunnel. Import the updated file using the instructions in Create a virtual network (classic) by using the Azure portal. After you complete the import, the virtual network dashboard will show the gateway connections to both of your local sites.

Record the Azure gateway IP address and preshared keys

After the new network configuration settings are imported, the virtual network dashboard will display the IP address for the Azure gateway. VPN devices on both both of your sites connect to this IP address. Record this IP address for reference.

You also need to get the preshared IPsec/IKE keys for each tunnel that was created. You use these keys and the Azure gateway IP address to configure your on-premises VPN devices.

You need to use PowerShell to get the preshared keys. If you aren't familiar with using PowerShell to manage Azure, see Azure PowerShell.

Use the Get-AzureVNetGatewayKey cmdlet to extract the preshared keys. Run this cmdlet once for each tunnel. The following example shows the commands you need to run to extract the keys for tunnels between the virtual network "Azure Site" and sites "Site A" and "Site B." In this example, the outputs are saved into separate files. Alternatively, you can pipeline these keys to other PowerShell cmdlets or use them in a script.

Get-AzureVNETGatewayKey -VNetName "Azure Site" -LocalNetworkSiteName "Site A" | Set-Content -Path C:\Keys\KeysForTunnelToSiteA.txt
Get-AzureVNETGatewayKey -VNetName "Azure Site" -LocalNetworkSiteName "Site B" | Set-Content -Path C:\Keys\KeysForTunnelToSiteB.txt

Configure on-premises VPN devices

Microsoft Azure provides VPN device configuration scripts for supported VPN devices. Select the Download VPN Device Script link on the virtual network dashboard for the appropriate script for your VPN devices.

The script you download has the configuration setting for the first site that you configured when you set up your virtual network, and can be used as is to configure the VPN device for that site. For example, if you specified Site A as the LOCAL NETWORK when you created your virtual network, the VPN device script can be used for Site A. However, you need to modify it to configure the VPN device for Site B. Specifically, you need to update the preshared key to match the key for the second site.

For example, if you're using a Routing and Remote Access Service (RRAS) VPN device for your sites, you need to:

1. Open the configuration script in any text editor.

2. Find the #Add S2S VPN interface section.

3. Find the Add-VpnS2SInterface command in this section. Verify that the value for the SharedSecret parameter matches the preshared key for the site for which you're configuring the VPN device.

Other devices might require more verifications. For example, the configuration scripts for Cisco devices set ACL rules by using the local IP address ranges. You need to review and verify all references to the local site in the configuration script before you use it.

Checkpoint: Review the VPN status

At this point, both of your sites are connected to your Azure virtual network through the VPN gateways. You can validate the status of the multi-site VPN by running the following command in PowerShell.

Get-AzureVnetConnection -VNetName "Azure Site" | Format-Table LocalNetworkSiteName, ConnectivityState

If both tunnels are up and running, the output of this command looks like the following example.

LocalNetworkSiteName    ConnectivityState
--------------------    -----------------
Site A                  Connected
Site B                  Connected

You can also verify connectivity by viewing the virtual network dashboard in the Azure management portal. The STATUS value for both sites shows as Connected.

Phase 3: Configure virtual machines

You need to create a minimum of two virtual machines in Microsoft Azure for this deployment: a domain controller and a file server to serve as the DAG witness.

1. Create virtual machines for your domain controller and your file server using the instructions in Create a Virtual Machine Running Windows. Make sure that you select the virtual network you created for REGION/AFFINITY GROUP/VIRTUAL NETWORK when specifying the settings of your virtual machines.

2. Specify preferred IP addresses for both the domain controller and the file server using Azure PowerShell. When you specify a preferred IP address for a VM, it needs to be updated, which requires restarting the VM. The following example sets the IP addresses for Azure-DC and Azure-FSW to 10.0.0.10 and 10.0.0.11 respectively.

   Get-AzureVM Azure-DC | Set-AzureStaticVNetIP -IPAddress 10.0.0.10 | Update-AzureVM
   

   Get-AzureVM Azure-FSW | Set-AzureStaticVNetIP -IPAddress 10.0.0.11 | Update-AzureVM
   

   Note

   A VM with a preferred IP address will attempt to use that address. However, if that address has been assigned to a different VM, the VM with the preferred IP address configuration will not start. To avoid this situation, make sure that the IP address you use isn't assigned to another VM.

3. Provision the domain controller VM on Azure using the standards used by your organization.

4. Prepare the file server with the prerequisites for an Exchange DAG witness:

   1. Add the File Server role using the Add Roles and Features Wizard or the Install-WindowsFeature cmdlet.

   2. Add the Exchange Trusted Subsystems universal security group to the Local Administrators group.

Checkpoint: Review virtual machine status

At this point, your virtual machines should be up and running and should be able to communicate with servers in both of your on-premises datacenters:

• Verify that your domain controller in Azure is replicating with your on-premises domain controllers.

• Verify that you can reach the file server on Azure by name and establish an SMB connection from your Exchange servers.

• Verify that you can reach your Exchange servers by name from the file server on Azure.

Phase 4: Configure the DAG witness

Finally, you need to configure your DAG to use the new witness server. By default, Exchange uses the C:\DAGFileShareWitnesses as the file share witness path on your witness server. If you're using a custom file path, you should also update the witness directory for the specific share.

1. Connect to Exchange Management Shell.

2. Run the following command to configure the witness server for your DAGs.

   Set-DatabaseAvailabilityGroup -Identity DAG1 -WitnessServer Azure-FSW
   

See the following articles for more information:

Configure database availability group properties.

Set-DatabaseAvailabilityGroup.

Checkpoint: Validate the DAG file share witness

At this point, your DAG is configured to use the file server on Azure as your DAG witness. Do the following steps to validate your configuration:

1. Validate the DAG configuration by running the following command.

   Get-DatabaseAvailabilityGroup -Identity DAG1 -Status | Format-List Name, WitnessServer, WitnessDirectory, WitnessShareInUse
   

   Verify that the WitnessServer parameter is set to the file server on Azure, the WitnessDirectory parameter is set to the correct path, and the WitnessShareInUse parameter shows Primary.

2. If the DAG has an even number of nodes, the file share witness is configured. Validate the file share witness setting in cluster properties by running the following command. The value for the SharePath parameter should point to the file server and display the correct path.

   Get-ClusterResource -Cluster MBX1 | Get-ClusterParameter | Format-List
   

3. Next, verify the status of the "File Share Witness" cluster resource by running the following command. The State of the cluster resource should display Online.

   Get-ClusterResource -Cluster MBX1
   

4. Lastly, verify that the share is successfully created on the file server by reviewing the folder in File Explorer and the shares in Server Manager.