Share via


Hybrid IT: Microsoft Dynamics CRM Disaster Recovery (DR) in Azure IaaS – POC

Microsoft Dynamics CRM announced support for CRM deployment on Azure IaaS Virtual Machines. Here is the post on Microsoft Dynamics blog Cloud Certification now available for Microsoft Dynamics CRM. Reading this, I got the idea of spanning an On-Premise CRM deployment to Azure IaaS VMs.

What sounds interesting to me is preparing a CRM DR (Disaster Recovery) environment in Azure IaaS. An extension of CRM On-Premise deployment by adding replica domain controller(s) (DC), additional CRM Server(s) in same deployment and SQL AlwaysOn Availability Group (AG) replica node. After a few days spent playing with lab environment and reusing some of the learnings from my previous POC attempt Hybrid IT: SQL Always on Availability Group Replica Node in Azure IaaS, I could get a Hybrid CRM environment to usable state. Hybrid because out two CRM servers one is On-Premise Hyper-V VM and other is Azure IaaS VM, same way there is an additional domain controller and one of SQL AG replica node residing on Azure IaaS VMs.

Here is a diagram of the topology I planned and configured. The On-Premise environment running completely on Hyper-V, Azure VMs are under typical Azure subscription. RRAS server is configured as gateway for On-Premise systems and IPSec VPN tunnel connects On-Premise VPN device (RRAS Server) with the Azure gateway.

 

Figure 1 Hybrid Dynamics CRM Deployment

 

Configuring On-Premise part of Deployment:

Primary milestone of the project is preparing and configuring On-Premise side of the deployment. Comprising of five (5) virtual machines. A domain controller, CRM server, RRAS server for sit-to-site VPN and two SQL Nodes. Here is an outline of the steps to get the On-Premise infrastructure working.

  • Setup Active Directory domain by creating first domain controller.

  • Setup RRAS server- Here is the document describing Site-to-Site VPN configuration steps in detail.

  • Setup SQL AlwaysOn Availability Group with 2 On-Premise replicas. There are multiple resources available with focus on different aspects of the process. This is the document which closely resembles configuration approach I followed. Closely because, I skipped Availability Group Listener creation and I am using newer versions of OS, SQL then those referred in this document.

Additional Domain Controller on Azure VM:

With Site-to-Site VPN in action, Azure IaaS is visible as an extension of Hyper-V virtual network. Depending on Windows Firewall configuration, one can verify/test connectivity by pinging VM on Azure from On-Premise VM. After this connectivity is established, its matter telling your AD Domain about this new site from Sites and Service. Post this step an Azure VM can be promoted as an additional domain controller. Detailed steps are outlined in this Azure documentation.

SQL AlwaysOn Replica in Azure:

SQL AlwaysOn offers a neat feature, Add Azure Replica Wizard. This nifty wizard takes away a lot of ground work required for preparing an Azure VM to be an AlwaysOn Replica. It takes care of creating a VM, adding it to domain, Failover Cluster and finally to AlwaysOn Availability Group. Here is a blog post describing requirements and a good usage walkthrough of Add Azure Replica Wizard. This document doesn’t talk about SQL Availability Group Listener but below is another good resource that well describes Listener configuration. Document below is using the Add Azure Replica Wizard for identical purpose as my configuration scenario including pointers to Listener configuration steps.

Extend on-premises AlwaysOn Availability Groups to Azure - https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-extend-on-premises-alwayson-availability-groups/.

Add Azure Replica Wizard preforms multiple stages of the configuration. Depending on the environment, there are possibilities of exceptions at some stage. I would refer blog post to get an idea of known issues with the Add Azure Replica Wizard.

 I suggest installing latest service pack and cumulative updates for SQL Server. Not just SQL Server this rule applies for any software you use. This takes out chances of running into issues those are already addressed by released fixes.

SQL AlwaysOn Listener:

Next is the AlwaysOn Listener configuration. I followed below document to create/configure AlwaysOn Listener for my Hybrid AlwaysOn Availability Group.

Configure an ILB listener for AlwaysOn Availability Groups in Azure - https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-configure-ilb-alwayson-availability-group-listener/

This document covers good details for you to follow through. Alternatively, you can choose to use this ready script provided by SQL AlwaysOn team. I chose not use the ready script but walked through steps to create ILB Listener. How clients connect to the AlwaysOn Listener and how to control some of the behaviors is well described here. Refer to “MultiSubnetFailover Keyword and Associated Features” section for relevant information.

Dynamics CRM Servers:

Hybrid SQL Availability Group is functional and has replicas across sites, On-Premise and Azure IaaS. Last phase of the project is installing and configuring CRM servers. First step of this last phase is to bring up two web servers to host CRM application on both sites, one is Azure IaaS VM and other is On-Premise Hyper-V VM. CRM server setup remains same as a typical On-Premise environment. Install first CRM server creating a new CRM deployment pointing to standalone SQL Server. First I installed CRM On-Premise server pointing to On-Premise SQL node 1. Yes, at this stage we won’t tell CRM about the SQL High Availability. For details on CRM full server installation one can refer this page. For 2nd server on Azure VM, I ran CRM server setup choosing option to connect to existing deployment pointing to On-Premise SQL Node 1. This document can be referred for detailed information on installing CRM server on additional servers in same CRM deployment.

On successful completion of CRM server setup on both servers, we have two CRM servers hosting Full Role. Browsing CRM website pointing to either of servers works normally. Being in same CRM deployment, either of the CRM server points to same back-end configuration and organization databases.

Dynamics CRM 2015 Implementation Guide provides good information on how to configure an existing CRM deployment to leverage SQL AlwaysOn high availability. Below is the CRM product documentation page describing the configuration process step by step.

Set configuration and organization databases for SQL Server 2012 AlwaysOn failover - https://technet.microsoft.com/en-us/library/jj822357.aspx

Out of above document, Cluster and SQL Availability Group creation step changes a little. Here we already have AlwaysOn Availability Group. We would add CRM databases to our existing Availability Group then resume following the document from step “Create the SQL logins…” up to the bottom. Making changes to connection string as described configures CRM Application to use the Availability Group Listener “HYBRIDSQLAGL” instead of AlwaysOn replica node name. This configuration allows CRM server to connect to SQL Databases in Availability Group irrespective of Replica node hosting the databases. CRM Application can continue to function and remain accessible even in situations when On-Premise or Azure IaaS servers are not accessible.

MultiSubnetFailover keyword is required as we have multi-subnet listener for an AlwaysOn Availability Group Listener. Refer to this article for more information on MultiSubnetFailover keyword of connection string.

What I described here is an example or can be called a POC (proof of concept). Disaster Recovery Strategy heavily relies on Recovery Point Objective (RPO) and Recovery Time Objective (RTO) directives from business. Depending on business and environmental requirements there could be need for additional resources and configuration steps to support multiple unique combinations. For Example: deploying a Hybrid AD FS deployment can be added to above topology and it would support your CRM Internet Facing Deployment (IFD) to be accessible over internet. ADFS on Azure VMs blog post gives good overview of scenarios and general information about it.

 

Additional Resources:

SQL AlwaysOn Team Blog - https://blogs.msdn.com/b/sqlalwayson/

Microsoft Server Software support for Microsoft Azure virtual machines - https://support.microsoft.com/en-us/kb/2721672

Performance Guidance for SQL Server in Windows Azure Virtual Machines - https://blogs.msdn.com/b/sqlcat/archive/2013/06/17/performance-guidance-for-sql-server-in-windows-azure-virtual-machines.aspx

ADFS on Azure VMs - https://blogs.technet.com/b/abizerh/archive/2013/11/19/adfs-on-azure-vms.aspx

 

Hope this helps! Cheers!

Bhavesh Shastri