Академический Документы
Профессиональный Документы
Культура Документы
Prepared by
Robert DeLuca, Jim Phillipps, James Svolos, David Reynolds Stavan Patel, Henry Robalino,
Jason Beck, Alejandra Hernandez, and Joel Yoker
Version 1.0
Update [Customer] in Doc Properties
2013 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express
authorization of Microsoft Corp. is strictly prohibited.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
ii
SMB Azure Business Continuity and Disaster Recovery
Prepared by Robert DeLuca, Jim Phillipps, James Svolos, David Reynolds Stavan Patel, Henry Robalino, Jason Beck, Alejandra
Hernandez, and Joel Yoker
"361936590.docx"
Microsoft Azure
Change Record
Date Author Version Change Reference
Table of Contents
1 Introduction............................................................................................................................................... 6
1.1 Using the Document.................................................................................................................................... 6
2.2 Dependencies................................................................................................................................................. 9
3.2 Dependencies.............................................................................................................................................. 21
4 Appendix: Configure Azure Virtual Networks and Site to Site VPN Gateway...............24
4.1 Dependencies.............................................................................................................................................. 24
1 Introduction
This document is intended to provide technical details for supporting Business Continuity and
Disaster Recovery planning for generic virtual machine workloads, managed and not managed,
by System Center Virtual Machine Manager. It includes sections outlined by technical scenario
and is generalized to support several types of workload deployments.
Auzre guidance on supporting BCDR scenarios can be divided across public and hybrid cloud
environments using each environments unique capabilities. There are three main decision
points which drive whether public or hybrid cloud constructs can be used to support BCDR
within a given cloud-hosted application or service these being the data location, the failover
mechanism and Backup (and subsequent restoration) method. When combined with public and
hybrid cloud constructs, these decision points form the basis for a comprehensive cloud-based
BCDR strategy.
This document will cover these areas as they relate to standard virtual machine/workload
deployments.
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.
2.2 Dependencies
Install and configure Windows Azure PowerShell on local machine.
Complete the configuration of Windows Azure virtual network, local network, and RRAS
gateway.
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
The Active Directory database, logs, and SYSVOL should be placed on a separate Azure data disk
to ensure data persistence through any site repair or recovery, and to ensure 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 organizations requirements dictate such a configuration.
Note: If a cloud service exists, select the existing service and skip to step number 5.
Note: The name of the cloud service is the name of the new virtual machine being created and
can be modified if needed.
Note: The subnet will be filled in based on the affinity. If there are additional subnets, select
the appropriate one.
Note: The site link will be changed to a new Azure to on-premises site link in a later step.
5. In Active Directory Sites and Services under Sites, right-click on Subnets and select New
Subnet.
6. Enter the Prefix to the Azure Virtual Network Subnet (i.e. 192.168.2.0/24).
7. Select the Site created for the Azure domain controller, and click Next.
8. In Active Directory Sites and Services under Sites, then Inter-Site Transports, right-click
on IP and select New Site-Link.
9. 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.
10. Back in Active Directory Sites and Services under Sites, Inter-Site Transports, then IP,
right-click on the Site-Link created in the last step and select Properties.
11. Enter the desired Cost and Replication time in 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.
15. Enter the value of 1 to enable change notifications and a value of 0 to disable.
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. 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, System and Security, then System.
5. Under Computer name, domain and workgroup settings, select Change Settings.
6. In the Computer Name tab, select Change.
7. Select the Domain radial button and enter the on-premises domain and click OK.
8. When prompted, enter on-premises administrator credentials.
9. After the successfully joining the domain, Restart the virtual machine.
Note: The site can be changed in the future if the proper site has not been created yet.
21. Enter and confirm the Directory Services Restore Mode (DSRM) and click Next.
Note: Be sure to change all of the drive paths (X) to the Attached Empty Disk from the
previous section.
25. Review the configuration on the Review Options page and click Next.
26. Review the warnings on the Prerequisites Check page and click Install.
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.
3.2 Dependencies
Complete the configuration of Scenario 1: Host an Active Directory Domain Controller in
Windows Azure, including all dependencies.
Storage required for backups will vary based on the size of your organizations domain
controller virtual machines including the size of the Active Directory database, logs, and SYSVOL.
Windows Server Backup will automatically retain backups on locally-attached dedicated backup
disks and remove old backups as needed. Testing is recommended to determine the most
appropriate backup disk size.
Active Directory domain controller backups are generally only valid within the Active Directory
forest tombstone lifetime. There are situations where domain controller backups older than the
forest tombstone lifetime can be used to initiate a full forest recovery, but this is a complex
scenario outside the scope of this scenario guide. Assistance from Microsoft Support is
recommended if attempting such a recovery.
Domain controller backups must be secured to the same degree as domain controllers. Ensure
that any Azure subscription administrators and co-administrators are trusted to the same degree
as domain administrators.
Note: The data disk need not be initialized or formatted at this time. Windows Server Backup
will automatically initialize and format the backup disk when a backup schedule is configured.
7. In the Show All Available Disks dialog, place a check beside the dedicated data disk for
storing backups, and click Ok
Note: Any existing data on the selected disk will be destroyed. If the instructions in this guide
have been followed, the newly added data disk will not be formatted or initialized and can be
easily identified because it will have no volumes listed in the Show All Available Disk dialog.
Be sure not to select the data disk in use by Active Directory for its database, logs, and/or
SYSVOL.
8. The Select Destination Disk page should now display the data disk to be used for storing
backups. Place a check beside the data disk and click Next. Read the warning about
disk reformatting and click Yes to use the selected data disk.
9. Verify all settings on the Confirmation page and click Finish to format the backup data
disk and create the new backup schedule.
10. Click Close when the backup schedule creation is complete.
Note: Testing the validity and restorability of the backup is beyond the scope of this guide, but
is strongly recommended.
4.1 Dependencies
Install and configure Windows Azure PowerShell.
Note: Change the server names highlighted in yellow and the corresponding IPv4 addresses.
The yellow highlights are the properties of the on-premises network. The green highlights are
properties of the Azure virtual network.
<NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<Dns>
<DnsServers>
<DnsServer name="LocalDC" IPAddress="192.168.5.1" />
</DnsServers>
</Dns>
<LocalNetworkSites>
<LocalNetworkSite name="LocalNetwork">
<AddressSpace>
<AddressPrefix>192.168.5.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress><Local Public IPv4 Number></VPNGatewayAddress>
</LocalNetworkSite>
</LocalNetworkSites>
<VirtualNetworkSites>
<VirtualNetworkSite name="VirtualNetwork" AffinityGroup="YourAffinity">
<AddressSpace>
<AddressPrefix>192.168.2.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
<AddressPrefix>192.168.2.0/28</AddressPrefix>
</Subnet>
<Subnet name="GatewaySubnet">
<AddressPrefix>192.168.2.16/29</AddressPrefix>
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="LocalDC" />
</DnsServersRef>
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="LocalNetwork">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
15. Copy and Paste the configuration in notepad and save as AzureNetwork.netcfg in C:\.
16. Type, Set-AzureVNetConfig -ConfigurationPath C:\AzureNetwork.netcfg and press
Enter.
17. Confirm the values match in the Azure Management Portal -> Networks -> Virtual
Network, Local Network.
Note: Creating the VPN gateway in Azure can take over thirty minutes after running the
command.
20. In the Azure Management Center -> Networks -> Virtual Network -> VirtualNetwork,
select download a VPN Device Configuration Script.
21. For the Vendor select, Microsoft.
22. For the Platform select, RRAS.
23. For the Operating System select, Windows Server 2012 R2.
Note: The script will download as a .cfg file and will need to be changed to .ps1.
1. On the Local Edge server, rename the downloaded VPN Device Script from .cfg to .ps1.