注销一个活动状态的 Entra ID说白了就是把你整个 Azure AD / Entra ID 目录给拆了。这事儿听起来简单真做起来一堆坑尤其是目录还“活着”、还有订阅、还有用户在里面蹦跶的时候微软不会让你轻松点下那个删除按钮。我前阵子刚帮一个客户处理完这样一次“临终关怀”把整个过程和踩过的雷整理出来给正准备动手或者已经被报错卡住的朋友一份能直接照做的实操参考。开头先回答一个最核心的问题什么样的人需要看这篇东西你已经确认这个 Entra ID 目录不再承载任何生产业务想彻底清掉你有多租户某个测试/沙箱目录闲置了很久想退租省心你公司合并重组旧的 identity 体系要退场必须干净注销你试过在 Entra 管理后台点删除结果发现一堆前置条件不满足被拦在半路。这篇东西会从“为什么注销不容易”、到“怎么把前置条件一条条摆平”、再到“真正点击注销之后会发生什么”最后是“卡住时的排查思路”一次性讲透。全程不涉及编程写码但会涉及 PowerShell 命令、Entra admin center 界面操作以及一些容易被忽略的隐藏条件。1. 注销 Entra ID 到底在注销什么很多人以为“注销 Entra ID”就是把用户账号删掉、把域名解绑其实完全不是一回事。你真正在做的事情是把整个 Microsoft Entra ID 租户以前叫 Azure Active Directory 租户从微软的云身份体系里彻底移除。可以这样理解这个操作每个 Entra ID 租户相当于一栋独立大楼大楼里住着用户、组、应用注册、条件访问策略、企业应用、域绑定这些住户。注销租户不是清理住户而是把整栋大楼爆破掉地基都给你挖了。所以一旦注销成功意味着这个目录下所有用户账号永久失效不能再登录微软服务所有已注册的企业应用、应用注册、服务主体全部消失你在这个租户里绑定的自定义域名会被释放之后可以重新绑定到别的租户与这个租户关联的所有 Microsoft 365 / Azure 订阅如果还挂着会彻底失去身份支撑甚至可能直接被影响所有条件访问策略、MFA 设置、自助密码重置配置全部烟消云散。这里有个极其重要的区分注销 Entra ID 不等于取消 Azure 订阅也不等于删除 Microsoft 365 的账单合约。更准确的理解是你在把“身份层”拆掉。如果还有订阅额度、账单合约依赖这个身份层那么要么先解绑要么你别想顺利注销。1.1 为什么活动状态的目录不能直接注销微软设置这么苛刻的删除前置条件不是纯粹为了恶心你而是防止误操作。试想一个几百号人的公司目录如果任何一个全局管理员手滑点了删除第二天全员登录不上那绝对是一场灾难。所以微软在 Entra ID 删除逻辑里设计了多重保险前置条件检查删除前会逐项检查目录是否还关联着订阅、是否还存在活跃用户、是否有自定义域名没有处理好等延迟删除窗口即使是符合条件、可以删的目录也不会立即消失而是进入一个 30 天的“软删除”状态期间可以反悔用 PowerShell 或后台恢复全局管理员权限要求能发起删除动作的必须是这个租户的全局管理员Global Administrator其他角色一律没资格。这些机制合在一起导致最常见的现象就是目录是活动的、里面还有用户、身上还挂着订阅结果点了删除了然被弹回来一串错误码。真正要顺利注销必须先把这些保险一个个解锁。2. 注销前必须确认的硬性条件拿我处理的那个客户举例目录里有 40 多个用户、3 个自定义域名、一个 Azure 免费订阅、还连着 Microsoft 365 E3 试用版看着就头大。但说到底要先过掉下面几道硬门槛。2.1 订阅必须全部解绑或取消这是最常见的卡点。Entra ID 不能“带病”注销——只要目录还关联着任何 Azure 订阅、Microsoft 365 订阅、企业移动与安全订阅后台就会拒绝删除请求。实操顺序是这样登录 Entra admin centerentra.microsoft.com先别急着找删除入口先去检查订阅账单归属如果挂的是 Azure 订阅进 Azure 门户的“订阅”页面确认订阅的“目录”列看是否指向你想注销的那个租户如果是计费管理员可尝试直接取消订阅Cancel subscription。注意免费试用订阅可以直接取消即用即付订阅取消后还要等一个计费周期确认如果是 Microsoft 365 订阅去 Microsoft 365 管理后台取消或关闭自动续费等订阅过期、进入禁用状态后再处理 Entra ID。有些订阅的取消不是立刻生效的尤其企业协议EA或者云解决方案提供商CSP名下的订阅你可能根本没有权限直接取消得联系你的 CSP 供应商或 EA 管理员让他们操作。我当时就遇到一个客户是走 EA 通道买的订阅自己后台点了半天最后还是走工单让供应商解绑的花了两天。提示判断是不是所有订阅都处理干净了有一个快速办法——在 Entra admin center 的“概述”页看右侧“订阅”区域是否显示为 0。如果不是 0说明还有尾巴没断。2.2 目录里不能有活动用户这个条件看起来严格实际上有具体口径可循。微软的文档术语是“该目录不能包含用户除非该目录的删除操作是由该目录中最后一位全局管理员执行的”。什么意思呢如果你的目录里除了你自己这个全局管理员之外还有其他普通用户、其他管理员那么删除操作会直接失败。你要么先把这些用户删掉要么临时把所有其他用户账号禁用并删除直到整个目录里只剩下你这个“最后的全局管理员”。这里有几个容易忽略的点同步过来的用户从本地 AD 通过 Entra Connect 同步上来的不算“外部用户”同样会挡住删除。我之前那家客户就是本地 AD 同步过来的几百号测试账号不删根本过不去来宾用户Guest User同样算数。哪怕只邀请过一两个外部协作者只要状态还是“已邀请/已接受”也会卡条件服务主体Service Principal虽然不算用户但有极少数情况会引用目录内的账号后面单说。所以实际操作时我建议先用 PowerShell 快速清点一遍所有用户再动手删。命令行逻辑如下Connect-MgGraph -Scopes User.ReadWrite.All, Directory.ReadWrite.All Get-MgUser -All | Select-Object UserPrincipalName, UserType, AccountEnabled看到列表之后你把非必要的用户对象全部清除。注意如果有 Exchange Online 邮箱许可证的用户直接删 Entra ID 用户会报错得先去 Microsoft 365 管理后台移除许可证或者在 Exchange 管理中心把邮箱转换为共享邮箱后再删。实际处理过程中这种“隐行依赖”最烦人。2.3 自定义域名必须移除Entra ID 租户默认会有一个 *.onmicrosoft.com 域名这是系统自带、无法删除的。但你自己加的自定义域名比如 company.com必须在删除租户之前先移除。移除域名的前提是这个域下没有绑定任何用户邮箱、没有用于 SharePoint、没有配置为 UPN 后缀。说得直白一点先把所有依赖这个自定义域的资源全部迁移到 onmicrosoft.com 域名或者在删除用户前就把域下的账号清理干净。我当时处理客户目录的时候自定义域下还挂着两个共享邮箱一开始没意识到结果点删除按钮被系统拦截报错信息提示“目录包含一个或多个域”。回 Azure 门户的“自定义域名”页面一看两个域名状态都显示“需要验证”。这就是明显的尾巴。办法是先把这两个共享邮箱对象处理掉等域下没有资源了回到自定义域名页面选中域名点“删除”。如果域名处于主域名状态且被设为默认域得先改默认域为 onmicrosoft.com 那个然后才能删。这一步顺序错了后面全卡住。2.4 没有进行中的合规或加急操作一些比较少见的场景也会拦删除比如目录正在做合规保留Legal Hold、还在处理数据主体请求DSR、目录启用过高级审计等。这类情况不是每个目录都会遇到但如果你发现“所有常规条件都满足了还是不能删”可以往这个方向排查。之前有一次我帮一个客户排查目录里明明没有订阅、没有自定义域名、没有多余用户但删除按钮就是灰的。后来在后台翻到一个企业应用下面挂着“合规性保留”标记电话跟客户确认后才想起来他们三个月前申请过一次电子发现eDiscovery保留事后忘了释放。把这个保留移除后删除请求才顺利提交。3. 实操完整注销流程记录说完了前置条件下面是我实际操作过的完整步骤每一步都记录在案照着点就行。3.1 第一步备份你需要的任何东西这一步我的经验是宁可多准备不要到时候再后悔。注销后数据没有后悔药30 天延迟期一过整个目录灰飞烟灭。需要备份的内容包括所有用户的 UPN、显示名、部门等基础信息导出成 CSV 存起来有条件访问策略的 JSON 配置如果你计划在另一个租户重建的话应用注册的 App ID、权限范围、客户端密码有效期记录域名 DNS 解析设置重新绑定到新租户时要用。导出用户数据可以用 PowerShellGet-MgUser -All | Export-Csv -Path entra_users_backup.csv -NoTypeInformation -Encoding UTF8配置策略和应用清单建议直接在 Entra admin center 逐个页面截图或者导出 JSON。虽然麻烦但真到重建的时候你会庆幸做了这一步。3.2 第二步清理订阅和许可证这个步骤要按订阅类型分情况处理。Azure 订阅进 Azure 门户导航到“订阅”找到对应订阅点“概述”里的“取消”。按页面提示确认取消原因后提交。如果页面没有“取消”按钮说明你的角色不是订阅所有者需要找账号管理员操作或者走 Azure 支持请求。Microsoft 365 订阅进 Microsoft 365 管理后台admin.microsoft.com在“计费”-“产品和服务”里找到订阅关闭自动续费等订阅到期。当然更直接的办法是联系计费管理员提前取消省得浪费一个月时间。这里还要注意一个事有些订阅会有“关联的付款方式”或“Azure AD 中分配的许可证”即使订阅停掉如果还有用户占用着许可证删除用户也会被卡。所以最好先给所有用户批量移除许可证再删用户。批量移除许可证的操作在 Microsoft 365 后台“批量操作”里就有选用户、选许可证直接删。如果是加急场景用 PowerShell 更像批量操作$users Get-MgUser -All $license Remove-MgUserLicense -UserId $user.Id -RemoveLicenses (ENTERPRISEPACK) # 示例移除 E3当然如果你已经按 2.2 的步骤把所有用户都删了这一步其实就可以跳过。3.3 第三步删除目录内的用户如果这不是一个可以“只留最后一位管理员”的删除场景就按正常顺序来先把普通用户删完再处理最后的全局管理员。有 Exchange Online 邮箱的用户需要在 Exchange 管理后台先删除邮箱。如果邮箱是共享邮箱直接删除用户对象会报错“邮箱仍存在”。这两个后台之间的依赖是最令人头疼的地方。我客户那次就是 5 个共享邮箱拖了两天。还有已激活企业应用的用户如果企业应用还挂在目录里删除用户有概率被引用冲突。此时建议把企业应用也先清理掉步骤放到后面一起说。如果目录里的用户非常多可以用 PowerShell 批量删除Get-MgUser -All | Where-Object { $_.UserPrincipalName -like *test* } | ForEach-Object { Remove-MgUser -UserId $_.Id }别笑真实清理场景中把测试前缀的用户批量清掉非常常见。先删测试账号、来宾账号最后处理剩余账号。3.4 第四步清理企业应用和应用注册这一步容易被忽略但非常关键。目录里如果存在企业应用Enterprise Application或者应用注册App Registration删除租户时会被判定为“目录中存在活跃对象”。正确的清理顺序是进 Entra admin center左侧“应用程序”菜单先看“企业应用程序”把还在启用的应用逐一删除或者点击“属性”把“启用此应用程序以分配用户?”置为“否”再进“应用注册”把注册的应用全部删除如果提示“对象引用未释放”先回到企业应用页面删除对应的服务主体再回来删应用注册。这里有一个容易踩坑的地方有些应用是微软系统内置的比如 Office 365 相关的企业应用你删不掉也不允许删。这种系统级应用不会阻止目录删除放心。要删的是你自己创建的第三方应用注册以及你自己注册的服务主体。查一遍应用注册数量Get-MgApplication -All | Select-Object DisplayName, AppId3.5 第五步移除自定义域名这一步我在 2.3 里已经讲过了。实际操作时只要你把用户和邮箱清理干净进入“自定义域名”页面大部分域名已经处于“可删除”状态。需要注意的一个细节是如果自定义域是作为 UPN 后缀在用的也就是用户登录名是 usercompany.com即使这个用户已经被删了系统有时还会缓存一段时间。这时候可以等 10~20 分钟再刷新页面或者直接用云端 PowerShell 强制把域标记为可删除。不过真实场景里我几乎没遇到过必须强制的通常都是缓存延迟问题。3.6 第六步发起注销当你把上面这些条件全部满足后就可以正式进入注销流程了。入口路径Entra admin center - “概述”- 右侧“属性”- 页面底部“删除目录”。点击后会出现一个确认面板会列出所有已满足的条件有些情况下还要求你输入租户名称确认。提交删除请求后目录不会立刻消失而是进入延迟删除状态微软默认是 30 天。这期间目录仍然可以通过 Graph API 查出但大多数功能都不可用全局管理员登录 Entra admin center 会看到“此目录正在等待删除”的横幅提示如果想反悔管理员可以发起撤销删除目录会恢复到正常状态。如果你在 30 天内反悔了用 PowerShell 就能取消删除Connect-MgGraph -Scopes Directory.ReadWrite.All Get-MgDirectoryDeletedItem -DirectoryObjectId object_id Restore-MgDirectoryDeletedItem -DirectoryObjectId object_id这里尤其要注意延迟期结束之后目录就会被永久删除再也救不回来。所以提交删除请求前你一定要确认自己真的不再需要这个租户了。4. 常见报错与排查技巧我在处理多个租户注销时几乎每次都会遇到几个经典报错这里整理成一个速查表方便你对照排查。4.1 报错速查表报错/现象大概率原因处理办法删除按钮是灰的无法点击当前账户不是全局管理员检查角色切到全局管理员再试“目录包含一个或多个订阅”还有 Azure 或 M365 订阅未取消检查订阅列表取消所有计费绑定“目录包含用户”还有非删除操作者本人之外的用户用 PowerShell 清点账号并删除“目录包含自定义域名无法删除”自定义域名下还有资源把 UPN/邮箱/SPO 站点迁到默认域名再删域“存在企业应用程序”启用的企业应用未被处理删除/禁用企业应用及其服务主体“无法删除用户应用程序正在使用此用户”有应用注册或企业应用引用了该用户先清理应用引用再删用户“Microsoft Entra ID 正处于删除状态”之前的删除请求未取消等待周期内无法重复发起要么等待周期结束要么先恢复再重新处理删除请求提交后仍然能登录处于 30 天软删除期功能受限但身份信息暂存确认是否要持久删除否则等待即可4.2 隐藏检查项企业应用/服务主体很多用户搞不清楚企业应用和服务主体的关系。简单说企业应用是一个“应用实例”服务主体是它在你的目录里的“身份令牌”。如果你手贱删掉了 Azure AD 里 Microsoft 自带的企业应用可能影响整个租户功能但如果你自己创建的第三方应用没删干净删除租户时就会被卡。我当时处理客户时遇到一个场景企业应用列表里有一个看起来是系统自带的应用名字叫 “Microsoft.Azure.WebJobs”但它是通过 ARM 模板部署测试环境时自动注册进来的也算“活跃对象”。后来我把这个应用删除后才顺利走通删除流程。所以在清理企业应用时别只听名字判断是否系统内置最好逐个查一下创建时间。一般在“创建日期”一列能看到很多老早之前测试遗留的应用。4.3 用 PowerShell 诊断一切如果页面上一时看不出来到底哪里卡住建议直接通过 Graph API 查所有限制条件。我在实际操作中喜欢先用下面这一组命令把所有对象一次性拉出来看# 查看所有用户包括来宾 Get-MgUser -All | Select-Object UserPrincipalName, UserType # 查看所有应用注册 Get-MgApplication -All | Select-Object Id, DisplayName # 查看所有企业应用服务主体 Get-MgServicePrincipal -All | Select-Object Id, DisplayName, AppId # 查看自定义域名 Get-MgDomain | Select-Object Id, IsDefault, IsVerified一次性拉完你基本就能判断是哪个环节漏了。我的习惯是把每一类的结果数量先数一遍如果用户数量不为 1、应用数量不为 0、域名数量大于 1就进一步排查。4.4 特别提醒全局管理员是最后一个删除对象有些博客会告诉你直接把所有用户删掉保留最后一个全局管理员提交删除请求就行。这里隐藏一个小坑如果目录中还有其他管理员角色比如用户管理员、Exchange 管理员、安全管理员即使这些管理员账号没有对应的用户对象但只要有活跃的管理员角色分配删除请求照样可能被拦。所以完整流程是把最后一个全局管理员以外的所有管理员角色先移除删除这些管理员账号最后确保只剩一个全局管理员账号登录着并发起删除。我当时就吃过这个亏。客户目录里有一个抱着“Exchange 管理员”角色的账号它和其他测试账号一起被删了结果角色分配还没解除干净直接导致第一次删除请求失败。后来回到“角色和管理员”页面反复确认没有其他活跃角色分配才成功。5. 删除后的 30 天延迟期里能做什么提交删除请求后很多人的第一反应是“删了就跑”。其实这 30 天延迟期是可利用的窗口用来做最后的检查、恢复错误操作。5.1 恢复目录的具体操作如果你提交删除请求的 30 天内意识到不对比如发现还有服务依赖这个租户可以执行恢复操作。除 PowerShell 之外Azure 门户里也有恢复入口登录 Azure 门户portal.azure.com搜索“已删除的目录”或直接浏览到 Entra admin center找到“已删除的目录”列表选择目标租户点击“恢复删除”按钮即可。恢复过程通常几分钟就能完成恢复后所有用户、组、应用注册都会回滚到删除前的状态。不过强烈建议不要抱侥幸心理删除前把所有前置条件查清楚最好就不要走到恢复这一步。5.2 延迟期内的登录体验延迟期内的租户你用全局管理员账号还能登录但大部分管理操作会受限页面顶部会一直出现警告横幅。我之前有一次在延迟期内想进租户导出一个条件访问策略的配置结果发现策略列表已经变成只读想复制一份配置出来都没门。所以真打算备份务必在删除请求提交之前做别等进了延迟期再想起来。如果你的目录内还有用户需要继续负担服务这 30 天他们大概率已经无法正常使用了。这实际上是强烈的信号提醒你删除租户前一定把所有关联服务、用户迁移完毕不要指望延迟期的宽限。6. 注销之后那些你容易忽略的蝴蝶效应注销成功后你确实把身份层拆掉了但世界并不会立刻清净。有几件“后续事项”容易被忽略实际影响却不小。6.1 微软账号与 Entra ID 的关联问题如果你用微软个人账号注册过 Azure后来又在同一个账号下创建了那个即将被注销的 Entra ID 租户那么注销后这个微软账号可能仍然保留着 Azure 的“全局管理员”痕迹但已经没有租户可管了。奇怪但真实存在的现象是注销租户后你重新登录 portal.azure.com右上角可能还是能看到那个目录名点进去却提示已删除。这不是 bug是 Azure 门户的目录切换器缓存了已删除租户信息过一段时间会自动消失。问你一句要不要移除老旧目录引用时选择“是”就行了。6.2 自定义域名的再次使用如果你注销后想把同一个自定义域名绑定到另一个 Entra ID 租户需要注意一个 DNS 验证和旧的目录残留记录的问题。虽然租户已被删除但 DNS 的 TXT 验证记录、SPF 记录等可能需要手动清理再重新做一遍域名验证。如果原租户还有 Exchange Online 的痕迹DNS 里的自动发现记录Autodiscover可能会指向旧地址导致你新租户绑定域名后邮件收发异常。这个问题我当时处理客户时没有踩到因为客户没有邮箱服务但如果你是带 Exchange 的场景记得去 DNS 管理后台做一次全面清理。6.3 含 Azure AD 域服务的目录要注意如果你的租户还启用了 Microsoft Entra Domain ServicesAAD DS那注销流程更复杂。AAD DS 会在你的 Azure 订阅里创建一个托管域你必须先删除这个托管域再等它从后台释放通常需要几小时到一天。释放过程中DNS 的解析可能仍然指向旧 IP这时即便提交了租户删除请求也大概率会失败。所以遇到这种情况先去 AAD DS 页面把托管域删掉等状态变成“已删除”后再回头处理 Entra ID 租户删除流程。别急着发工单先把时序走对。6.4 引用该租户的外部应用程序很多开发场景中你的其他租户或外部应用可能用 client credentials 方式调用这个租户的 API。一旦租户被注销这些应用会立刻出现 401/403 报错。如果你不是百分之百确定没有外部依赖建议先做一次应用日志排查确认 90 天内的调用量是否为 0再动删除的念头。我之前处理一个客户时就是因为一个自动化脚本还在向旧租户 Graph API 发请求导致删除前最后检查发现了这个依赖。这时候如果稀里糊涂删了后续所有 CI/CD 流水线都会挂掉。7. 我对这个操作的一句话总结Entra ID 注销这件事真正考验的从来不是点按钮的那一下而是之前的资源梳理和依赖排查。订阅、用户、域名、应用、角色、外部依赖每一环节都要处理到位。只要有一环遗漏后面就是连环炸。真到了决定注销的时候先别急着动手花一天时间把所有依赖拉出来看一遍比你点了删除又反悔、恢复、再来一遍要快得多。按照上面这个流程走基本一次就能顺利提交剩下的就是等 30 天延迟期结束让旧租户尘归尘土归土。