Microsoft 365 Licensing: How to Stop Overpaying

M365 FM - Microsoft 365 Licensing - How to Stop Overpaying 00:00:00 Speaker: Most. Microsoft three. Sixty five overspend isn't a pricing problem. It's an assignment problem. You're not paying too much per seat. You're paying for seats nobody should be holding, and nobody is watching. If you want the models behind Microsoft three hundred sixty five cost explained one system at a time, subscribe. That's what this show does today a full audit framework assignment hygiene, group based licensing E3 versus E5 add ons, copilot reclaiming unused licenses renewal tactics. But before the audit, a word from the sponsor sponsor segment. This episode is supported by stellar Migrator for exchange. Here's why that matters for this topic. A migration isn't just a technical project, it's a licensing event. Think about what happens during a tenant move. You stand up a new tenant. You buy subscriptions there while the old ones are still running. Users get licensed in both places. Mailboxes exist twice for a few weeks, sometimes a few months. The project ends, the celebration happens, and the old subscription keeps renewing. Nobody cancels it because nobody owns that step. That's how license waste gets born, not during daily operations, but during the big changes when everyone is focused on moving data and not on counting seats. Stellar migrator for exchange is built for that kind of move. Exchange migrations. Mailbox moves tenant to tenant work with a clear view of what's being moved and where it lands. That clarity is what lets you shut the old environment down on schedule instead of paying for two. If you're planning a migration or you're in the middle of one, the link is in the description. Check it out. Now the model that creates the waste. Section one the model behind overpaying. Here's how most organizations handle Microsoft three. Sixty five licensing. Once a year, someone buys a number of seats. That number comes from a forecast, a budget line, or last year's number plus ten percent. Then the seats get assigned. Someone joins a manager asks, and it assigns a license. Someone needs Visio. So it adds Visio. Someone moves departments and gets a different license and then nothing. Nobody looks again until renewal. If anyone looks at all. That's the old model licensing treated as a purchase event. Something you do once, then forget. But in reality, licensing isn't an event, it's a running system. Think about the three clocks inside it. Assignment runs continuously. Every day someone is added, moved, or removed. Billing runs continuously to. Every month those assignments turn into charges and governance. Governance runs once a year. If it runs two clocks moving every day, one clock moving once a year, that's the gap and spent drifts inside it. Here's what that drift looks like in practice. A contractor leaves in March. The account stays active because the disabled request never reached the right person. The license stays on it. It builds in April, May, June. Nobody notices because one license is a rounding error. But it's never one license. It's the contractor and the person who changed roles and kept both licenses, and the project team that got premium add ons for a six week pilot. And the accounts, nobody can explain each one small together a line item. What typically happens is that the drift never shows up as a single event. There's no alert, no invoice that says waste. There's just a total that creeps up a little each quarter, and a renewal where the number is higher than last year because we grew. Did you grow or did you just not remove anything? So what does the waste actually look like? Industry assessments tend to put unused or underused software licenses somewhere between ten and thirty percent of spend. I treat that as a range, not a promise. Your tenant might sit at the low end, it might sit above it. The point isn't the exact figure. The point is that nobody measures it, and executives rarely see it for a structural reason. They see the invoice. The invoice shows products and quantities. It doesn't show who holds each license, whether they signed in this year or whether they're still employed. Finance sees a number. It sees assignments. Neither sees the gap between them, and the admin center doesn't close that gap. By default, it tells you how many licenses you bought and how many are assigned. It doesn't tell you how many of those assigned seats are doing anything. So the flaw isn't carelessness. Nobody is being lazy here. It's the model behind it, a model built around buying when the cost lives in assigning. To fix that, you first need to understand how Microsoft actually structures a license because it's not what most people assume. Section two How Microsoft. Three sixty five licensing is actually structured. Most people think of a Microsoft three hundred sixty five license as one thing a badge, a seat. Joe has E three. That's the mental picture. And it's wrong in a way that costs money. What's actually underneath is four layers product SKU, service plans, add ons and assignment start at the top. The product SKU is the thing you buy. Microsoft three. Sixty five E3 Microsoft three hundred sixty five E5 Business Premium F3. It has a name, a price, and a quantity. This is the layer finance sees. Now go one level deeper inside every excuse. It's a list of service plans. Exchange online SharePoint teams, Intune entry ID, defender components dozens of them. Each one a separate switch that can be on or off for a given user. So a license isn't a seat, it's a bundle of service plans and you pay for the whole bundle whether the user touches every part of it or just opens email. That's the structural fact. Most budgets ignore. The price, attaches to the bundle, the usage attaches to the plans, and nobody reconciles the two third layer add ons. These are separate SKUs that sit on top of a base license team's phone, audio conferencing, power BI Pro Visio project. Each one has its own price, its own quantity, and its own line on the invoice. And the fourth layer is assignment. This is where a SKU or an add on gets connected to a person directly, one user at a time or through a group. Here's the catch with assignment, it's the only layer that changes every day. The SKU doesn't change. The service plans don't change. Assignment does, which is why it's where the money leaks. Now a word on how the billing works because it isn't uniform. Most of what we're talking about is per user. One named user, one license, one charge. But not everything. Some things are tenant level. You pay once for the tenant or for a capability that applies across it. Some things are per device, like certain kiosk or shared device arrangements, and some things are usage based. You pay for what runs, not who holds a seat. Think of the metered billing around some copilot agent activity, or pay as you go services tied to an Azure subscription for billing shapes, sometimes inside the same tenant, sometimes inside the same invoice. And that mix is where intuition breaks down because most of us learned software costs somewhere else per seat. Tools you buy one hundred seats of a project app. One hundred people can use it. If someone leaves you free a seat and give it to the next person. One seat, one person, one price. That model is simple. It's also the model most admins carry into Microsoft three. Sixty five. But here it fails for three reasons. First, the seat isn't one thing, it's a bundle. So two users with the same seat can hold very different capability and very different cost. Second seat stack a user can hold a base SKU plus three add ons. Each one builds on its own. So the real cost of one person isn't a number, it's a sum of parts. Third, some capabilities don't follow the seat at all. They follow the tenant or the usage. Count your seats all day. You still haven't counted what you're paying for, so the per seat habit gives you a false sense of control. You think you're managing one variable, you're actually managing layers. And this is why the problem shows up first at the assignment layer, because that's the only layer where a person, a bundle, and a bill meet. One click in the admin center attaches a whole set of service plans to one human, and that click rarely gets reversed. Which means before you can optimize anything else, you need to know exactly what you own and exactly who holds it. That's where we go next. Section three assignment hygiene starts with knowing what you own. Start with a question most admins can't answer fast. How many licenses do you actually hold right now? Not how many did we buy? How many are sitting on real people today? Those are different numbers. And Microsoft tracks three of them separately. First subscribed units. That's what you bought the total on the contract. The quantity finance approved. Second assigned units. That's how many of those seats are attached to a user by direct assignment or through a group. Third available units. That's the difference seats you're paying for that nobody holds. Subscribe minus assigned equals available. Simple math, but it hides a trap in both directions. A high available count means you bought more than you use. That's idle spend sitting there billing every month, a zero available count feels responsible. It looks like a tight, efficient tenant, but it only tells you every seat is attached to someone. It doesn't tell you whether that someone still works here, still signs in, or still needs what's in the bundle. So fully assigned isn't the same as well used. Hold on to that. Now where do you go to see this? Most people start in the Microsoft three hundred sixty five admin center billing, then licenses. You get a clean table product name licenses available, licenses assigned. It's a fine starting point for a quick look. Then there's the admin center. Under billing licenses, you see the same products from the identity side, and here you can drill into a product and see which users and groups hold it. That's the view that shows whether assignment is direct or inherited from a group. Then there's Microsoft Graph. The licensing data is exposed through the subscribed SKUs endpoint, and on each user you can read the assigned licenses. That's the layer where you stop clicking and start pulling data. You can count, filter and store and PowerShell sits on top of graph. The Microsoft Graph PowerShell module lets you pull every user, every license, every service plan into one table in a few lines. That table is the closest thing to the truth you'll get. Why the extra tools? Because the admin center summary hides detail. Look at what that first table doesn't show. It shows a product and two numbers. It doesn't show which service plans are disabled on each user. It doesn't show whether a license came from a group or was clicked in by hand. It doesn't show when the account last signed in. It doesn't show whether the user is enabled at all. It also rolls up by product. So if someone holds E3 plus a Visio add on plus a team's phone license, those sit on three different rows. Nothing connects them back to one person. The summary answers how many? It can't answer who, why and for what. And waste lives in the who, why and what. So before you change anything, capture a baseline. Take a snapshot you can compare against in thirty, ninety, and three hundred and sixty five days. Without it, you can't prove a single dollar saved. Here's the minimum. I'd record subscribed, assigned and available units for every SKU. That's your inventory. The monthly cost per SKU using what you actually pay, not the list price that turns units into money. The count of users holding each SKU split by direct assignment versus group assignment. That tells you how much of your tenant runs on manual clicks. The count of disabled accounts that still hold a license. That's your first obvious leak. The count of licensed users with no sign in in the last ninety days will refine that later, but get a raw number now. The count of users holding more than one base SKU and the count holding add ons, and the number of licensing errors sitting in your groups. If you use them, export it all dated. Store it somewhere that isn't someone's laptop. Now a warning don't fix anything yet. the urge is strong. You'll see a disabled account holding E5 and want to strip it right away. Resist it. A baseline taken after cleanup is a baseline that proves nothing. Take the snapshot first, because once the numbers are on one page, something happens. The seats stop looking like a pile of assignments. They start sorting themselves into patterns. The same few kinds of waste over and over. And there are five of them. Section four the five patterns of license waste. Open your baseline export and sort it a few different ways. The same five shapes keep showing up. Different tenants, different industries, same shapes. I'll name them because a named problem is easier to hunt. The first one is the orphan. An orphan is a license that belongs to someone who's gone. The employee left. The contractor's project ended. The intern went back to school. The person is out of the building, but the account is still alive and the license is still attached. It's the simplest way to understand. You're paying for a seat and nobody's sitting in it. And it's the easiest to find. Filter for disabled accounts that still hold a license filter for accounts tied to people who left months ago. One query and you have a list. The second pattern is the ghost. A ghost is different. The account is enabled. The person may even still work here, but the account never signs in. Maybe it was created for someone who never started. Maybe it was set up for a project that got cancelled. Maybe the person uses a different account and this one is a leftover from a rename or a merger. Ghosts are harder than orphans. Nothing marks them as dead. They look alive on paper, and the license looks justified because the account is active. So you can't catch a ghost. By checking status. You catch it by checking behavior. And behavior is where it gets tricky, which we'll get to. Third, the duplicate a duplicate is a user holding overlapping licenses, two base SKUs, and one person E3 and E5 together business premium, plus an enterprise plan, an add on that's already included in the bundle underneath it. How does this happen? Usually through change, someone gets a new license for a new role and the old one stays. Someone gets a trial that converts on top of what they already had. Someone runs a migration and both environments assign something. The service plans overlap. Microsoft often handles that by letting the higher one win or by flagging a conflict, but the billing doesn't care about the overlap. Both SKUs bill. You pay twice for capability that's only delivered once. The fourth pattern is overbuying. This one isn't about any user, it's about the quantity you bought. Somebody forecasted growth. A hiring plan, an acquisition, a big rollout. The seats got purchased to match. Then the hiring slowed. The acquisition closed smaller. The rollout shrank to a pilot. The seat stayed on the contract. You'll see it in your baseline as a large available count. Units paid for, attached to nobody. It isn't a hygiene problem at the user level. It's a decision made once months earlier and never revisited. And the fifth pattern is over licensing here. The seat is real, the person is real and the person is active, but the license is bigger than the job. A premium skew on someone who needs email and a browser. E five on a person who never touches a security tool, a compliance feature, or an analytics app. A full desktop bundle on someone who works from a shared terminal. Nothing is broken. Nothing is idle. The person just holds more than they use. And every month you pay. The difference over licensing is the hardest to see because it never looks like waste. It looks like standardization. Everyone gets E5. It's simpler. Yes. Cheaper? No. So that's the list. Orphans. Ghosts. Duplicates. Over buying. Over licensing. Notice how they sort by difficulty. Orphans are mechanical, a status check. Ghosts need behavior data duplicates need a cross-check over buying. Needs a conversation with finance. Over licensing. Needs a conversation about what people actually do all day. Start at the easy end. The mechanical one pays for the effort of everything that follows, and it teaches you where your process is broken. And the orphans, nearly every time come from one place. The moment a person leaves and nobody owns the step that follows. Section five joiners, movers, leavers. Waste doesn't come from the tenant. It comes from people. Every license has a life that follows a person through three moments. They join, they move. They leave. Joiners, movers, leavers. Most admins treat these as three separate tickets, but in reality they're one life cycle. And the life cycle is where nearly all the money leaks out. Start with the joiner because it's the one that works. Someone is hired, a manager files a request, it assigns a license, there's a clear trigger, a clear owner, and a clear result. Nobody forgets to license a new hire because the new hire complains within an hour. That's the pattern to notice. The joiner step works because someone is waiting for it. Now look at the lever. The employee resigns. HR processes the exit. The last day arrives somewhere in that chain. A ticket is supposed to reach it, asking for the account to be disabled and the license removed. Sometimes it does, sometimes it arrives late, sometimes it arrives with the account disabled, but the license untouched because the checklist says disable account and doesn't say remove license. And here's the structural problem. Nobody is waiting for it. Nobody complains when a license stays on a departed user. No alarm fires. No manager notices the cost, lands on a different team's budget. A month later, as one line on an invoice that nobody reads at the seat level. So the license stays because nobody owns the removal, not because people are careless. HR owns the exit. It owns the account. Finance owns the bill. Each of them touches one piece, and the license sits in the gap between all three. What typically happens is that Offboarding gets handled in a rush around the last day by whoever has time. The account gets disabled for security. That part feels urgent. The license part feels like housekeeping and housekeeping weights. Then there's a wrinkle. Sometimes the license is kept on purpose. A manager asks to keep the mailbox for ninety days. Someone needs access to the departed user's files, so the license stays for a while. And a while becomes a year. Because the temporary exception had no end date and no one owned the end. Now, the third moment, which is quieter and costs more. The mover a person changes roles. Marketing to sales, sales to finance, finance to a leadership team. Each new role brings new needs. So each one brings a new license or a new add on. The new license gets added. That's the joiner logic again with someone waiting for it. But the old one never leaves. Nobody requests the removal because the person isn't asking to lose anything. The manager of the old team doesn't think about it. The manager of the new team only asked for what was missing and it doing exactly what was requested adds without subtracting. So the person ends up holding the sum of every role they've ever had. The Visio from the project three years ago, the power BI from the analyst phase, the teams phone from a desk they no longer sit at, counted across a few hundred movers over a few years. That's your duplicate pattern. Built one reasonable request at a time. So what's the actual fix? Not a better reminder, not an email to managers asking them to review their team's licenses once a quarter. Reminders depend on a person remembering, and the whole problem is that no one owns the step. The fix is to connect the HR event to the license event. Think about where the truth already lives. HR knows who joined, who moved, and who left. It knows the date, the department, the job title, the manager. That record is already accurate because payroll depends on it. The license should respond to that record, not to a ticket. When the HR system marks a person as a lever, the account state should change and the licenses should go with it. When the record shows a new department, the entitlement should follow the new department and the old one should drop off at the same moment. No ticket, no reminder, no gap for the license to hide in. That's the shift from someone remembering to remove to a system that removes because the record changed and that only works if assignment itself becomes automatic, which means the answer isn't a better checklist. It's automation. Shared mailboxes, service accounts and resource accounts. Not every account needs a license. That sounds obvious, but some of the quietest waste in a tenant sits on accounts that were never people in the first place. Start with shared mailboxes. A shared mailbox is the support inbox. The invoices address the info at that. Five people watch. It has no license by default, and in most cases it doesn't need one. Users get access to it through permissions and they use their own license to open it. So if you see a paid license on a shared mailbox, ask why. Now there are limits and this is where people trip. An unlicensed shared mailbox is capped at fifty gigabyte. Past that size. It needs an exchange online plan two license, or a license that includes it to grow toward one hundred gigabyte. The archive works the same way. If you turn on the online archive for a shared mailbox, it needs a license to hold it. Same for litigation. Hold those features. Pull a license back in so the rule isn't shared. Mailboxes are free. The rule is that they're free until they cross a threshold up to fifty gigabyte. No archive, no hold, no license. What typically happens is that someone hits the size warning, panics, and assigns a full E3 to fix it. The mailbox now works, but a lighter exchange plan would have done the same job for a fraction of the price. One mailbox, one bundle of service plans nobody needs. Check your shared mailboxes against that size. Anything licensed and under fifty gibibyte with no archive or hold is a candidate to strip. Now the second group service accounts. These are the accounts that run things. A scanner that emails PDFs. A line of business app that sends notifications. A script that talks to SharePoint somebody created each one years ago, usually in a hurry, usually with whatever license was handy and whatever was handy is often E3, sometimes e5. Think about what that account actually does. It sends mail through a connector. Maybe it reads a document library. It doesn't need teams. It doesn't need desktop apps. It doesn't need a security suite protecting an inbox that nobody opens yet. It holds the full bundle and it holds it forever because nobody dares touch an account they can't explain if it breaks something. Whoever removed the license owns the outage. So the license stays and the cost stays with it. The honest fix is to find out what each service account really does, then match it. Some somebody no license at all because the app uses a different authentication path. Some need only an exchange mailbox. Very few need a full user SKU, and some of them shouldn't be user accounts anymore. They should be app registrations that don't consume a seat. Third group resource accounts, meeting rooms, equipment, mailboxes and the accounts behind teams, rooms, devices, room and equipment. Mailboxes don't need a license at all because they're just resources. People book, but a teams rooms device signs in as an account, and that account needs the right entitlement. Microsoft sells dedicated SKUs for that teams rooms and teams rooms Pro they cover the rooms meeting features at a flat per device price, and they cost far less than putting a user bundle on the account. So here's the common mistake a room gets set up using a leftover E5 because that's what the installer had. The room works. The bill is five times what it should be repeated across every room in the building. Count your rooms, compare the license on each one to the dedicated SKU. That's a short list with a clear answer, but all of this still treats accounts as objects. Who holds what and what type they are. The harder question is behavior. Which of these accounts and which of your people actually use what they're paid for? 00:19:48 Speaker: Then. Section seven finding inactive users without breaking things inactive sounds like a simple word. It isn't, because there are two ways to measure it, and they give you different answers. One is sign in activity, the other is workload activity. Sign in activity asks a narrow question did this account authenticate to anything that data lives in entry ID and the account record carries a last sign and timestamp. You can pull through graph workload activity asks a different one. Did this person actually use exchange SharePoint teams? OneDrive? That comes from the usage reports in the admin center, and it tells you what they did, not just whether they showed up. Why does the gap matter? Because a sign in can be hollow. A phone that syncs mail in the background, signs in every day. The person behind it might not have read a message in a year, and the reverse happens to someone can do real work in a shared channel through a different path, and never trip the check you're watching, so you need both sign in to find candidates workload to confirm them. Now one level deeper on sign ins and splits them into two kinds. An interactive sign in is a human typing a password, approving a prompt, or tapping a key. A non-interactive sign in is software acting on the user's behalf using a token that's already there. Background refreshes mobile mail apps that renew themselves, and the last sign in property bundles those in ways that can fool you. If you only read the interactive one, you'll flag people who live inside a mobile app all day. If you read everything combined, a stale device pinging a server will make a dead account look alive, so read them separately. Interactive tells you whether a person is present. Non-Interactive tells you whether something is still running under that name. An account with neither is a clean candidate. An account with only non-interactive needs a question, not a removal. Next, the usage reports. They're useful and they have limits. You should know before you trust them. They cover a rolling window with options of seven, thirty, ninety, and one hundred and eighty days, nothing longer. So you can't use them to prove someone hasn't touched a service in a year. And in many tenants, the user names in those reports are anonymized. By default, you see a scrambled ID instead of a person. A global admin can switch that setting off. And for this work, you'll want it off. But it's a privacy decision. Make it on purpose and tell your security and works council people before you flip it. Also, report data lags by a day or two. Find for a monthly review. Not fine for a decision you plan to make today. So with the data in hand, the real question is where to draw the line. Here's where templates fail you. Someone online says ninety days with no sign in. Remove the license. Clean, simple and wrong. For a lot of businesses, ninety days is nothing. For a seasonal retailer, a school, a farm, or a tax firm. It's far too long for a call center with high turnover, where a missing agent has gone in two weeks. Pick the threshold from your own patent. Look at how your people really work. Then set a number you can defend in front of a manager who's angry about losing a license, and you'll probably want more than one threshold. Frontline staff on short contracts get a short one, office staff get a longer one. Then comes the part that protects you. Exceptions. People on parental leave, long sick leave or sabbatical will look inactive and aren't seasonal. Workers go quiet by design, remove their license in the off season and you've created work for yourself in the spring. And then the accounts that must never be touched on a sign in rule break glass accounts. Those emergency admin accounts exist to sit unused until the day everything else fails. Their silence is the point. Strip a license or disable one. And you've built a trap for the worst day of your year. So keep an exception list named accounts, a reason, an owner and a review date. Because an exception without an end date is just the orphan problem in a new costume. Once you have a list you trust, the next question is how to act on it without causing an outage. That's the reclaim process. Section eight the reclaim process. You have a list names. Last sign in dates. Usage numbers. Exceptions marked. Now the dangerous part. Acting on it because a license removal looks tiny in the admin center. One click. But on the other side of that click sits a person who needed something on Monday morning and now can't open it. So the process has four steps. Notify, wait, remove, retain. Start with the notice before anything changes. Tell the user and their manager. Short message plain words. This license looks unused. Here's the date it will be removed. Reply if you still need it. That one email does two jobs. It catches the mistakes in your data, the person on leave you missed, or the quiet account that runs a monthly report, and it moves the decision to the people who actually know the answer. Then the grace period fourteen to thirty days works for most tenants long enough for someone to be back from a trip and see the message short enough that the list doesn't go stale while you wait during that window, nothing happens. No removal, no disabling, just a clock and a way to object, then removal. And here's where you need to know what you're really touching. Because people fear this step for good reason. When you remove a license, the data doesn't vanish on the spot. What happens depends on the workload. Take the mailbox, remove the exchange online license, and the mailbox enters a soft deleted state. Mail stops flowing to it. The user loses access, but the contents sit there, recoverable for thirty days. Restore the license inside that window and the mailbox comes back. As it was, OneDrive follows a different path and a more forgiving one. When the user account is deleted, the OneDrive is held for a retention period of ninety days by default, and the manager can get access to those files. But a license removal alone on an account that still exists doesn't delete the files. The data stays. The user just can't reach it. Once the entitlement is gone, teams is the odd one. The chats and channel messages a person wrote don't belong to their license channel posts live in the team chat history is stored in hidden mailbox folders, so it follows the mailbox rules and your retention policies decide how long it lasts. So the pattern is this. Remove a license and access ends fast data and slowly if at all. That's why the thirty day window matters. It's your undo button within it. A wrong call costs you a few minutes after it. A wrong call can cost you a mailbox, and that's why I treat thirty days as a floor, not a target. Don't permanently delete accounts the same week you strip their licenses, strip the license, wait, then decide about the account. Now one case catches people off guard. The inactive mailbox say a person leaves and your organization needs to keep their mail for legal reasons or policy. You can place a retention policy or a hold on the mailbox, then delete the user account. The mailbox doesn't disappear. It becomes an inactive mailbox preserved with its hold in place, and an inactive mailbox doesn't need a license. That's the good news. You keep the data and stop paying for the seat, but the conditions are strict. The hold has to be in place before the account is deleted. If the hold isn't there when the license goes away, the mailbox is simply deleted after the thirty day window. And if you want the inactive mailbox to grow past fifty gigabyte or you want an archive on it, that brings the license requirement back so the order of operations matters. Hold first, delete second, skip the first step and you've lost what you meant to keep. This is the part of the process that deserves a written run book, not tribal knowledge. A page that says for a lever, place the hold if required, confirm it applied. Remove the license, wait out the window, then delete. Run the process once and you've cleaned up the backlog. That's real money and worth doing. But look at what you've built. A manual pass driven by a list run by a person with a calendar. It works once. Next quarter, the same patterns grow back because the cause is still there. Making it permanent takes a different kind of control, one where the license follows a rule instead of following a click. Section nine group based licensing. The structural fix direct assignment has one design flaw it depends on a person. Every direct license is a decision somebody made by hand on one day for one reason, and the reason lives in a ticket or in someone's memory or nowhere at all. Six months later, the license is still there and the reason is gone. That's why it doesn't scale. Not because clicking is slow. Because a click leaves no rule behind. Ask why someone holds F5, and the only honest answer is somebody assigned it. Multiply that by five thousand users. You don't have a licensing model. You have five thousand separate decisions and no way to audit any of them. So the fix isn't a faster click. It's replacing the click with a rule. That's what group based licensing does. In entry ID, you assign a license to a security group instead of to a person. Every member of the group gets the license. Add someone to the group and the license lands on them. Remove them and it comes off. The process runs on its own. Entry watches the group, and when membership changes, it reconciles the licenses for you. No ticket, no admin session. Now what does it need? Your tenant needs entry id p one or higher, and in practice, most Microsoft three hundred sixty five business and enterprise bundles already cover it. The group has to be a security group or a Microsoft three hundred sixty five group, with security turned on mail enabled security groups and distribution lists don't work for this. Every user also needs a usage location set that's the country attribute, and Microsoft requires it before it will assign any license. We'll come back to that because it breaks more rollouts than anything else. And the group can hold users. Not devices, not contacts, just user accounts. Here's the shift that matters, and it's easy to miss when the license follows. Membership. Membership becomes the control point. Think about what that means. Before the question was who clicked? Now the question is who's in the group? And that second question is far easier to govern. A group has an owner. A group has a membership you can export in seconds. A group can have access reviews. So someone has to confirm every few months that the people inside still belong. You've moved the decision from a thousand scattered clicks to one place you can see, and that one place can be automatic. This is where dynamic groups come in. A dynamic group doesn't have members you add by hand. It has a rule written against user attributes and evaluates the rule, and anyone who matches is in. Anyone who stops matching is out. So you write something like this department equals finance or job title contains engineer or country equals Germany. Combine them with and or and not. And you can describe a persona in one line. Now connect that back to the life cycle problem we covered earlier. A mover changes departments in the HR system. The department attribute updates in entra the dynamic rule Reevaluates. The person drops out of the old group and lands in the new one. The old license leaves and the new one arrives in the same path. A lever is marked as disabled or loses the attribute. Your rule depends on. They fall out of every group that rule built. The license goes with them. Nobody remembered anything. The record changed and the license followed. That's the structural fix, not a better process. A system where the removal step can't be forgotten because it was never a step. But notice what just happened. The rule is now the entire control. If the rule is wrong, it's wrong for everyone. It touches instantly at scale. A bad filter doesn't miss license one person. It miss licenses a department and the rule only works if the attributes behind it are true. A department field that's blank, outdated, or typed three different ways will quietly put people in the wrong place. So the power is real, but it comes with a design problem because a group that's built carelessly doesn't fix the mess, it automates it. Section ten designing licensed groups that don't collapse. The first design choice comes before you write a single rule. What does one group represent? There are two common answers one group per sq or one group per persona. Start with the SQ version. You create a group called E3 users and everyone who needs E3 goes in. It's easy to explain. It maps one to one with what finance buys. If you want to know who holds E3, you open one group. But look at what the group actually knows. It knows a product. It doesn't know a reason. Why is Priya in the E3 group? Because she's in finance? Because someone asked. Because she was in marketing two years ago. The group can't tell you. So you're back to the same problem as direct assignment. Just with a middleman. Someone still decides by hand who gets added and the rule lives in their head. Now the persona version, you create a group called Standard Office Worker, and the group is defined by a description of work department, job type, location. The license is a property of the persona, not the other way around. That flips the question instead of who gets E3. You ask, what does a finance analyst need? And the answer becomes the entitlement. Written once applied to everyone who fits. When the business changes its mind and it. Will you change one assignment on one group, not one thousand users. So persona wins on meaning SKU wins on simplicity. Most mature tenants end up with personas on top and SKUs underneath. Here's how that works in practice. Split your group into two layers. The first layer is the base license group one per persona frontline. Standard power user privileged. Each one carries the single base SKU that persona needs and nothing else. The second layer is the add on group. These are small, narrow, and optional. A group for Visio, a group for power BI Pro, a group for teams phone. Each one carries exactly one add on. Why split them? Because add ons don't follow personas cleanly. Not every power user needs Visio. Maybe eight people in the whole company do. If you bake Visio into the persona, you've licensed four hundred people to cover eight. So the add on stays separate with its own membership. Often a small hand-curated group or a dynamic rule with a tighter filter. And the benefit shows up at audit time. You can see the add on cost, the member list, and the owner all in one place. Now, the part that sounds boring and decides whether this lasts. Names and owners. A group without a naming convention becomes a junk drawer within a year. License group two test E five copy of sales standard. Nobody knows which ones are live and nobody dares delete one. Pick a pattern and stick to it. Something like a prefix for the purpose, then the tier, then the scope l I c base standard l I c base frontline l I c add on Visio. You can read the group's job from its name, and you can sort and filter them with a script. Then give every group an owner, a named person, not a team mailbox, someone accountable for what the group contains and whether it should still exist. Put the owner and a short description in the group's properties so it travels with the object. An ownerless group is an orphan waiting to happen. Same pattern, new object and then the one that breaks the most designs. Attribute quality. A dynamic rule is only as clean as the data it reads. Say your standard persona rule is Department equals finance. Sounds precise, but what's in the department field across your tenant. Finance, finance and accounting. Fin. Finance. Ocean with a trailing space for spellings. One team and your rule catches one of them. The people it misses don't get a license. They open a ticket. And the fastest fix is a direct assignment which quietly rebuilds the problem you just removed. The reverse is worse a blank field, a copy pasted title, a contractor tagged as an employee, and someone lands in a persona that gives them far too much. So the rule isn't the hard part. The source is which system owns the department field? Who updates it when someone moves, how quickly does it sink? If HR is the source of truth, then HR data quality is now a licensing control. Whether HR knows it or not. Get that agreement in writing before you build a single rule. Because even with clean attributes, good names and clear owners groups still fail, not randomly, but in the same few ways. Again and again. Group licensing failure modes. Group licensing doesn't fail loudly. That's the first thing to accept. A bad direct assignment gives you an error on screen. A bad group assignment can sit there for weeks, and the only sign is a user who can't open something. Start with conflicts. Some licenses can't live together on one person. Certain SKUs share service plans that are mutually exclusive. Two products that both claim the same service, and Microsoft won't let both turn on for the same user. Say a user lands in your standard group, which carries one base SKU, and also in a legacy group that carries another. The second assignment fails and flags a conflict and moves on. The user keeps whatever they had first or nothing. It depends on the order things landed and the group itself looks fine. It shows members. It shows a license only when you open the member list and look for the status, do you see the error sitting on one person? Then there's the plain math problem. Insufficient units. You assign a license to a group of four hundred. You own three hundred and eighty seats. Entry doesn't refuse the group. It licenses people until the seats run out. Then stops. Twenty users end up with no license and nobody is told. No email, no alert. This is what I mean by silent. The system did exactly what it was built to do. It just didn't tell anyone that the result is wrong. Which means a joiner can start on Monday, drop into the right group, and still sit there without a mailbox. Because last week's batch used the final seat. Now the one that breaks more rollouts than any other usage location. Microsoft won't assign a license to a user with no country set. Some services aren't sold in every country, so the platform needs to know where the person is before it grants anything. If that attribute is blank, the assignment errors out with a message about usage location. You can fix it one user at a time, but the cleanup fix is upstream in the source set usage location. When the account is created from the same HR record that feeds department and title. Otherwise, every new hire is a small, predictable failure. Next, nesting. You build a neat structure, a parent group for the whole company, child groups for each region, and you assign the license at the top expecting it to flow down. It doesn't. Group based licensing doesn't cascade through nested groups. Only direct members of the licensed group get the license. Members of a group inside it get nothing. Plenty of designs die on that one line. Flatten it. License the group where the people actually sit. So what do you do about all of this? You treat the IRC as a standing task, not a clean up project. In the intra admin center, each licensed group shows its members with an error. State graph exposes the same thing, so a script can count the failures across every group and drop the number in front of you each morning. That number should be zero when it isn't, you want to know before the user does. Check it weekly at minimum. Daily. If your mid migration. Treat every error as a symptom. A pile of usage location errors means your provisioning is broken. A pile of unit errors means finance bought too few seats or someone is over licensing the queue isn't noise. It's the one place where group licensing tells you the truth. And that matters right now. Because the next step is the risky one. You're about to move people who already hold direct licenses into groups in a live tenant done carelessly. That's how you create the very errors we just covered on real people in the middle of a workday. 00:36:22 Speaker: Section twelve. Moving from direct to group assignment. Most tenants don't start clean. They start with years of direct assignments. Thousands of them. Each one a small decision nobody wrote down. So the move to groups isn't a build, it's a migration. And the first step is boring on purpose inventory. Pull every user, every license and one more field. How it was assigned graph carries that on each license record. If the assignment came from a group, it shows a group ID. If it was clicked in by hand, that field is empty. So filter for the empty ones. That list is your direct assignments and it's the full scope of the project. Now sort it by pattern group people by the exact combination of licenses they hold, you'll find that a few combinations cover most of your tenant, maybe E3 alone for the majority E3 plus visual for a small slice, E5 for a few hundred, and then a long tail of odd one offs. The common combinations become your personas. The odd ones become questions. Does this person really need that stack, or is it left over from an old role? Answer those now, because the migration is the cheapest moment to fix them. Next, build the target groups. Create the base group for each persona and the add on groups beside it using the names and owners you've already agreed on, assign the license to the group, then add the users for a static group. Import the member list for a dynamic group. Write the rule and let entra. Fill it before you trust a dynamic rule. Check its membership preview against your inventory. If the rule catches four hundred people and your list has four hundred and forty, those forty need an explanation. And here's the part that surprises people. Once the group holds the license and the users are in entra reconciles on its own, it sees the user already holds that license directly, and it doesn't assign a second one. It just records that the same license now has two sources one direct, one from the group. No duplicate charge, no service interruption. The user notices nothing because the license never left. That overlap is the whole safety mechanism for a while. The user is covered twice, so don't rush the next step. Confirm. First, open the group, check the member list and look for errors. You want every member showing an active license from the group with zero conflicts and zero unit shortages. Run your script against the whole tenant and count users where the group source is present. Only when that number matches your inventory do you remove the direct assignments and do it in order. This sequence protects you. Start with a the pilot. One small group, maybe fifty people in a department where you know the manager. Remove their direct licenses. Wait a few days and watch for tickets. If nothing comes in, widen it. Do large batches outside working hours and keep each batch to a size you can undo by hand a few hundred, not a few thousand. Leave the privileged accounts for last admins, executives, anyone whose outage becomes a phone call. By then, you've run the process twenty times and you know how it behaves. Watch for one trap. If you remove a direct license from a user before the group license has landed, you've just stripped them. The mailbox goes into that thirty day soft delete state we covered, so always verify the group source on that specific user, not just on the group as a whole. Now rollback. Think about it before you start, not after something breaks. Your rollback is the baseline export. It lists exactly who held what and how. If a batch goes wrong, you can reassign directly from that file in minutes. Keep it dated and ready. Also, don't delete your old process on day one. Keep the ability to assign directly open for the first month so a surprise doesn't leave a new hire waiting and take one thing from the timing. Removal is reversible within the window. A deleted group isn't. So don't clean up groups until the dust has settled. When this is done, the tenant looks different. Assignment follows rules. Errors show up in one queue. The life cycle problem has a mechanism behind it. That's hygiene and it's the foundation, but it only controls who holds a license. It doesn't ask whether the license itself is the right one. So now we move up a level from how seats are assigned to which seats you're buying in the first place. Section thirteen, E three versus E five. The wrong question. Sooner or later, every licensing conversation lands on the same sentence. Do we need E five? It comes from a c I o after a security briefing. It comes from a partner at renewal time. It comes from a vendor who just showed a slide with a lot of shield icons, and whoever asks it expects a yes or a no. That's the problem. The question has only two answers. Think about what it assumes. It assumes the tenant is one thing, one audience, one need, one price. Pick a tear and everyone gets it. But in reality, you don't have one audience. You have a finance team that handles wire approvals. You have admins who can change anything in the tenant. You have a warehouse crew that opens email twice a day, and you have a few hundred people in the middle who write documents and join meetings. Put one tier on all of them and someone is wrong. If you say yes, you pay for security tooling on thousands of people who will never face the threat it covers. If you say no, you leave the highest risk accounts without protection. They actually need both answers. Cost money. One costs it every month on the invoice, the other costs it later in an incident. So the frame forces an all or nothing choice, and the choice itself is the floor. To get out of it, you need to see what E5 actually is, not the slide, the contents. E3 is the base office, apps exchange, SharePoint teams, and a solid set of identity and device management. Most people do their whole job inside it. E5 is e3 plus for blocks stacked on top. The first block is security. Microsoft Defender for endpoint for office three hundred sixty five for identity, and for cloud apps, plus the higher tier of entry ID, which brings identity protection and privileged identity management. That's threat detection response and risk based access. The second block is compliance, the advanced Purview tools, premium eDiscovery, advanced audit, insider risk management, communication compliance. These are for legal teams, regulators and And investigations. The third block is voice team's phone and audio conferencing, so people can make calls from teams and dial into meetings by phone. And the fourth is analytics Power BI Pro bundled in along with the reporting tools around it for blocks for different buyers inside your company. Security cares about the first legal cares about the second facilities and telecom care about the third. Analysts care about the fourth. Now look at that list again. Almost nobody needs all four at once for all of their people. A bank might need the security and compliance blocks. For most staff, a manufacturer might need almost none of the compliance block and a lot of the voice one. A consulting firm might want analytics and nothing else. Yet the tier sells them as one package at one price, and the price is the sum of all four. That's the shift to make. Stop buying tiers. Start buying capabilities. A tier is a bundle someone else designed. For an average customer who doesn't exist. A capability is a specific thing. A specific group of people needs to do their job safely. When you start from the capability, the question changes. It's no longer E3 or E5. It's which of these blocks does this group of people need and what's the cheapest way to cover it. Sometimes the cheapest way is the full E5 bundle. When a group needs three of the four blocks, the bundle usually wins because the parts cost more apart than together. Sometimes it's E3 with one add on, and sometimes it's E3 for ten thousand people and E5 for three hundred. You can only find that out by looking at each capability on its own. What it does, who truly needs it, and what it costs when bought alone. So let's open the box block by block, starting with the one that carries the most weight in every E5 pitch. Security section fourteen. What E5 adds in security. Security is the block with the biggest price tag, so it's the one that gets bought on fear. Open the box and it isn't one product, it's four defender tools and one identity upgrade, each protecting a different door. Start with defender for endpoint. It watches the devices laptops, servers, sometimes phones. It spots malware, odd behavior, and attackers moving between machines, and it can isolate a compromised device from the network in minutes. Defender for office three hundred sixty five plan two watches the inbox and the collaboration tools, safe links, safe attachments, and the investigation tools that trace a phishing message to everyone who received it. Plan one already ships in business premium. E3 gets only the basic filtering, so plan two is the real upgrade defender for identity watchers. Your on premises Active directory. It looks for stolen credentials, lateral movement and reconnaissance. If you have no on prem directory, that tool has almost nothing to look at and defender for cloud apps watches how people use cloud services, which apps they connect, what data flows out, which ones nobody approved. Then the identity piece entry IDP two adds two things identity protection scores, sign ins and users by risk, and can force a password change or block access when a score climbs. Privileged identity management makes admin rights temporary. Nobody stays a global admin all day. They request the role, use it and it expires. Now who needs which? Not everyone. That's the whole point. Privileged identity management matters most for your admins. A few dozen people at most. Identity protection matters for anyone whose account would hurt if stolen. Executives finance anyone who can approve a payment or touch a customer database defender for endpoint matters. Wherever devices hold sensitive data or face real attack. a developer laptop? Yes. A shared kiosk in a warehouse, much less. But here's the quiet cost overlap. Many tenants already own a security tool that does part of this. An endpoint product from another vendor running on every machine. A mail filter in front of exchange. A cloud access broker someone bought three years ago by F5 on top, and you pay twice for the same job and then run two agents fighting over the same files. So before you add anything, write down what you already run product coverage renewal date. Then compare it block by block against what E5 would replace. The savings only appear when the old tool actually goes away. Overlap also hides inside Microsoft's own catalog business. Premium already carries defender for business and plan one Mail Protection. Some E3 customers hold entry ID P one and don't realize the P2 gap is smaller than the pitch suggests. Next, the alternative you don't have to take the whole bundle. Microsoft sells these pieces on their own defender for endpoint plan two, defender for office three hundred sixty five, plan two, and entry ID P2 can each be added to E3 separately. There's also the E5 security add on, which stacks the security block onto E3 without the compliance, voice and analytics parts. The trade is simple add one or two pieces and standalone pricing usually wins. Add most of the security block and the add on or full E5 tends to cost less than the parts somewhere between two and four components. The lines cross price lists change, so don't trust a number from a video. Run the math yourself on your own counts with your own agreement, and remember who it's for. Cost the privileged and high risk personas on their own. A few hundred seats of E5 security is a very different bill from a company wide upgrade. Security is only half of what the tier adds, though the other half serves a different buyer entirely and rarely sits in the IT budget at all. Compliance section fifteen what E5 adds in compliance and analytics compliance is a different kind of purchase. Security tools, stop attacks, compliance tools. Answer questions. Who saw this file? What did this person say? Can you prove it to a regulator, a court, or a board? So the buyer isn't the security team, it's legal, HR risk or a records manager. And they usually show up with a specific need, not a general worry. Start with the purview tools E5 adds eDiscovery premium is the heavy version of legal search. E3 already gives you standard eDiscovery, which can find and export content across mailboxes and sites. Premium adds custodian management review sets analytics that group near-duplicate documents and workflows built for real litigation. If you've never been sued, you may never open it. Advanced audit extends the audit log. Standard audit keeps records for one hundred and eighty days. Advanced, keeps them longer, and logs richer. Events like when someone reads a specific mail item that detail matters after a breach. When someone asks exactly what an attacker looked at, insider risk management watches for patterns inside the company. Someone downloads an unusual number of files, then resigns two weeks later. It scores that behavior and routes the case to a small review team and communication compliance scans messages in teams exchange and Viva engage for policy problems. Harassment, leaked financial data regulated advice. Financial firms often have to run something like it. Most other companies don't. Now the analytics block, which is smaller and easier to judge E5 includes power BI Pro. That's the license that lets someone publish reports and share them with others. Fine. If you have analysts building dashboards, but how many of those do you have? Fifty. Two hundred. Compare that to the five thousand seats you might be upgrading. And remember that viewing a shared report doesn't always need Pro, since reports hosted on capacity can be read by free users here, the bundle can work against you. You pay for power BI Pro on every E5 seat, and the report builders are a small slice of them. Buying Pro on its own for those few people is often cheaper than carrying it across the whole population. Then voice E5 includes phone system and audio conferencing. Phone system turns teams into a business phone calls in, calls out voicemail call queues. Audio conferencing gives meetings a dial in number so someone driving can join by phone. Whether that's valuable depends on how you work. If your company runs on mobile phones and desk phones from another vendor, this block does nothing for you. If you're retiring a PBX, it replaces real spend. Notice something about the calling piece. Phone system alone isn't a full phone plan. You still need a calling plan or a carrier connection to reach regular phone numbers. The license is the software side. The minutes are another bill. So now the question that decides your seat count, which of these features need every user licensed and which don't? The answer splits. Some of this is scoped to the person. Phone system only works for users who hold it. Power BI Pro only applies to people who publish or share insider risk policies cover the users. You assign them to other features. Touch more people than you've licensed. Audit logging for one retention behavior for another, whether they reach the whole tenant or only licensed users, changes how many seats you must buy to stay inside. The rules get that wrong in one direction and you over buy for the whole company, get it wrong in the other, and you run features on people you never licensed. So the next step isn't pricing, it's scope. Who must be licensed for a feature? Every premium feature carries a scope rule. Nobody reads it at purchase. Everybody needs it at audit. The rule answers one question who has to hold the license for this feature to be legal? And the answer falls into two camps. The first camp is per user scope. The feature only works for people who hold the license, and it only applies to them. Assigned phone system to four hundred people and four hundred people can make calls. The other four thousand can't. Power BI Pro works the same way. Insider risk policies too, because you pick which users a policy covers and those users need the entitlement. This camp is friendly. You buy exactly the seats you use, and the edge of the feature matches the edge of the license. The second camp is where it gets harder. Some features run at the tenant level or touch people beyond the ones you licensed. Think about what that means. You switch on a capability for the whole organization, and it processes data about everyone. A policy that applies to all mailboxes. An audit setting that logs every user. A scan that reads every message in a channel, including messages written by people who hold no premium seat. Microsoft's licensing terms generally say the same thing about these. If the feature touches a user, that user needs the license, not the admin who configured it, the person it applies to. So the real work is sorting your features into those two camps, and you can't do it from the marketing page. You do it from the service description and the licensing guidance for each feature, one by one, because the answer changes by product. Now, why does partial licensing matter? Because it creates a gap that looks like savings. Say you buy E5 compliance features for the legal team and the executives. Two hundred people. Then you turn on a communication policy that applies to everyone in the company. On paper, you save the cost of four thousand eight hundred seats in practice. You're running a feature on four thousand eight hundred people who aren't entitled to it. Nothing breaks. The portal doesn't block you. The feature runs, the dashboard fills up, and the invoice stays small. That's the danger. The platform enforces some of these rules and trusts you on the others. When it trusts you, the gap stays invisible until a vendor review, a software audit or a regulator asks how a control was licensed. And the cost isn't only back billing, it's the compliance claim itself. If you tell a regulator that every employee's communications are monitored and only a fraction hold the entitlement, you've made a statement your own records can't support. So the safe move runs in both directions for per user features license only the people who need them for tenant wide features either license the full population or scope the feature down so it only touches people you've licensed. Scoping down is often the better path. Most of these tools let you target a group. You apply the policy to the licensed group only and it stops at that boundary, the feature still works. The scope matches the seats. Then comes the step almost everyone skips. Write it down for each premium feature you run, keep a short record what it is, which scope rule applies, which group it's assigned to, how many people that group holds, and which license covers them. Add the date, the source document you checked, and the name of whoever approved it. One page per feature is enough. That page does three jobs. It proves to an auditor that you made a deliberate decision. It stops the next admin from widening a policy by accident, and it gives you a clean place to check at renewal. When someone asks whether you can drop a feature or add one without it, scope lives in one person's head. When that person leaves, so does the answer. And look at what these records start to show. Different groups of people need different features at different scopes. Some need security, some need compliance. Some need nothing beyond the base. Which means the single biggest lever isn't choosing a tier at all, it's mixing them. Mixed licensing strategy mixing is the real lever, not E3 for everyone, not E5 for everyone. A deliberate split built around what people actually do. The unit you design around is the persona four of them cover most tenants, frontline people who touch email and a few apps, often on a shared device for a few hours a shift standard. The big middle. They write, meet, share files and live in teams. Power analysts. Engineers. Project leads. Same base as standard, plus a few heavier tools. Privileged admins. Executives finance fewer people far higher risk. Each persona gets its own base license and each one answers a different question. Frontline asks what's the cheapest thing that still works? Privileged asks what's the cost if this account is stolen? Now, the premium tier E5 belongs on the privileged persona first and often only there. Think about who an attacker wants the admin who can reset any password. The executive whose mailbox holds deal talk the finance lead who approves wire transfers. A stolen account in those roles is an incident. A stolen account in a warehouse is a nuisance. So the identity protection, the risk scoring, the temporary admin rights, they go where the damage would land. Maybe three hundred people, not three thousand. Everyone else stays on a lower base and picks up what they need on top. That's the add on layer we built earlier. Visio. For the eight people who draw diagrams, Power BI Pro for the analysts who publish teams phone for the front desk. Each one is a small group, a named owner, and a line on the invoice you can defend. Let's put numbers on it. Treat these as round illustrative prices and swap in your own agreement. Say you have five thousand users today. All of them hold E5 at roughly fifty seven dollars per user per month. That's two hundred and eighty five thousand dollars a month now split by persona eight hundred. Frontline users move to F3 around eight dollars. That's six thousand four hundred three thousand standard users move to E3 around thirty six dollars. That's one hundred and eight thousand seven hundred power users. Get E3 plus a targeted add on or two, call it forty six dollars average. That's thirty two two hundred and five hundred. Privileged users. Keep E5 at fifty seven. That's twenty eight under five hundred. Add it up about one hundred and seventy five thousand dollars a month against two hundred and eighty five thousand. The gap is one hundred and ten thousand a month over a year. That's roughly one point three million dollars. Is every number perfect? No list. Prices shift, discounts change the math, and some personas will need extra pieces you didn't predict. The shape is what matters. Most of the money sits in the standard and frontline groups because that's where the head count is. Notice something else about that model? The privileged group is the smallest, and it's also where you spend the most per seat. That's the point. You're not cutting security. You're moving it to where it earns its cost. There's a cost on the other side. And be honest about it. A mixed model takes more work, more groups, more rules, more edge cases. Someone has to decide which persona a contractor fits. Someone has to handle the person who gets promoted into a risky role on a Tuesday. But that work is exactly what group licensing is built to carry. The persona is a rule. The rule is a group, and a mover changes personas the moment the attribute changes and one more guardrail. Run the scope check from the last section on every premium feature you keep. If a compliance policy touches the whole tenant, a privileged only license won't cover it. Scope the policy down or license the population it reaches. So far, the mix comes from moving people down from E5, but look at where the headcount really sits. In that example, eight hundred users at the bottom and a base price that's a fraction of the next tier up. That's where the largest per seat savings sit. And it's the group most tenants licensed the worst. 00:55:20 Speaker: Who are front line and light users. Start with the fact most tenants never face. Microsoft sells licenses built for people who don't sit at a desk. There are three real options at the light end. Microsoft three. Sixty five F1. Microsoft three. Sixty five F3 and Business Basic. They cost a fraction of E3, and for the right person, they do the whole job. F1 is the thinnest. It gives you web and mobile versions of the office apps, teams and a small mailbox 2G buy it no desktop apps. Limited file storage. Think of someone who checks a schedule, reads a company update, and joins a team chat from a phone. F3 steps up, the mailbox, grows to fifty gigabytes. You get more storage, plus the identity and device management tools that E3 carries. Still no installed desktop office, but the web apps cover most light editing. Most front line tenants land. Here, Business Basic sits a little differently. It's from the business family, so it comes with the user cap and plan rules we'll get to shortly. But as a product, it gives you a full fifty gigabyte mailbox, teams and web apps at a low price for small groups or light office staff. It's a clean fit. Now, what do these licences leave out? That's the part to check before you move anyone. None of them include the installed desktop apps. No full outlook on a PC, no word or Excel running locally with every feature. If someone builds heavy spreadsheets or lives in macros, the web version will frustrate them within a week. Storage is tighter to F1 especially, and some of the advanced tools tied to the higher tiers simply aren't there, so check any premium feature you rely on against this queue before you commit. But look at what the exclusions actually cover heavy editing, offline work, large mailboxes, local installs. Ask who in your warehouse, your stores, or your call floor. Does any of that? Almost nobody. And that's where the common mistake lives. Giving E3 to everyone who touches a shared device. It happens for understandable reasons. Someone sets up a tenant, picks E3 as the standard, and applies it across the board. Because it's simple. Nobody asks whether a person who badges in at a shared terminal needs a desktop install they'll never use. You end up paying full price for capabilities the work can't reach. A shared tablet runs web apps, a kiosk runs a browser. A phone runs a mobile app. The license promises a desktop suite, and the device can't host one that's over licensing, and it's quiet because the user isn't complaining. They don't know what they're missing and neither does anyone else. So let's look at how the light patterns actually work. Start with the kiosk, a shared device in a break room or on a floor. People sign in, check a schedule or a notice and sign out. F1 usually covers this because the work is read heavy and short. Then the shift worker, someone with a personal phone and an account who clocks in, checks, messages and joins a team huddle. Often F3 fits better since they need a proper mailbox and a bit more control around the account then the part timer or seasonal hire. Here, the license choice interacts with how fast you can add and remove people with group licensing. A seasonal worker lands in the front line group on day one and leaves it on the last. No leftover seats. Notice how this connects to what we built earlier. The frontline persona is a group with a base license assigned by rule. Getting the SKU right for that single group moves hundreds or thousands of seats at once. One check before you move anyone. Pilot a small group. First confirm the apps they use, work in the browser and on mobile and confirm nobody depends on a feature the lighter plan lacks. Do that and the savings are real, and they come without anyone losing the ability to work. But light licenses raise another question. Not about the tier, but about the family, because some of these small, cheap plans live in a different product line entirely, with different rules about how big a tenant can be. And that's where the next mismatch hides business versus enterprise plans and tenant boundaries. Microsoft sells two plan families. They don't behave the same way. Business plans are built for smaller organizations. Enterprise plans are built for everyone else. The names sound like a size label. They're actually a set of rules. The first rule is a cap. Business plans stop at three hundred users. That limit applies per plan, and it's the reason this family exists in the first place. Cross it and Microsoft expects you to move up. You can't just keep adding seats and hope nobody notices because the platform enforces it at purchase. Now the cap is a ceiling, but it creates a trap that sits below it. Say you run a two and eighty person company. Business standard feels right and it is. Then you acquire a small firm and your headcount lands at three forty. The assignment fails not on the new users alone, but on the whole planning conversation. Suddenly a plan you've run for years doesn't fit, and you're migrating seats under pressure. So watch the number long before you reach it. Growth plans, acquisitions, and seasonal hiring all pushed toward that line. And the best time to decide is well before you hit it. Next question. Can you mix the two families in one tenant? Yes, and this is more useful than most admins realize. Microsoft lets you hold business and enterprise subscriptions side by side with different users on each. The tenant is the boundary, not the plan. A user on Business Basic and a user on E3 can share one directory, one teams, one set of groups. But there's a limit on that freedom. The three hundred user cap follows the business family, not the tenant. Once total business seats pass it, the family is out of room and the extra users have to sit on enterprise, and some features differ between the families, so a mixed tenant can behave unevenly if you don't check it first. That's why persona groups matter. Again, a frontline group on Business Basic and a power group on E3 can co-exist as long as you know where each one's ceiling sits. Now the comparison people rarely run. When does business Premium beat an enterprise stack. Business premium is the interesting one. It bundles the office apps, exchange teams and a real security layer, including defender for business, Intune and entry ID P one all at one price. It's closer to E3 plus a security add on than to a basic plan for a group under three hundred. The math can be striking by E3. Then add endpoint protection, device management, and identity control separately, and you assemble something close to business premium at a higher total by business premium, and the same capabilities arrive in a single seat. That makes it a strong fit for a small division, a subsidiary, or a company that never expected to grow past a few hundred. You get the protection without building the stack, but it has edges to. It lacks some of the heavier compliance and analytics tools that sit in the top enterprise tier, and it won't scale past the cap. So for a mature tenant with thousands of users, it's a targeted choice, not a default. The test is simple count the people, list the features they'd have to buy separately, and price both paths on your own. Agreement licenses and plans make up most of the invoice, but they aren't all of it. A second layer sits underneath, built from small line items that rarely get a second look add ons, and they grow quietly. Add ons and the quiet cost stack nobody approves. One hundred thousand dollars of add ons in one meeting. They approve eleven dollars, then fifteen, then a few more. That's how the stack builds. Each line item is small enough to pass without a second look, and each one has a good reason on the day it's bought. So let's name what's usually in their team's phone, which turns teams into a business phone. Audio conferencing, which adds a dial in number to meetings. Power BI Pro for people who publish and share reports. Visio for diagrams. Project for planning work and the defender add ons we covered earlier like plan two for office three hundred sixty five or for endpoint bought on top of a base that already carries a lighter version. Every one of them is a real product. Every one of them solves a real problem for somebody. But here's the pattern. The add on gets bought for a person or a project or a moment, and the moment ends. A consultant needs project for a six month rollout. Someone licenses it, the rollout finishes, the team moves on, and the license stays. Nobody on the project owns the invoice, and nobody on the invoice knows the project existed, or a department head asks for power BI Pro for a quarterly review. It gets assigned directly by hand in the admin center. Two years later, that person has changed teams twice and the license has followed them through both. That's the same orphan pattern from earlier, just with a smaller price tag and a smaller price tag means a smaller chance anyone looks. Now the second trap standalone versus bundled take teams phone. You can buy it on its own as an add on to E3, or it comes inside E5. Say you add it to two hundred E3 users, then later someone upgrades a few of those same people to E5. Now they hold E5, which includes teams phone, and the standalone add on is still assigned underneath. You're paying for the same capability twice. The system doesn't object. Both licenses sit there and only one of them does anything. It runs the other way to a team is told the bundle is cheaper, so they move everyone to E5 to get voice, but only the front desk uses voice. Now you've bought security, compliance and analytics blocks for people who need it. One thing so neither buy the bundle nor buy the parts is a rule. It's a calculation and it changes every time your head count for each component changes. Which brings us to the audit. And it's a different audit from the one you've run so far. The earlier work was about people who's gone, who's inactive, who holds two licences. This one is about line items for every add on. You ask two questions. First assignment. Who holds it today? Pull the list straight from the group or from graph. If it was assigned by hand, count the seats and match them against what you pay for second usage. Who actually used it in the last ninety days? For power BI, that means someone published or shared for teams phone someone placed or took a call for Visio and project someone opened the app. The usage reports in the admin center cover most of these with the same limits we hit before, so treat them as a strong signal, not a verdict. Now set the two lists side by side. The gap between them is your waist. Someone holds the license and never touch the tool. That's the seat you can reclaim, usually without a single complaint. And the other gap matters to someone uses a feature through a bundle or a trial with no license behind it. That's the one that shows up in a vendor review. Then write down an owner for each add on a name, a reason it exists, and a date to check it again. An add on without those three things is a future line item nobody can explain. Run this once and you'll likely find a few hundred dollars a month hiding in places nobody was watching. Run it at every renewal and the stack stays honest. But there's one add on that doesn't behave like the others. It costs more per seat than almost anything on this list. It depends on things outside the license itself, and everyone is under pressure to buy it. Copilot, copilot licensing. What you're actually buying. Copilot is sold like a seat. It behaves like a system. That gap is where the money goes. Start with the purchase itself. Microsoft. Three sixty five copilot is a per user add on. You don't buy it alone. It sits on top of a qualifying base license, and the base has to be in place first. For most tenants, that means E3, E5, business standard or business premium. If someone holds a frontline license, the add on may not attach at all, so check eligibility before you plan a purchase around a persona. The price is flat per user per month, and it's one of the highest line items on your invoice, higher than most base licenses in the lighter tiers, which means one assigned seat can cost more than the license. It depends on now what's in the box. An assistant, Inside word, Excel, PowerPoint, outlook, and teams. It drafts, summarizes, and answers questions about your own work, but the assistant doesn't contain the knowledge. It borrows it. That's the part that gets missed. Copilot works through Microsoft Graph, the layer that connects your mail, files, meetings, chats, and calendar. Ask it to summarize last week's project, and it searches what you can already reach. It reads on your behalf using your permissions. So the value of the seat depends on three things outside the license first graph itself. If your content lives in a file, share a legacy system, or somebody's personal drive, copilot can't see it. It can only work with what's in Microsoft three hundred sixty five or connected to it. Second permissions copilot respects them, and that cuts both ways. If a user can technically open a sensitive file because a site was shared too widely years ago, copilot can surface it in an answer. It didn't break a rule. The rule was already broken. Now it's visible. Third, data quality stale documents five versions of the same deck folders. Nobody cleaned in a decade. Copilot treats all of it as source material. Feed it clutter and the answers come back cluttered. So the paid seat isn't the finished product. It's the final piece bolted onto a foundation you built or didn't. Now a different question that causes real confusion. Not every co-pilot experience needs the paid seat. There's co-pilot chat. It's a web based chat experience grounded in the internet, available to users with an eligible enter account at no extra seat cost. It can't reach your graph content the way the paid version does. It answers from public sources and from files a user pastes in useful, just not the same product. And then there are agents. These are custom assistants that do specific jobs, like answering HR questions or pulling a status report. Some run with usage based billing instead of a flat seat. You pay as they work in messages or consumption through an Azure billing setup. That's a separate meter. Someone in your company can build an agent, point it at a team, and start generating charges without a single new license being assigned, the invoice shows it. The admin center license count doesn't. So now you have two cost models side by side, a fixed seat paid whether it's used or not, and a variable meter paid only when something runs, each one fails differently. The seat fails by sitting idle, the meter fails by running away. And that brings us to the thing most rollouts get wrong. They treat the seat as the starting line by the licenses, assign them, announce it, and wait for results. But a seat without readiness is just a monthly charge. If the content is scattered, the permissions are loose and nobody knows what to ask it. The user tries it twice, gets a mediocre answer, and goes back to what they did before. The seat keeps billing every month quietly, at a rate higher than the base license under it. That's wasted spend, and it's easy to miss because the license shows as assigned and nothing is technically broken. So readiness comes first. Clean permissions, a sensible content structure, and a clear reason someone would use it on a Tuesday afternoon. Which leaves the real question not whether to buy copilot, but who should hold a seat and how you prove it was worth it. Section twenty two copilot rollout without wasting seats. Most copilot rollouts start with a list of names executives first, then their assistants, then whoever asked loudest. And that list becomes the pilot. But a pilot built on enthusiasm proves nothing. It tells you who likes new tools, not where the tool pays for itself. So design it around the work instead. Pick roles with a measurable task load. People who write a lot of status updates summarize long email threads, sit in six meetings a day, or build the same report every Monday. Sales operations, project managers, customer support leads. Those jobs have a countable volume of repeatable text, and you can time it, then measure before you start. How long does the weekly Report take today? How many minutes go into catching up after a day of meetings? Write the numbers down because without a baseline, every result becomes an opinion. Keep the group small fifty to one hundred seats across a few different roles so you can compare. Run it for at least two months. The first two weeks are curiosity and the real habits show up after that. Now, how do you judge adoption? Don't ask people if they like it. Ask the data. The copilot usage report in the admin center shows per user the last activity date across each app. Word Excel. Teams. Outlook. It also shows active user accounts over a set window that tells you who touched it, where and how recently read it with care. One prompt in thirty days counts as active. And that's a thin kind of active. So look at the pattern instead. Weekly use across more than one app is a habit. A single burst in week one. Then silence is a user who tried it and left pair the numbers with a short survey and a few conversations. The report shows what happened. People explain why. Next. The rule most tenants never write what happens to a seed nobody uses. Define it before you hand out the first license. Something like no copilot activity for forty five days and the seat goes back. Notify the user, give them two weeks to respond, then remove it and return it to the pool. That sounds harsh until you check the price. An idle seat costs more per month than the base license under it. A forty five day window is generous and the user can always ask again. And with a waiting list, the seat moves to someone who will use it. Automate the check. Pull the usage data on a schedule, compare it against assigned seats, and flag the gap. Same pattern as every other reclaim process in this audit with a higher price per mistake. Now the purchase itself, staged or all at once. A staged purchase means you buy in waves pilot first, then a second group based on the results, then a third. Each wave has to earn the next one. An enterprise wide commitment means you sign for everyone, usually to get a better per seat price or a smoother conversation at renewal. That discount is real, but it fixes your spend before you know your adoption rate and a percentage of a seat. Nobody opens is still a seat. Nobody opens, so check whether your agreement lets you scale up smoothly. If it does, staging almost always wins. If you must commit large to get a price, commit to the number your pilot supports, not the number the roadmap promises. And then there's the conversation with the people who signed the checks. Don't bring them cost per seat. That number only ever looks big. Bring cost per hour recovered. If a seat costs thirty dollars a month and the person saves three hours of work in that month, the question changes what is an hour of that person's time worth for a project manager or an analyst? The answer often clears the seat cost before lunch on the first day, and if the pilot shows a seat saving ten minutes a week, then the math fails. And you've learned that for a few thousand dollars instead of a few hundred thousand. That's the model. Seats earn their place with evidence and lose it without. But there's a gap in all of this. Everything so far controls. Who gets assigned a license? It says nothing about who is allowed to buy one. Section twenty three preview note governance covers who can buy, not just who can assign controlling self-service purchases and trials. Every control we've built so far has one hole in it. It assumes the license came from you, but Microsoft lets end users buy things not through procurement, not through a ticket. A person clicks a button, enters a card, or accepts a trial, and a subscription appears in your tenant. It's called self-service purchase, and for several products, it's switched on by default. Think about what that creates. A manager wants power BI Pro or Visio, or a team's premium trial. They find a link, they sign up, and now there's a subscription you didn't approve. With licenses assigned to people you didn't pick. It never touched your groups. It never touched your owner list. That's a shadow license and it builds like any other. So where do you find the setting in the admin center? Under billing, there's a self-service purchase section. It lists products and each one has a toggle allowed or not allowed. Most tenants have never opened that page, but the admin center only shows part of the picture. The full list lives in PowerShell. Through the Miss Commerce module, you connect and you can list every product that supports self-service purchase and see its policy. Then you set that policy to disabled product by product, or loop through all of them in one pass. Run that once and the door closes. Users who try to buy get a message telling them to ask their admin, which is exactly the conversation you wanted in the first place. Now, closing the door isn't always the answer. Some companies want a few people to try tools fast, so there's a middle option. Keep the setting off for the tenant and handle requests through a short form that routes to an owner. You get the speed plus a record of who asked and why next trials they look free, so nobody treats them as a purchase. Here's what happens. Someone starts a trial for an add on. It runs thirty days, people get used to the feature and a few teams start depending on it. Then the trial ends and the subscription converts to paid. Sometimes it renews automatically at full price, and sometimes it simply lapses and breaks a workflow which creates urgent pressure to buy it right now. Either way, you lost the decision. The product chose its own timing, so check how trials are handled before they start. Some trial subscriptions convert on a schedule, and the end date and billing status are visible on the subscriptions page. Review that page for anything labeled trial and write the expiry date on your calendar. Better block trial signups for the same products you block purchases for, so the pipeline stays closed at both ends. Then ask the question underneath all of this, who in your organization has buying rights? There's a role for it. Billing administrators can purchase and manage subscriptions. Global administrators can do it too, along with everything else. And in a partner managed setup, the partner may hold rights you've forgotten about. Pull the list of people in those roles. Count them. Ask whether each one still needs it, and whether each one knows. The settings above exist in many tenants. The answer is a former project lead and an admin who left the company last year. Fewer people with buying rights means fewer surprises on the invoice. Now you have the whole control surface who can assign, who can buy, and what happens when a trial ends. What's missing is the proof that all of it is working. For that, you need data pulled on a schedule without anyone remembering to ask. 01:13:55 Speaker: The reporting and automation stack. A license audit you run by hand is a license audit. You run once. Then the spreadsheet goes stale and the waste grows back. So the last piece isn't another review. It's a pipeline. Data gets pulled on a schedule, lands somewhere people can see it, and flags problems. Before anyone asks, start with the source. Two tools do most of the work. The first is Microsoft Graph. It's the API behind almost everything in the admin center, and it exposes the license data directly. You can call it to list every SKU with purchased and assigned units. You can pull every user with their assigned licenses, their service plans, and their sign in activity. One query whole tenant same shape every time. The second is PowerShell, which wraps graph in commands. You can read the Microsoft Graph PowerShell module lets you write a short script that loops through users, checks what they hold, and writes the result to a file. No clicking, no pagination through a portal, and the output matters more than the method. Build one clean table. User license assignment source last sign in department account status. Everything else you've learned in this audit is a filter on that table. Orphans. Disabled accounts that still hold a license. Ghosts. No. Sign in in your threshold window. Duplicates. Two overlapping skews on one row. Group errors. Any user whose license state shows a problem. Now getting it to run without you. There are three common homes for the job. Each fits a different kind of team. An Azure Automation Runbook runs your PowerShell script on a timer nightly, weekly, whatever you need. It's simple and it uses a managed identity so you don't store a password anywhere. Logic apps do the same job with a visual designer. You connect to graph, run the query, and send the result onward, mostly without code. They suit teams who think in workflows more than scripts, and Power automate fits the lighter cases. A weekly flow that pulls a license count and posts it to a team's channel. A trigger that fires when someone's account is disabled and opens a ticket to check their licenses. It's the right tool when the output is a message to a human. Pick one. Don't build three pipelines that disagree with each other. Now where does the data go? Somewhere people will actually look. A dashboard is the usual answer. Power BI works well here, since it reads straight from a file, a SharePoint list, or a database your script writes into, and the dashboard should stay small for numbers. Earn a permanent spot. Unused units purchased minus assigned per SKU. That's money sitting on the shelf. Inactive users accounts holding a paid license with no activity past your threshold. Duplicates users holding overlapping licenses with the cost of the overlap beside them, and error accounts. Group licensing failures waiting in the queue. Each number needs a trend line. A single snapshot tells you where you are. Twelve months tells you whether the process is working. If inactive users climb every quarter, your reclaim rule is leaking. Then put an owner's name next to each tile, otherwise it's decoration. Now, the question of buying a tool for all this third party license management products exist, and some are good. They connect to your tenant, normalize the data, and add features. You'd spend weeks building cross tenant views. Cost allocation by department alerts out of the box. Some also track other vendors so you see Microsoft next to everything else. When do they pay for themselves? Run a rough test. Take what the tool costs per year. Then estimate the admin hours you'd spend building and maintaining the same thing, plus the savings it would find that you'd miss for a tenant of a few hundred users, the answer is usually no. A script and a dashboard cover it for several thousand users, multiple tenants, or a finance team that wants chargeback by cost center. The math flips fast, but even then, a tool is only a faster way to see the problem. It doesn't own the fix, and that's where the reports start earning their real keep. Because clean numbers on unused units, inactive seats, and overlapping SKUs aren't just an internal win, they're the evidence you carry into the one meeting where licensing money actually gets decided. The renewal, renewal tactics and commercial levers. Most renewal conversations start too late. Someone gets an email from the partner sixty days out, maybe thirty. The quote shows up, the number looks big, and the only real option left is to sign it. By then, the leverage is gone. Not because the data is bad, but because the calendar is. So start one hundred and eighty days before the renewal date at one hundred and twenty days at the latest. That's when you still have time to reclaim seats, test a lighter skew on a pilot group, and rebuild the numbers before anyone asks for a commitment, put the date on a shared calendar with the dashboard we just built attached to the invite. Why so early? Because every change we've covered takes weeks to land, moving frontline users to a lighter plan. Pulling idle co-pilot seats closing out dead. Add ons. If you finish those after the quote arrives, the quote is already wrong. Now, what you can actually do at renewal depends on how you buy. And three agreement types cover most tenants. The Enterprise Agreement, or E is a direct contract with Microsoft. Usually for larger organizations, it runs three years. Pricing is fixed by level for that term, and you threw up once a year for any seats. You added the Microsoft customer agreement. The MCA is the newer direct model. It's built around buying online in a more flexible way, with fewer commitments baked into the contract itself. And CSP, the cloud solution provider route you buy through a partner who manages billing and often support terms, are shorter, and the partner decides much of what the commercial relationship looks like. Here's the difference that matters flexibility and E gives you price certainty and takes away room to move. You commit to a quantity and the contract expects you to keep it. CSP gives you room to move and charges for it in other ways. The MCA sits between them depending on how you buy under it. So the agreement type isn't a procurement detail. It decides which of the savings you found can be collected next. The term itself annual versus monthly. Many subscriptions come in a few billing shapes. A one year commitment paid upfront or monthly, or a month to month term with no commitment at all. The monthly option exists for a reason and you pay for it. The price is often around five to twenty percent higher depending on the product. That premium is the cost of an exit door, and whether it's worth paying depends on how sure you are of your numbers. A seat you'll hold for three years belongs on an annual term, a seat for a pilot, a seasonal team, or a co-pilot group still proving itself might belong on a monthly one. The mistake runs both ways. Put everything on annual to chase the lower price, and you're locked into seats you may drop, put everything on monthly for safety, and you're paying the premium on seats that never move. Now the term most admins hope exists. True down. A true down is the right to reduce your seat count during the term or at the next anniversary. And it's not universal. Under an E, you generally can't lower quantity mid-term and reductions happen at renewal or anniversary within the rules of that contract. Under CSP, flexibility depends on the term you chose and the partner's policy. Some licenses can be cancelled within a short window after purchase then not at all. So read the actual agreement, not the sales summary. Find the clause on reductions and note the dates it applies because if you can't reduce midterm, every seat you add today is a seat you carry until the next window that changes how you size the buy. Finally price. Two questions. First, price protection. Does your agreement lock the rate for the full term or only for the first year? And E typically holds pricing for the term. Other routes may not. Second list price changes. Microsoft updates prices on its own schedule and has raised them on specific products with advance notice. If your terms don't protect you, a renewal can arrive with a higher rate on a seat that hasn't changed at all, so check both before the first meeting. You can't negotiate a price you don't know is moving. That's the map of what's fixed and what's open. Next comes the conversation where you try to change it, negotiating with evidence. Walk into the room with a spreadsheet and you're a customer asking for a favor. Walk in with utilization data, and you're a customer who knows exactly what the contract is worth. That's the whole difference. And it's built months before the meeting. So what does clean data look like? Not a screenshot of the admin center, a table purchased units, assigned units, and active units per SKU, with a trend over the last twelve months. Inactive seats with the dates behind them. Add ons with an owner and a usage count. Copilot seats next to the activity report. Hand over a number you can defend and the conversation changes. The other side stops guessing at your headcount and starts working from yours. But the data only helps if you act on it first. Right size before you commit, not after. Here's what typically happens a team finds fifteen percent waste in the audit, feels good about it, and then signs the renewal at the old quantity. The plan was to fix it later and later under most agreements means the next window, maybe a year out, maybe three. So reclaim first, move the frontline users, pull the idle seats, drop the dead add ons, then let the quote reflect the new shape of the tenant. Every seat you remove before signing is a seat you never have to carry. The same logic applies to growth. Don't buy for the forecast. Buy for what's assigned in active today, plus a small buffer you can name. If the business really does grow, adding seats is easy. Removing them isn't. Now the levers and there are a few worth knowing. Bundling is the first. Microsoft likes to sell more in one deal, so adding a product can unlock a better rate on the ones you already hold. That sounds like a win, and sometimes it is. But run the math on the whole package. A discount on E5 means little if the bundle also pulls in a seat count, you can't use. Multi-Year terms are the second. A longer commitment usually buys a lower rate and price certainty. It also takes away your room to correct mistakes, so match the term to the confidence. Three years on the standard persona where headcount is stable and the skew is settled, shorter terms or monthly billing on the pieces still proving themselves like copilot. And then there's the partner in a CSP setup. The partner is part of the negotiation. Whether you plan for that or not. They carry their own margin, their own terms, and sometimes their own incentives. So ask direct questions. What's the markup? What flexibility do they offer on reductions that Microsoft doesn't? Can they match a direct price? If you buy through an EA, the question flips. What does the partner actually do for the fee you're paying? A good partner earns the margin by catching things you'd miss a week. One just forwards the quote. Now the part that costs the most when it goes wrong. What not to concede. The classic trade is flexibility. For a small discount, the seller offers three percent off for a fixed quantity locked for the full term. It sounds like a deal, but three percent of a bill is small, and the right to lower your seats in a bad year is worth far more than that. So price the flexibility itself. If a reduction, right, a shorter term or a monthly option cost you two or three percent, that may be cheap insurance. Pay it where the numbers are uncertain and watch for the quiet versions of the same trade. A discount tied to a minimum. Spend. A price lock that only holds if you keep a certain bundle. A concession on copilot that comes with a seat floor you can't drop below. Read every condition on the discount because the condition is usually the price. Walk away from anything that trades your options for a rounding error. That covers the negotiation. But a good renewal is a single event, and everything we've built so far is a process. The audit, the groups, the reclaim rules, the dashboards, the commercial dates. None of it holds unless somebody runs it again next week. So what does that look like as a rhythm with owners and a calendar? The operating rhythm. An audit tells you where you are. A rhythm keeps you there. Without one, everything you've built starts to decay. On a schedule you can almost predict. Levers pile up, groups throw errors. Nobody reads. a new ad on, shows up on the invoice with no name beside it, and twelve months later you're running the same audit again from scratch, wondering how the waste came back. So the fix is a calendar for beats, each with a job, a metric, and a name attached. Start weekly and keep it short. Fifteen minutes. No more. Two things get checked. First, the group licensing error. Cue anyone stuck without a license. Anyone with a conflict. Anyone missing a usage location? These are people who can't work properly right now, so this one can't wait for the month. Second, new orphans pull the list of disabled or deleted accounts that still hold a paid seat and clear them. If your automation catches most of them, the list is tiny. If it isn't tiny, that tells you the life cycle process has a leak, then monthly this one takes an hour, maybe two. You review inactive users against the threshold you set earlier, who crossed it? Who's already in the grace period? Who's ready for removal? Then the add on check. Open the add on list, compare assigned seats to the last ninety days of usage, and ask each owner one question. Is this still needed? If an owner can't answer, that's your answer. Notice what the monthly beat does. It keeps the stack from growing in the dark. Each small line item gets looked at while it's still small. Next quarterly. Here the questions get bigger. Review the personas themselves. Are the tears still the right shape? Maybe a department changed how it works. Or a new role doesn't fit any group or. The frontline population doubled after a hiring push. Personas drift because the business does. If you never revisit them, the group slowly describe a company that no longer exists. Then co-pilot pulled the usage report against assigned seats. Apply the reclaim rule. Look at who's active across more than one app and who stopped, and compare the results to the baseline from your pilot. Because that's the number the finance team will ask about. Seats that earn their place stay seats that don't go back to the waiting list quarterly is also when you read the dashboard. Trend lines a single month can mislead three months show direction now annual. This is the heavy one and it starts earlier than people expect. Renewal prep begins one hundred and eighty days out as we covered. That means pulling the full utilization table, finishing the right sizing, checking true down rights and price protection, and setting the quantities you'll defend, but pair it with something most teams skip an architecture review, step back from the seat counts, and ask whether the model still fits. Is E5 still the right call for the privileged tier, or has a standalone product caught up? Has Microsoft changed what a bundle includes? Did the company grow past a planned cap or merge with another tenant? The renewal is the only point in the year when changing the structure costs almost nothing, so use it. That's the calendar. But a calendar with no owners is a suggestion. So assign names and tie each name to a number. Someone in identity owns the error q and the metric is open. Errors older than a week, someone in service desk or HR operations owns orphans measured by licensed disabled accounts. Whoever runs the platform owns the inactive review and the add on list measured by reclaimed seats and unowned add ons. The business owner of each persona signs off quarterly on who sits in it, and someone with budget authority owns the renewal, measured by the gap between assigned seats and active seats on signing day. One person, one metric. One review date. If a number has two owners, it has none. Put all four beats together and look at what changed. The old model treated licensing as a purchase made once a year and forgotten. This one treats it as a running system with inputs, checks and feedback. Assignment is continuous, so oversight is continuous too. That's the shift. And once it's running, the only question left is how you start the first thirty days. Thirty days can change the direction of the bill. It won't fix everything, and nobody should promise that. Week one is inventory. Nothing gets removed yet. Pull every subscribe SKU with purchased and assigned units, pull every user with their licenses, their assignment source, and their last sign in. Put it all in one table, then freeze the baseline. Total monthly spend unused units per SKU. Licensed disabled accounts. Inactive users past your threshold add ons with no owner co-pilot seats with no activity. These numbers are your before. Without them, any savings you report later is a guess. Week two targets the obvious waste and obvious has a narrow meaning here. Licensed accounts that are disabled or deleted. Duplicate SKUs on the same user. Add ons covered by a bundle the user already holds. Unassigned units you can drop at the next window. Skip the judgment calls. For now. Anything involving real people gets the notify and grace process we covered earlier. So start those clocks this week and let them run. Week three is design. Sketch the personas on paper. First front line. standard power, privileged map each one to a base license and the add ons that belong to it. Then built the group's name them, assign owners and check the attribute quality behind any dynamic rules. Don't cut anyone over yet. Add a small test group. Let entra, reconcile and read the error queue. Fixing a rule on ten users is cheap. Fixing it on five thousand is not weak. Four is the pilot and the report move one real population onto groups. Maybe a department, maybe a region. Confirm the license is landed, remove the direct assignments and watch for complaints. If you're testing copilot, set the pilot baseline now before the first seat goes out. Then rerun the week one table and compare. So what should you expect? Be honest with yourself and with the executives. A tenant that never ran an audit often finds somewhere between five and fifteen percent of its license spend in reclaimable waste. The first month usually captures part of it, mostly the mechanical kind. The rest depends on SKU changes and renewal timing, so it lands over quarters, not weeks. Measure it in three ways monthly recurring spend before and after units reclaimed in dollars per SKU, and the gap between assigned and active seats, which should narrow every month. Report the savings that have already hit the invoice separately from the ones that are scheduled. Executives trust a number they can find on a bill. That's the start. What's left is what it all adds up to. Conclusion. Here's the shift in one line. Licensing isn't something you buy, it's something you run. The old model treated it as a purchase event. Buy in the spring a sign on request. Look again at renewal. But assignment never stops and neither does the billing. Only the oversight was annual. Everything in this audit is a way to close that gap. Lifecycle automation groups, personas, owners, a calendar and the cost of leaving the gap open is concrete. Every month without a lifecycle process is a month of paid capability that nobody touches. Seats for people who left. Add ons for projects that ended. A co-pilot seat that got opened twice. Nothing breaks, so nothing gets flagged. If this framework was useful, leave a review. It helps more admins find it, and most of them are paying for something they've never checked. And if you want to keep going, connect with me on LinkedIn. Tell me which part of the Microsoft three hundred sixty five model you want taken apart next. Because right now, somewhere in your tenant, a license is billing for a person who isn't there. It will bill again next month.