Building my first Azure network within the Azure Preview mode and tripped up by a few Gotcha’s.

The first thing I did was to provision a new virtual machine and start building servers (as you would), and when coming to add additional machines ran into a few potential issues on the networking side of things.

In Hyper-V and VMware you can dynamically re-assign which network a virtual machines network adapter is connected to.  Unlike Hyper-V and VMware Azure locks the virtual machines configuration into a static state which cannot easily be changed.

The other interesting thing to note about how networking is configured in Windows Azure is that all machines are configured with a DHCP address, and not a static IP address that servers traditionally are configured with.

So second attempt, built my Virtual network using a 10.0.1.0/24 subnet, built a few virtual machines (I haven’t found a way to alter Virtual Machines assigned network settings within the preview so had to re-provision the machines).  Then comes the Active Directory Build.  Once virtual machines have been provisioned on the Virtual Network, the Virtual Network settings are locked.  The only setting that can be modified is sub-netting.  How to change DNS settings issued by Azure DHCP on new virtual machines on the Virtual Network?  You can’t, you need to statically assign the DNS settings on the Local Network Adapter on the virtual machines.  (When provisioning Virtual Networks the first machine built in my findings so far has been .4 so using a Virtual Network of 10.0.1.0/24 your first server would be 10.0.1.4, so you could set this on your Virtual Network before building your first machine which if .4 is assigned you could make your Primary Domain Controller and Primary DNS server).  I have built a few test networks using different subnets (192.168.x.x, 172.16.x.x and 10.x.x.x) and so far every time the first machine is issue .4 as its IP Address.

So second time lucky? Unfortunately not, the next stage of my Azure Network involved provisioning a Site to Site VPN with my new network of Azure Servers and my lab environment.  Unfortunately as per my second attempt, the Virtual Network settings cannot be modified once Virtual Machines have been deployed.  Not only does this include DNS servers etc…. but this includes VPN settings.  The only thing you can change are Subnets on the Virtual Network Settings, and End Point mappings (Published open ports for servers).  Not VPN settings.

So the lesson to learn from this, you can’t just fire up Azure and crash about building machines, you need to plan ahead!

Before you start building Virtual Machines, you need to complete your Topology design, you need to know which Subnets are going to be used for Azure, and which Subnets you would be connecting to via VPN on-premise.  Planning is key here to a successful implementation.

Some points to be aware of within the Azure Preview.

• Only one site per Virtual Network
• Only one Gateway per Site
• Only one Active Tunnel between Site and VNet
• 5 Sites and 5 VNets per Subscription

Now onto the Good points, Its not all doom and gloom.  When provisioning VPN, Microsoft provide sample config files for all major models of Cisco and Juniper firewalls that help getting the VPN up and running as quickly as possible.

The key to a successful Azure Network deployment (as with any IT Project) is planning.

Stage 1) Plan your Virtual Network Settings

In this stage you need to define network names and locations, you need to plan your subnet architecture and placement of DNS servers, You can use On-Premise or Azure DNS services, but if you are looking to build an Office in a Box (Clean AD Install in Azure), be mindful that there are some gotcha’s along the way.

Stage 2) Affinity Groups

When you come to building your Azure Network you will need to build Affinity Groups, these essentially govern which datacentres your infrastructure is provisioned and wherever possible will provision your Azure Network on the same Clusters for optimal performance.

Stage 3) Build, configure and connect any site to site VPNs required before you start building your virtual machines.  This is a painful process to implement or change later.

All of the above said, this Technology is still in it’s infancy and badged as Preview mode.  Things will no doubt get easier as Azure matures (O365 started off bumpy with majority of configuration done via PowerShell, was only with SP2 for Exchange 2010 that Hybrid (Replacing Co-Existence Model) did things start to become fluid.

Remember, the key to success is planning.

Welcome to Azure Networking, A new website dedicated to the virtual networks and virtual machine hosting options introduced at the 2012 TechEd for Windows Azure.

My name is Daniel Dickinson and I work as an Office 365 Solution Architect for UK O365 Market Leader ICS Solutions Ltd. (For more about me visit my personal Blog http://www.ngen.co.uk or my Office 365 Blog http://www.o365ignition.com).

So why start a website about Azure?

Azure Networking brings that missing piece to complete the Office in a Box (Zero Servers required On Premise) to build an Enterprise Capable Infrastructure.  With Office 365 Microsoft took Exchange, Lync and SharePoint out of the On Premise arena and into the Cloud, but to get the best from Office 365 (Rich Co-Existence, Hybrid, Single Sign On) you still needed On Premise servers for Active Directory Domain Services (AD DS) and Active Directory Federated Services (ADFS).  Now with Azure, true Office in a box, or Office in the cloud is a reality.

Cloud computing has been building momentum over the past 5 years, but now we are starting to see it mature and a change in how both Consumers and Businesses think about IT.

A new culture of BYOD (Bring Your Own Device) and WFA (Work From Anywhere) is here.  The next few years in IT are going to be very interesting.
So welcome to my new website, where I hope to share my journey into this exciting new era of true Next Generation IT.