Server Deployment Records for Hosters

SPLA is Microsoft monthly licensing program for hosters, managed service providers, and outsourcers that deliver Microsoft software to external customers. It is pay as you consume, and compliance is verified for every monthly reporting cycle across a 36 month lookback, not just your current position. When a Big Four firm conducts that audit under the MBSA audit clause, it works from records. The quality of your server deployment records decides whether the audit runs on your evidence or on the auditor assumptions. This article sets out what to capture and why.

Why records are the whole defense

A SPLA audit is not a snapshot. The auditor has authority to request deployment records, server configuration data, customer contracts, and usage logs, and to test every month in the lookback. Where your records are complete, the auditor reconciles against them. Where they are missing, the auditor estimates, and estimates are rarely in your favor. Back fees at the price file rate are not negotiable, so any month the auditor has to reconstruct from assumptions tends to cost more than a month you can evidence.

What to capture for every server

Good server deployment records tie each server to what ran on it, who it served, and for how long. The aim is that any month in the lookback can be reconstructed from your own data.

• Server identity and role, so each machine is traceable and its function is clear.
• Product and version deployed, mapped to the correct SPUR entry for that month, since the Services Provider Use Rights change over time.
• The licensing metric in use, whether SAL per user or processor and core based, recorded consistently month to month.
• Customer mapping, so every reported SAL block ties to the customer it served and no estate is left unattributed.
• Commission and decommission dates, so a server that was live for part of a month is counted correctly and not for periods it did not run.
• Multi tenant boundaries, documented so shared infrastructure is allocated cleanly between customers.

A month that reconciles, line by line

The table below shows what a defensible monthly record looks like for a single reporting cycle. The figures are indicative.

These figures are indicative. The point is that every reported number traces to a server, a product version, a metric, and a customer. A record like this leaves the auditor nothing to reconstruct.

Sealed counts and the audit trail

For user based metrics, the defensible practice is to seal daily authentication counts so the SAL figure you reported each month can be proven later. Authentication data captured at the time, and stored unchanged, is far stronger evidence than a reconstruction built months afterward. We go deeper on this in customer mapping for every reported SAL, and on the wider record set in building a SPLA compliance register.

Where deployment records fit in SPLA defense

Server deployment records are the foundation of the structural defense that protects a hoster, which is reporting discipline applied every month. Records make the reporting provable, and provable reporting is what holds up across a 36 month lookback. Our SPLA audit defense guide sets out that full discipline, and the hoster readiness workbook turns it into a checklist you can run against your own estate. Strong records are where it all starts.

If you want a second set of eyes first, our SPLA audit defense team challenges the counting before back fees are set.