Compliance is, when it comes to licensing, a matter of being able to document you have acquired the correct amount of licenses to cover the installations and/or access to the given software.
The first pre-requisites for compliance are accurate inventory and accurate licensing calculations, e.g. finding out how to license a given installation, which can be done like this for a server license:
Hardware specification – X cores!
“Software name – core based”
License Metric (cores) – Y
License entitleme
Minimum requirement – A
These factors are not consistent across all server licenses, and may change based on new versions being released.
The second pre-requisite for SPLA compliance is proper documentation.
Spreadsheets are not enough
Once accurate licensing calculations are applied and processes for keeping these current and updated you need to find a way to document how you came to the amount of licenses you have ordered for a specific reporting month, basically by documenting the relation between installations/access and the licenses you have ordered.
Many service providers do their licensing calculations in spreadsheets and keep these as documentation, but as any value in a spreadsheet can be changes at any time, a spreadsheet is simply not useful for documentation purposes.
Compliance is also about handling what is not SPLA
One often seen compliance risk is the use of License Mobility.
With License Mobility through Software Assurance, an end customer can deploy certain server application licenses purchased under a Volume Licensing agreement in an Authorized Mobility Partner’s datacenter. So License Mobility is an exclusion from SPLA, as the customer is exercising the right to transfer traditional licenses with SA.
One challenge is how to keep track of the transferred license entitlements versus the amount of licenses required for the period the installation is covered by License Mobility.
SPLA Manager is built for documentation purposes
All inventory data, License calculations, and finalized orders are stored in the LicenseWatch SPLA database, where they reside, tamperproof, and available upon request.
The License Statement Report documents the following:
- Which automated license calculations have been accepted and ordered without change
- Which changes have been made prior to finalizing the monthly order,
- How a given installation has been licensed, including license SKU, License metric and hardware specifications for the installation,
- Which users has access to a given SAL and through which security groups
Save time and money through proper documentation
The old proverb: “He who has the best argument, wins the discussion” can be re-written into: “He who has the best documentation wins the audit”
There are a variety of audit types that you may encounter as a SPLA service provider. This can be an independent audit, a Self-Certification audit or a verified self-assessment (VSA), but common for them all is that they are based on data collection and the result must be auditable and describe the need for licenses in relation to acquired licenses.
If you are selected for an independent audit the auditor will typically ask you to run their script and respond to their requests for data. This type of audit is time-consuming, expensive, and frequently adversarial, with the so-called independent auditors making assumptions that often favored Microsoft to the detriment of the service provider.
With SPLA Manager all hardware information is collected automatically and changes during the reporting month is discovered and recorded making the basis for accurate license calculations possible. Once the reporting month is finalized the License Statement Report shows how each installation has been licensed and which changes from the automated licenses suggestion that may have been performed.
Generating the documentation automatically every month is what will save you a ton of time and money during an audit.
