做 M365 运维这些年我接过不少“帮我们省点云费用”的需求最后基本都落在同一件事上Microsoft 365 许可审计。说白了就是把每个订阅、每个用户手里的许可证和真实使用情况对一遍账。听起来就是登录后台数人头但真正做起来你会发现里面全是细节账、政策账、博弈账。这篇文章把我自己的审计流程、卡过的壳、以及后续怎么避免再翻车的经验一次性讲清楚。先说一个我刚做完的真实案例方便你判断这篇内容适不适合你一家 300 多人的客户租户里有近 10 种 SKU光 E3 就买了 260 个席位可实际活跃用户勉强 210 人剩余 50 个席位里还有十几个分配给了已离职但账号没禁用的人。把多买的、没用的、分错的加在一起一年白白浪费的授权费用超过十五万。这个数字对任何一家公司都不是小钱而这种情况在大多数企业里都普遍存在。适合看这篇文章的人你正在做 M365 管理员或者负责 IT 成本控制马上要做季度/年度盘点或者你只是单纯发现账单越来越贵想搞清楚钱花在了哪里。我会从许可模型的底层逻辑讲到具体的 PowerShell 拉数命令再讲到如何把审计结果落地成省钱的决策尽量做到“看完就能干”。1. 先想清楚M365 许可审计到底在审什么1.1 从“人均一个包”到“服务计划级的精细管控”很多刚接触 M365 的人会以为许可审计等同于查看“每个用户有没有被分配许可证”。但这只是最表层的动作。真实的审计至少包含三个层级SKU 层级租户买了哪些订阅每个订阅买了多少席位实际分配了多少席位。这一步回答“钱花在哪个产品上了”。用户层级每个用户分别被分配了哪些订阅。这一步回答“谁手里拿着什么”。服务计划层级每个订阅内部往往包含多个服务计划比如 E3 里含 Exchange Online、SharePoint Online、Teams、Power BI Pro 等你可以给某个用户保留 Exchange Online 但关掉其他计划。这一步回答“分配给用户的功能是否真的被使用了”。如果你只做到第一层审计报告就是一张财务清单做到第二层能发现分配不均和离职账号只有做到第三层才能发现“用户明明有 E3却只用了邮箱其他功能全闲着”这类真正的浪费。我在实际操作中会一次性把三层数据全部拉出来再叠加上活跃度报表这样才能得到一张完整的“许可账”。1.2 内部审计与外部合规审计的差别还有一类审计容易被混淆微软侧发起的合规审计。它的重点是核对你的实际用户数和已分配许可数是否匹配防止你使用了未购买授权的功能。这种审计通常比较严重涉及法律风险不是日常运维能完全控制的。我日常做的“Microsoft 365 License Audit”更多是指内部成本治理审计目的有三个识别闲置和过度分配的许可控制软件开支发现离职未清、重复购买、上下交错的情况修正管理漏洞为下一次采购谈判提供真实的使用数据避免继续拍脑袋买席位。这两种审计在数据需求上有大量重合但侧重点不同。内部审计更关注“买少了还是买多了”外部合规审计更关注“用超了没有”。我建议无论有没有接到通知都按合规的标准来做内部审计至少保证账实相符这样哪天真来了合规要求你也能第一时间拿出完备的数据。2. 审计前必须吃透的许可模型细节2.1 SKU、服务计划、许可证分配三个概念各管什么在拉数据之前必须理解 Microsoft 365 的授权体系是怎么组织的。你买的订阅在后台叫 SKU比如ENTERPRISEPREMIUM是 E3ENTERPRISEPACK是老版 E3 的另一种编号SPE_E5是 Microsoft 365 E5。每个 SKU 自带一组服务计划ServicePlans比如邮箱功能对应ExchangeOnline云存储对应SharePointOnline/OneDriveForBusiness即时通讯对应Teams桌面 Office 对应DesklessOPP或OfficeClient按 SKU 不同叫法略有差别当管理员给用户分配许可证时本质上是在做两件事一是确定这个用户拥有哪个 SKU 的授权二是选择该 SKU 下的哪些服务计划对该用户生效。默认情况下所有计划都是开启状态但你可以只分配部分计划。这个机制从产品设计上是为了灵活性但也是审计里最容易出问题的根源。我见过好几个租户管理员为了图省事给所有用户一键分配了全套计划导致即使某些用户只用 Teams也被分配了 Exchange Online 和桌面 Office 授权。不是说这样会立刻多扣钱但当你做 SKU 级降级时会发现很难判断用户到底依赖哪些功能所以审计必须做到服务计划级。2.2 按用户计费和按设备计费的坑大部分 M365 订阅是按用户计费的但也有例外比如 Windows 10/11 企业版升级、某些远程桌面授权是绑定设备的。在一个混合办公环境里用户可能有多台设备设备级的许可证数量往往难以精确核对很容易重复购买或漏买。我做审计的时候会单独建立一张“用户-设备”对照表把绑定设备的许可证如 Windows Enterprise E3/E5 附加模块独立核算不混进按用户计费的 SKU 里。这样既方便对账也能避免后续做许可证裁剪时误伤了某个设备。2.3 常见的隐藏成本附加组件与按比例扣费另一个容易在审计中被忽略的是附加组件Add-on。比如你给部分用户开了 Audio Conferencing、Power BI Premium Per User、Visio Plan 2、Project Plan 3这些小额的 SKU 往往散落在不同用户头上汇总起来金额却不小。我在一次审计中就发现客户的 Visio 和 Project 订阅总共分散在 80 多人身上但其中超过一半的人近半年都没打开过相关应用。还有一类隐藏成本与“按比例扣费”有关。如果你的订阅支持按使用天数折算在你调整用户许可证的当月账单会产生按天计算的比例费用。这类费用在月账单里呈现为几块钱到几十块钱不等的零头即使你回收了一个许可证财务可能还是会看到当月多扣了一笔。这不是微软乱扣费而是按比例结算机制。审计人员如果只看“人头数”不看“按比例天数”就容易被账单上的数字误导。3. 实际操作一套从租户到用户的完整审计流程3.1 先用管理员中心做初筛真正动手时我建议先打开 Microsoft 365 管理员中心里的“许可证”页面看一遍总的订阅列表和已分配数量。这一步能帮你快速建立整体认知比如哪些 SKU 已经超卖、哪些 SKU 明明还有大量余额却没人用。管理员中心的优点是直观点进每个订阅就能看到分配了许可的用户列表。缺点也很明显数据粒度不够看不到服务计划级的使用情况没有活跃度信息你无法判断一个用户拿到许可后是否真的在用用户少还好上千人的租户靠手动页面操作不现实。所以管理员中心只适合做初筛不建议拿它当最终依据。我会用它确认几个关键数字比如已购买席位和已分配席位然后立刻切到 PowerShell 和报表中心去拉明细。3.2 用 PowerShell 把许可账目拉成明细表PowerShell 是 M365 许可审计的核心工具。有条件的建议直接使用 Microsoft Graph PowerShell SDK因为旧版 MSOnline 和 AzureAD 模块正在逐步被弃用继续学旧工具等于走回头路。先安装模块并登录Install-Module Microsoft.Graph -Scope CurrentUser Connect-MgGraph -Scopes User.Read.All, Organization.Read.All, Report.Read.All登录完成后第一步是拉取租户内所有订阅信息Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, {NTotalLicenses;E{$_.PrepaidUnits.Enabled}}, {NWarning;E{$_.PrepaidUnits.Warning}}, {NSuspended;E{$_.PrepaidUnits.Suspended}}这里面ConsumedUnits代表已分配的许可数量PrepaidUnits.Enabled是实际购买的可用许可数量。很多人会把这两个数字搞混审计报告的起点数据必须是PrepaidUnits.Enabled而不是你在采购合同上看到的那个“套餐总数”。接下来要建立 SKU 名称映射表因为用户上的许可证信息通常只带 SKU Id不带友好名称$skus Get-MgSubscribedSku $skuMap {} foreach ($s in $skus) { $skuMap[$s.SkuId] $s.SkuPartNumber } $users Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, AssignedLicenses $report foreach ($u in $users) { $licenses ($u.AssignedLicenses | ForEach-Object { $skuMap[$_.SkuId] }) -join , [PSCustomObject]{ UPN $u.UserPrincipalName DisplayName $u.DisplayName AssignedSKUs $licenses } } $report | Export-Csv license-audit.csv -NoTypeInformation -Encoding UTF8这样你就得到了一张“用户名 已分配订阅”的二维表可以直接扔进 Excel 做透视分析。经验之谈任何一张许可审计报表最后都必须能透视成“按 SKU 看用户数”和“按用户看 SKU 数”两个维度只给一个维度后续分析都容易失真。3.3 结合活跃用户报表算“真实使用率”拿到分配明细只是审计的一半另一半是使用情况。M365 报表中心提供了活跃用户报告但我更推荐用 Graph API 直接拉取这样能把数据直接揉进脚本$active Get-MgReportOffice365ActiveUserDetail -Period D90 $active | Select-Object UserPrincipalName, ExchangeLicenseAssignDate, ExchangeLastActivityDate, SharePointLicenseAssignDate, SharePointLastActivityDate, TeamsLicenseAssignDate, TeamsLastActivityDate | Export-Csv m365-active-report.csv -NoTypeInformation -Encoding UTF8注意这个报表里的日期范围是 D30、D60、D90 等我一般至少拉 D90因为只看 30 天容易误伤那些周期性使用但最近正好轮空的部门。拿到活跃度数据后把它和许可分配表按UserPrincipalName关联起来就能得到每个用户在每个功能上的“分配状态 最后活动日期 是否为僵尸账号”的完整数据矩阵。对于 Exchange Online还可以结合 PowerShell 单独看邮箱的LastUserActionTime或邮箱访问日志对于 SharePoint/OneDrive可以参考文件活动事件对于 Teams查看用户加入会议或聊天的时间。功能越细分判断越准确但审计成本也会上升。对大多数企业来说用 M365 报表中心的活跃度数据已经能覆盖八成的判断需求。4. 审计结果怎么变成钱优化与回收4.1 把用户分为四类活跃、低活、闲置、未授权数据拉出来后我最常用的是“四分法”来归类用户活跃用户许可证所包含的核心服务都有近期活跃记录保留许可。低活跃用户有使用痕迹但频率很低比如只登录过几次 Outlook 网页版。这类用户需要进一步判断如果能降级到低一档订阅就尽量降级。闲置用户许可证分配后从未使用或者近 90 天没有任何服务活动是回收的首要对象。未授权用户活跃但有服务使用记录却没有对应的许可证。这类用户俗称“裸奔用户”是合规风险需要立即补配或由管理员关闭其访问通道。在多数租户里闲置用户的比例高得吓人。我见过一个 500 人规模的公司有 65 个分配了 E3 许可的人过去半年只登录过一两次而且登录后只看了下 Teams 消息就退出。这些人占了全年预算的 13%属于典型的资源浪费。4.2 降级、回收、共享账号的决策建议对闲置用户的正确处理不是只回收而是先判断业务上是否还需要账号存在。如果账号本身还有业务价值但不再需要高级功能就给对方降级到 F3 或 Business Basic 这类低档订阅如果账号已经不需要保留则考虑禁用账号并回收许可。我通常在回收前做一步“温和确认”给用户发一封邮件告知其许可证即将因长期未使用被降级或回收设置 7 到 14 天的异议期。这种做法看起来多了一道流程但实战中能避免大量“我刚要开始用就被你停了”的投诉。毕竟管理员的目标是省钱不是和生产部门对着干。还有一个经常被忽略的选项是共享邮箱。如果某些人只是为了接收特定邮箱或共享日历而需要 Exchange 功能不一定要分配用户级别的订阅。共享邮箱本身不额外占用许可证只要用户已经有其他 M365 许可就能直接访问共享邮箱。这类场景如果识别准确可以省下不少独立邮箱许可。4.3 谨慎处理服务计划裁剪不是删除当确定一个用户保留某个订阅但只需要其中一部分功能时就可以启用部分服务计划分配。举个例子某个用户确实在用 Office 桌面应用但根本不需要 Exchange Online 和 SharePoint Online那你可以在分配 E3 许可时通过禁用不必要的服务计划来避免该用户产生相关数据或占用相关能力。操作上直接在管理员中心的“许可证”页面取消勾选对应服务计划即可也可以用 PowerShell 批量处理。需要特别提醒的是裁剪服务计划不等于删除用户数据。比如你禁用了某个用户的 Exchange Online 计划他的邮箱数据一般不会立即删除但会变得不可访问或进入特殊状态。如果后续又要开放该计划数据通常还在。这意味着服务计划裁剪的“可逆性”比回收整个许可要高适合那些暂时无法判定归属的场景。同时裁剪服务计划时要留意按产品分组的服务。比如 Teams 和 SharePoint Online 在很多订阅里相互关联裁剪某个服务可能导致 Teams 出现异常最好的做法是先在测试用户上验证影响范围再批量操作。5. 审计过程中最常见的坑和排查思路5.1 数据对不上的几种典型原因做审计时最让人头疼的不是命令不会写而是数据之间互相矛盾。下面是几个最常见的数据不一致原因和处理方法。现象常见原因排查方案已购买席位与已分配席位对不上部分用户使用按比例天数计费服务计划被单独分配按ConsumedUnits和PrepaidUnits.Enabled重新核对用户被显示为“未授权”但实际能用 Teams共享许可证、设备许可证或外部用户检查用户所属安全组和共享许可配置报表活跃度与管理员经验不符日期范围设置太短或使用了错误的报表字段改为 D90并核对各服务的活跃定义某用户明明已离职许可还挂着账号未禁用且未回收许可结合入离职流程定期清理离职账号5.2 本地同步、直属用户和特邀用户的差异如果公司用了本地的 Active Directory 做身份源再同步到 M365那么用户的创建、禁用、删除通常都在本地 AD 里操作。这类同步用户的许可证管理有一点需要注意你在 M365 后台手动给用户分配了许可证但本地 AD 的同步属性里没有对应设置某些云应用和服务可能会在下次同步时重置许可状态造成“分完又被改了”的情况。我的建议是对于同步用户许可证的分配还是通过管理后台或云管理流程来做不要在本地 AD 里尝试控制 M365 服务状态除非你明确在同步规则里做了对应映射。这样既能保证审计数据稳定也能避免权限边界混淆。另外租户里还有一类特邀用户或来宾用户。他们通常来自其他组织在审计时需要单独归类不要和正式员工的许可混在一起看。很多企业会给来宾用户分配付费许可但实际上他们更常以免费来宾身份访问 Teams 或 SharePoint这样做往往可以直接策略性回收。5.3 报表权限和 Graph API 调用的注意点Graph API 的调用权限是审计实操里最容易被卡住的环节。很多管理员平时只有用户管理员权限拉活跃报表时会被拒绝。我需要的最小权限通常包括User.Read.AllOrganization.Read.AllReport.Read.All申请权限时建议在 Graph Explorer 里先测试一遍确认能拿到数据再写自动化脚本。还有一个细节如果你的租户启用了条件访问策略PowerShell 登录可能会被额外的 MFA 或合规策略拦截。这时需要提前申请一个符合条件的服务账号或者利用 Break Glass 账号进行短时间的高权限操作但这类账号务必严格管控、用完即恢复。我个人强烈不建议直接在自动化脚本里存明文账号密码。更安全的做法是用托管身份或者使用Connect-MgGraph的交互式流加上定期令牌管理。毕竟审计报告会包含大量用户隐私信息和授权明细一旦泄露比省下的许可费可严重得多。6. 如何把审计变成例行机制而不是一次性的整治6.1 设定审计节奏与责任矩阵很多团队只有在年底采购续费时才做一次许可审计结果往往是年初省了钱到年中又慢慢恢复原样年末再重新“整治”一遍。出现这种情况的根本原因是缺少例行机制。我建议至少按季度执行一次轻量审计每年执行一次全量审计。轻量审计可以只看分配数和活跃用户变化全量审计则需要包含服务计划级、附加组件级和合规匹配。责任矩阵上IT 运维负责拉数据和初步分析IT 负责人负责审核和确认优化动作采购/财务负责核实账单和预算调整。这是一个三方配合的过程任何一方缺席审计都很难持续。6.2 自动化报表与轻量脚本为了不让审计变成一个人的苦差事可以用计划任务定期跑脚本把结果输出到指定共享目录或 Excel 模板里。比如每月 1 号凌晨自动调用 Microsoft Graph 拉取订阅和用户许可数据生成 CSV再通过邮件发给 IT 团队。脚本维护上我的经验是模块化。把“连接”“拉订阅”“拉用户”“拉活跃度”“导出”分别写成独立函数这样任何一次 Microsoft Graph SDK 升级或权限配置变动都只需要改对应模块不会影响整套流程。同时脚本运行日志要保留至少半年方便追查某次数据突变的原因。6.3 与采购、财务协作让省钱可量化最后一步也是审计价值真正落地的环节把审计结果转化为成本节省数字同步给采购和财务。比如上季度回收了 20 个 E3 许可和 8 个 Visio 许可证按照当前单价折算年度可节省预算多少后续建议在采购续费时减少相应席位数。如果财务团队能在月账单里标识出这些变化整个许可管理的闭环就算建立了。以后再做审计就不再是你自己埋头拉数据而是有一个跨部门协作机制在支撑大家都看得到实际收益。我个人的感受是M365 许可审计考验的从来不是谁 PowerShell 写得溜而是谁能把一次性的数据盘库变成持续的成本控制文化。工具和技术只是第一步真正的分水岭在于你是否愿意花时间去理解业务节奏、用户习惯、采购周期并把这几件事串起来。希望这篇文章能让你少踩几个坑把这件看似繁琐的活做得又准又顺。