企业官网建设流程全解析

注销一个活动状态的 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 订阅、企业移动与安全订阅，后台就会拒绝删除请求。

实操顺序是这样：

1. 登录 Entra admin center（entra.microsoft.com），先别急着找删除入口，先去检查订阅账单归属；
2. 如果挂的是 Azure 订阅，进 Azure 门户的“订阅”页面，确认订阅的“目录”列，看是否指向你想注销的那个租户；
3. 如果是计费管理员，可尝试直接取消订阅（Cancel subscription）。注意免费试用订阅可以直接取消，即用即付订阅取消后还要等一个计费周期确认；
4. 如果是 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 解析设置（重新绑定到新租户时要用）。

导出用户数据可以用 PowerShell：

Get-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），删除租户时会被判定为“目录中存在活跃对象”。

正确的清理顺序是：

1. 进 Entra admin center，左侧“应用程序”菜单，先看“企业应用程序”；
2. 把还在启用的应用逐一删除，或者点击“属性”把“启用此应用程序以分配用户?”置为“否”；
3. 再进“应用注册”，把注册的应用全部删除；
4. 如果提示“对象引用未释放”，先回到企业应用页面，删除对应的服务主体，再回来删应用注册。

这里有一个容易踩坑的地方：有些应用是微软系统内置的，比如 Office 365 相关的企业应用，你删不掉，也不允许删。这种系统级应用不会阻止目录删除，放心。要删的是你自己创建的第三方应用注册，以及你自己注册的服务主体。

查一遍应用注册数量：

Get-MgApplication -All | Select-Object DisplayName, AppId

3.5 第五步：移除自定义域名

这一步我在 2.3 里已经讲过了。实际操作时，只要你把用户和邮箱清理干净，进入“自定义域名”页面，大部分域名已经处于“可删除”状态。

需要注意的一个细节是：如果自定义域是作为 UPN 后缀在用的，也就是用户登录名是 user@company.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 报错速查表

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 门户里也有恢复入口：

1. 登录 Azure 门户（portal.azure.com）；
2. 搜索“已删除的目录”或直接浏览到 Entra admin center；
3. 找到“已删除的目录”列表，选择目标租户；
4. 点击“恢复删除”按钮即可。

恢复过程通常几分钟就能完成，恢复后所有用户、组、应用注册都会回滚到删除前的状态。不过强烈建议不要抱侥幸心理，删除前把所有前置条件查清楚，最好就不要走到恢复这一步。

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 Services（AAD 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 天延迟期结束，让旧租户尘归尘土归土。