ITAMChannel is a hub of coverage for all the latest news and views within the IT Asset Management Industry

Top Three Ways To Sabotage Your Licensing Compliance Under Microsoft SPLA

SHARE
,

Microsoft’s Services Provider License Agreement (SPLA) is the principal licensing agreement for companies that want to use Microsoft products to deliver hosted software solutions over the Internet. Microsoft’s standard volume license agreements expressly prohibit using the software for “commercial hosting” purposes (though, limited exceptions are offered for certain use cases and subject to specific requirements). Microsoft SPLA offers an alternative licensing framework for companies whose hosting operations otherwise would be impeded by that prohibition.

All software licensing requires mature software asset management (SAM) practices to ensure that software usage does not exceed the scope of the entitlements acquired by a company. However, SPLA compliance entails special challenges, primarily because Microsoft SPLA is based on a monthly license-reporting model. Instead of conducting an inventory and placing a forward-looking order for licenses to accommodate current and upcoming needs, companies licensing software under SPLA must confirm their usage each month and report that usage to an authorized SPLA reseller (such as Insight or SHI). In effect, SPLA licensees are required to conduct monthly, internal audits and to place monthly orders based on the results of those audits. Given that many companies lack the skill set required to conduct a single audit, the SPLA requirements can entail significant risks.

Most companies obviously want to stay in compliance with their contractual obligations. However, companies desiring to play chicken with the significant financial exposure that can arise under a SPLA audit initiated by Microsoft can magnify the extent of their non-compliance (and the payment required to settle the audit findings) by taking the following steps with regard to their hosting environments:

 1. Give Customers the Keys (and Don’t Keep a Spare).

Many hosting customers want to limit the ability of service providers to access their IT environments. That is a natural inclination, especially for companies in highly regulated industries (such as healthcare or financial services), where applicable law imposes substantial data-security and data-privacy obligations. The fewer parties able to access a computing environment, the easier it is to satisfy those obligations.

Hosting providers wanting to provide services to such companies often seek to accommodate that preference by setting up hosted servers on the providers’ infrastructure and then surrendering all administrative access to those servers to the customers. However, providers subject to SPLA-reporting obligations take that approach at their significant peril.

Without access, it is typically not possible to confirm what Microsoft products are being used within a hosted environment and, therefore, to accurately report what products are being “used” (more on that word in point 2, below). If the provider’s customers have physically dedicated hosting environments, then it is easier for customers to provide their own licensing, thereby minimizing SPLA-reporting obligations. However, a physically dedicated hosting framework is not feasible or cost-effective for many companies, and hosting providers must be in a position to confirm all product usage within multi-tenant architectures.

Some companies that cede administrative access to their customers report usage under SPLA based on billing data and customer orders instead of up-to-date deployment inventories. This is a recipe for disaster. Over time, customers may add users or install additional or new Microsoft products in the hosted infrastructure. If those deployments are discovered during an audit, Microsoft’s auditors will presume that ALL such usage is within the scope of the provider’s SPLA obligations. If that provider has been reporting usage based on whatever a customer ordered when it signed its service agreement, then the gap between what is in use and what is reported (and the associated costs to resolve the audit findings) can be financially crippling.

The best approach is to retain administrative access to all hosted systems, to measure usage on a monthly basis, and to report usage based on those measurements. For companies that want to offer their customers an option where customers receive exclusive administrative control, it may be possible to configure the hosting environment to take advantage of technologies like Microsoft’s “Shielded VM” functionality. (For more information on that option, click here.)

2. Report Usage Based on Actual Usage. No, really.

Many companies make the mistake of reporting SPLA usage based on the number of users that actually access a product during a given month or on the number of servers actually accessed by those users. That’s not an unreasonable approach at an intuitive level – use means use, right? – but under SPLA it is an incorrect approach that can yield significant compliance problems.

SPLA requires that user-licensed products be licensed based on the number of users authorized to access a product, regardless of whether those authorized users actually access that product during a reporting month. Even if a company has reliable and accurate records to demonstrate actual user access, those records likely would be ignored by Microsoft’s auditors during an audit. Furthermore, Microsoft defines the word “use” very expansively, to include the mere installation of a product on a server. Therefore, even if an installation in a hosting environment never has been run or used by an end user, unless the SPLA incorporates an explicit reporting exception that pertains to that installation, Microsoft auditors will assume that it must be reported.

Companies licensing software under SPLA need to carefully review the agreement and to ensure that they understand all of the sometimes counter-intuitive licensing obligations that it incorporates.