Microsoft's cloud licensing sets up a compliance nightmare

Beware! Running Microsoft software in the cloud is a confusing mess with serious pitfalls

On the list of items that IT pros would rather never have to think about, software licensing takes a close second behind backups. Holding frequent license compliance checks and ensuring that licensing is purchased as it's needed is frequently a challenging, time-consuming process. All too often, these tasks are neglected, leaving many enterprises open to substantial legal liability.

As I've noted before, the licensing landscape is no better when you move into the cloud. In fact, it grows substantially more confusing, both for users and for the cloud providers seeking their business.

Most enterprises purchase their Microsoft software through one of Microsoft's volume licensing mechanisms, such as the Open Business, Open Value, Select, and Enterprise agreements. These licensing plans all differ in various respects -- primarily in terms of what kind of discount is granted (usually based on volume), how payment for the software is spread out, and whether the software is licensed as a subscription or as a permanent license. Regardless of which licensing channel you buy through, you're essentially buying the same usage rights, and you're always responsible for complying with the agreement's terms.

How Microsoft's cloud licensing works in the cloud
That equation changes entirely when you move to the cloud. If you read the fine print of the license agreements that you agree to when you install the software you've bought for your on-premises environment (we all do, right?), you see that most licenses require that the software be installed on hardware you own. Although you could install that software on your own hardware even if it's squirreled away in a colocation center, you're not allowed to install it on a public cloud such as Amazon's EC2 (at least not without jumping through some hoops first -- more on that later).

Of course, there are legal ways to run Microsoft software in the cloud. The primary mechanism is through the SPLA (service provider licensing agreement). Cloud service providers sign an SPLA, so they can effectively rent Microsoft licenses to their customers. A cloud service provider can license its server farm for Microsoft Server, stand up a wide range of Microsoft products on its gear, then allow you to access those Microsoft applications.

Although some products (such as the actual Windows Server OS you access) are licensed on a per-processor basis, many are licensed with SALs (subscriber access licenses). These SALs differ from the more commonly known CALs (client access licenses) in that they effectively license the server product.

As an example: For an on-premises installation, you might buy a Microsoft Exchange license for each server you run it on and a certain number of Exchange CALs to allow your users to access Exchange. Under the SPLA, by contrast, a provider simply needs to keep track of how many users are using Exchange and pay for that usage every month. It doesn't need to know how many instances of Exchange Server are running.

This is attractive for cloud users because it takes the burden of license compliance off their shoulders, and it converts large licensing investments into a monthly operational cost that can flex with the organization's needs. In other words, it does exactly what the cloud is supposed to do: make things easier.

The many gotchas in Microsoft's cloud licensing
Unfortunately, there's a catch. Actually, there are quite a few of them. Most gotchas are experienced by the service provider. If you're familiar with running Microsoft platforms (such as SQL and Exchange), you can imagine the challenge of tracking the number of users who are using those products in a single on-premises environment. Now take that challenge and multiply it by hundreds or thousands of environments hosted in a cloud service provider's infrastructure.

Further compounding that challenge is an entirely different definition for what a user is. In an on-premises environment, you might need to have a number of licenses equal to the maximum number of named users who actually use a given product. In the cloud, SPLA partners are required to track the number of users (actual people -- not accounts) who are authorized to access a product that month, whether they actually access it or not. That technically means if you as a cloud consumer give a certain user in your organization permission to access a Microsoft product hosted by a cloud service provider under an SPLA, that provider must be able to note that fact and pay for that user's right to access the product, even if the user never actually logs in.

Simply put, that's an enormous license compliance challenge for cloud providers to keep up with. Although that's not your problem as a consumer of those services, you'll see the effects of it in terms of limited abilities to control your hosted servers or intrusive reporting software installed to report usage back to the provider. If you don't see any of those things, your provider may risk disappearing in its own cloud of smoke when Microsoft performs a compliance audit and hands it a back-breaking bill.

That's not all. Cloud users also face some annoying limitations. The first is that you effectively need to repurchase all the licenses you're already using on-premise. Say you decide to move a Microsoft Remote Desktop Services-based offering (which includes Office and a few other productivity apps) along with Exchange and a SQL-based app into the cloud. Assuming you own all that software already and don't want to upgrade, you're going to start paying monthly via your service provider for the same software you own. After three years of use, you've essentially paid the full license price again. And you will do so again after the next three years.

Fortunately, Microsoft has a program called License Mobility that works as a subagreement to the SPLA. It lets cloud customers submit their licenses to Microsoft, which verifies it and lets SPLA partners use those licenses in their cloud infrastructures for your service. At first glance, this seems to end the double payment for licensed Microsoft software.

As with all things Microsoft, however, there are limitations. First, the licenses you own must be covered by Microsoft's Software Assurance maintenance program to be eligible for License Mobility. Second, not all Microsoft products are eligible for License Mobility. SQL and Exchange licenses are eligible, for example, but not the Remote Desktop Service CALs, Office licenses, and Windows Server OS licenses -- they all need to be paid for again.

Although using the cloud might appear to be simple, maintaining license compliance with Microsoft is anything but. It's true that much of the burden rests on the shoulders of the service providers, but it still affects users. Your hosted IaaS environment may be subject to greater provider oversight. Some wary cloud vendors may prohibit use of certain difficult-to-monitor applications. The provider's costs go up, and thus so do yours.

The inconsistent rules and lack of any standardized compliance enforcement capability in Microsoft's software products make things much more difficult than they should be. Microsoft is pushing the cloud heavily these days, with Azure and Office 365. But its own rules are out of sync and need to be changed.

This article, "Microsoft's cloud licensing sets up a compliance nightmare," originally appeared at Read more of Matt Prigge's Information Overload blog and follow the latest developments in storage at For the latest business technology news, follow on Twitter.

Copyright © 2013 IDG Communications, Inc.