The Microsoft Licensing Statement (MLS) is a critical document for managing Microsoft software assets, but it’s poorly understood and Microsoft account teams may sometimes withhold an MLS from customers who need it. Ensuring that this document is accurate and up to date is essential to compliance.
Built on data about customer purchases through volume licensing programs, an MLS is Microsoft’s version of the truth at audit time. An MLS is not to be the total picture, since it excludes OEM software, such as Windows acquired with new PCs, as well as purchases through retailers. These gaps can be filled only with good customer purchasing records.
The MLS is a spreadsheet with a series of tabs.
The Organization Summary lists the customer’s subsidiaries, acquisitions, and other business entities. All Microsoft volume softare purchased by these entities should be listed in the MLS.
The License Summary shows the quantity of licenses the customer has purchased, by product and version version, as well as license entitlements gained through upgrades and SA. It’s confusing for many customers, so we’ll look at it in more detail below.
The Transaction Summary summarizes how many volume licenses of each product version the customer organization has purchased.
The License Agreements tab lists all of the agreements the customer signed, with the name of the business entity that signed the agreement, agreement numbers, stop and start dates, and the entity’s location.
The Transaction Data tab is raw data showing each license purchase. Its many columns include the entity that purchased the license, the agreement it was purchased through, the quantity of licenses purchased, the type of license—License and SA, SA alone, Standard (license-only purchases), subscriptions, etc.— the reseller through whom it was purchased, and the country of use. It’s the second-most consulted tab and essential for anyone who wants precise details about a customer’s purchase history.
The FAQ and Glossary explains terms used in the MLS.
The Pivot Data tab contains data used in the License Summary.
The License Summary is used when developing an Effective License Position (ELP), which compares the customer’s inventory data with Microsoft’s licensing data to determine which products are over- or under-licensed.
This clip from a customer’s MLS (altered slightly) shows a customer’s Project Standard licenses. The customer has 30 licenses for pre-2003 versions as seen in the Effective License Quantity column. The top row shows 54 Project 2013 licenses with current Software Assurance (SA). Some or all of these may be deployed as an earlier version (e.g., Project 2010), but SA entitles the customer to Project 2013.
The 2003 and 2007 Project numbers are more complex. Effective License Quantity shows licenses purchased without SA or for which SA expired. The Upgrade License Quantity (w Maintenance) column shows licenses in limbo: SA was purchased for them in earlier agreements, but no underlying license purchase can be found and these are thus not counted in the Effective License Quantity.]
Performing this comparison is not straightforward, since the License Summary shows license entitlements, not deployments. A customer’s inventory data may show 1,000 copies of Office 2010, while the MLS shows 1,000 licenses for Office 2013. Because the customer has SA on Office, its 2010 licenses were upgraded to Office 2013 the moment that product was released. But the customer is still compliant: 2013 version licenses cover the 2010 version deployments via Office’s built-in downgrade rights.
The columns devoted to SA are another source of confusion.
Licenses for a current product may not appear in the Effective License Quantity column, but only in the Active SA column, even if the customer is in the third year of an EA and has made its final payment on licenses and SA. Why aren’t those “Effective” Licenses?
That depends on who creates the MLS (they’re put together by contractors). Licenses with SA may not be included in the Effective License Quantity column because (in theory) an upgrade could come along before the agreement expires, resulting in an upgrade to a later version. The licenses with SA are simply for “the latest version of the product,” whatever it might be at the end of the agreement, when SA expires.
Some licenses may appear as upgrades only, without accompanying licenses. Typically this means that Microsoft has no record of the license purchases, only of SA. Since SA can only be purchased at the time a license is purchased, where are those original licenses?
That generally requires combing through the Transaction Data tab or customer purchasing records to uncover the original licenses. Here are three situations we encountered recently:
A customer was on the hook for more than 100 copies of Project Professional on which they had paid SA for many years, but the original licenses could not be found by the auditor. We pointed out that Project 2003 was the first version with a Professional edition and customers with SA on the previous version (like our customer) were granted Project Professional licenses. No transaction took place, so the licenses had to be inferred from the Project 2003 SA migration rights.
A customer faced a $250,000 bill for missing Office licenses. Reviewing their purchasing history we found that the customer had originally purchased a “Professional Desktop,” which bundles Windows, Office, and Core CAL suite licenses with SA. A 2007 renewal listed the individual components rather than the bundle, but the MLS failed to record the transition to separate Office licenses. Correcting the MLS eliminated the shortfall.
A customer was short in a wide range of licenses, which we traced to acquisition of another company. The acquired firm had terminated SA on its licenses a few months before it was acquired, but Microsoft permitted our customer to pay the back SA on those licenses and renew it in their 2008 EA. We determined that the acquired licenses, listed in a 2008 amendment, had never been added to the MLS.
Customers should never accept a verbal concession that affects their licensing position without getting a written contract amendment and ensuring that the MLS reflects the concession. Absent such documentation, Microsoft has just planted a time bomb in the customer’s licensing record. It will eventually go off, with potentially explosive consequences. An auditor is obligated to treat any gaps as non-compliance, regardless of any verbal agreements that might have been made.
Customers should request an MLS from their reseller every quarter and make sure any unusual transactions or concessions appear there.
Account teams sometimes deny customers timely access to the MLS. One customer was told an MLS could not be ordered unless the customer agreed to a SAM engagement. Another was told the MLS would arrive when the auditor did.
In both cases, customers were denied reasonable access to critical information that could help them proactively determine their compliance and challenge any gaps in the MLS. Had they routinely asked for an MLS before a confrontational situation arose, these problems could have been avoided.
Paul DeGroot is one of the world’s leading experts on Microsoft licensing principles, policies, and strategies. He led the licensing practice at Directions on Microsoft, and subsequently formed Pica Communications, LLC to deliver exceptional insight into Microsoft licensing for audiences and organizations worldwide. In his role as Senior Consultant at Software Licensing Advisors, he has led customers to more than $250 million in negotiated savings over the last three years.
Paul will be in London, delivering an intensive 3 day Microsoft Licensing & Negations Workshop, a fantastic opportunity for anyone looking to improve their Microsoft knowledge from 19th – 21st October. For more information and how to book, click here.