April 29, 2026
BlogHow to Avoid the Three Most Expensive Words in a Microsoft Audit
There are three words you should never say to a Microsoft auditor: “I don’t know.”
Not because honesty is bad. But in a Microsoft audit, those three words don’t just leave a question unanswered. They hand the auditor permission to fill in the blank with the worst-case interpretation. And in Microsoft licensing, the worst-case interpretation is almost always “license everyone.”
After two decades of audit defense engagements, I’ve watched “I don’t know” turn small licensing questions into seven-figure problems. Here’s why it happens, and what to say instead.
Microsoft Licenses Potential, Not Use
Potential use vs. actual use is the single most misunderstood concept in enterprise licensing, and it’s the foundation of nearly every audit shortfall I’ve ever seen.
When clients think about their licensing position, they think about who is actually using a product. When Microsoft thinks about your licensing position, they think about who could use a product based on how it’s provisioned. These are not the same thing. They are rarely even close.
If 50 employees actively use a SQL Server and 5,000 are technically capable of authenticating against it, Microsoft’s default assumption is that you owe licenses for the population that could access it. The burden is on you to demonstrate otherwise. And “I don’t know” isn’t a demonstration. It’s a concession.
A few examples will make this concrete.
The SQL Server That Just Got Re-Licensed by Core
Picture a SQL Server instance with 32 cores supporting an internal application. The auditor asks: How many users access this server?
If your answer is “I don’t know,” you have just lost the right to license that server under the Server + CAL model, assuming Server + CAL was even on the table for this workload to begin with. Microsoft will tell you (correctly, by their rules) that without a defensible user count, the only remaining licensing option is per-core. And per-core licensing on a 32-core box isn’t a rounding error. It’s a six-figure conversation.
Worse, that “I don’t know” can metastasize. If you couldn’t articulate user access for that server, the auditor has every reason to ask the same question about your other SQL servers. Suddenly you’re not facing one re-licensing event. You’re facing a portfolio review.
The right answer when the auditor asks who accesses that SQL Server is something like: “That instance supports our internal expense reporting application. It serves 87 users in the finance organization. We license it under the Server + CAL model and have CALs assigned for those users.”
The honest reality is that for many SQL Servers today, per-core is the only available licensing model. SQL Server Enterprise has been core-only since 2012. Broad-access systems and public-facing applications can’t be bounded by user count, and most clients no longer hold the legacy Server + CAL entitlements that would even make the question relevant. But where Server + CAL is still a viable model for a given workload — typically SQL Server Standard supporting a defined user population — you need to know it’s viable and be able to say so out loud. Otherwise, you’ll pay for the more expensive model by default, on a server where you didn’t have to do so.
The RDS CAL Trap
Remote Desktop Services (RDS) is where this gets really painful, and it’s a trap that catches even sophisticated customers.
Here’s the scenario. Somewhere along the way, an admin assigned the Domain Users group to an RDS server. Maybe it was a temporary fix that became permanent. Maybe nobody remembers who did it. The auditor finds that group membership and says: “Every member of Domain Users is authorized to access this RDS server. You owe an RDS CAL for each of them.”
If you have 8,000 employees in Domain Users, that math gets ugly quickly. And if your response is “I don’t know who actually uses the RDS server,” congratulations: You just bought 8,000 RDS CALs.
But do you actually owe them? Not necessarily.
If that RDS server sits behind Citrix, and many do, and you’re enforcing user-level access through Citrix policies that only publish RDS resources to a defined subset of users, then that is your defensible position. The Domain Users group on the RDS server itself becomes a red herring, because the only path to actually launch an RDS session runs through a Citrix layer that gates access to a known, named user population.
The auditor’s argument is “this group has access.” Your counterargument has to be “this group has theoretical access, but here is the access control layer that enforces who can actually use it, here is the user list that layer permits, and here are the licenses we hold for those users.” That is an articulated compliance position. It’s defensible. It might save you 7,500 CALs.
The vMotion Question
Here’s a virtualization version of the same trap, and it shows up the moment any Microsoft workload is running in a VMware or Hyper-V cluster.
The auditor asks: “Can these VMs move between hosts?”
If you say “I don’t know” (or worse, “yes” without context), you’ve just opened the door to one of the most expensive licensing rules Microsoft has on the books. Their position is straightforward: If a VM running a licensed Microsoft product could move to another host, that host has to be licensed too. Every host the VM is eligible to land on. Whether it has ever actually run there or not.
For a SQL Server or Windows Server workload sitting on a 12-host vSphere cluster, that math gets ugly fast. You don’t owe licensing for the one host the VM lives on today. You owe licensing for every host in the cluster.
There are two ways out of that situation, and you need to know up front which one applies to you:
Software Assurance (SA) with License Mobility rights. SA on those licenses gives you mobility rights that allow the VM to roam without re-licensing every host. If you have SA, say so, clearly and on the record.
Pinning the VMs. If you’ve configured Distributed Resource Scheduler (DRS) rules, anti-affinity rules, or host affinity that prevents the VMs from moving outside a defined subset of hosts, that becomes your defensible position. You only owe licensing for the hosts the VMs are actually permitted to run on, not the entire cluster.
You’re Not Out of Compliance. You Just Can’t Articulate It
This is a theme I come back to over and over with clients. Most organizations I work with are not actually out of compliance. They just don’t know how to articulate the compliance they already have.
The licenses are usually there. The access controls are usually there. The architectural justifications are usually there. What’s missing is the ability to walk an auditor through them in real time, with confidence, with documentation, and in language that maps to Microsoft’s rules.
That gap between actually being compliant and being able to demonstrate compliance is where almost all audit dollars get lost. Not in genuine non-compliance, but in defensible positions the client never managed to defend.
What Preparedness Actually Looks Like
Before any Microsoft audit — or honestly, before any internal license review — you should be able to answer three questions for every server and service in scope:
What does this support? What application, what business function, what user population.
Who has access, and how is that access enforced? Group memberships, Citrix policies, application-layer authentication, network segmentation — whatever is actually controlling who lands on the server.
What licensing model are we using, and why is it the right one for this server?
If you can answer those three questions, you can defend almost any reasonable Microsoft licensing position. If you can’t answer them, you’re negotiating with one hand behind your back — and Microsoft’s auditors are very good at sensing exactly when that’s happening.
The Bottom Line
Audit defense isn’t really about having the right licenses. It’s about being able to prove you have the right licenses, in the auditor’s language, with the documentation to back it up.
The next time someone from Microsoft (or any auditor) asks you a license-impacting question, the answer is never “I don’t know.” The answer is “let me come back to you on that with specifics” — and then you go find the specifics. Because in a Microsoft audit, the words you don’t say are often worth more than the licenses you do own.
At Directions on Microsoft, we help clients articulate compliance positions they often already have, before an auditor asks the question. Because the difference between a defensible answer and a seven-figure surprise isn’t usually about licenses. It’s about preparation.
