Per user, per device, per core, subscription versus perpetual, and the interactions that produce surprise findings. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session eight of forty. Last week was the count, and how the number you report becomes a floor. Today is the question underneath the count: what are you being counted on? Because a Microsoft estate is not measured one way. There are user metrics, device metrics, core metrics, and consumption metrics, and the same organisation costs materially different amounts depending on which of them applies. That sounds theoretical until you see a retailer paying for six thousand people to use nine hundred terminals. Today: the four metric families, the per user against per device choice which is the oldest decision in Microsoft licensing and still live, core based licensing and the way virtualisation changes the arithmetic, subscription against perpetual and what you actually own, and the interactions between metrics, which is where most compliance surprises are born. Let's talk about counting.
Five takeaways. One, the families: what each metric counts, and which populations each one punishes or rewards, because a metric is not neutral, it has a shape it suits. Two, user against device: the oldest choice in this vendor's licensing, where per user has become the default, and the specific workforce shapes where the less popular answer is dramatically cheaper. Three, core based licensing: how server counting works, the minimums that catch people out, and why virtualisation changes the arithmetic rather than the rules. Four, the models: subscription against perpetual with Software Assurance, what you own, what you rent, and what you still have on the day you stop paying. And five, the interactions: four places where two metrics meet and produce a finding nobody expected, including the renewal where a product changes its counting basis and reprices an estate that did not change at all. That last one is the check that closes today, and it is the one most likely to happen to you.
The four metric families. Per user: a named individual counted across all their devices, which is the modern default and suits people who carry a laptop, a phone, and a desktop. Per device: a machine, counted whoever uses it, which suits shared machines run by many people in shifts. Per core: physical or virtual cores on a server, with minimums per processor and per server, where the count follows the hardware rather than the people. And consumption: metered usage, Azure services, Copilot credits, which suits variable demand and where the commitment rather than the meter is the risk, as module four will show. Then the rule underneath all four, in the last row, which is the actual content of this slide: each family counts something different about the very same estate. And the practical consequence is that the same organisation costs different amounts depending on which family it is counted by, and in several places that choice is genuinely yours to make rather than something handed to you on a quote. Most buyers never realise a choice was available, because the quote arrives with one metric already selected.
Per user against per device, the oldest choice in Microsoft licensing and still very much live. Per user wins when people carry several devices: a laptop, a phone, a desktop at home, one licence covering the person wherever they work, and in a knowledge worker estate that is almost always fewer licences than counting machines. Per device wins when many people share few machines: shop floors, warehouses, clinical settings, call centres running shifts, factory terminals. Twenty people across three shifts using one terminal is one device licence, and on the user metric it is twenty user licences. Same reality, twenty times the count. And the third card is the one that describes most real organisations: the estate usually contains both shapes, and gets licensed one way throughout because it is administratively simpler. I want to be fair to that decision, simplicity is a real benefit, one policy is easier to run, easier to audit, easier to explain. But it should be a decision with a number attached rather than a default nobody priced. And notice how this connects to session six: whether a shared terminal population is counted as qualified users or as devices is exactly the question your enrollment's profile settles, so settle it deliberately.
First check. A retailer has four thousand head office staff with laptops and phones, and six thousand store staff sharing nine hundred point of sale terminals across three shifts. How should the estate be licensed? A, per user throughout, for administrative simplicity and one consistent policy. B, per device throughout, since devices are fewer than people overall. C, split by shape: per user for the four thousand multi device knowledge workers, per device for the shared terminals where six thousand people map to nine hundred machines. Or D, per user for stores and per device for head office. Pause here, and actually count the licences each way for each population. Which side does each metric favour?
The answer is C, and the arithmetic makes it obvious once you do it. Head office: four thousand people with two or three devices each is four thousand user licences, against many more device licences, so per user wins clearly. Stores: six thousand people sharing nine hundred terminals is nine hundred device licences against six thousand user licences, and that difference is large enough to fund a licensing team several times over. A licenses the whole estate on the metric that suits forty percent of it, and I want to be honest that A is the most common real world answer, because simplicity is genuinely valuable and split metrics do create administrative work. The point is not that A is stupid, it is that A should be chosen knowing it costs five thousand one hundred extra licences, rather than chosen by default. B applies store logic to head office, where multi device users make devices the larger number. D inverts both populations, which is the answer you get from applying a rule without looking at the shape. The general principle: the metric should follow the shape of the population, and where an estate contains two shapes, expect two metrics and price the overhead honestly against the saving.
Core based licensing, five points on how server counting actually works. Cores, not sockets: server products are licensed by physical cores, with minimums per processor and per server, which is the modern basis and catches anyone still thinking in processors. The minimums bite: a lightly specified server does not licence cheaply, because the per processor and per server floors set a base regardless of how few cores are populated, so twenty small servers can cost more than the hardware suggests. Virtualisation changes the arithmetic: licensing the host against licensing the guests is a design decision with a very large price difference, and your consolidation ratio drives which is right. CALs sit alongside: server licences cover the server and client access licences cover who or what connects, so a server estate always has two counts running in parallel and, in my experience, only one of them gets actively managed. And Azure Hybrid Benefit: existing core licences with active Software Assurance can offset cloud compute cost, which is where this session meets module five and where genuinely large money moves. Our guest analyst has a story about the fourth item on that list, and about what happens when a metric moves underneath an estate.
Guest analyst The hardest conversation I have had about metrics was with a healthcare group who had done nothing wrong. Twelve thousand staff, about three thousand five hundred shared clinical workstations on wards, and they had licensed the clinical estate per device for years, entirely correctly, because that is the shape of the population: nurses on rotating shifts using whichever machine is free. Then at renewal, the product they relied on for that population was proposed on a per user basis. Their estate had not changed by a single machine or a single nurse. The count went from three thousand five hundred to about nine thousand, and the quote reflected it. Now what I want you to notice is the sequence, because their first instinct was to argue that the change was unfair, and unfairness is not an argument that moves a global product decision. What did move it was arithmetic. We produced both counts, side by side, with the shift patterns behind them, and showed that this population was structurally a device population and always had been. We did not get the metric change reversed, because that was never available. What we did get was a three year transition: phased pricing that stepped up rather than jumping, and a price hold across the change, which was worth several million against the alternative. So the lesson is narrow and useful: when a metric moves under you, the direction of travel is usually not negotiable and the transition almost always is. And you cannot negotiate the transition without both counts in your hand before you respond.
Three thousand five hundred devices becoming nine thousand users with no change to the estate, and the win was not reversing the change, it was a phased transition and a price hold worth several million. The direction of travel is usually not negotiable and the transition almost always is. Second check, on infrastructure.
Check two. A team consolidates forty lightly used physical servers onto four large hosts. What happens to the core licensing? A, it falls proportionally, fewer servers means fewer licences. B, it depends on the core counts and the licensing approach: the four hosts may carry many more physical cores each, and licensing at host level covers the guests only if the hosts are fully licensed, so the answer is an arithmetic exercise rather than a headcount of boxes. C, it stays identical, since the workloads are unchanged. Or D, consolidation always reduces licensing cost. Pause here. What is actually counted, servers or cores? And which of those did the consolidation change?
The answer is B. Work it through: forty lightly specified servers might carry eight cores each, so three hundred and twenty cores subject to minimums. Four large hosts might carry sixty four cores each, so two hundred and fifty six cores. Whether that is cheaper depends entirely on the specification and on how you license the virtual estate, and it might be a saving or it might not be. The point is that the unit is cores rather than boxes, and consolidation projects are routinely justified on box count by people who have never seen the licensing arithmetic and have no reason to think of it. A and D make the box assumption explicit, and D adds the word always, which turns something frequently true into something false. C ignores that licensing follows the infrastructure rather than the workload, which is the specific thing that makes virtualisation interesting from a licensing point of view. And the instruction that generalises well beyond this example: any infrastructure change that alters core counts, host ratios, or virtualisation topology is a licensing event, and the licensing arithmetic belongs in the design review, where it is cheap to act on, rather than in an audit finding, where it is not.
Subscription and perpetual, what you own and what you rent. Subscription: you pay for a term and you use the software during it, and if you stop paying, use stops, with no residual right whatsoever. Everything in Microsoft 365 works this way, which is why a lapsed subscription is an operational event rather than a commercial one, people cannot work. Perpetual with Software Assurance: you own a version, and while SA is current you get upgrade rights and a set of benefits, and if you drop SA you keep the version you own, frozen at that point, which is a genuine asset with a genuine ceiling. Why the mix matters: an estate with perpetual server licences and subscription productivity has both a floor that it owns and a flow that it rents, and knowing precisely which is which changes what you are able to walk away from, which module six converts into leverage at the renewal. And the note gives you the question to ask of every material line on any quote: if I stop paying for this in year four, what do I still have? That single question separates an asset from an obligation, and a buyer who cannot answer it for their own estate is negotiating in the dark about their own position.
Where metrics interact, four places surprises come from. Server plus CAL: two counts running in parallel where only one gets managed, and the CAL shortfall surfaces long after the server estate quietly grew. Virtualisation plus cores: host ratios changing the count without changing the workload, which surfaces after a consolidation or a cluster expansion, exactly as in the last check. External users: partners and customers touching internal systems through portals, extranets, and integrations, which module seven handles in full because it is a compliance topic as much as a metric one. And metric changes at renewal: a product moving from one counting basis to another, surfacing in the renewal quote where the same estate suddenly reprices. That fourth row deserves particular attention, and Tom just gave you the case: when Microsoft changes how a product is counted, an estate that did not change at all can cost materially more, and the defence is knowing your counts on both bases before the renewal rather than reacting to the quote afterwards. Which is precisely what the last check is about.
Last check. At renewal, a product you have licensed per device for years is proposed on a per user basis. Your estate has many shared devices. The correct response: A, accept, per user is the modern standard and resisting is futile. B, count the estate on both bases before responding, because a metric change reprices an estate that has not changed, and the counts are the only argument that works: if per user is materially worse for your shape, that is a negotiation about transition terms, phasing, or price protection rather than a fact to accept. C, refuse the renewal until the old metric is restored. Or D, accept and reduce device numbers to compensate. Pause here. Your estate did not change. What did?
The answer is B, and Tom's healthcare group is the worked example. When the counting basis moves, an estate that did absolutely nothing can face a materially larger bill, and the only argument that lands is arithmetic: nine hundred terminals against six thousand people, or three thousand five hundred workstations against nine thousand nurses, is a number that makes the case by itself. An objection in principle does not, because fairness is not a lever with a global product decision behind it. So the response begins with counting both ways rather than with taking a position. And be clear about what is actually negotiable: rarely the direction of travel, since product metrics genuinely do change across the whole market, and very often the transition, phasing, a price hold across the change, a transitional arrangement that recognises the shape of your estate. That is where several million dollars sat in Tom's case. A concedes without measuring, which is the recurring error of this entire course. C picks a fight you cannot win over a decision made for every customer. And D confuses the metric with the deployment: reducing devices achieves nothing once the count has moved to people. Bring both counts, then negotiate the transition.
The metric discipline, three habits, and they matter because metrics are where estates drift quietly, since nothing announces the drift. Know your counts on both bases: for any population that could plausibly be licensed either way, keep both numbers current, which costs one query to maintain and is the entire argument when a metric changes at a renewal you did not schedule. Treat infrastructure change as a licensing event: consolidations, cluster expansions, virtualisation redesigns, cloud migrations, all of them move core counts, and licensing belongs in the design review where it is cheap rather than in the audit where it is not, which is a sentence worth repeating to your infrastructure architects in exactly those words. And ask the year four question of every material line: if I stop paying, what do I still have? It separates the assets from the obligations, it tells you where your exit leverage actually lives, and it takes about twenty minutes for an entire estate. Next session, Software Assurance: what it genuinely buys, what it costs as a percentage, which benefits actually get used in practice, and the cases where dropping it is the right answer.
Session eight, three sentences. One: four metric families count different things about the same estate, so the same organisation costs different amounts depending on how it is counted, and in several places that choice belongs to you rather than to the quote. Two: per user suits multi device knowledge workers and per device suits shared machines, so an estate containing both shapes should expect to run two metrics, and administrative simplicity should be priced rather than assumed free. Three: core based licensing counts cores rather than boxes, which makes every infrastructure change a licensing event, and a metric change at renewal reprices an estate that did not change, answered with counts on both bases and a negotiated transition rather than an objection in principle. Next week, Software Assurance. See you there.
Homework, about an hour, and this week you count one population both ways. One, find the shared device population: shop floors, terminals, clinical devices, shift machines, and if you genuinely have none, use the largest population where people outnumber devices. Two, count both bases: users in that population and devices they share, two numbers, and the ratio between them is the whole argument if the metric ever moves. Three, price the difference at your contracted rates, per user against per device for that population, and write it down, because at some renewal somebody will ask and the person who already has the number wins the exchange. Four, list the infrastructure changes planned in the next year, any consolidation, cluster change, or migration, because each one is a core count change and each belongs in a licensing review now rather than in an audit later. And five, ask the year four question of your five largest lines: if you stopped paying, what would you still have, and mark each one asset or obligation. That last exercise takes ten minutes and tells you where your leverage is.
Five reads before next session, all free on redress compliance dot com. First, the Microsoft licensing guide, for the metric families across the whole product estate in reference form. Second, the Microsoft 365 add on licensing guide, on how add ons count alongside a base metric and where they quietly duplicate something you already own. Third, the SQL Server licensing and cost optimisation guide, which works core based licensing through in real detail including the minimums, and is the best single read if servers are a large part of your estate. Fourth, Microsoft licensing implications for cloud migration, on what happens to core counts and hybrid benefit when workloads move, which is module five's territory. And fifth, Microsoft SAM and licence optimisation, the practice that keeps both counts current between renewals so that you are never counting for the first time under pressure. That is session eight. Metrics decide what you owe before any discount applies, cores are not boxes, and the buyer with both counts negotiates the transition. Next week, Software Assurance. See you there.