Uncategorized

Azure Data Center Pairings

Author: John Savill

Date: 06/22/2014

Article…

Q: What are the Microsoft Azure data center pairings?

A: All Microsoft Azure data centers are paired with another data center that’s physically separated by hundreds of miles. Data is asynchronously replicated between the two data centers (when the storage account is enabled for georeplication) to protect against an Azure site failure. (Think about a hole-in-the-ground scenario, in which a data center is completely destroyed; you’d want the secondary site to be far enough away to ensure that it wasn’t also affected by the event that caused the primary data center to fail.) Azure data center pairings are as follows:

US West

VNet-to-VNet: Connecting Virtual Networks in Azure across Different Regions

Author: Yu-Shun Wang

Senior Program Manager, Azure Networking

Tuesday, June 17, 2014

Overview

At TechEd 2014, we released Multi-Site VPNs, in-region VNet-to-VNet, and cross-region VNet-to-VNet features. This blog is the first of a mini-series to walk you through the configuration steps and examples of how you can connect your virtual networks together using the VNet-to-VNet feature.

VNet-to-VNet connectivity utilizes the Azure VPN gateways to connect two or more virtual networks together securely with IPsec/IKE S2S VPN tunnels. Together with the Multi-Site VPNs, you can connect your virtual networks and on-premises sites together in a topology that suits your business need. The diagram below shows a simple example of a fully connected topology between virtual networks and on premises sites.

There are several scenarios this connectivity can enable. Below is just a partial list:

  1. Cross region geo-redundancy and geo-presence; e.g., SQL AlwaysOn across different Azure regions
  2. Cross subscription, inter-organization communication in Azure
  3. Regional multi-tier applications with strong isolation boundary; or connecting existing workloads in different VNets together to form new applications

Considerations

There are a number requirements and considerations on the VNet-to-VNet feature documented here. Below is a short list of the key points:

  1. You MUST create or use the Azure Dynamic Routing VPN gateways to connect your virtual networks. Static Routing VPN gateways are NOT supported for VNet-to-VNet.
  2. For each virtual network, you can connect up to 10 “networks”; i.e., both virtual networks and on premises sites combined cannot exceed 10.
  3. You need to ensure that the address prefixes don’t overlap among all the connected networks.
  4. VNet-to-VNet feature works across regions and subscriptions – same or different regions, single or across subscriptions.

With that in mind, let’s build a simple example from scratch to connect the VNets!

Connecting Two VNets in the Same Subscription

From an Azure virtual network, connecting to another virtual network is essentially the same as connecting to an on premises network via site-to-site (S2S) VPN. In this blog, we will start from scratch to create the virtual networks, the VPN gateways, and then connect them together, all within the same Azure subscription. Below lists the steps you will go through:

  1. Create the virtual networks and matching local networks with cross premises connectivity
  2. Create the Azure Dynamic Routing VPN gateways for the virtual networks
  3. Connect the virtual networks together

Using the following diagram as an example, we will create and connect the two virtual networks, VNet1 and VNet2, together:

  • VNet1: Address Space = 10.1.0.0/16; Affinity Group = WestUS
  • VNet2: Address Space = 10.2.0.0/16; Affinity Group = NorthEurope

In the example below, we will be using the Azure PowerShell cmdlets. Please refer to the Azure PowerShell instruction pages to install and configure your PowerShell environments:

Please note that for a simple VNet-to-VNet setup as described here, you can use the Azure Management Portal to carry out steps 1 and 2 below. We use PowerShell because as we continue to add more connections to the VNet (e.g., Multi-Site VPNs), Azure PowerShell cmdlets or REST APIs are the only options to configure these features currently.

[Step 1] Create VNet1 and VNet2 and the Corresponding Local Networks

The first step is to create the two virtual networks, and the matching local networks. From the perspective of each virtual network, e.g., VNet1, the other virtual network, VNet2, is just another VPN connection defined in the Azure platform. As a result, customers must create and define the following connections:

Virtual Network Virtual Network Site Definition Local Network Site to Connect
VNet1 VNet1 (10.1.0.0/16) VNet2 (10.2.0.0/16)
VNet2 VNet2 (10.2.0.0/16) VNet1 (10.1.0.0/16)

Please note that you will need to define each virtual network twice: first as an Azure virtual network, then as a local network site connected to the other virtual network. You must ensure the Address Space elements specified in both definitions are the same, or the communication will not work correctly between the two virtual networks. To make things easy to read, the example uses the same name for both definitions of the virtual network and the local network. This is not a requirement, but will make reading the definitions easier.

The following PowerShell cmdlets create the two Affinity Groups for the two virtual networks. Note that you can re-use existing Affinity Groups of the same regions if you prefer:

PS D:\> New-AzureAffinityGroup -Name WestUS -Location "West US"
PS D:\> New-AzureAffinityGroup -Name NorthEurope -Location "North Europe"

Once the Affinity Groups are created, you can export the current network configuration file (NETCFG.XML) with following cmdlet:

PS D:\> Get-AzureVNetConfig -ExportToFile "D:\MyCurrentNETCFG.XML"

To create the two new virtual networks and the corresponding local networks, use a text editor such as Notepad.exe to insert the following segment into the NETCFG file, in this case, MyCurrentNETCFG.XML:

<LocalNetworkSites>
 <LocalNetworkSite name="VNet1">
 <AddressSpace>
 <AddressPrefix>10.1.0.0/16</AddressPrefix>
 </AddressSpace>
 <VPNGatewayAddress>1.0.0.1</VPNGatewayAddress>
 </LocalNetworkSite>
 <LocalNetworkSite name="VNet2">
 <AddressSpace>
 <AddressPrefix>10.2.0.0/16</AddressPrefix>
 </AddressSpace>
 <VPNGatewayAddress>2.0.0.2</VPNGatewayAddress>
 </LocalNetworkSite>
</LocalNetworkSites>
<VirtualNetworkSites>
 <VirtualNetworkSite name="VNet1" AffinityGroup="WestUS">
 <AddressSpace>
 <AddressPrefix>10.1.0.0/16</AddressPrefix>
 </AddressSpace>
 <Subnets>
 <Subnet name="Subnet-1">
 <AddressPrefix>10.1.0.0/24</AddressPrefix>
 </Subnet>
 <Subnet name="GatewaySubnet">
 <AddressPrefix>10.1.200.0/29</AddressPrefix>
 </Subnet>
 </Subnets>
 <Gateway>
 <ConnectionsToLocalNetwork>
 <LocalNetworkSiteRef name="VNet2">
 <Connection type="IPsec" />
 </LocalNetworkSiteRef>
 </ConnectionsToLocalNetwork>
 </Gateway>
 </VirtualNetworkSite>
 <VirtualNetworkSite name="VNet2" AffinityGroup="NorthEurope">
 <AddressSpace>
 <AddressPrefix>10.2.0.0/16</AddressPrefix>
 </AddressSpace>
 <Subnets>
 <Subnet name="Subnet-1">
 <AddressPrefix>10.2.0.0/24</AddressPrefix>
 </Subnet>
 <Subnet name="GatewaySubnet">
 <AddressPrefix>10.2.200.0/29</AddressPrefix>
 </Subnet>
 </Subnets>
 <Gateway>
 <ConnectionsToLocalNetwork>
 <LocalNetworkSiteRef name="VNet1">
 <Connection type="IPsec" />
 </LocalNetworkSiteRef>
 </ConnectionsToLocalNetwork>
 </Gateway>
 </VirtualNetworkSite>
</VirtualNetworkSites>

The segment above defines two virtual networks, VNet1 and VNet2, and two local networks, also called VNet1 and VNet2. Please note the following before we proceed further:

  1. For simplicity, there is only one subnet (“Subnet-1”) besides the “GatewaySubnet” in each virtual network, and the DNSServersRef element is skipped in the example above. We also skip the “VPNClientAddressPool” element. You can add those elements to your NETCFG as needed.
  2. If you already have “LocalNetworkSites” and “VirtualNetworkSites” sections in your NETCFG, please copy the corresponding “LocalNetworkSite” elements and the “VirtualNetworkSite” elements into those two sections.
  3. The “VPNGatewayAddress” for the LocalNetworkSite is the VIP (Public IP) address of the corresponding Azure VPN gateway for the virtual network. The actual address will not be available until the Azure VPN gateway is created. Right now, we use “1.0.0.1” and “2.0.0.2” as the temporary placeholders for the two addresses.

Once this is done, save the new NETCFG as “MyNewNETCFG.XML”, and use the following PowerShell cmdlet to upload the updated NETCFG file to your Azure subscription:

PS D:\> Set-AzureVNetConfig -ConfigurationPath D:\MyNewNETCFG.XML

This step will take a couple of minutes to complete. Once completed, you will be able to see the virtual networks and the local networks from the Azure Portal.

[Step 2] Create the Dynamic Routing VPN gateways for each virtual network

Once the virtual networks are created with the corresponding VPN connections, the next step is to create the Azure VPN gateway for each virtual network. This can be done through either Azure Management Portal, or Azure REST APIs. Only the Dynamic Routing gateway type is supported. Please note that currently, Azure PowerShell cmdlet “New-AzureVNetGateway” does NOT support creating a dynamic routing gateway. (We are working on filling this gap in Azure PowerShell. Please stay tuned …)

From the Azure Portal, navigate to the “Networks” page, then go to the “Dashboard” page of both VNet1 and VNet2. At the bottom of each page, click “Create Gateway” and select “Dynamic Routing” as shown below:

[Step 3] Connect the VPN gateways

After both gateways are created, you will be able to get the public IP addresses of these two VPN gateways either from the Portal or with the following cmdlets:

PS D:\> Get-AzureVNetGateway -VNetName VNet1 | ft VIPAddress
VIPAddress

Part 2 of 4 – Deploying desktop virtualization

, ,

Author: Enterprise Mobility TeamView article…

This is the second in my series of blog posts about desktop virtualization using Windows Server 2012 R2 and Microsoft Azure. In today’s blog post, I want to talk about how to deploy desktop virtualization. In my last post, I introduced the various desktop virtualization deployment models that we can use, including on-premises, Microsoft Azure, and a combination of both (hybrid). I want to give you an overview of each deployment model and wrap up this post with a discussion about Remote Desktop Session Host (RD Session Host) image management. Let’s jump right in and take a closer look at on-premises deployment.

On-premises

On-premises deployment is pretty straightforward, and there are a number of Test Lab Guides that provide step-by-step instructions for configuring Remote Desktop Services. But the old saying “A picture is worth a thousand words” is appropriate here. Figure 1 illustrates a typical Remote Desktop Services infrastructure deployment. If you’re unfamiliar with what each one of the Remote Desktop Services role services does, check out my first blog or see Remote Desktop Services Overview and the Remote Desktop Service Component Architecture.

Figure 1. Example of on-premises Remote Desktop Services infrastructure

The session-based Remote Desktop Services infrastructure is a prime candidate for virtualization itself. Figure 1 shows which role services can run on the same virtual machine (VM) and which might require one or more VMs. Of course, for testing purposes, you can run all of these in one or two VMs. However, for production environments, you’ll need to scale out further to support user capacity.

Also, it should be pointed out that the file server in this sample infrastructure is running Windows Server 2012 R2 (required to support SMB 3.0). The file server stores user profile disks, backs up data, and provides shared folders in which users can store data and share that data with other users.

Again, check out the Test Lab Guides for more information about deployment.

Microsoft Azure

As illustrated in Figure 2, deploying Remote Desktop Services in Microsoft Azure (IaaS) is very similar to on-premises deployment. There are the same Remote Desktop Services role services as with the on-premises solution. However, you’ll notice some minor differences. For example, the load balancer and traffic manager are virtual entities in Microsoft Azure. Figure 2 also includes the Azure Management Portal, which is used to manage and monitor services running in Microsoft Azure (see my previous blog). Notice that the RD Virtualization Host server cannot be run in Microsoft Azure, as you are unable to virtualize, systems that run virtualization.

Figure 2. Example of Remote Desktop Services infrastructure in Microsoft Azure

You’ll need to synchronize your on-premises Active Directory Domain Services (AD DS) with Microsoft Azure Active Directory (see the AD DS domain controller in Azure). You’ll need to perform this synchronization so that users can use their same domain credentials to sign in to the Remote Desktop Services infrastructure. You can perform synchronization by using the Azure Active Directory Sync tool. For more information about synchronizing Azure Active Directory with your on-premises AD DS, see Administering your Azure AD directory.

Note that this infrastructure contains multiple instances of SQL Server (which supports the RD Connection Broker in high-availability solutions). Also, if you want to support users in multiple cloud services, you can deploy the Remote Desktop Services infrastructure in one cloud service and the RD Gateway and RD Web Access role services in the other clouds.

When deploying your Remote Desktop Services infrastructure in Azure, consider the following:

  • Azure subscriptions have a maximum number of virtual networks, VM cores, storage, and cloud services that can be supported. Consequently, you might need to create multiple subscriptions.
  • Because Azure deployments are partially based on the number and size of VMs, optimize the number and size of VMs to provide the highest cost-performance ratio.
  • Use Azure availability sets when creating solutions that require high availability.

A wealth of deployment information about deploying Remote Desktop Services in Azure is available at Azure Desktop Hosting – Reference Architecture and Deployment Guides, which includes the following guides:

Hybrid

As you might guess, hybrid deployments of Remote Desktop Services combine both on-premises and Azure deployment methods. Typically, you would start with your on-premises deployment and then create your Azure deployment.

As with the Azure deployment model, you will need to synchronize your on-premises AD DS with Azure Active Directory. This synchronization ensures that users can access on-premises or Azure resources by using the same credentials.

You will need also create a virtual private network (VPN) connection between your on-premises desktop virtualization infrastructure and your Azure infrastructure. This connection will allow users to transparently use desktop virtualization on premises or in Azure, and it will allow virtualized desktops in Azure to access on-premises resources. For more information about Azure VPN connections, see Windows Azure Virtual Network Overview and Windows Azure: Virtual Network.

RD Session Host image management

One last deployment topic that I’d like to cover is creating a standard RD Session Host image. Because the recommendation is to use VMs on premises, you can use the same virtual hard disk image for on-premises and Azure deployments. Both System Center 2012 R2 Virtual Machine Manager and Azure support the creation of VM templates, so the idea is to create a VM template in both infrastructures that is based on the same RD Session Host image.

The process is pretty straightforward. Let’s take a look at it.

  1. Install and configure an RD Session Host in an on-premises Hyper-V VM.
  2. Run Sysprep.exe on the VM (to generalize the operating system).
  3. Export the Hyper-V VM.
  4. For on-premises deployment, perform the following:
    1. Import the exported VM as a template in System Center 2012 R2 Virtual Machine Manager.
    2. Deploy RD Session Host servers as required by using the template.
  5. For Azure deployment, perform the following:
    1. Upload the VM virtual hard disk file into Azure storage.
    2. Create a VM template in Azure that has the same configuration as the original VM and uses the VM virtual hard disk file that you uploaded in the previous step.
    3. Deploy RD Session Host servers as required by using the template.

Of course, the big advantage of using this method is consistency in RD Session Host server farms (where you have two or more VMs). You want each VM running RD Session Host within the farm to be identically configured so that users have the same experience, regardless of which VM they connect to.

Another advantage is that this method allows you to quickly “spin up” additional RD Session Host VMs if you need additional capacity. You can always “spin down” or remove the extra VMs later when they aren’t needed.

Summary

That’s an overview of Remote Desktop Service deployment–on premises, in Azure, or both. Clearly, you have the flexibility to place your desktop virtualization infrastructure where it can best support your business and your users. Deploying Remote Desktop Services is easy and requires minimal changes to your infrastructure. And you can grow your Remote Desktop Services infrastructure to meet your demands now and in the future.

But how do we connect devices to our newly deployed infrastructure? That’s the topic of my next blog post! See you then!

NEXT BLOG POST IN THIS SERIES: Accessing desktop virtualization (Coming June 5)

aggbug.aspx?PostID=3632051&AppID=10242&AppType=Weblog&ContentType=0