Microsoft Azure

A Tale of Two Azures


Did you know that there are two versions of Azure? Yes; and they are completely different. There are also some situations and solutions that you now take for granted and will not be available to you. In this article, I’ll explain why Azure’s left brain is not talking to its right brain.

Microsoft Azure’s Split Brain

Microsoft Azure evolved into something new last year. You might not have known, but when you worked with resources in Azure, you were working with the Service Management model, also known as V1. If you worked with virtual machines in this classic deployment, then you created a virtual machine on a virtual network. A cloud service, with optional load balancing, provided a public IP address that you could implement NAT-style endpoints with.

A classic Service Management virtual machine deployment (Image Credit: Microsoft)
A classic Service Management virtual machine deployment (Image Credit: Microsoft)

Every item in that deployment was created by hand, and scaled out deployments required lots of PowerShell.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

Microsoft introduced Azure Resource Manager (ARM), also known as V2, with the new Azure Portal to move to a template-based approach of deployment. This style can speed up deployment, scale it out more easily, and reduce human effort. A virtual machine deployment in ARM is very different to a Service Management one. The most noticeable differences are:

  • The cloud service is no longer used.
  • A load balancer must be constructed to create load balancing and NAT rules.
A virtual machine deployment using Azure Resource Manager (Image Credit: Microsoft)
A virtual machine deployment using Azure Resource Manager (Image Credit: Microsoft)

From an implementer’s perspective, an ARM deployment is much more complex. Currently there’s no user interface for the load balancer, and it must be built using some nasty looking PowerShell — note that I am not scared of PowerShell, but I find this feature to be off-putting.

The differences go way beyond virtual machines. Every aspect of Azure is affected. You cannot assume that if something was available in Service Management that it will be available in ARM. Some features in ARM can only be deployed via PowerShell (Azure Backup) and others do not have support yet (Azure RemoteApp).


The other big differences affect management:

  • You must be running Azure PowerShell 1.0 or later to use the generally available set of ARM cmdlets. You can access the ARM cmdlets after you log into ARM using Login-AzureRmAccount (we use Add-AzureAccount to log into Service Management).
  • The old management portal can only be used to manage Service Management. The new Azure Portal can be used to manage both a lot, but not all, of the Service Management components (no support yet for Azure Backup, Azure Site Recovery, RemoteApp or Azure AD) and ARM.

Note that if you are using the new Azure Portal, then Service Management components will appear under different blades. For example ARM virtual machines appear in a blade called Virtual Machines, and Service Management virtual machines appear in a blade called Virtual Machines (Classic).

Purchasing Azure

How you purchase Azure will affect what models of Azure are available to you. You will have both Service Management and ARM if you acquire Azure via:

  • Trial/MSDN/Direct Billing
  • Enterprise Ageement
  • Open Licensing credits

However, Microsoft has been making a big push on a new cloud sales and distribution channel called Cloud Solution Provider (CSP) since the WPC 2015 (Worldwide Partner Conference in July) of last year. This channel allows selected large resellers and distributors to resell Azure to customers and smaller resellers with monthly post-usage billing. This channel has proven to be very interesting to Microsoft partners, but there’s a catch with Azure; Azure in CSP does not support Service Management. This means that solutions that require, or might require at a later time, features are not in ARM or that are too hard to implement in ARM without a UI will not be suitable or CSP.

My Opinion

It is very early days for ARM, but I like what Microsoft wants to do. The potential to create complex solutions from templates really does simplify and accelerate deployment. It’s going to be at least five months before we have feature parity with Service Management, so those customers that are building IaaS (infrastructure) solutions probably should stick with Service Management for now. I also hope that Microsoft deals with some of the deployment complexity; the older interfaces in the Management Portal for VPN, endpoints, and availability sets are much easier to use and more reliable that their equivalent in ARM/Azure Portal. But eventually, I think Microsoft will get things right with ARM, and I’ll be happy to switch over at that time.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: