TBD

August2016

Version 3.0a

Prepared by

TBD

Table of Contents

1Introduction

1.1Purpose

1.2Scenario Overview

2Scenario 1: Host an Active Directory Domain Controller in Windows Azure

2.1High-Level Scenario Overview

2.2Dependencies

2.3Design and Deployment Considerations

2.4Configuration and Walkthrough Steps

2.4.1Deploy Windows Server Virtual Machine in Azure

2.4.2Add Data Disk for Active Directory Database

2.4.3Configure the Attached Data Disk on the Virtual Machine

2.4.4Create Site, Subnet, and Site Link in Active Directory

2.4.5Configure DNS and Join Virtual Machine to the Domain

2.4.6Promote Windows Azure Virtual Machine to a Domain Controller

2.4.7Verify Domain Controller Functionality

3Scenario 2: Delayed Replication Site in Windows Azure

3.1High-Level Scenario Overview

3.2Dependencies

3.3Design and Deployment Considerations

3.4Configuration and Walkthrough Steps

3.4.1Create Sites and Site Links in Active Directory

3.4.2Configure Replication Schedules on the Lag Site Site-Links

3.4.3Deploy Additional Window Server Virtual Machines in Azure

3.4.4Optional: Creating Additional Replications Sites in Windows Azure

3.4.5Prevent Registration of Global DC Locator Records

4Scenario 3: Active Directory Backup to Azure Data Disks

4.1High-Level Scenario Overview

4.2Dependencies

4.3Design and Deployment Considerations

4.4Configuration and Walkthrough Steps

4.4.1Attach Azure Data Disk to Domain Controller Virtual Machine

4.4.2Install Windows Server Backup

4.4.3Configure Windows Server Backup

4.4.4Test Backup Settings

5Appendix: Configure Azure Virtual Networks and Site to Site VPN Gateway

5.1Dependencies

5.2Configuration and Walkthrough Steps

5.2.1Setup Virtual Network in Azure

5.2.2Configure Local Edge Server

5.2.3Connect the Azure Gateway

1

Active Directory - Migration and BCDR Guide, , Version 3.0a
Prepared by
"Migration and BCDR - Active Directory Guide.docx"

1Introduction

This guide is intended to provide technical details for supporting the planning and configuration of Business Continuity and Disaster Recovery (BC/DR) and Server Migration, for workloads which use Active Directory Domain Services. It includes sections outlined by technical scenario and is generalized to support several types of workload deployments.

1.1Purpose

The purpose of the guide is to support lab and production configurations during customer engagements. It may not align exactly with the customer infrastructure, but the aim of the document is to simplify and outline common configuration steps associated with each scenario.

1.2Scenario Overview

The aforementioned BC/DR options can be applied to each workload using a series of scenarios. For Active Directory Domain Services, the following scenarios are defined:

1.On-Premises DCs with Replica DC in Azure VM: This scenario outlines providing capabilities for on-premises Active Directory Domain Services through cloud-based domain controller virtual machines. In addition, this scenario can be used to extent Active Directory Domain Services to Microsoft Azure.

2.On-Premises DCs with Delayed Replication DC in Azure VM: This scenario outlines providing DR capabilities for on-premises Active Directory Domain Services through cloud-based domain controller virtual machines with a delayed replication interval. Delayed replication allows a time window during which invalid or improper changes to Active Directory can be rolled back through the “authoritative restore” process.

3.Backup of Azure-based DC to Azure Data Disk: This scenario outlines scenarios related to backup and restore of Active Directory domain controllers to dedicated backup disks attached to Microsoft Azure IaaS Virtual Machines.

While these do not encompass all of the potential possible scenarios one could establish for BC/DR of Active Directory Domain Services using cloud infrastructures, it provides a basis for the most common scenarios which would be encountered. These scenarios will be expanded as newer data and cloud platform capabilities come available.

The following sections provide step-by-step examples of how these scenarios can be established in a cloud environment. This documentation assumes that the reader has access to and a working knowledge of the Windows Server Hyper-V and System Center private cloud environment and has access to a Microsoft Azure subscription.

2Scenario 1: Host an Active Directory Domain Controller in Windows Azure

This section describes the scenario of deploying a domain controller within Microsoft Azure for disaster recovery of Active Directory Domain Services.

2.1High-Level Scenario Overview

Through connecting an on-premises network with an Azure virtual network via Site-to-Site VPN and promoting an Azure virtual machine to a domain controller domain users and system will be able to maintain a level of functionality in case of catastrophic failure of the on-premises Active Directory infrastructure.

Figure 3: High-level Solution Architecture

2.2Dependencies

  • Install and configure Windows Azure PowerShell on local machine.
  • Complete the configuration of Windows Azure virtual network, local network, and RRAS gateway.
  • Create on-premises sites and subnets in Active Directory.
  • Design and Deployment Considerations

When hosting a domain controller in Windows Azure it is important to restrict access to the Azure Subscription. Users with administrator access to the Azure Subscription have access to a domain controller image and domain accounts. Azure Subscription administrators must be trusted as domain administrators.

The Azure virtual network should have no publicly accessible endpoints, with the only connection being the site-to-site VPN. Azure ExpressRoute is recommended to increase the reliability and speed of the connection.

The Azure virtual network address space must be reachable from one or more on-premises domain controllers for Active Directory replication to occur. On-premises servers and workstations must also have connectivity to the virtual network address space to communicate with Azure-based domain controllers in the event of an on-premises domain controller failure. For configuration simplicity and reduced time-to-recovery, it is recommended that domain controllers, servers, and client computers have access to the virtual network subnet at all times, rather than waiting for a failure to occur before allowing server and client access.

Azure-based domain controllers should reside in a dedicated Active Directory site with an appropriate site link connecting the site to existing on-premises site(s). Azure will effectively become a new location for your organization. Adjustment of site link costs and DC locator DNS records can be used to optimize replication patterns, site coverage, and discovery of domain controllers by clients and servers. In the default configuration, Azure-based domain controllers in a separate site will not regularly service clients and servers from other sites, but some traffic may be seen if domain controllers are located using non-site-specific global records. Global locator record registration is important as it allows Azure domain controllers to quickly service Active Directory clients in the event of an on-premises domain controller failure. This can be disabled to reduce network traffic, but will delay failover to Azure domain controllers and may require manual administrator intervention.

The decision to use schedule-driven replication or notification-driven replication over the Azure site link should consider network traffic, Azure bandwidth charges, and the risk of losing on-premises Active Directory changes in the event of an on-premises domain controller failure. Schedule-driven replication may help decrease network traffic depending on the nature of your organization’s Active Directory change patterns. Notification-driven replication will minimize replication latency, ensuring any Active Directory changes made to on-premises domain controllers are quickly replicated to cloud-based domain controllers.

The Active Directory database, logs, and SYSVOL should be placed on a separate Azure data disk for data persistence through any site repair or recovery, and Active Directory database integrity in the case of a VM failure, reset, crash, or other case where the operating system is not shut down cleanly.

Consider the DNS configuration of your organization and determine the appropriate failover/DR approach. Azure domain controllers are configured as DNS servers and can host all required DNS zones, but this does not mean clients and servers will automatically use them in the event of an on-premises DC/DNS failure. If clients and servers are pointing exclusively to on-premises domain controllers for DNS, some level of intervention will be required to leverage the Azure domain controllers for DR. On the other hand, if clients and servers are configured with Azure domain controllers as a secondary or tertiary DNS server, some additional Azure network traffic will likely be seen during normal operations.

The configuration and walkthrough steps provided below configure one domain controller to service a single-domain Active Directory environment. In the case of multiple domains or forests, the configuration steps should be followed for each domain that requires disaster recovery capabilities. All Azure domain controllers can reside on the same virtual network and share a common Active Directory site, subnet, and site link configuration, or can be configured in separate sites if your organization’s requirements dictate such a configuration.

2.4Configuration and Walkthrough Steps

2.4.1Deploy Windows Server Virtual Machine in Azure

  1. From the Microsoft Azure Management Portal (Azure Portal) create new virtual machine in Compute -> Virtual Machine -> From Gallery.
  2. Select a Windows Server 2012 R2 Datacenter Image.
  3. Configure the version (select the latest date), enter computer name, standard, the appropriate size, administrator name use and password. Continue to the virtual machine configuration.

Note: If a cloud service exists, select the existing service and skip to step number 5.

  1. Select “Create a new cloud service”.

Figure 4: Virtual Machine Configuration in Azure Portal.

Note: The name of the cloud service is the name of the new virtual machine being created and can be modified if needed.

  1. Select the appropriate Affinity Group.

Note: The subnet will be filled in based on the affinity. If there are additional subnets, select the appropriate one.

  1. Use an automatically generated Storage Account, unless a previously created storage account is necessary.
  2. Select an Availability Set if one is appropriate.
  3. Continue to the next Virtual machine configuration page.
  4. Check the boxes for VM Agent and Microsoft Anti-Malware.
  5. Continue and the new virtual machine will be prepared.
  6. Confirm the virtual machine was created by navigating to Virtual Machines in the Azure Portal.
  7. The status next to your new virtual machine should be a green check mark “Running”.

Figure 5: Virtual Machines in Azure Portal.

2.4.2Add Data Disk for Active Directory Database

  1. Navigate to Virtual Machines in the Azure Portal.
  2. Select the virtual machine created in the last section.
  3. At the button of the management portal select Attach -> Attach Empty Disk.
  4. Enter the desired size of the disk.
  5. Configure the cache option to NONE.

Figure 6: Configuration options for attaching an empty disk.

  1. Continue to create and attach the new disk.
  2. Configure the Attached Data Disk on the Virtual Machine
  1. Connect to the virtual machine from the Azure Portal.
  2. Enter the Administrator credentials.
  3. Initialize and format the data disk in Disk Management.
  4. Create Site, Subnet, and Site Link in Active Directory

Complete this step with Windows PowerShell

  1. Connect to an on-premises domain controller as an Administrator.
  2. Open Active Directory Sites and Services.
  3. Right-click on Sites, select New Site.
  4. Enter the desired site name for the Azure Site and select the default site link and click OK.

Note: The site link will be changed to a new “Azure to on-premises” site link in a later step.

  1. In Active Directory Sites and Services under Sites, right-click on Subnets and select New Subnet.
  2. Enter the Prefix to the Azure Virtual Network Subnet (i.e. 192.168.2.0/24).
  3. Select the Site created for the Azure domain controller, and click Next.

  1. In Active Directory Sites and Services under Sites, then Inter-Site Transports, right-click on IP and select New Site-Link.
  2. Enter the desired Name (i.e. AzureSite-OnPremSite) for the Site-Link and select the sites to be added to the link (i.e. AzureSite, OnPremSite, etc).

Note: The Site-Link must contain the Azure site and one or more on-premises sites.

  1. Back in Active Directory Sites and Services under Sites, Inter-Site Transports, then IP, right-click on theSite-Link created in the last step and select Properties.
  2. Enter the desired Cost and Replication timein minutes.

Note: Choose a cost to reflect the appropriate replication and site coverage preferences. This will likely be a cost higher than the cost used on most on-premises site links.

  1. Optional: Configure Change Notification for the new Site-Link.
  2. In the Site-Link Properties, navigate to the Attribute Editor tab.
  3. Locate the Attribute options, and select Edit.

  1. Enter the value of 1 to enable change notifications and a value of 0 to disable.

Windows PowerShell equivalent commands
The following Windows PowerShell commands, run at an administrator-level Windows PowerShell command prompt, perform the same function as the preceding procedure.
Create New Site:
New-ADReplicationSite -Name <"Azure Site Name">
Create New Subnet:
New-ADReplicationSubnet -Name <"Azure Virtual Network Subnet Prefix"> -Site <Azure Site>
Create New Site Link:
New-ADReplicationSiteLink -Name "<SiteLinkName>" -SitesIncluded <CloudSite,SiteName1[,SiteName2]> -Cost <SiteLinkCost> -ReplicationFrequencyInMinutes <ReplicationTime> -InterSiteTransportProtocol IP
-OtherAttributes @{'options'=1}

Note: Choose a cost to reflect the appropriate replication and site coverage preferences. This will likely be a cost higher than the cost used on most on-premises site links. Also, the Site-Link must contain the Azure site and one or more on-premises sites.

2.4.5Configure DNS and Join Virtual Machine to the Domain

Complete this step with Windows PowerShell

  1. In the Azure Virtual Machine, configure the IPv4 TCP/IP Settings.
  2. Open the Network and Sharing Center, open the Ethernet interface and select Properties.
  3. Configure the preferred DNS server to the on-premises DNS address and the secondary DNS server to the loopback address (127.0.0.1).
  4. In Control Panel navigate, Systemand Security, then System.
  5. Under Computer name, domain and workgroup settings, select Change Settings.
  6. In the Computer Name tab, select Change.

  1. Select the Domain radial button and enter the on-premises domain and click OK.
  2. When prompted, enter on-premises administrator credentials.
  3. After the successfully joining the domain, Restart the virtual machine.

Windows PowerShell equivalent commands
The following Windows PowerShell commands, run at an administrator-level Windows PowerShell command prompt.
Configure DNS:
DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ( “<On-Premises DNS IPv4 Address>”, “127.0.0.1”)
Join Virtual Machine to the Domain:
Add-Computer -DomainName <On-Premises Domain>
Restart-Computer

2.4.6Promote Windows Azure Virtual Machine to a Domain Controller

Complete this step with Windows PowerShell

  1. Connect to the virtual machine and open the Server Manager.
  2. Navigate to Add Roles and Features.
  3. Click Next on the Before You Begin.
  4. On the next page select the Role based or featured based installation radial button and click Next.
  5. In the Server Selection page Select a server from the server pool radial button and select the desired server from the list. Click next to continue.
  6. On the Server Roles page select Active Directory Domain Services role.
  7. In the new window, review the features and click Add Features.

.

  1. Click Next on the Features page.
  2. Click Next on the AD DS page.
  3. On the Confirmation page check the box Restart the destination server automatically if required and click Install.
  4. This will take a few minutes to complete, the virtual machine will automatically reboot on completion.
  5. After the installation is complete, return to the Server Manager.
  6. Click on the flag with the yellow warning icon.
  7. In the down drop select Promote this server to a domain controller.
  8. This will launch the Active Directory Domain Services Configuration Wizard.
  9. Select Add a domain controller to an existing domain radial button.
  10. Enter your on-premises domain into the domain section.
  11. Add a domain administrator account for the credentials and click Next.
  12. Check the boxes for Domain Name System (DNS) Server and Global Catalog (GC).
  13. Select the site created for the Azure.

Note: The site can be changed in the future if the proper site has not been created yet.

  1. Enter and confirm the Directory Services Restore Mode (DSRM) and click Next.
  2. Review the DNS Options page and click Next.
  3. Select the domain controller to replicate from in the Additional Options page and click Next.
  4. On the Path page, change the path letter to new attached disk (i.e. “X:\Windows\NTDS”) and click Next.

Note: Be sure to change all of the drive paths (“X”) to the Attached Empty Disk from the previous section.

  1. Review the configuration on the Review Options page and click Next.
  2. Review the warnings on the Prerequisites Check page and click Install.

Windows PowerShell equivalent commands
The following Windows PowerShell commands, run at an administrator-level Windows PowerShell command prompt.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Use the following script to promote the virtual machine to a domain controller:
#
# Windows PowerShell script for AD DS Deployment
#
Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath "X:\NTDS" `
-DomainName "<Corporate Domain>" `
-InstallDns:$true `
-LogPath "X:\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "<Created Site for Azure>" `
-SysvolPath "X:\SYSVOL" `
-Force:$true

Note: Be sure to change all of the drive paths (“X”) to the Attached Empty Disk from the previous section. All the <Bold> area are to be change to customer specific details.