If your company licenses products to third parties under the Microsoft Service Provider License Agreement (SPLA), you may receive a request to perform a self assessment and provide a certification of compliance to Microsoft. The SPLA self-assessment audit is a new audit flavor that is unlike the independent audits Microsoft has historically used to audit its service providers. I have been representing server providers in Microsoft SPLA audits for the last 12 years. I am helping many of my clients navigate the murky licensing issues that arise when conducting a SPLA certification. If you have received a letter requesting a Microsoft SPLA self assesment and certification consider the following:

  1. Data Collection – before you can certify that you are in compliance with your Microsoft SPLA, you need to review a number of sources of data. I advise my clients to gather the same data that Microsoft's independent auditors would use, including any free tools generally accepted in those audits. If you standardize on the same tools to manage the environment that an auditor would use to audit the SPLA environment, the chances of getting a big surprise in an audit are much lower. I generally like to review MAP toolkit data, active directory data, and RV Tools data. While none of these tools are required by the SPLA, absent existing tools or atypical architecture, these are the tools of choice for Microsoft SPLA audits.
  2. Validation – regardless of the tools you use, it is important to have a process to validate that your deployment data is complete and accurate. To prove completeness and accuracy in a Microsoft SPLA audit, discovery data is compared to other data sets to "test" whether all machines in the environment have been captured. Active Directory objects are often used in Microsoft SPLA audits for completeness testing. Compare your discovery tool output to your active directory machines, and you will usually find that there are many more machines in active directory than in you have discovered. Routine comparison of the Active Directory to the discovery data is key to proving completeness in a Microsoft SPLA audit. You can also compare the total number of devices managed by the anti-virus software ot determine that you have captured inventory data on all of the devices. Most companies are pretty good at getting anti-virus software installed on all of their hardware. If you have machines that have AV running that are not reflected in your discovery data, you will likely fail the completeness testing in a SPLA audit. Routinely reconciling your AV data to you discovery data is a best practice to help you discover missing machines.
  3. Calculating the Effective License Position for SPLA – once you have reliable discovery data for all of your SPLA deployments, you need to calculate your effective license position for SPLA. In many instances, SPLA use cases can be technically complicated and SPLA customers regularly have difficulty interpreting Microsoft's ever-changing and complex licensing rules. Many SPLA partners struggle with Windows Server and SQL Server licensing. One positive aspect of the SPLA audit is that entitlement data is easy to discover. Your last monthly true-up order constitute the entitlements for your SPLA self-assessment. We will help you review the data form the tools in the same manner as Microsoft's third-party auditors so that you can be confident when you complete the SPLA certification.
  4. Written Policies and Procedures for SPLA – to properly defend a SPLA audit you need data showing what Microsoft products were deployed in your customer-facing environment for each month of the SPLA term. We have developed a set of recommended policies and procedures over the last 12 years of defending SPLA audits, and we encourage our clients to adapt our template for use in their organization. The goal of our SPLA policies and procedures is to insure that the SPLA partner has all the data necessary to prove that they were in compliance during each monthly true-up period. The policy provides step-by-step data collection and analysis steps designed to mitigation any compliance risks and to prepare for future Microsoft SPLA audits.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.