Pitfall 1 — Under-Licensing in Virtualised Environments
Virtualisation under-licensing is the #1 SQL Server audit finding globally. The complexity of core-based licensing in virtual environments — combined with VM sprawl, live migration, and shared infrastructure — creates compliance gaps that even diligent SAM teams miss.
The Scenario
Your infrastructure team virtualises SQL Server on VMware or Hyper-V. VMs migrate between hosts via vMotion or Live Migration. New SQL VMs are cloned without licence allocation. A partially licensed host is assumed to cover all VMs — which is false unless all physical cores are licensed with Enterprise Edition + SA (granting unlimited virtualisation rights). Every running SQL Server instance must be fully licensed, and auditors will map every VM to its physical host.
The Financial Exposure
A single unlicensed SQL Server Enterprise VM on a 40-core host can trigger a $550,000+ true-up (40 cores × ~$14,000/core list price). If the auditor determines the VM migrated across multiple hosts, each host may need to be licensed — multiplying the exposure. Standard Edition at 4-core minimum per VM is less expensive ($3,945/core × 4 = $15,780 per VM) but still material when 10–20 VMs are unlicensed across an estate.
Remediation
Track every SQL VM in real-time: Integrate VM deployment workflows with licence management — no SQL VM should be created without a licence allocation. Licence entire hosts where feasible: For hosts running multiple SQL VMs, licensing all physical cores with Enterprise + SA provides unlimited virtualisation rights and eliminates per-VM tracking. Use SA for licence mobility: Without SA, moving a VM to a different host violates the 90-day reassignment rule. SA grants licence mobility, allowing VMs to migrate freely across hosts in a server farm. Scan regularly: Use Microsoft's MAP Toolkit or third-party tools (Snow, Flexera, ServiceNow SAM) to discover all SQL Server instances — including those installed but not actively used.
Pitfall 2 — Edition Mismatch and Unintentional Enterprise Feature Usage
Edition mismatch — running Enterprise Edition binaries on a server licensed for Standard — is a high-frequency, high-cost audit finding. The gap between Standard and Enterprise pricing means a single mismatch can cost $200K–$500K+ in retroactive licensing.
Enterprise Installed, Standard Licensed
A DBA downloads the wrong installation media or uses a generic product key during setup. The server runs Enterprise Edition binaries while only Standard licences are assigned. In an audit, Microsoft detects the installed edition (via SELECT @@VERSION or SERVERPROPERTY('Edition')) and compares it to entitlements. The financial gap is enormous: Enterprise at $14,256/core vs Standard at $3,945/core — a 3.6× cost multiplier. On a 16-core server, the difference is $165K. Remediation: implement strict deployment controls — maintain an internal software library with edition-specific media. Run monthly checks: SELECT SERVERPROPERTY('Edition') across all instances and compare to your licence register.
Developer Edition Serving Business Workloads
Developer Edition is free but restricted to development and testing only. It includes all Enterprise features, making it tempting for internal tools and reporting databases. If a Developer Edition instance processes production data, serves end-users, or runs business-critical workloads, it is completely unlicensed from Microsoft's perspective — equivalent to having no licence at all. Remediation: segregate environments rigorously. Developer Edition should only exist on servers flagged as non-production in your CMDB. Monitor network connections to Developer instances — if production application servers connect to them, that is a compliance violation.
Enterprise Features Used on Standard Licence
SQL Server Standard allows certain features but restricts others to Enterprise (e.g., online index rebuild, columnstore on Standard has limitations pre-2016, data compression in older versions). A subtler edition mismatch occurs when the correct Standard edition is installed but Enterprise-only features are enabled or used. While Microsoft typically audits by installed edition rather than feature usage, best practice is to ensure features match entitlements. Use sys.dm_db_persisted_sku_features to identify Enterprise-only features in your databases.
Pitfall 3 — Server+CAL vs Per-Core Model Errors
SQL Server Standard offers two licensing models: Per-Core (no CALs needed, unlimited users) and Server + CAL (one server licence + a CAL for every accessing user or device). Choosing the wrong model — or failing to maintain CAL counts — is a common and expensive mistake.
| Factor | Server + CAL | Per-Core |
|---|---|---|
| Best for | Small, internal databases (≤25–30 users) | External-facing, large user populations, web apps |
| External users | NOT permitted — CALs cannot cover external parties | Permitted — per-core covers unlimited users |
| Cost structure | ~$930 server + ~$230/user CAL | $3,945/core (4-core minimum per VM) |
| Breakeven | ~25–35 users — above this, per-core is typically cheaper and simpler | |
| Compliance risk | High — must track every accessing user/device | Low — just count cores, no user tracking |
| Audit exposure | Missing CALs for indirect users (web apps, middleware) | Only physical core count verification |
The Indirect Access Trap
The most dangerous CAL pitfall is indirect access. If an application (ERP, CRM, web portal) queries a SQL Server database, every user of that application needs a SQL Server CAL — not just the application's service account. A web application with 5,000 users connecting to a SQL Standard Server+CAL instance requires 5,000 CALs (5,000 × $230 = $1,150,000) — far exceeding the cost of per-core licensing. SAM teams must map application architectures to identify all paths to SQL Server databases. If any path includes external users (customers, partners), CALs are not permitted and per-core licensing is mandatory.
Pitfall 4 — DR, QA, and Non-Production Licensing Gaps
Non-production environments — disaster recovery, QA, staging, training — are a persistent compliance blind spot. The assumption that "non-production doesn't need licensing" is incorrect under Microsoft's terms.
Disaster Recovery — Passive vs Active
With active Software Assurance, you receive one passive failover instance at no additional licence cost. "Passive" means the server receives data (log shipping, mirroring, Always On secondary) but does not serve read queries or run reports. The moment a DR server serves read workloads (readable secondary in Always On), it is "active" and requires its own full licence. Without SA, there are no free failover rights — every standby server must be independently licensed. In audits, Microsoft examines whether Always On secondaries have ALLOW_CONNECTIONS = READ_ONLY or ALL — either setting makes the secondary active and licensable.
QA and Test Environments
If you install Standard or Enterprise edition in a QA/test environment, that instance must be licensed — regardless of whether it processes production data. The safest approach: use Developer Edition (free, full Enterprise features) for all non-production SQL Server instances. Developer Edition requires each user to be covered by Visual Studio/MSDN subscriptions. If your test environment uses Standard/Enterprise edition media, either replace with Developer Edition or assign proper licences. In audits, Microsoft scans all servers — they do not distinguish "production" from "test" by server name; they check installed editions against entitlements.
Training and Demo Environments
Training servers used by employees to learn SQL Server should use Developer Edition under MSDN/Visual Studio subscriptions. Demo environments used to showcase software to customers or partners are not covered by Developer Edition if the audience includes external parties — these require production licences. The line is: if the SQL Server instance serves any business function beyond internal development and testing, it needs a production licence.
Pitfall 5 — The 90-Day Licence Reassignment Rule
Microsoft's licensing terms restrict licence reassignment: a SQL Server core licence cannot be moved to a different server more frequently than once every 90 days. This rule has significant implications for virtualised and dynamic environments.
What It Means
If you assign SQL Server core licences to Server A on January 1, those licences cannot be reassigned to Server B until April 1 — regardless of whether Server A is decommissioned, fails, or is no longer needed. The only exceptions: (a) permanent hardware failure (the licence can move immediately if the original server is destroyed), or (b) active Software Assurance, which grants licence mobility rights within a server farm, effectively overriding the 90-day restriction for SA-covered licences.
Why It Matters in Virtual Environments
In VMware environments with vMotion/DRS, SQL VMs can migrate between physical hosts automatically — potentially multiple times per day. Each migration technically moves the workload to a different server. Without SA licence mobility, every host that could receive a SQL VM must be fully licensed — or you violate the 90-day rule. This is why SA is effectively mandatory for virtualised SQL Server: it grants server farm licence mobility, allowing VMs to move freely within a defined farm without triggering the 90-day restriction.
"Software Assurance is not optional for virtualised SQL Server — it is a compliance requirement in practice. Without SA's licence mobility rights, every physical host in a vMotion-enabled cluster must be independently licensed for every SQL VM that could potentially land on it. The cost of licensing every host far exceeds the cost of SA."
Pitfall 6 — Shadow IT and Untracked SQL Server Installations
SQL Server Express Edition is free and can be installed by any developer or application without procurement approval. Third-party applications frequently bundle SQL Server Express or even Standard Runtime licences. This creates a shadow IT compliance problem.
The Hidden Installation Problem
SQL Server can exist in your environment without anyone in SAM knowing: (1) Express Edition installed by developers as a local database — Express is free but has limitations (10 GB database size, 1 GB RAM). If workloads outgrow Express and are upgraded to Standard without a licence, you have a compliance gap. (2) Third-party application bundles that include SQL Server Standard Runtime — the Runtime licence restricts usage to that specific application only. If a DBA connects directly to the database or other applications query it, the Runtime licence is violated and full Standard licences are required. (3) Departmental installations — business analysts or data teams install SQL Server for personal reporting without IT knowledge. Remediation: run quarterly discovery scans (MAP Toolkit, SCCM, or third-party SAM tools) across all servers and workstations. Flag every SQL Server instance — Express, Developer, Standard, Enterprise — and reconcile against your licence register.
Pitfall 7 — Documentation and Proof of Licence Ownership
In a Microsoft audit, the burden of proof is on the customer. If you cannot produce documentation proving you purchased sufficient licences, Microsoft will assume you are under-licensed — regardless of your actual entitlement.
✅ Documentation Requirements for Audit Defence
- Volume Licensing Service Centre (VLSC): Ensure your Microsoft Volume Licensing portal shows all SQL Server licence purchases. Cross-reference VLSC entitlements with your internal deployment records — discrepancies indicate either missing purchases or incorrect portal records
- OEM licence proof: OEM SQL Server licences (bundled with hardware) require the original Certificate of Authenticity (COA) sticker or equivalent proof. If the hardware is decommissioned, the OEM licence is lost. Maintain a register linking OEM SQL licences to specific hardware serial numbers
- Software Assurance records: SA coverage dates are critical — they determine eligibility for licence mobility, failover rights, and version upgrade entitlements. If SA lapsed and was not renewed, you lose these benefits retroactively. Maintain SA renewal records with exact coverage periods
- Licence assignment records: Document which licences are assigned to which physical hosts or VMs. This is the "effective licence position" (ELP) that auditors will request. Without it, you must reconstruct the assignment — often unfavourably, as auditors assume worst-case deployment
- Physical hardware inventory: Every server running SQL Server must have documented: socket count, cores per socket, total physical cores, and whether it is a virtualisation host. This data determines the required licence count. Automated discovery tools should feed this inventory continuously
- Version and edition register: Maintain a record of SQL Server version and edition installed on every instance. Use
SELECT @@VERSIONandSERVERPROPERTY('Edition')across all instances quarterly. Any instance running a higher edition than licensed must be immediately remediated
Financial Exposure Summary — By Pitfall
Understanding the financial magnitude of each pitfall helps SAM teams prioritise remediation efforts. The following table quantifies typical audit exposure per pitfall for a mid-to-large enterprise SQL Server estate.
| Pitfall | Frequency in Audits | Typical Exposure per Finding | Priority |
|---|---|---|---|
| 1. Virtualisation under-licensing | Very High (70 %+ of audits) | $200K–$2M+ | Critical |
| 2. Edition mismatch | High (50 %+ of audits) | $100K–$500K per instance | Critical |
| 3. CAL model errors | Medium (30–40 % of audits) | $50K–$1M (indirect access) | High |
| 4. DR/QA gaps | High (50 %+ of audits) | $50K–$300K | High |
| 5. 90-day rule violations | Medium (in virtualised estates) | $100K–$500K (multi-host licensing) | High |
| 6. Shadow IT | Medium (30 % of audits) | $20K–$200K | Medium |
| 7. Documentation failures | Very High (amplifies all other findings) | Increases all exposures by 20–50 % | Critical |
SAM Remediation Framework — Quarterly Compliance Cycle
Discovery and Inventory
Run full SQL Server discovery across all physical hosts, VMs, and workstations. Identify every instance: edition, version, core count, host assignment, and SA status. Flag new instances added since last scan. Output: complete instance inventory with licence requirement calculation per instance.
Reconciliation and Gap Analysis
Compare discovery results against licence entitlements (VLSC + OEM + CSP records). Identify gaps: under-licensed instances, edition mismatches, expired SA, missing CALs, unlicensed DR servers, Developer Edition in production roles. Output: prioritised remediation list with financial exposure per gap.
Remediation Execution
Close gaps: purchase missing licences, downgrade editions, replace Standard/Enterprise with Developer in non-production, enable SA where mobility is needed, document licence assignments. Output: updated effective licence position (ELP) with zero gaps.
Documentation and Audit Readiness
Update all documentation: VLSC reconciliation, hardware inventory, licence assignment records, SA coverage dates, edition/version register. Test audit readiness: can you produce every document Microsoft would request within 48 hours? If not, identify and fix documentation gaps before the cycle restarts. Output: audit-ready documentation package.