Deconstructing JSON: Tale of Two VNETs (Linked templates with VNET peering!)

The last month or so has been packed with announcements and training! I’ve been to Ignite in Atlanta, as well as some internal training and some fun community events.  Finally, I’ve had some time to sit down and work on trying out a few things.  If you missed the announcement around Ignite time, Azure VNET Peering is now generally available.   With peering, you can now link virtual networks together without having to set up multiple VNET gateways.

This peering feature can be set up using the Azure Portal, but what fun is that, right?  Let’s do it with some ARM templates instead.  My goal was to create two VNETs with different address spaces (you can’t peer networks with an overlapping address space) then peer them together.  I could do this with one big template, but I wanted to also take some time to try out linking templates together – where one parent template calls others.  I also wanted to take advantage of parameters files to create the different VNETs.

For this example, I ended up with five JSON files:

  • azuredeploy.json – The deployment template for one VNET
  • vnet1.parameters.json – The parameters file for VNET1
  • vnet2.parameters.json – The parameters file for VNET2
  • peeringdeploy.json – Template to peer together the networks once created
  • parentdeploy.json – The template used to manage the complete deployment

Within the parentdeploy.json file we only need to define the schema and resources sections and the only resource I’m calling is the “Microsoft.Resources/deployments” type.  Within that, you’ll need to define a name, mode, template link (located in a repo or blob storage) and an optional parameters link.  For this deployment, I’m calling the deployment resource three times – once for each vnet, plus a final time to peer them. In the snippet below, you can see that I called the azuredeploy.json file and the vnet1.parameters.json file.

     "apiVersion": "2015-01-01", 
     "type": "Microsoft.Resources/deployments", 
     "name": "linkedTemplateA", 
     "properties": { 
       "mode": "Incremental", 
       "templateLink": {
       "parametersLink": { 

The second resource uses the same template link and uses the vnet2.parameters.json file.  Finally, the last one will only call the peeringdeploy.json template with no parameters file needed. Each deployment resource needs it’s own unique name and you can’t reference anything directly that isn’t included in the template itself.   There are also ways to share state between linked templates to be even more “elegant” in your template creation.

Within the peeringdeploy.json template we also only need to define resources which link the newly created VNETs together. In the snippet below, you can see BigNetA (created with vnet1 parameters) being connected to BigNetB (created with vnet2 parameters).

    "apiVersion": "2016-06-01",
    "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
    "name": "BigNetA/LinkToBigNetB",
    "location": "[resourceGroup().location]",
    "properties": {
    "allowVirtualNetworkAccess": true,
    "allowForwardedTraffic": false,
    "allowGatewayTransit": false,
    "useRemoteGateways": false,
        "remoteVirtualNetwork": {
        "id": "[resourceId('Microsoft.Network/virtualNetworks', 'BigNetB')]"       

Finally, as with all my previous templates, I can deploy the whole thing with just one line of PowerShell!

 New-AzureRmResourceGroupDeployment -ResourceGroupName $RGName -TemplateUri $templateFileURI -verbose


Microsoft Cloud Networking – The Poster!

If there’s one thing I’ve learned while doing IT, it’s that nothing is really simple.  And with the addition of the “cloud” when it comes to providing services for your business or your customers, things just keep getting more complicated.  Remember the days where you had one nice T1 coming into your office and all was right in the world?  (Ah… the good ol’ days….)

Anyway, sometimes when you are looking at changing the networking for your company to support more cloud offerings like Office365 or moving workloads into Azure, you could really use a cheat sheet to get you pointed in the right direction and give you some insight into what you might need to research further as you work on your design.  Enter the “Microsoft Cloud Networking for Enterprise Architects” poster!

This printable, 8-page poster (it fits on legal paper) gives you the skinny on the design components and considerations for networking in the cloud age.  Topics cover are:

  • Evolving your network for cloud connectivity  Cloud migration requires changes to the volume and nature of traffic flows within and outside a corporate network.
  • Common elements of Microsoft cloud connectivity  Integrating your networking with the Microsoft cloud provides optimal access to a broad range of services.
  • Designing networking for Microsoft SaaS (Office 365, Microsoft Intune, and Dynamics CRM Online)  Optimizing your network for Microsoft SaaS services requires careful analysis of your Internet edge, your client devices, and typical IT operations.
  • Designing networking for Azure PaaS  Optimizing networking for Azure PaaS apps requires adequate Internet bandwidth and can require the distribution of network traffic across multiple sites or apps.
  • Designing networking for Azure IaaS  Optimizing networking for IT workloads hosted in Azure IaaS requires an understanding of Azure virtual networks (VNets), address spaces, routing, DNS, and load balancing.

There are several other posters that might be of interest as well, focusing on identity, security and storage. Find them with some other handy resources for IT architecture.

The Imperfect Lab: Azure Networking – Two Ways

Around this time last year, I kicked off my “Imperfect Lab” and used it as a story to play around in Azure and get more comfortable with PowerShell. And then I got busy with some other work priorities (as we all do) and I shut down those VMs, with the hopes of dusting them off in the future to continue with more learning.

At any rate, with all the changes to Azure in the last year, it’s really time to reboot the Imperfect Lab and give it a new shine, using some of the fresh new tools – particularly the *new” Portal, Azure Resource Manager (ARM), Azure PowerShell 1.0 and Templates.

Let’s recap what I have to start with (all in “classic” Azure Service Manager)

  • A cloud service and related virtual network
  • Two domain controllers (one using the minimal interface and one running core)
  • One member server that runs the AD Sync service
  • Traditional AD synced to Azure AD

So now where to begin?

When using ARM, it’s no longer possible for the creation of a VM resource without a virtual network, so it seemed fitting for me to start with the network.  It’s also not possible to mix ASM and ARM resources, I’ll be using this network to deploy all the lab VMs I’ll be using in ARM going forward. For those of you who aren’t familiar with old-school Azure, the classic mode (aka Azure Service Manager or ASM) made it possible to create resources in a cloud service without an user-manageable virtual network.

One of the other tasks that was difficult using ASM was programmatically creating and updating networking. It required downloading and editing an XML file and I found that generally distasteful. With ARM, you’ve got two options – straight up PowerShell or an ARM Template.

If you don’t know where to begin with an ARM Template, you can check out this repository of Azure Quickstart Templates. To create a basic network with two subnets, I used this one –

You can deploy this template using the Azure portal (which will allow you to adjust the parameters to your liking) or you can edit the template to your meet your needs or you can deploy it as is via PowerShell. If you want more details on the ways you can deploy templates, I recommend reading this –

The other option is use just vanilla PowerShell from the command line or via ISE. I used the following, which is using PowerShell 1.0:

$vnetName = "ImperfectRMNet"
$RGroup = "ImperfectRG"
$Location = "West US"
New-AzureRmResourceGroup -Name $RGroup -Location $Location
$subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name SubNet6 -AddressPrefix ""
$subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name SubNet7 -AddressPrefix ""
New-AzureRmVirtualNetwork `
 -Name $vnetName `
 -ResourceGroupName $RGroup `
 -Location $Location `
 -AddressPrefix "" `
 -Subnet $subnet1, $subnet2

Take note that with PowerShell 1.0, there is no “Switch-AzureMode” cmdlet and all of the “New” commands include “RM” in the cmdlet somewhere to differentiate between creating classic Azure resources.  There is nothing else to this basic network, no external IP address or load balancer that would normally come default with a cloud service in ASM.

The Imperfect Lab: Connecting a VNET to another VNET

As I mentioned yesterday, I’m struggling with setting up the “perfect” lab environment for myself. So instead of trying to make it perfect, I’m just going to start by simply getting started and letting in evolve.  Because starting is most of the battle, right?  Most environments grow and change and become a bit messy, so I am just going to embrace a little chaos!

My starting goal is to create two networks in Azure (in two different regions) and connect them.  To start I’ll need two VNETs in Azure. I also created two corresponding storage accounts in each region, so that when I’m building my servers, everything is as neat an organized as I can make it.

In each of the networks, I carved out a few subnets, because I don’t know exactly what I’m doing with them yet. Keep in mind you will need to make at a small Gateway subnet in each. Also, as soon as you put a VM in a subnet, you can no longer edit it.

  • ImperfectNet – (West region)
  • AnotherNet – (East region)
Because I want to connect them together with site-to-site networking, I have to create corresponding “local” networks in Azure to sort of trick each network into thinking its connecting to a physical network.  So under the “Local Networks” tab, I created “ImperfectLocal” and “AnotherLocal” with the same IP address ranges as the virtual networks. Be sure to put in a fake VPN Gateway Address as a placeholder here, you’ll update it later after Azure gives you a real gateway address.

In each network, I threw the ticky-box under Site-to-Site Connectivity, selected the correct “local” network and then created the Gateway subnet.  After everything was finished configuring, when you return to the dashboard page of each network, you will see the remote network showing.  Azure will tell you that “the gateway was not created”.
Click “create gateway” at the bottom. For VNET to VNET connectivity, you have to go with Dynamic Routing.  Do this for each network and wait for it to complete.  (Creating gateways actually takes a while, this might be a good time to get lunch.)
Once your gateways are created, write down the IP addresses carefully and then edit those “local networks” with the fake VPN gateways to the correct ones Azure just assigned you.
Finally, you have connect the networks together with shared key.  There isn’t any way to do this in the portal, so pop over to PowerShell and use the following code to hook them together.  You have to run the command twice with the corresponding network names and the SAME shared key. Please make your key longer then the sample I put in here.

Set-AzureVNetGatewayKey -VNetName YourVNETName -LocalNetworkSiteName TheOppositeLocalNet -SharedKey abc123xyz

Set-AzureVNetGatewayKey -TheOtherVNetName YourVNETName -LocalNetworkSiteName TheOtherLocalNet -SharedKey abc123xyz

So now I’ve got two connected networks in Azure, albeit empty of servers.  Next up… starting to build out my “imperfect” domain.

One more thing… if you want the offical “Azure” instructions for this, complete with images, go to  

Modernizing Your Infrastructure with Hybrid Cloud – Week 3 Has Arrived!

This week’s focus is on networking. It starts out with Kevin Remde and Keith Mayer continuing the series on “Modernizing Your Infrastructure with Hybrid Cloud” and in today’s episode they discuss various options for networking. Tune in as they go in depth on what options are available for hybrid cloud networking as they explore network connectivity and address concerns about speed, reliability and security.

  • [2:46] What components are involved in Hybrid Cloud Networking?
  • [5:30] What are some of the technical capabilities of Hybrid Cloud networking?
  • [9:25]  Which VPN gateways are supported with Microsoft Azure?
  • [11:28]  What are some of the common scenarios that customers are implementing for Hybrid Cloud networking?
  • [15:40]  Besides Site-to-Site IPSec VPNs, are there any other connectivity options for Hybrid Cloud networking?
  • [20:10] DEMO: Can you walk us through the basic steps for setting up a Hybrid Cloud network?
Check back at as the week progresses for some related blog posts:
  • Tuesday: Step by Step: Setting a Static IP address on your Azure VM by Brian Lewis
  • Wednesday: Building Microsoft Azure Virtual Networks by Matt Hester
  • Thursday: Cross-premises connectivity with Site-to-Site VPN by Kevin Remde
  • Friday: Cross-premises connectivity with ExpressRoute by Keith Mayer

Making Sense of DNS Queries: Recursive or Iterative?

I’ve been dealing with DNS for a pretty long time.  It’s always been a key component of keeping Active Directory and all the clients on your network happy and connected.  But for the life of me I can never seem to remember which is which when it comes to recursive or iterative DNS queries.  It’s like a trivia question that has just gone wrong in my brain.

Today at work, I was was asked one of those “Hey, do you know who would do X?” questions by a colleague and as I was hunting down the answer, I realized it was just like DNS queries!  
Simply put, if you ask your manager a question and he/she comes back with the complete answer, you have just performed a RECURSIVE query.  You asked and someone else took on the responsibility of locating the correct answer.  
If you ask your manager a question an he/she comes back with a referral directing you to ask a different person, that is an ITERATIVE query.  You are responsible for walking the tree of your organization, theoretically getting closer and closer to the answer with each query you make.  Iterative starts with I and “I” do the work to find the answer. 
Sometimes it just takes a real life example to make concepts stick. However if you want technical details go here:

Azure DNS: What Comes First?

Oh, it’s that age old question – what comes first? The chicken or the egg?  With Windows Azure, the question often is about DNS. What comes first?  The IP address of the DNS server or the machine itself?

Honestly, it depends on what you plan on doing with your virtual machines and how you utilize the virtual networks.

Option 1: Spin up a VM as a “Quick Create”
When you do this, you are creating a VM without a custom virtual network that you control. The Azure fabric will assign an external IP address (VIP) and an internal IP address (DIP) isolated from all other machines. An appropriate DNS server from the fabric will be injected and your DNS name will be registered so your VM can be reachable from the Internet. All is done.

You could create other VMs the same way and the only way they would be reachable from one to the other is over the Internet via ports you opened. They would not share any “internal” networking.

Option 2: Create a Virtual Network and the create VMs attached to your VNET.
When you do this, you are controlling the internal address assignments and purposely joining VMs to that network so they can communicate with each other.  For that they need an “internal” DNS server.
Because the DNS settings are injected into the VM upon boot, you must have the IP address of that DNS server in mind before you begin and assign it within your Virtual Network settings, before creating the VMs themselves.

This DNS server could be from your on-premises network (if you are creating a site-to-site VPN) or one that does not yet exist in your Azure VNET, like an server acting as an Active Directory DC, perhaps.
When you create a virtual network, take note of the first IP address that would be assigned to a machine, or you can now choose to statically assign IP addresses using PowerShell. Add that address as the DNS server in your virtual network.  Then when you create VMs they will know to use the internal DNS you specify as the primary DNS.

An external address (VIP) would still be automatically assigned and the name of the cloud service would be either your server name or something else that fits into the design of what you are trying to accomplish. That DNS name would still be registered with Azure DNS, but your internal IP address would be registered with the DNS server you specified.

Happy networking!

For more “Pieces of Azure” find them here: