By now, I hope you’ve read Part 1: Introduction to get everything set up and ready.

Much of the documentation on Windows Azure is confusing when it comes to networking. There are a few reasons for this:

• Networking, specifically virtual networks were released later in the lifecycle.
• Since Windows Azure has its beginnings in PaaS, the concepts don’t necessarily apply to IaaS.
• Terminology changed, for example “Cloud Service” was first called “Hosted Service,” and some API’s still use the term.

Networking Definitions

If you keep those things in mind, and pay attention to the date of publication for whatever article you’re reading, it should help you understand what’s being written about. In this article, I’m going to highlight just a few networking concepts as they relate to IaaS and then we’ll start creating our network.

There are 3 definitions we need to know to start:

Virtual Private Network (VPN) – A VPN creates a private network that operates like a local network but spans greater distances. We’re not going to create a VPN for our scenarios, however you could do so to protect your Windows Azure virtual machines from external access.

Virtual Network – A virtual network in Windows Azure is a container where you define the IP address ranges your virtual machines may use. Windows Azure uses infinite-lease DHCP addresses and you can’t assign static IP addresses.

• By defining your IP addresses with a virtual network, you can control which IP’s are given to your virtual machines.
• This is also where you can define a DNS server. Any virtual machine in a specific virtual network will be automatically assigned the DNS server specified.
• Finally, you must assign an Affinity Group to your virtual network. This way, all VMs in your virtual network can be hosted closely together (i.e., same datacenter).

Cloud Service – Formerly called Hosted Service. A Cloud Service comes from the PaaS world but allow me describe how it’s useful in the IaaS world. A Cloud Service is also another container. You can assign a subnet to a Cloud Service, which allows you better control of how your IP addresses are assigned. We’ll use this concept later for our domain controllers. Cloud Services have other benefits as well:

• Separation of “roles,” which allow you to start up one Cloud Service before others start. For example, our domain controllers will be in their own Cloud Service and we want this one to start up first since everything else depends on it.
• Separation of “roles” also permits us to have different external entry points. For example, we’ll open up ports 80 and 443 for SharePoint but we don’t want these open for our domain controllers.
• By creating two or more endpoints within a Cloud Service that have the same port number, Windows Azure recognizes a need for a load balancer and automatically load balances those endpoints.
• You have the ability to export and import configurations of a Cloud Service. We’ll look at this in more detail later and why it’s so important.
• Virtual Machines within a Cloud Service can communicate freely over any port and protocol. Cloud Services within a Virtual Network can also communicate freely over any port and protocol.

So with that, I hope I’ve convinced you to use Virtual Networks and Cloud Services wisely to design your network and SharePoint Farms. Without using these concepts, you could have problems with farms communicating with each other, DNS issues, security issues due to exposing too many endpoints and complicated setup of load balancing.

Paul Stubbs (@paulstubbs) was the source again for most of this information and I’ve added a link to his blog in the resources section.

Virtual Network

We want to create a virtual network and an associated Affinity Group. We’ll do this using PowerShell because it’s easier, repeatable, and it documents what we’re doing. First, we need to create an XML-based configuration file. Use your favorite text editor (mine is Notepad++) and create a new file with the following contents:

 
   
     
   
 
   
     
       
         192.168.0.0/16
       
     
       
         192.168.1.0/29
       
       
         192.168.2.0/24
       
     
         
             
         
       
     
   

Name this file SharePointFarmVNET.xml. Feel free to change the network range and subnets to your desire. However, keep the following things in mind:

• By default, Windows Azure assigns the first VM an x.x.x.4 address. We’ll spin up our domain controller first, which will be our DNS server so it will have that .4 address. You should probably keep this as is.
• We want our domain controllers to have a small IP range. In CIDR notation, a /30 gives you just 2 usable host addresses but Windows Azure doesn’t allow this. The next smallest is a /29, which gives 6 usable host addresses so that’s what we’ll use.
• You can add as many DNS addresses as you want.
• All the Subnets must be a part of the overall Address Prefix. Search for “subnet calc” online to find calculators if you want more specific IP address ranges and read up on “CIDR notation.”

Now that we’ve defined our network, let’s create it. First, let’s do a quick connection test. Open Windows Azure PowerShell and type in the following:

Get-AzureSubscription | Select SubscriptionName, CurrentStorageAccount 

Next, we’ll assign those values to some variable. I’m going to use my values, be sure to substitute these for your own.

$subscriptionName = "Windows Azure Wahid"
$storageAccount = "wahidstore" 
Select-AzureSubscription $subscriptionName 
Set-AzureSubscription $subscriptionName -CurrentStorageAccount $storageAccount

Next, we need to pick an Affinity Group. To see a list, use:

Get-AzureLocation | Select Name 

Select one and specify it below for $AGLocation. The Affinity Group is one of the most important decisions you can make. Everything will be tied to this. I made a mistake once and chose the wrong Affinity Group and to change it, I had to delete my virtual network, storage account, VMs and a bunch of other things. The Affinity Group you choose here must be in the same datacenter as your disks (storage account).

# Affinity Group parameters 
$AGLocation = "East US"
$AGDesc = "SharePoint 2013 Architecture Affinity Group"
$AGName = "AG-Arch-SharePoint" 
$AGLabel = "AG-Arch-SharePoint" 

Now we’ll create the Affinity Group:

# Create a new Affinity Group 
New-AzureAffinityGroup -Location $AGLocation -Description $AGDesc ` 
-Name $AGName -Label $AGLabel 

We shouldn’t have a virtual network configuration but if you do and want to clear it, use:

Remove-AzureVNetConfig -ErrorAction SilentlyContinue 

Finally, we apply the network configuration

# Apply new network. Either use the full path or run PowerShell from the location of the XML file.
$configPath = "C:\Scripts\Azure\SharePointFarmVNET.xml" 
Set-AzureVNetConfig -ConfigurationPath $configPath

That’s it, we’ve created an Affinity Group and virtual network. To verify and check our results, type in:

Get-AzureVNetConfig | Select -ExpandProperty XMLConfiguration 

Domain Controllers

Next, we’ll create our Cloud Service container and domain controller. Most of this should be self-explanatory.

• If you’ve uploaded your vhds, just follow along.
• If you’re creating brand new vhds, pay special attentions to the notes.

For $diskname, put in the value of the disk that has been uploaded. And for $subnet, $vnetname, and $ag, use the values from the previous steps, when you created them.

Remember, csupload adds the disks to the repository for you but CloudXPlorer or other tools may not. First, check to see if the disk is in the repository by typing:

Get-AzureDisk | select diskname 

If it’s not there, you’ll have to add it now. For example,

Add-AzureDisk -DiskName "Arch-DC-1.vhd" -MediaLocation "https://wahidstore.blob.core.windows.net/vhds/Arch-DC-1.vhd" -OS Windows 

Let’s continue. The commands below setup the variables, create a VM configuration and setup the Cloud Service variable.

Note: If you don’t have an existing vhd in Azure and just want to create a new one, comment out the $diskname and uncomment the last 3 lines.

## Domain Controller 1 Parameters
$vmName = 'Arch-DC-1'
$diskName = "Arch-DC-1.vhd"
$size = "ExtraSmall"
$deploymentName = "SP2013-DC1-Deployment"
$deploymentlabel = "SharePoint 2013 DC1 Deployment"
$subnet = "DomainControllers"
#$imageName = 'MSFT__Win2K8R2SP1-120612-1520-121206-01-en-us-30GB.vhd'
#$vmStorageLocation = "http://wahidstore.blob.core.windows.net/vhds/Arch-DC-1.vhd"
#$password = "pass@word1"

Now we create the VM configuration.

Note: If you’re creating a new vhd instead of using one that was uploaded, uncomment and use the second set of commands instead of the one that follows.

## Create VM Configuration if using uploaded vhd
$dc1 = New-AzureVMConfig -Name $vmName -InstanceSize $size -DiskName $diskName | Add-AzureEndpoint -Name 'RemoteDesktop' -LocalPort 3389 –PublicPort (Get-Random –Min 10000 –Max 65000) -Protocol tcp
Set-AzureSubnet -SubnetNames $subnet -VM $dc1

I found that when creating VMs this way, no endpoints are created. If you want to be able to use Remote Desktop to administer the machine, you need to add the endpoint like I’ve done above (using Add-AzureEndpoint).

## Create VM Configuration if creating new VM
#$dc1 = New-AzureVMConfig -Name $vmName -InstanceSize $size -ImageName $imageName -MediaLocation $vmStorageLocation 
#Add-AzureProvisioningConfig -Windows -Password $password -VM $dc1
#Set-AzureSubnet -SubnetNames $subnet -VM $dc1 

The rest is the same whether you’re just attaching an existing vhd or creating from from an image:

## Cloud Service Paramaters 
$serviceName = "ArchDC"
$serviceLabel = "ArchDC"
$serviceDesc = "Architecture Domain Controllers"
$vnetname = 'vNet-Arch'>
$ag = 'AG-Arch-SharePoint'

When we do the next part, New-AzureVM, it will first create the Cloud Service for us and then create the VM using the disk we specified.

## Create the VM(s)
New-AzureVM -ServiceName $serviceName -ServiceLabel $serviceLabel -ServiceDescription $serviceDesc -AffinityGroup $ag -VNetName $vnetname -VMs $dc1

My output looks like this:

So let’s wrap up. We’ve created a virtual network with 2 subnets, we’ve created a Cloud Service in that virtual network, and we just created a virtual machine in that Cloud Service. Here’s how our little deployment looks right now:

What’s next? We’ll create our SharePoint Farm, including the SQL Servers.

Resources

Paul Stubbs Blog: http://blogs.msdn.com/b/pstubbs

Series Navigation

SharePoint on Windows Azure – Part 2: StorageSharePoint on Windows Azure Part 1: IntroductionSharePoint on Windows Azure – Part 4: SharePoint Farm