SPLA Data Deep Dive: What Auditors Require and Why

Note: the transcript was edited and simplified for readability.

Welcome back to our series of events focused on Microsoft audits for service providers. Today, we'll discuss the technical aspects of data gathering in a Microsoft SPLA audit. While it may seem complex, I'll do my best to make it easy to understand.

Mistakes during this phase, as with any part of the audit, can impact your penalty negotiations. Some errors may be difficult, if not impossible, to reverse. Therefore, it's paramount to carefully consider the data you provide, understand why it's requested, and how to gather and maintain it to minimise penalties.

Today's host

My name is Alexander Golev, and I lead the SAMexpert division focused on service providers. We're a specialised consulting firm dedicated to all things Microsoft. However, we don't sell Microsoft licenses, so our interests always align with yours without a hidden agenda.

We help reduce costs, negotiate audits, and optimise agreements and cloud usage. And because we don't sell Microsoft products, we're always on your side.

We have successfully supported numerous providers and ISVs through over a hundred audits with a 100% success rate, consistently reducing audit bills beyond what you could achieve on your own.

When to begin taking care of the data

I want to start with the timeline, not the data or tools themselves.

When should you start paying attention to this if you don't do it regularly? You need to get ready as soon as you receive the audit notice from Microsoft. At some point in the audit, you'll have to gather data, so start preparing immediately. Unless you have solid legal reasons to refuse the audit (and I can't stress this enough), you'll have to provide them with the data.

Whether you like it or not, audits are almost inevitable. We're not Microsoft, and frankly, I don't care about Microsoft. I'm just stating the facts.

Always begin with the scope

What do you need to do in the first 30 days after receiving the audit notice to prepare for data gathering?

First and foremost, understand the scope. This means identifying which environments in your hosting estate fall under the SPLA and which are exempt. Examples of exempt environments include:

• Collocation

• Dedicated hardware where clients provide all licenses

• Linux-only clusters

• Your internal corporate usage licensed separately (e.g., with volume or partner licenses)

If an environment is outside the scope, don't gather data from it. Narrow your focus to the specific devices or clusters within the SPLA scope.

Remember: Don't overshare. It must become your mantra.

Do you want to use your own tools or scripts?

The next question is how you will collect inventory data. While auditors will bring their own scripts, they may accept your data, but your tools might not meet their requirements.

Document the tools and scripts you already use. Many providers have custom solutions, while others may use traditional software asset management tools that collect inventory data, calculate license requirements, report usage, and bill clients.

We've encountered everything from sophisticated custom solutions to situations where license reporting is based on guesswork. If you have a dedicated tool like Octopus Cloud or SPLA Manager, that's great. Specialised tools are ideal. However, you might also have a traditional inventory tool, an internal script, or scripts from previous audits.

Next, consider the following questions:

1. Does your tool cover all in-scope environments, servers, and virtual machines?

2. Does it exclude anything outside the scope of SPLA, CSP hosting, or other hosting needs? Ensure the tool doesn't collect data from out-of-scope environments.

3. Most importantly, do you trust your tool? If you use a specialised tool, is it your primary source of truth for billing and SPLA reporting? Often, these tools are deployed and used in the process but aren't fully trusted.

Specialised SPLA tools can be configured to provide accurate data automatically, but they require careful setup and validation.

When facing an audit, you must decide whether to trust your tool or rely on auditor scripts. If you're unsure about the quality of your data, auditor scripts might be the safer option.

While specialised SPLA tools can be configured to provide accurate data automatically, they require proper setup. You'll need to ensure all servers are scanned, BYOL (bring your own license) instances are correctly flagged, and the reporting is 100% accurate. When set up correctly, these tools offer a significant advantage in automating data collection and reporting.

When facing an audit, you must decide whether to trust your tool or rely on auditor scripts. If you're unsure about the quality of your data in the tool, auditor scripts might be the safer option.

If you have an independent audit defence partner, involve them in the tool assessment. Be wary of help from SPLA resellers. They might claim to assist, but their help will likely be limited to basic instructions on running audit scripts. Their hands are tied. They're Microsoft partners. They have to play the game on Microsoft's side, incentivised to sell you more licenses, not to help you minimise your audit liability.

If you assess your tools yourself, focus on scope and data quality. Remember, your biggest risk is oversharing. Provide data in small increments. Provide less. You can always provide more later if requested. Once you've shared something, it's difficult to retract.

Auditor's request #1: Questionnaire

The first data request will come in the form of a questionnaire. It will likely be an Excel spreadsheet with basic questions about your data centres, locations, clients, and hosted products.

When responding:

1. Provide clear, concise, and factual answers. Avoid vague or evasive language. It's better to leave a question unanswered than to provide a misleading or incomplete response. If you ramble or speculate, you might raise unnecessary red flags. If you don't know the answer, say so.

2. Use Microsoft's language. Be as technical as possible in your responses. Speak their language to minimise assumptions and misunderstandings.

3. Don't overshare. If you're unsure of an answer, don't rush to respond. Research the answer thoroughly, consult with experts, or ask relevant stakeholders. Don't simply guess or fill in the blanks with irrelevant information.

Audits can be stressful, and emotional reactions can lead to costly mistakes. Stay calm, professional, and focused.

Supervise IT communications

Do not allow auditors to communicate directly with your IT department without supervision. This often leads to problems. Treat your IT staff like brilliant geniuses who need a chaperone to ensure they don't inadvertently share incorrect or unnecessary data.

Assign a non-technical supervisor to oversee all communications and review all data exchanged with the auditors. IT professionals may not fully grasp the legal and commercial implications of their actions, and they could unintentionally provide data that complicates the audit. For example, if an audit tool runs perfectly, it may not raise any red flags, but it may include data outside of the scope.

Vigilance is key. If you're communicating with auditors, don't simply react technically. Be strategic about the information you share.

Auditor's request #2: Hardware Inventory

What technical data do the auditors want, and why?

Auditors will always provide you with scripts and instructions, along with the exact data requirements: which fields they need and from where to gather the data. If these details are not provided upfront, don't hesitate to ask for them.

The initial data request focuses on your hardware and virtual machines. They will provide platform-specific scripts. For VMware, the most common platform, you can use their scripts or provide RVTools reports, which neatly extract all VMware data into an Excel format. However, we haven't encountered working scripts for less common hypervisors like Proxmox or Nutanix. In such cases, you may need to manually extract the data and populate the auditor's spreadsheet template.

Why do they need this data? There are several reasons:

1. To compile a list of in-scope virtual and physical machines: This serves as the baseline for identifying "systems running Microsoft software", as defined in your agreement. While the agreement requires providing access to these systems, in practice, you'll usually only need to run scripts and share the resulting data.

2. To create the Hardware Inventory Report (or Master Server List): This report, a mandatory part of the final audit report, details your hardware infrastructure. While Microsoft typically only receives the final commercial calculations, this report is essential for the auditor's assessment.

3. To calculate Windows Server license requirements: This data, including processor and core counts (both physical and virtual), is necessary for determining the required Windows Server licenses, as well as licenses for other software like SQL Server, which is based on virtual cores.

Specifically, auditors need the following:

• Host-to-guest mapping: This shows which VMs run on which hosts.

• Cluster information: This reveals potential VM migration paths, which is necessary for understanding license requirements.

• Processor and core counts: Both physical and virtual, as these metrics are used for license calculations.

Auditor's Request #3: Asset Ownership

After you've provided your hardware and virtualisation data, the auditors will request two more pieces of information: machine ownership and software/user inventory from each machine. Let's address machine ownership first.

Simply put, machine ownership refers to which end client owns which machine. If a machine is used internally, flag it as such. This seemingly simple request has two important implications:

1. Licensing Start Date: When calculating the licensing start date for a machine, auditors should ideally use the date you onboarded the client, not the machine's creation date. Without this information, they might assume you've been licensing the machine since its creation, even if it was only recently brought under your SPLA. We've seen cases where this misunderstanding leads to significant discrepancies in licensing periods and, consequently, the penalties.

2. Reporting Requirements (Older SPLA Agreements): Older SPLA agreements require detailed reporting on clients consuming over $1,000 of SPLA software monthly. While newer agreements have dropped this requirement due to regulatory pressure, non-compliance can still jeopardise your SPLA. It might not result in monetary penalties, but it could be used as an excuse to terminate your agreement, particularly if the local Microsoft office aims to reduce SPLA partners.

Remember, SPLA terms require you to "reasonably demonstrate different scope and duration". Per the same terms, the auditors will always assume the worst case. Providing the above data is, therefore, crucial for accurate compliance calculations.

Auditor's Request #4: Software Inventory

Software and User Inventory is where the audit process truly intensifies. Auditors will request that you scan all virtual and physical machines with their scripts or provide data from your own tools. This is standard practice.

Microsoft and its auditors expect – and require – you to run scripts that inventory every virtual machine, regardless of your level of support or access. Pushing back against scanning unsupported or inaccessible virtual machines is challenging, though not impossible. Be prepared to scan everything, but you can push back with strong arguments and evidence that you cannot access certain machines or are not responsible for their contents.

This inventory comprises two parts: software and user data. To collect software data, you'll likely run their Visual Basic or PowerShell scripts unless your tools suffice. These scripts are usually run once per domain or workgroup and remotely invoke WMI queries, scanning the registry and other Windows functions to gather installed software details.

The goal is simple: identify the software title, version, edition, and ideally, the installation date. The installation date is crucial to prevent auditors from assuming the software was always installed.

Any missing information in the script output, such as SQL Server and Visual Studio editions, will prompt the auditors to request additional evidence, usually screenshots or other script outputs. This additional evidence is often needed due to WMI limitations. For instance, if you deploy a SQL Server Reporting Server on a separate machine (which is licensable), the script might not extract the edition of the original SQL Server media you used to install it. You'll then need to manually gather this data, likely through screenshots. Analysis Services and Visual Studio editions (especially from 2019 onwards) are also notorious for requiring additional data collection.

Why is this information necessary? Auditors want to know what Microsoft software runs on every machine in your environment so they can calculate your required licenses for each month. They use the software title, edition (Standard or Enterprise – the difference significantly impacts the price), and installation date to determine when licensing should have started.

Auditor's Request #5: User Inventory

Some Microsoft software, like pre-365 versions of Office, Visual Studio Enterprise/Professional, and even SQL Server Standard (with Subscriber Access Licenses), is licensed per user. Additionally, users accessing desktops with this software need Remote Desktop User licenses.

Therefore, auditors also request information about users and security groups. If a machine is domain-joined, they'll ask for data from your Active Directory (AD). They already have local security group data from the inventory scripts, but they'll need your AD user data as well. They'll provide scripts, command-line tools, or PowerShell commands to extract this data.

For standalone machines or workgroup members, user data is already in the inventory script, so no additional action is needed.

This is one reason why traditional SAM tools like Flexera and Snow fall short. They don't provide the required security group and user data for calculating SPLA user licenses. While Snow License Manager tracks software usage for remote desktops, SPLA doesn't care about usage; it requires a count of all users authorised to access remote desktops and software.

Even if a user doesn't access a remote desktop for a month, a license is still required. If they're a member of a security group with remote desktop access, they always need a license, active or not (disabled accounts are a separate discussion).

This information is best gathered by specialised SPLA reporting tools like Octopus Cloud. While we've heard of third-party add-ons for tools like Flexera that allegedly do the same, we haven't seen them in action and cannot confirm their effectiveness.

The required data typically includes all security groups, user accounts, creation dates, last logon dates, and account status (enabled or disabled). This helps auditors estimate the required user licenses for each month. The more accurate your data, the more accurate their calculations will be. Providing details about changes, creations, and onboarding dates further improves accuracy.

Auditor's Request #6: Additional Inventory

If auditors discover software with its own access controls, they'll request additional data through specialised scripts or alternative evidence. This applies to software like SharePoint Server, Azure DevOps Server (formerly Team Foundation Server), legacy Dynamics products like Navision, or when remote desktop access is controlled by Citrix.

A particularly complex case arises when you're reporting SQL Server Standard per user. Since SQL Server is rarely accessed directly and often used through other software (e.g., accounting or design software), identifying authorised users becomes challenging. Each of the potentially hundreds of third-party software titles has its own user management system.

In this scenario, you'll likely be asked to provide screenshots listing users with access to each software title. This is a labour-intensive process, but it's necessary to accurately report per-user SQL Server licensing.

Auditor's Request #7: End-User Contracts

Auditors will also request evidence of client onboarding and, in some cases, offboarding dates. If you recently offboarded a client, their machines might still be running for legal reasons, but you'll need to provide evidence of this.

By default, auditors will ask for all your end-client contracts, but you can consider this sensitive information. Instead, you can provide an extract from your CRM or billing system, which is often considered sufficient.

Crucially, if you allow clients to deploy their own Microsoft licenses or have no control over what they deploy, you'll need written evidence of this. A simple declaration of "We don't provide them Microsoft Office" won't suffice. Microsoft holds you responsible for everything in your data centres unless you have proof otherwise.

Therefore, you need written evidence of BYOL (bring your own license) agreements and proof that clients accept compliance responsibility. Auditors won't accept verbal declarations.

While you can later discuss your difficulties in gathering this information with Microsoft, the audit report will initially hold you responsible. Your goal is to minimise the liability reflected in the report before entering commercial negotiations.

How to prepare for an audit and reduce headache

An audit isn't just about the audit itself. You can proactively prepare for the possibility of an audit. If you need an audit readiness checklist, please message us (there's a form below the transcript) with your audit concerns and current progress, and we'll share it with you free of charge.

Here are some key steps to improve your audit readiness:

1. Know Your Scope: Clearly define what falls under your SPLA, CSP hosting, BYOL, internal use, Linux, and pure VDI environments. Understand which data centres are in scope, including disaster recovery sites.

2. Get a Specialised Tool: While not mandatory, a dedicated tool like Octopus, SPLA Manager, or activAeon simplifies the process and reduces frustration. You can also develop custom scripts, but ensure they're comprehensive and reliable.

3. Ensure Tool/Script Coverage: Regularly verify that your chosen tool or script covers all in-scope machines. This is crucial for maintaining "tool health" and avoiding surprises during an audit.

4. Perform Self-Assessments: Conduct regular internal self-audits, even if they're not full-fledged. Focus on the basics: Windows Server, your provided products, and evidence of BYOL, if applicable. Verify Windows Server calculations and ensure you include all relevant hosts while excluding out-of-scope machines.

5. Leave No Stone Unturned: Scrutinise all software running on hosted machines to ensure it's known and necessary. There's no room for ambiguity in licensing, especially in SPLA. If it's installed, someone must be paying for it. If it's unused, remove it.

6. Maintain Active Directory Hygiene: Regularly check users and security groups. Delete disabled users and remove inactive users from groups. This practice is as essential as personal hygiene.

7. Bill Clients Accurately: In cases of shared Active Directory responsibility, ensure clients are billed accurately each month based on real data, not sales estimates. This incentivises them to avoid mistakes and keeps you from being liable for their oversights.

8. Account for Human Error: If you use custom scripts, ensure they're not just designed for the ideal scenario. They must account for human error and accidental configurations. For example, a script that only counts Office users in a specific security group on a designated server won't capture accidental installations elsewhere. Full visibility is key.

9. Demand Evidence of Licenses: For all end-client installs and licenses, require proof of licenses or written acceptance of responsibility. This should be documented in your terms and conditions.

Audience Q&A

Question:

When talking about security groups in the audit, are auditors looking for high watermarks over a period of time?

Answer:

Auditors focus on your current data. They can only see high watermarks if you provide data from an SPLA tool with snapshots from previous periods. Typical scripts only extract data from the current moment.

To calculate your past license requirements, auditors look at creation dates, account status (enabled/disabled), security group memberships, and activity. They use the last activity date for disabled accounts to estimate when a user last accessed a resource.

While you're required to report the high watermark, audits typically only reveal the current state of your systems.