Microsoft has offered Windows Azure since early 2010. But the April release of Windows Azure Infrastructure Services now allows IT to use the cloud service to deploy VMs and apps designed to run on Windows Server, including SQL Server, SharePoint, and other apps and infrastructure (see the June 2013 feature, "Deploy VMs in Windows Azure," for more on Windows Azure Infrastructure Services).
If you're planning to use Windows Azure as an extension of your datacenter, it makes sense to create a hybrid Active Directory forest in which domain controllers exist on-premises and in the cloud. The reason for this is many server applications require Active Directory access, and you really don't want apps running in the cloud to have to consult an on-premises DC every time they need to perform an operation. Not only is doing so inefficient, but a WAN failure could cause an app to malfunction due to its inability to contact an on-premises DC. As such, it's important to extend your Active Directory to the cloud. Microsoft is enabling that through its new Windows Azure Active Directory (WAAD).
On the surface, the idea of extending your existing Active Directory forest to Windows Azure seems deceptively simple. After all, Windows Azure makes use of VMs running exactly the same Windows OSes that can be run on-premises. Besides, organizations routinely extend Active Directory forests to off-site datacenters all the time, so why should extending an Active Directory forest to a Windows Azure cloud be any different?
Creating a hybrid Active Directory by using a mixture of on-premises and cloud-based DCs is no different than building a multi-site Active Directory forest. As is the case with many things in IT, the devil is in the details.
Prerequisites to Deployment
As I guide you through the process of deploying WAAD, I'll presume you already have an on-premises directory in place. I'll also assume you have a basic working knowledge of Active Directory and DNS.
Just as important, your on-premises network must include an externally accessible VPN server. You should provision this VPN server with a static IP address that's publicly accessible. It requires a VPN in order to establish connectivity between the servers that are hosted on Windows Azure and your on-premises servers.
Throughout the course of my deployment evaluation, I established a virtual network on Windows Azure, but this virtual network wasn't externally accessible. The easiest way to establish connectivity between the on-premises network and the Windows Azure virtual network is to make use of your on-premises VPN.
Set up a Hybrid Active Directory
The first step in the process is to open the Active Directory Sites and Services tool and create a new WAAD site. To do so, right-click on the Sites container and choose the New Site command from the shortcut menu. When the New Object - Site dialog box appears, enter "Azure" as the site name, select the DEFAULTIPSITELINK and click OK (see Figure 1). Upon doing so, you should see a message indicating the new site has been created. Click OK to clear this message.
Build a replica DC on a VM running on top of Windows Azure. Set this up with the presumption that Windows Server is already installed on the replica DC and the replica DC has been assigned an IPv4 address. Make note of the address that you're using for your replica DC.
Go back to the on-premises DC and, from within the Active Directory Sites and Services console, right-click on the Subnets folder and choose the New Subnet command from the resulting shortcut menu. When the New-Object Subnet dialog box appears, enter the subnet in the Prefix dialog box. The prefix must be entered in Classless Inter-Domain Routing (CIDR) notation (for example, 157.54.208.0/20). Select the Azure site object before clicking OK.
So far you've configured the on-premises Active Directory forest to recognize a new site, but haven't yet established communication between the two sites. Furthermore, the WAAD instance is dependent on DNS. Typically the on-premises DNS server used by Active Directory isn't externally accessible. This is a problem because the replica DC hosted on Windows Azure will need access to the on-premises DNS.
The first step in making the server externally accessible is to register the on-premises Active Directory-integrated DNS server with WAAD. This allows you to associate the DNS server with the Windows Azure virtual network. To accomplish this, you can open the Windows Azure Management Portal and click on the Networks link found in the navigation pane. Then click the New button and select the Networks | Virtual Network | Register DNS Server options (see Figure 2). Enter the name of your on-premises DNS server into the name field and then enter the DNS server's IP address into the DNS Server IP Address field.
You're also going to need to have WAAD integrated with a DNS server. Therefore, click the New button and navigate to Networks | Virtual Network | Register DNS Server. Now, enter the name and IP address that you'll use for your cloud-based DNS server.
Establish Connectivity
Once you've registered the on-premises and the cloud-based DNS servers, the next task is to provide connectivity between the two networks. This is done by establishing site-to-site VPN connectivity between the on-premises network and the Windows Azure virtual network.
From the Windows Azure Management Portal, click on the Networks link and then click on the New button. Next, click on Networks | Virtual Network | Custom Create. Windows Azure will launch the Create a Virtual Network Wizard. Enter a name for the virtual network and then select the appropriate affinity group.
At this point, you must click the arrow icon to move to the Address Space and Subnets page. Click on the CIDR button and then use the Add Address Space button (and, optionally, the Add Subnet button) to define the address space and any required subnets for the virtual network (Azure, which you named earlier).
No comments:
Post a Comment