Windows Server 2012 Setting Up Active Directory Service and DNS

Step-By-Step: Adding a Windows Server 2012 Domain Controller to an Existing Windows Server 2003 network

1. Download Windows Server 2012 R2. If you plan on completing this Step-By-Step in a virtual lab, it is recommended to download the FREE Hyper-V Server 2012 R2 first.
2. Check to ensure the Domain Functional Level is currently setup to at least Windows 2003 mode. This is the lowest required Domain Functional Level that would allow a Windows Server 2012 Domain Controller installation. Windows NT / 2000 Domain Controllers are not supported via this process.

1. Via the Active Directory Users and Computers console, select the domain via the right mouse button on it. 
2. Select Raise Domain Functional Level and review the Current domain functional level reported
   
   
   The Domain Functional Level does not need to be raised if the Current domain functional level is reportingWindows Server 2003.
   
   NOTE: Should a lower domain be showcased (i.e., Windows Server 2000), please keep in mind that raising Domain Functional Level is a one time action and cannot be reverted. Remember Windows NT / 2000 Domain Controllers are not supported via this process.
3. Ensure your profile is a member of the Enterprise Admins group.

Getting Started

1. Setup and install your Windows Server 2012 machine
2. Configure the new server's IP address to correspond to the target domain and ensure the existing Domain Controllers, where DNS is installed and configured, are visible by your new Windows Server 2012 install.

Setting Up Domain Controller Fuctionality

1. Open the Server Manager console and click on Add roles and features
   
   
2. Select Role-based of featured-based installation and select Next.
   
   
3. Select the Active Directory Directory Services role.
   
   
4. Accept the default features required by clicking the Add Features button.
   
   
5. On the Features screen click the Next button.
6. On the Confirm installation selections screen click the Install button.
   
   NOTE: Check off the Restart the destination server automatically if required box to expedite the install should you be able to reset the target server automatically.
   
   
7. Click the Close button once the installation has been completed.
   
   
8. Once completed, notification is made available on the dashboard highlighted by an exclamation mark. Select it and amidst the drop down menu select Promote this server to a domain controller.
   
   
9. Select add a Domain Controller into existing domain
   
   
10. Ensure the target domain is specified.  If it is not, please either Select the proper domain or enter the proper domain in the field provided.
11. Click Change, provide the required Enterprise Administrator credentials and click the Next button.
12. Define if server should be a Domain Name System DNS server and Global Catalog (GC). Select the Site to which this DC belongs to and define Directory Services Restoration Mode (DSRM) password for this DC
    
    
13. Click the Next button on the DNS options screen.
14. In the Additional Options screen you are provided with the option to install the Domain Controller fromInstall From Media (IFM). Additionally you are provided the option to select the point from which DC replication should be completed. The server will choose the best location for AD database replication if not specified. Click the Next button once completed.
    
    
15. Specify location for AD database and SYSVOL and Click the Next button.
    
    
16. Next up is the Schema and Domain preparation.  Alternately, one could run Adprep prior to commencing these steps, Regardless, if Adprep is not detected, it will automatically be completed on your behalf.
    
    
17. Finally, the Review Options screen provides a summary of all of the selected options for server promotion. As an added bonus, when clicking View Script button you are provided with the PowerShell script to automate future installations. To click the Next button to continue.
    
    
18. Should all the prerequisites pass, click the Install button to start the installation.
    
    
19. After it completes the required tasks and the server restarts, the new Windows Server 2012 Domain Controller setup is completed.
20. Lastly, on each server/workstation within the target domain require a NIC properties configuration update to point to the new Domain Controller. Open the DHCP management console, select Option no. 006 and under server/scope options and add the IP address of your new Domain Controller as DNS server.
    
    

Should you see one of our #CANITPRO Step-By-Step posts in any social media venue, feel free to contribute thoughts and additional ideas.  Additionally, feel free to connect with us on any topic you would like to see covered. 

What workloads can you protect with Azure Site Recovery?

Azure Site Recovery enables customers to deploy application-aware availability solutions that contribute to your organization's business continuity and disaster recovery (BCDR) strategy. Whether it's Windows Server or Linux-based apps, Microsoft enterprise applications or offerings from other vendors, you can use Azure Site Recovery to enable disaster recovery, on-demand development and testing environments, and cloud migration.

Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat to ensure their applications and services work well on Microsoft platforms such as Azure and Hyper-V. You can customize your disaster recovery solution for each specific application.

Key Features

Azure Site Recovery features that contribute to your application-level protection and recovery strategy include:

• Near-synchronous replication with RPOs as low as 30 seconds to meet the needs of most critical applications.
• App-consistent snapshots for single or N-tier applications.
• Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies, including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
• Flexible recovery plans that enable you to recover an entire application stack with a single click, and include external scripts or manual actions.
• Advanced network management in Site Recovery and Azure simplifies network requirements for an app, including reserving IP addresses, configuring load-balancers, or integration of Azure Traffic Manager for low RTO network switchovers.
• rich automation library that provides production-ready, application specific scripts that can be downloaded and integrated with Site Recovery.

Workload summary

Site Recovery replication technologies are compatible with any application running in a virtual machine. In addition we've done additional testing in partnership with application product teams to further support each app.

Workload	Replicate Hyper-V VMs (to a secondary site)	Replicate Hyper-V VMs (to Azure)	Replicate VMware VMs (to a secondary site)	Replicate VMware VMs (to Azure)
Active Directory, DNS	Y	Y	Y	Y
Web apps (IIS, SQL)	Y	Y	Y	Y
SCOM	Y	Y	Y	Y
Sharepoint	Y	Y	Y	Y
SAP Replicate SAP site to Azure for non cluster	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Exchange (non-DAG)	Y	Coming soon	Y	Y
Remote Desktop/VDI	Y	Y	Y	N/A
Linux (operating system and apps)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Dynamics AX	Y	Y	Y	Y
Dynamics CRM	Y	Coming soon	Y	Coming soon
Oracle	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Windows File Server	Y	Y	Y	Y

Protect Active Directory and DNS

All enterprise applications such as SharePoint, Dynamics AX and SAP depend on an Active Directory and DNS infrastructure. As part of your BCDR solution you'll need to protect and recover these infrastructure components before recovering your workloads and apps.

Using Site Recovery you can create a complete automated disaster recovery plan for Active Directory and DNS. For example if you're using Active Directory for multiple applications such as SharePoint and SAP in your primary site and you want to fail over the complete site, you can fail Active Directory over first using a recovery plan, and then fail over the applications that rely on Active Directory using application-specific recovery plans.

Learn more

Protect SQL Server

SQL Server provides a foundation for data services for many business applications in an on-premises datacenter. Site Recovery and SQL Server HA/DR technologies are complementary and can be used together to provide end-to-end protection for multi-tiered enterprise applications. Site Recovery offers the following benefits for SQL Server environments:

• Easy protection and replication of standalone or clustered SQL servers to Azure or a secondary site. Provides a simple and cost-effective disaster recovery solution for many SQL Server versions and editions.
• Integration with SQL AlwaysOn Availability Groups, managing failover and failback processes with recovery plans in Azure Site Recovery.
• End-to-end recovery plans for the entire application stack, including the SQL Server databases.
• Scaling up of SQL Server for peak loads using Azure Site Recovery by “bursting” them into larger IaaS virtual machine sizes in Azure.
• Testing of SQL Server in Azure or a secondary site using Azure Site Recovery. Test failovers can be used for analytics data compliance checks without impacting your production environment.

Learn more

Protect SharePoint

Azure Site Recovery helps you to protect your SharePoint deployment. With Site Recovery you can:

• Eliminate the need and associated infrastructure cost for a stand-by farm for disaster recovery. With Site Recovery, you can enable protection of the entire farm (Web, app and database tiers) to Azure or to a secondary site.
• Simplify application deployment and manageability. Updates deployed to the primary site are automatically replicated, and will be available when the farm is recovered on the secondary site. This eliminates the management complexity of keeping a stand-by farm up-to-date, lowering costs.
• Simplify SharePoint application development and testing by creating a production-like copy on-demand replica environment for testing and debugging.
• Simplify transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.

Learn more

Protect Dynamics AX

Azure Site Recovery helps you protect your Dynamics AX ERP solution:

• Enable protection of your entire Dynamics AX environment (Web and AOS tiers, database tiers, SharePoint) to Azure or to a secondary site using Site Recovery.
• Simplify migration to the cloud by using Site Recovery to migrate Dynamics AX deployments to Azure.
• Simplify Dynamics AX application development and testing by creating a production-like copy on-demand for testing and debugging.

Read more

Protect RDS

Remote Desktop Services enables virtual desktop infrastructure (VDI), session-based desktops, and applications, allowing users to work anywhere. With Site Recovery you can enable protection of managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and sessions to a secondary site or Azure.

Learn more

Protect Exchange

Microsoft Exchange includes in-built support for high availability and disaster recovery. Exchange DAGs and Azure Site Recovery can work together.

• Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Recovery plans in Site Recovery can include DAGs to orchestrate DAG failover across sites.
• For small deployments, such as a single or non-clustered servers, Site Recovery can protect and fail over to Azure or to a secondary site.

earn more

Protect SAP

Use Site Recovery to protect your SAP deployment:

• Enable protection of the entire SAP deployment with different layers to Azure or to a secondary site.
• Simplify cloud migration by using Site Recovery to migrate your SAP deployment to Azure.
• Simply SAP development and testing by creating a production-like copy on-demand for testing and debugging applications.

Protect SQL Server with SQL Server disaster recovery and Azure Site Recovery

The Azure Site Recovery service contributes to your business continuity and disaster recovery (BCDR) strategy by orchestrating replication, failover and recovery of virtual machines and physical servers. Machines can be replicated to Azure, or to a secondary on-premises data center. For a quick overview read What is Azure Site Recovery?.

This article describes how to protect the SQL Server back end of an application using a combination of SQL Server BCDR technologies and Azure Site Recovery. You should have a good understanding of SQL Server disaster recovery capabilities (failover clustering, AlwaysOn availability groups, database mirroring, log shipping) and of Azure Site Recovery, before you deploy the scenarios described in this article.

Overview

Many workloads use SQL Server as a foundation. Applications such as SharePoint, Dynamics, and SAP use SQL Server to implement data services. Applications deploy SQL Server in a number of different ways:

• Standalone SQL Server: SQL Server and all databases are hosted on a single machine (physical or a virtual). When virtualized, host clustering is used for local high availability. No guest-level high availability is implemented.
• SQL Server Failover Clustering Instances (Always On FCI): Two or more nodes of SQL server instances with shared disks are configured in a Windows Failover cluster. If any of the cluster instances is down, the cluster can fail over SQL Server to another instance. This setup is typically used for HA on a primary site. It doesn't protect against failure or outage in the shared storage layer. Shared disk can be implemented using ISCSI, Fiber channel or Shared VHDx.
• SQL Always On Availability Groups: In this setup, two nodes are setup in a shared nothing cluster with SQL Server databases configured in an availability group with synchronous replication and automatic failover.

In Enterprise editions, SQL Server also provides native disaster recovery technologies for recovering databases to a remote site. In this article, we'll leverage and integrate with these native SQL disaster recovery technologies:

• SQL Always On Availability Groups for disaster recovery for SQL Server 2012 or 2014 Enterprise editions.
• SQL database mirroring in high safety mode for SQL Server Standard edition (any version), or for SQL Server 2008 R2.

Site Recovery can protect SQL Server as summarized in the table.

	On-premises to on-premises	On-premises to Azure
Hyper-V	Yes	Yes
VMware	Yes	Yes
Physical server	Yes	Yes

Support and integration

These SQL Server versions are supported by the scenarios in this article:

• SQL Server 2014 Enterprise and Standard
• SQL Server 2012 Enterprise and Standard
• SQL Server 2008 R2 Enterprise and Standard

Site Recovery can be integrated with native SQL Server BCDR technologies summarized in the table below to provide a disaster recovery solution.

Feature	Details	SQL Server version
AlwaysOn availability group	Multiple standalone instances of SQL Server each run in a failover cluster that has multiple nodes. Databases can be grouped into failover groups that can be copied (mirrored) on SQL Server instances so that no shared storage is needed. Provides disaster recovery between a primary site and one or more secondary sites. Two nodes can be set up in a shared nothing cluster with SQL Server databases configured in an availability group with synchronous replication and automatic failover.	SQL Server 2014 & 2012 Enterprise edition
Failover clustering (AlwaysOn FCI)	SQL Server leverages Windows failover clustering for high availability of on-premises SQL Server workloads. Nodes running instances of SQL Server with shared disks are configured in a failover cluster. If an instance is down the cluster fails over to different one. The cluster doesn't protect against failure or outages in shared storage. The shared disk can be implemented with iSCSI, fiber channel, or shared VHDXs.	SQL Server Enterprise editions SQL Server Standard edition (limited to two nodes only)
Database mirroring (high safety mode)	Protects a single database to a single secondary copy. Available in both high safety (synchronous) and high performance (asynchronous) replication modes. Doesn’t require a failover cluster.	SQL Server 2008 R2 SQL Server Enterprise all editions
Standalone SQL Server	The SQL Server and database are hosted on a single server (physical or virtual). Host clustering is used for high availability if the server is virtual. No guest-level high availability.	Enterprise or Standard edition

Deployment recommendations

This table summarizes our recommendations for integrating SQL Server BCDR technologies with Site Recovery.

Version	Edition	Deployment	On-prem to on-prem	On-prem to Azure
SQL Server 2014 or 2012	Enterprise	Failover cluster instance	AlwaysOn availability groups	AlwaysOn availability groups
Enterprise	AlwaysOn availability groups for high availability	AlwaysOn availability groups	AlwaysOn availability groups
	Standard	Failover cluster instance (FCI)	Site Recovery replication with local mirror	Site Recovery replication with local mirror
	Enterprise or Standard	Standalone	Site Recovery replication	Site Recovery replication
SQL Server 2008 R2	Enterprise or Standard	Failover cluster instance (FCI)	Site Recovery replication with local mirror	Site Recovery replication with local mirror
	Enterprise or Standard	Standalone	Site Recovery replication	Site Recovery replication
SQL Server (Any version)	Enterprise or Standard	Failover cluster instance - DTC applicaiton	Site Recovery replication	Not Supported

Deployment prerequisites

Here's what you need before you start:

• An on-premises SQL Server deployment running a supported SQL Server version. Typically you'll also need an Active Directory for your SQL server.
• The prerequisites for the scenario you want to deploy. Prerequisites can be found in each deployment article. Links to these are provided in the Site Recovery Overview.
• If you want to set up recovery in Azure, you'll need to run the Azure Virtual Machine Readiness Assessment tool on your SQL Server virtual machines to make sure they're compatible with Azure and Site Recovery.

Set up Active Directory

You'll need Active Directory on the secondary recovery site for SQL Server to run properly. there are a couple of options:

• Small enterprise—If you have a small number of applications and a single domain controller for the on-premises site, and you want to fail over the entire site, we recommend that you use Site Recovery repication to replicate the domain controller to the secondary datacenter or to Azure.
• Medium to large enterprise—If you have a large number of application, you're running an Active Directory forest, and you want to fail over by application or workload, we recommend you set up an additional domain controller in the secondary datacenter or in Azure. Note that if you're using AlwaysOn availability groups to recover to a remote site we recommend you set up another additional domain controller on the secondary site or Azure, to use for the recovered SQL Server instance.

The instructions in this document presume that a domain controller is available in the secondary location. Read more about protecting Active Directory with Site Recovery.

Integrate protection with SQL Server Always-On (on-premises to Azure)

Protecting Hyper-V VMs in VMM clouds

Site Recovery natively supports SQL AlwaysOn. If you've created a SQL Availability Group with an Azure virtual machine set up as ‘Secondary’ then you can use Site Recovery to manage the failover of the Availability Groups.

NOTE:

This capability is currently in preview and available when Hyper-V host servers in the primary datacenter are managed in VMM clouds.

Prerequisites

Here's what you need to integrate SQL AlwaysOn with Site Recovery when you're replicating from VMM:

• An on-premises SQL Server (standalone server or a failover cluster).
• One or more Azure virtual machines with SQL Server installed
• A SQL Availability Group set up between an on-premises SQL Server and SQL Server running in Azure
• PowerShell remoting should be enabled on the on-premises SQL Server machine. The VMM server should be able to make remote PowerShell calls to the SQL Server.
• A user account should be added on the on-premises SQL Server, in these SQL user groups with at least these permissions:
  • ALTER AVAILABILITY GROUP: permissions here, and here
  • ALTER DATABASE - permissionshere
• A RunAs account should be created on VMM Server for the account in the previous step
• The SQL PS module should be installed on SQL Servers running on-premises,and on Azure virtual machines
• The VM Agent should be installed virtual machines running on Azure
• NTAUTHORITY\System should have following permissions on SQL Server running on virtual machines in Azure:
  • ALTER AVAILABILITY GROUP - permissions here, and here
  • ALTER DATABASE - permissions here

Step 1: Add a SQL Server

1. Click Add SQL to add a new SQL Server.
   
2. In Configure SQL Settings > Name provide a friendly name to refer to the SQL Server.
3. In SQL Server (FQDN) specify the FQDN of the source SQL Server that you want to add. In case the SQL Server is installed on a Failover Cluster, then provide FQDN of the cluster and not of any of the cluster nodes.
4. In SQL Server Instance choose the default instance or provide the name of the custom instance.
5. In VMM Server select a VMM server registered in the Site Recovery vault. Site Recovery uses this VMM server to communicate with the SQL Server.
6. In Run as Account provide the name of a RunAs account that was created on the specified VMm server. This account is used to access the SQL Server and should have Read and Failover permissions on availability groups on the SQL Server machine.
   

After you add the SQL Server it will appear in the SQL Servers tab.

Step 2: Add a SQL Availability Group

1. After the SQL Server machine is added the next step is to add the Availability Groups to Site Recovery. To do that, drill down inside the SQL Server added in previous step and click on Add SQL Availability Group.
   
2. SQL Availability Group can be replicating to one or more virtual machines in Azure. When adding the sql availability group you are required to provide the name and subscription of the Azure virtual machine where you want the availability group to be failed over to by Site Recovery.
   
3. In the above example Availability Group DB1-AG would become Primary on virtual machine SQLAGVM2 running inside subscription DevTesting2 on a failover.

NOTE:

Only the Availability Groups that are Primary on the SQL Server added in step above are available to be added to Site Recovery. If you have made an Availability Group Primary on the SQL Server or if you have added more Availability Groups on the SQL Server after it was added, refresh it using the Refresh option available on the SQL Server.

Step 3: Create a Recovery Plan

The next step is to create a recovery plan using both virtual machines and the availability groups. Select the same VMM Server that you used in Step-1 as source and Microsoft Azure as target.

In the example the Sharepoint application consists of 3 virtual machines which use a SQL Availability Group as its backend. In this recovery plan we could select both the availability group as well the virtual machine that constitute the application.

You can further customize the recovery plan by moving virtual machines to different failover groups to sequence the order of failover. Availability group is always failed over first as it would be used as a backend of any application.

Step 4: Fail over

Different failover options are available once an Availability Group has been added to a Recovery Plan.

Failover	Details
Planned failover	Planned Failover implies a no data loss failover. To achieve that SQL Availability Group’s Availability Mode is first set to Synchronous and then a failover is triggered to make the availability group Primary on to the virtual machine provided while adding the availability group to Site Recovery. Once the failover is complete, Availability Mode is set to the same value as it was before the planned failover was triggered.
Unplanned failover	Unplanned Failover can result into data loss. While triggering unplanned failover the Availability mode of the Availability Group is not changed and the it is made primary on to the virtual machine provided while adding the availability group to Site Recovery. Once unplanned failover is complete and the on-premises server running SQL Server is available again, Reverse Replication has to be triggered on the Availability Group. Note that this action is not available on the recovery plan and can be taken on SQL Availability Group under SQL Servers tab
Test failover	Test failover for SQL Availability group is not supported. If you trigger Test Failover of a Recovery Plan containing SQL Availability Group, failover would be skipped for Availability Group.

Consider these failover options.

Option	Details
Option 1	1. Perform a test failover of the application and front-end tiers. 2. Update the application tier to access the replica copy in read-only mode, and perform a read-only test of the application.
Option 2	1. Create a copy of the replica SQL Server virtual machine instance (using VMM clone for site-to-site or Azure Backup) and bring it up in a test network 2. Perform the test failover using the recovery plan.

Step 5: Fail back

If you want to make the Availability Group again Primary on the on-premises SQL Server then you can do so by triggering Planned Failover on the Recovery Plan and choosing the direction from Microsoft Azure to on-premises VMM Server.

NOTE:

After an unplanned failover reverse replication has to be triggered on the Availability Group to resume the replication. Till this is done the replication remains suspended.

Protect machines without VMM

For the environments that are not managed by a VMM Server, Azure Automation Runbooks can be used to configure a scripted failover of SQL Availability Groups. Below are the steps to configure that:

1. Create a local file for the script to fail over an availability group. This sample script specifies a path to the availability group on the Azure replica and fails it over to that replica instance. This script will be run on the SQL Server replica virtual machine by passing is with the custom script extension.
   Copy

   Param(
   [string]$SQLAvailabilityGroupPath
   )
   import-module sqlps
   Switch-SqlAvailabilityGroup -Path $SQLAvailabilityGroupPath -AllowDataLoss -force

2. Upload the script to a blob in an Azure storage account. Use this example:
   Copy

   $context = New-AzureStorageContext -StorageAccountName "Account" -StorageAccountKey "Key"
   Set-AzureStorageBlobContent -Blob "AGFailover.ps1" -Container "script-container" -File "ScriptLocalFilePath" -context $context

3. Create an Azure automation runbook to invoke the scripts on the SQL Server replica virtual machine in Azure. Use this sample script to do this. Learn more about using automation runbooks in recovery plans.
   Copy

   workflow SQLAvailabilityGroupFailover
   {
       param (
           [Object]$RecoveryPlanContext
       )
   
       $Cred = Get-AutomationPSCredential -name 'AzureCredential'
   
       #Connect to Azure
       $AzureAccount = Add-AzureAccount -Credential $Cred
       $AzureSubscriptionName = Get-AutomationVariable –Name ‘AzureSubscriptionName’
       Select-AzureSubscription -SubscriptionName $AzureSubscriptionName
   
       InLineScript
       {
       #Update the script with name of your storage account, key and blob name
       $context = New-AzureStorageContext -StorageAccountName "Account" -StorageAccountKey "Key";
       $sasuri = New-AzureStorageBlobSASToken -Container "script-container"- Blob "AGFailover.ps1" -Permission r -FullUri -Context $context;
   
       Write-output "failovertype " + $Using:RecoveryPlanContext.FailoverType;
   
       if ($Using:RecoveryPlanContext.FailoverType -eq "Test")
           {
           #Skipping TFO in this version.
           #We will update the script in a follow-up post with TFO support
           Write-output "tfo: Skipping SQL Failover";
           }
       else
           {
           Write-output "pfo/ufo";
           #Get the SQL Azure Replica VM.
           #Update the script to use the name of your VM and Cloud Service
           $VM = Get-AzureVM -Name "SQLAzureVM" -ServiceName "SQLAzureReplica";     
   
           Write-Output "Installing custom script extension"
           #Install the Custom Script Extension on teh SQL Replica VM
           Set-AzureVMExtension -ExtensionName CustomScriptExtension -VM $VM -Publisher Microsoft.Compute -Version 1.3| Update-AzureVM; 
   
           Write-output "Starting AG Failover";
           #Execute the SQL Failover script
           #Pass the SQL AG path as the argument.
   
           $AGArgs="-SQLAvailabilityGroupPath sqlserver:\sql\sqlazureVM\default\availabilitygroups\testag";
   
           Set-AzureVMCustomScriptExtension -VM $VM -FileUri $sasuri -Run "AGFailover.ps1" -Argument $AGArgs | Update-AzureVM;
   
           Write-output "Completed AG Failover";
   
           }
   
       }
   }

4. When you create a recovery plan for the application add a "pre-Group 1 boot" scripted step that invokes the automation runbook to fail over availability groups.

Integrate protection with SQL AlwaysOn (on-premises to on-premises)

If the SQL Server is using availability groups for high availability, or a failover cluster instance, we recommend using availability groups on the recovery site as well. Note that this guidance is for applications that don't use distributed transactions.

1. Configure databases into availability groups.
2. Create a new virtual network on secondary site.
3. Set up a site-to-site VPN between the new virtual network and the primary site.
4. Create a virtual machine on the recovery site and install SQL Server on it.
5. Extend the existing AlwaysOn availability groups to the new SQL Server virtual machine. Configure this SQL Server instance as an asynchronous replica copy.
6. Create an availability group listener, or update the existing listener to include the asynchronous replica virtual machine.
7. Make sure that the application farm is setup using the listener. If It's setup up using the database server name, please update it to use the listener so you don't need to reconfigure it after the failover.

For applications that use distributed transactions we recommendation you use Site Recovery with SAN replication or VMWare/physical server site-to-site replication.

Recovery plan considerations

1. Add this sample script to the VMM library on the primary and secondary sites.
   Copy

   Param(
   [string]$SQLAvailabilityGroupPath
   )
   import-module sqlps
   Switch-SqlAvailabilityGroup -Path $SQLAvailabilityGroupPath -AllowDataLoss -force

2. When you create a recovery plan for the application add a "pre-Group 1 boot" scripted step that invokes the script to fail over availability groups.

Protect a standalone SQL Server

In this configuration we recommend you use Site Recovery replication to protect the SQL Server machine. The exact steps will depend whether SQL Server is set up as a virtual machine or physical server, and whether you want to replicate to Azure or a secondary on-premises site. Get instructions for all deployment scenarios in the Site Recovery Overview.

Protect a SQL Server cluster (Standard or 2008 R2)

For a cluster running SQL Server Standard edition or SQL Server 2008 R2 we recommend you use Site Recovery replication to protect SQL Server.

On-premises to on-premises

• If the application's uses distributed transactions we recommend you deploy Site Recovery with SAN replication for a Hyper-V environment and VMware/physical server to VMware for VMware environment.
• For non-DTC applications, leverage the above approach to recover the cluster as a stand-alone server by leveraging a local high safety DB mirror.

On-premises to Azure

Site recovery doesn't support guest cluster support when replicating to Azure. SQL Server also doesn't provide a low-cost disaster recovery solution for Standard edition. We recommend you protect the on-premises SQL Server cluster to a standalone SQL Server and recover it in Azure.

1. Configure an additional standalone SQL Server instance on the on-premises site.
2. Configure this instance to serve as a mirror for the databases that need protection. Configure the mirroring in high safety mode.
3. Configure Site Recovery on the on-premises site based on the environment (Hyper-V orVMware/physical server.
4. Use Site Recovery replication to replicate the new SQL Server instance to Azure. It's a high safety mirror copy and so it'll be synchronized with the primary cluster, but it'll be replicated to Azure using Site Recovery replication.

The following graphic illustrates this setup.

Failback considerations

For SQL standard clusters, failback after an unplanned failover will require a SQL backup and restore from the Mirror instance to the original cluster and re-establishing the mirror.