Power BI中国迁移说明

1. 概述

为了支持高级功能，我们将停用 China East 1（CE1）和 China North 1（CN1） 区域Power BI。 这些区域不符合新式工作负荷的基础结构要求。 在这些区域的客户，其家庭租户将被迁移至中国北部 3（CN3），该区域提供更佳的性能、可扩展性和对最新功能的支持。

• CE1 和 CN1 区域将停用，在 2026 年 7 月 1 日之后不再受支持
• 我们将在即日起至 2026 年 4 月 15 日期间，将受影响的 Power BI 租户迁移到 CN3。
• 客户无法自行启动或控制主租户区域迁移

本文档提供有关将Power BI主区域迁移到 CN3 的客户的指导。

2. 谁受到影响？

检查Power BI主租户的位置：

• 转到 Power BI Web 门户
• 单击“？” 右上角的图标
• 选择 About Power BI
• 检查 “您的家乡区域是” 字段
• 如果主区域是 中国东部（上海） 或 中国北部（北京）， 请继续阅读此通知。 即使 CE1 或 CN1 中没有专用容量和共享工作区，如果主区域位于 CE1 或 CN1 中，则需要将主区域迁移到 CN3。
• 如果主区域既不是 CE1 也不是 CN1，请忽略这些说明。 您不会被迁移，因此无需执行任何操作。

3. 迁移计划

CE1 和 CN1 的停用日期为 2026 年 7 月 1 日。 请与 Microsoft 帐户代表协调优选迁移窗口（UTC+8），在 2026 年 1 月 1 日至 2026 年 2 月 15 日（含）或 2026 年 2 月 24 日至 2026 年 4 月 15 日（含）之间。 对于每周的任何一天，可用的迁移时间窗口如下所示，并且取决于你拥有的专用容量数。

如果你在 2026 年 3 月 3 日前未联系 Microsoft 帐户代表，我们将假定你处于失联状态。我们将在 2026 年 3 月 3 日至 2026 年 3 月 31 日期间自动迁移你。自动迁移会自动删除你的专用容量（如果有），迁移后你需要重新预配你的容量以还原完整服务。 Microsoft无法代表你重新预配新容量。 如果在2026年3月3日之后与Microsoft帐户代表联系，但在我们迁移您之前，我们会在您选择的时间迁移您。

请与Microsoft帐户代表合作，提前至少两周尝试安排迁移。 如果提前通知不足，所选日期可能与优先的代码部署计划冲突。 提前两周或更长时间通知时，部署计划可以配合客户的迁移计划。

3.1 如果没有专用容量（A/P/EM SKU）

首选时间是选项 1 星期一至星期五（UTC+8），以便Microsoft可以在其正常工作时间内更好地监控和协助您的迁移。 请注意，以下迁移时间窗口不包括迁移前和迁移后的工作。 在迁移窗口开始前大约需要 1 小时预算，以执行 迁移前任务 ，迁移后大约 1 小时才能执行 迁移后任务。

3.2 如果你有 < 10 个专用容量（A/P/EM SKU）

首选是选项 5，即星期六（UTC+8），以便 Microsoft 可以在 Microsoft 正常工作时间内更好地监视和协助您的迁移。 请注意，以下迁移时间窗口不包括迁移前和迁移后的工作。 您应该在迁移窗口开始前预留大约 2 小时来执行 迁移前任务，并在迁移后预留大约 2 小时来执行 迁移后任务。 必须在 04:00 / 16:00（UTC+8）之前删除容量，然后进入 “无容量”阶段，此阶段最多持续 5 小时；接着在 09:00 / 21:00（UTC+8）进入 迁移阶段，该阶段最长可持续 7 小时。

3.3 如果你有≥ 10 个专用容量（A/P/EM SKU 系列产品）

📢 罕见。 具有专用容量的 CE1/CN1 中的大多数客户具有 < 10 个专用容量。

首选是在选项7的星期六（UTC+8），以便Microsoft可以在正常的工作时间更好地监控和协助您的迁移。 请注意，以下迁移时间窗口不包括迁移前和迁移后的工作。 您应该在迁移窗口开始前预留大约 2 小时来执行 迁移前任务，并在迁移后预留大约 2 小时来执行 迁移后任务。 你必须在 00:00/12:00（UTC+8）之前删除容量，这样你将在进入迁移阶段（09:00/21:00（UTC+8））之前，处于无容量阶段，最长可达9小时，而迁移阶段可以持续长达7小时。

3.4 无容量阶段（5 或 9 小时）

📢 如果没有专用容量，请忽略此情况。

删除所有专用容量后，工作区会自动移回共享容量，Power BI访问速度可能会变慢且受限。 具体而言：

• 对于≥ 1GB 的所有数据集，所有用户都无法访问依赖于这些数据集的数据集和所有报表，在迁移后数据集恢复专用容量之前，计划的数据刷新将不起作用。
• 对于启用了 大型存储模式 的所有数据集，无论数据集大小如何，依赖这些数据集的数据集和所有报表都将对所有用户无法访问，并且计划的数据刷新将不起作用，直到数据集在迁移后重新启用专用容量。 此外，新预配的专用容量必须与迁移前位于同一区域中。 请注意， 大型存储模式 数据集仅在 CE2、CN2、CN3 中受支持。 CE1 或 CN1 不支持 它们，因此迁移后无需担心在 CE1 或 CN1 中重新预配新的专用容量。
• 对于所有数据集 < 1GB 和 小型存储模式，拥有免费许可证的用户将无法访问这些数据集和关联的报表。 只有具有 Pro 或 PPU（Premium Per User）许可证的用户才会保留其访问权限。 迁移完成后，当工作区恢复为专用容量时，拥有免费许可证的用户将重新获得访问权限。 如果希望用户在 “无容量”阶段 访问这些工作区，则需要将这些用户升级到 Pro 或 PPU 许可证。

3.5 迁移阶段（6 或 7 小时）

Power BI 将在最多 7 小时内不可访问，并在您登录时显示为维护中。 在 4 小时内完成迁移的可能性为 90%，并且不会花费 7 小时。

4. 我今天可以做什么？

以下是为迁移做准备的今天可以执行的步骤。 这些步骤不会导致服务降级。

4.1 审阅清单

5. 迁移前需要立即执行哪些操作？

这些步骤应在迁移前立即 按顺序执行 。 禁用租户级别的专用链接将导致您的 Power BI 服务开始临时降级。

5.1 禁用租户级专用链接

⚠️ 关键步骤。 如果未执行，则会阻止迁移。
⌛ 在进入 无容量阶段 之前，请至少等待 12 小时。
📢 不常见。 大多数客户未启用 TL-PL。

如果有专用链接，则在迁移前至少 12 小时按顺序执行以下步骤：

1. 启用公共 Internet 访问：Power BI => Admin portal => Tenant settings => Public Internet Access
2. 请在 Azure 门户中删除您已创建的所有关联专用终结点。
3. 在Azure门户中，删除相应的专用 DNS 区域
4. 在Azure门户中，删除专用链接服务（应仅为一个）。 在浏览资源组时打开“显示隐藏类型”。
5. 禁用设置：Power BI => Admin portal => Tenant settings => Tenant-level Private Link

禁用租户级专用链接将还原公共 Internet 访问 - 用户可以从任何网络进行连接，而不仅仅是批准的专用终结点。 发送到Power BI服务的数据流量不再专门遍历Microsoft的主干网络;现在可以通过公共路由。 迁移后 - 可以重新启用租户级别的专用链接设置并重新创建专用终结点。

请注意，若要使租户级专用链接正常工作，需要以下三项作：

1. 已启用租户级别的私有链接管理员设置
2. Private Link服务（PLS）（Microsoft.PowerBI/privateLinkServicesForPowerBI），在启用步骤 1 时自动创建
3. 绑定到 PLS 的私有终结点（PE）

如果仅启用租户管理员设置，或者同时启用了设置和PLS，但未启用PEs，那么在迁移之前，我们将禁用该设置并删除PLS。 由于没有 PE，因此删除此设置时不会对您的服务造成降级。

如果启用了该设置，并且存在 PLS 和 PE，那么您，作为客户，需要在迁移之前执行上述 5 个步骤，并完全禁用租户级的专用链接。 未能做到这一点将阻止您的迁移。

5.2 删除 AAS 挂起的迁移

⚠️ 关键步骤。 如果未执行，则会阻止迁移。
⌛ 在进入 无容量阶段 之前，请至少等待 12 小时。
📢 不常见。 大多数客户没有未决的 AAS 迁移任务。

作为 Power BI 租户管理员，请转到 Settings => Azure Analysis Service Migrations，并查找任何待定的 AAS 迁移。 在继续租户迁移之前，应将其删除，因为这可能会导致租户迁移失败。 还可以利用此 提供的链接 获取有关 AAS 迁移的综合指南。

5.3 从 BYOLA 和 BYOS 分离工作空间

⚠️ 关键步骤。 不会阻止，但 BYOLA（如 Azure Log Analytics）在迁移后将无法正常工作。
⌛ 在进入 无容量阶段 之前，请至少等待 12 小时。
📢 不常见。 大多数客户不使用 BYOLA/BYOS。

如果您使用创建自己的日志分析（BYOLA）或自带存储（BYOS），那么在迁移之前，工作区需要从 BYOLA (如 Azure Log Analytics) 中分离。 如果未遵循此步骤，Azure Log Analytics迁移后将无法正常工作。

5.4 捕获容量设置和工作区映射

⚠️ 不是迁移阻止，但你需要知道迁移后需要恢复专用容量的工作区。
⌛ 推荐在进入 “无容量阶段”前提前 1 到 2 小时进行准备。
📢 如果没有专用容量，请跳过此步骤。

使用此 PowerShell 脚本捕获 A-SKU 容量设置，使用此 PowerShell 脚本捕获高级工作区映射。 捕获此信息后，可以在 迁移后阶段 使用它来重新配置专用容量，并将工作区重新连接到这些容量。 请注意，并非所有容量设置都可以通过 API 捕获 - 某些设置（如 Contributor 权限和 Power BI 工作负荷需要在迁移前手动捕获，并在迁移后重新预配容量时手动配置。 此外，可以忽略 API 响应中显示的 PPU（Premium Per User）容量（SKU = PP3）。 这些容量不是专用容量，在迁移之前不需要删除。

5.5 捕获日志和使用情况

⚠️ 未阻止迁移。
⌛ 推荐在进入 “无容量阶段”前提前 1 到 2 小时进行准备。
📢 如果今天不捕获使用情况，请跳过此步骤。

某些使用情况数据在迁移后不可用，因此在迁移之前保存以下内容：

• 在迁移之前下载 Power BI 活动日志
• 在世系视图中查看计数
• 数据保护指标报告 （Purview 的一部分）
• 工作区级别的使用情况指标 在迁移之前不会保留数据。

5.6 删除专用容量

⚠️ 关键步骤。 如果未执行，则会阻止迁移。
⌛ 在进入 “无容量阶段”之前执行操作。
📢 如果没有专用容量，请跳过此步骤。

在进入迁移窗口的无容量阶段之前，您，作为客户，需要完成此步骤。 如果您在中国的任何 Azure 区域中有专用容量（A-SKU，P-SKU或EM-SKU）处于活动或暂停状态（您不应在 CN1 中有容量，因为这是不支持容量的区域），那么在进入迁移窗口的无容量阶段之前，您需要手动删除所有这些专用容量。 Pro 或 PPU 许可证上的工作区可以保持原样。 迁移之前，必须在每个区域中删除所有专用容量。 在删除容量之前 ，请勿 从专用容量分离工作区，即 不要 将工作区从专用容量迁移到 按使用许可证模式 （Pro 或 Premium Per User （PPU））。 专用容量删除 不 会导致数据丢失。 下表中列出了三种类型的专用容量，这些专用容量需要删除，并且列出了如何删除它们。

在删除容量之前，请记得保存容量设置和 容量到高级工作区的映射 ！ 虽然专用容量删除不会导致数据丢失，但它可能会对现已成为 Pro 工作区的高级工作区的功能造成限制。

• 对于所有数据集≥ 1GB，数据集和依赖于这些数据集的所有报表将不可访问，在迁移后数据集重新回到专用容量之前，计划数据集刷新将不起作用。
• 对于启用了 大型存储模式 的所有数据集（CE2、CN2、CN3），无论数据集的大小如何，依赖于这些数据集的数据集和所有报表都将不可访问，并且计划数据集刷新将不起作用，直到数据集在迁移后恢复专用容量， 并且 与迁移前相同的区域中。
• 对于所有数据集 < 1GB 和 小型存储模式，拥有免费许可证的用户将无法访问这些数据集和关联的报表。 只有具有 Pro 或 PPU（Premium Per User）许可证的用户才会保留其访问权限。 迁移完成后，当工作区恢复为专用容量时，拥有免费许可证的用户将重新获得访问权限。 如果希望用户在 “无容量”阶段 访问这些工作区，则需要将这些用户升级到 Pro 或 PPU 许可证。
• 使用 BYOK（自带密钥）的专用容量上的所有语义模型在重新使用 BYOK 的专用容量之前将不起作用。

删除 A-SKU 后，立即停止付费，并且失去专用 vCore。 重新预配 A-SKU 后，再次开始付费并重新获得专用 v-Cores 的分配。 删除 P-SKU 时，由于这是许可附加组件，vCore 会返回到您仍在支付的资源池，然后在再次预配置新的 P-SKU 容量时重新分配。

5.7 确认容量删除

⚠️ 这不是迁移的阻碍，但仍建议这样做。
建议在删除容量之后，并在进入“无容量阶段”之前执行该操作。
📢 即使认为没有专用资源，也要执行此步骤。

运行此 PowerShell 脚本： 9.5 确认已删除所有专用容量，以确认 已删除所有 专用容量。 未能删除所有专用容量将阻止迁移。

6. 在迁移期间我需要做些什么？

耐心等待。 在此阶段，无法访问Power BI，该阶段应持续 4 到 7 小时。 迁移完成后，Microsoft将向技术联系人发送电子邮件。 收到电子邮件或Power BI可供你访问后，请继续执行本文档中的下一步。

7. 迁移后需要执行哪些操作？

迁移后，可以确认已通过以下方式迁移：

• 转到 Power BI Web 门户
• 单击“？” 右上角的图标
• 选择 About Power BI
• 检查 “您的家乡区域是” 字段
• 确认主区域已更新到 中国北部 3

下面是迁移后应立即 按顺序执行 的步骤，以完全还原服务。

7.1 重新预配容量

📢 如果在迁移之前没有专用容量，请跳过此步骤。

迁移后，需要在中国支持的Azure区域（CE2、CN2、CN3）中重新预配专用容量。 无法在 CE1 或 CN1 中重新预配容量。 迁移后 ，容量不会 自动重新预配。 迁移后，新容量的容量 ID 将不同于迁移前容量的 ID，但名称可以保持不变。 迁移之前，应已捕获容量设置，以帮助你使用这两个 PowerShell 脚本： 9.1 保存 A-SKU 容量设置 和 9.2 保存基本容量设置和工作区映射。

• 可以通过Azure门户（或Azure CLI/ARM模板）设置 A-SKU（Azure嵌入）容量
• 可以通过 Power BI Admin Portal => Capacity settings => Power BI Premium 预配 P-SKU（高级）容量
• 可以通过 Power BI Admin Portal => Capacity settings => Power BI Premium 预配EM-SKU（企业嵌入）容量

如果只有少量容量，则可以手动创建容量，也可以使用此 PowerShell 脚本来重新 预配 A-SKU：9.3 重新预配 A-SKU 容量。

7.2 将工作区重新附加到容量

📢 如果在迁移之前没有专用容量，请跳过此步骤。 ⚠️ 重新附加到 P-SKU 后，可能延迟约 4 小时，然后具有免费许可证的用户才能访问内容

重新预配专用容量后，需要将工作区重新附加到这些容量以还原完整功能。 在迁移之前，应已使用此 PowerShell 脚本捕获工作区容量映射： 9.2 保存基本容量设置和工作区映射。 使用映射文件，可以使用此 PowerShell 脚本将工作区重新附加到容量： 9.4 将工作区重新分配到容量。 在将工作区重新附加到容量之前：

• ≥ 1GB 的数据集（和相关报表）-父工作区需要重新置于专用容量上。 在这些数据集可访问之前，所有用户都无法访问，并且计划的刷新将无法运行。
• 采用大文件格式（无论大小如何）的数据集（和相关报表）-父工作区需要重新置于专用容量上，并且与迁移前位于同一区域中。 在它们完成之前，所有用户都无法访问，并且计划的数据集刷新将不会运行。
• 1GB 的数据集（及相关报表）并且采用< - 需要将父工作区置于专用容量中。 在满足条件之前，访问权限仅限于 Pro 或 PPU 许可证的用户。 将工作区重新放回到专用容量可以为仅具有免费许可证的用户提供访问权限。
• 迁移之前在专用容量上使用 BYOK（自带密钥）的语义模型在迁移后将无法工作，除非它们回到使用 BYOK 的专用容量上。

在将工作区重新附加到 P-SKU 容量后，大约需要 4 小时，具有免费许可证的用户才能访问这些工作区及其相关的数据集和报告。 将工作区重新附加到 A-SKU 容量时没有这种延迟。

作为租户迁移的一部分，如果您还希望将工作空间迁移到其他地区的容量（例如 CE2 => CN3），请阅读此部分：10 租户迁移和工作空间迁移。

7.3 重新启用租户级专用链接

📢 如果不使用租户级别专用链接，请跳过此步骤。

按照以下步骤重新启用租户级别专用链接。 如果无法重新允许此设置，可能无法登录到网关应用。

7.4 在 CN3 中重新创建 AAS 网关

📢 如果不使用 AAS 网关，请跳过此步骤。

以前，如果您使用本地数据网关将 Azure Analysis Services (AAS) 模型连接到 Power BI，那么这些模型会配置为您的主区域 - CE1/CN1。 迁移后这些网关将不再有效，需要在 CN3 中重新创建这些 AAS 网关。

7.5 重新创建 Azure Analysis Service 迁移

📢 如果不使用 AAS 迁移，请跳过此步骤。

如果在 CE1/CN1 => CN3 迁移之前删除了挂起的 AAS 迁移，则可以重新创建新的迁移配对。 作为 Power BI 租户管理员，转到 Settings => Azure Analysis Service Migrations。 选择 Setup migration 并按照步骤操作。

7.6 将工作区重新连接到 BYOLA 和 BYOS

📢 如果不使用 BYOLA/BYOS，请跳过此步骤。

如果使用自带Log Analytics（BYOLA）和自带存储（BYOS），那么在迁移之后，工作区应重新被附加到这些服务，例如Azure Log Analytics。 迁移之前应该已将它们分离。

7.6 在 Excel 中分析 - 更新连接字符串

📢 如果不在 Excel 中使用“分析”，请跳过此步骤。

对于使用 Analyze in Excel 功能的 Excel 工作簿，迁移后，如果它们无法刷新，可能需要更新该数据集的连接字符串，或重新下载 ODC 连接，因为它可能包含对旧主区域（CE1/CN1）的引用。 如果需要，请参阅 本教程 以获取有关此步骤的帮助。

7.7 SharePoint中的嵌入链接 - 重新生成链接

📢 如果不在SharePoint中使用嵌入链接，请跳过此步骤。

Power BI 嵌入链接在SharePoint中，完成迁移后可能无法连接，因为该链接可能包含对旧主区域（CE1/CN1）的引用，需要进行更新。 若要解决此问题，迁移后，必须在Power BI中重新生成嵌入链接，然后更新它们的使用位置。

7.8 网关

📢 如果使用 AAS 网关，请转到 CN3 中的 7.4 重新创建 AAS 网关。 如果使用非 AAS 的其他网关，请继续阅读。 否则，请跳过此步骤。

如果有 网关，在迁移之前不需要做任何事情。 迁移后，CE1/CN1 中具有其中继终结点的所有非 AAS 网关将继续工作。 可以通过检查网关日志来确认依赖端点。 但是，由于计算机上的配置可能指向 CE1/CN1，因此在网关软件的所有功能可用之前，需要卸载并重新安装网关软件。 此外，如果在 2026 年 7 月 1 日之前没有重新安装，这些网关将停止在该日期工作，因为 CE1/CN1 中的中继终结点将被清除。 公共文档在此处。 还可以在不同的计算机上安装网关并在那里恢复。 不需要删除并重新创建网关群集，也不需要在 Power BI 服务中重新配置数据源连接。

对于个人网关PGW，需要卸载并重新安装，还需要重新输入所有凭据。 PGW 没有恢复密钥，每次都会在计算机上自动生成它们。 这就是卸载后 PGW 凭据失效的原因。

7.9 工作区级使用情况指标

📢 如果不使用使用情况指标，请跳过此步骤。

迁移后，工作区级使用情况指标（UM）不会在新区域 CN3 中捕获数据。 2026 年 4 月即将推出的补丁将使 CN3 的监控能够进行。 但是，即使使用此修补程序，迁移之前的数据也不会保留。 选项如下：

7.9.1 等待代码修复

⚠️ 迁移前未保留使用情况数据

代码修复即将于 2026 年 4 月/5 月推出。

7.9.2 更新 BaseUrl 参数

⚠️ 迁移前 ⚠没有保留使用情况数据️ 只有数据集所有者才能更新 BaseUrl 参数

1. 租户管理员运行 PowerShell 脚本，以便使用 UM 获取所有工作区的清单： 9.6 使用情况指标 - 获取已启用使用情况指标的所有工作区的工作区 ID、数据集 ID 和数据集所有者。

2. 对于给定工作区 + UM 数据集，让 UM 数据集所有者运行此 PowerShell 以更新值 Baseurl，并触发手动 UM 数据集刷新： 9.7 使用情况指标 - 修复 Workspace-Level 使用情况指标 V2。

新活动最多需要 24 小时才能开始显示在报表中。 如果在迁移到 CN3 7 天后运行修复脚本，则应看到过去 7 天的使用情况数据，大约在一小时内显示。 同样，迁移前不会看到任何使用情况数据。

7.9.3 删除 UM 数据集

⚠️ 迁移前 ⚠未保留任何使用情况数据 ️ 自定义的 UM 报告将丢失

1. 租户管理员运行此 PowerShell 脚本，以便使用 UM 获取所有工作区的清单： 9.6 使用情况指标 - 获取启用了使用情况指标 V2 的所有工作区的工作区 ID、数据集 ID 和数据集所有者。

2. 对于每个工作区，请将 ?showHiddenUsageMetricsModels=1 添加到浏览器 URL，进入 Manage group storage 页面，然后删除 UM 数据集。 然后为工作区重新创建 UM 报表。 删除作需要由工作区管理员、成员或参与者执行。

新活动最多需要 24 小时才能开始显示在报表中。 如果在迁移到 CN3 7 天后运行修复脚本，则应看到过去 7 天的使用情况数据，大约在一小时内显示。 同样，迁移前不会看到任何使用情况数据。

8. 常见问题

问： “如果迁移失败，会发生什么情况？
A： 您的主区域将回滚到 CE1/CN1，且不会丢失数据。 回滚将是即时的，因为迁移是 复制和粘贴，而不是 剪切和粘贴，因此原始元数据仍保留在 CE1/CN1 期间和迁移后。 成功迁移后，元数据最终将从 CE1/CN1 中删除。 无论迁移是失败还是成功，您都需要重新配置容量并重新连接工作区。 但是，请注意，如果在迁移前 CE1 中具有专用容量，则需要在 CE2、CN2 或 CN3 中重新预配新容量，因为我们已阻止在 CE1 中创建新容量。

问： “为什么无容量阶段需要 5 或 9 小时？
答： 我们需要等待每隔 12 小时在 UTC 中午和午夜运行的容量同步任务，以确保元数据已正确同步，从而启动迁移。

问： “迁移后，工作区 ID 数据集 ID、报表 ID、组 ID、网关对象 ID 和数据源连接 ID 是否会更改？”
一个： 否，迁移后 ID 将保持不变。

问： “网关连接、数据源连接和凭据在迁移后是否会正常工作？”
答: 是的。 但是，在迁移之前依赖于 CE1/CN1 的网关需要在 2026 年 7 月 1 日之前删除和重新配置。

问： “迁移后容量 ID 是否会更改？”
答: 是的。 由于迁移后需要重新预配新的专用容量。 不过，容量名称可能相同。 问： “是否可以批量执行单个租户迁移？
答: 不是。 单个租户只能完全迁移。

在删除容量后，计划的刷新是否还能正常运行？
答： 它们只会继续处理小文件格式和< 大小为 1GB 的数据集。

问： “为什么 2026 年 2 月 16 日至 2026 年 2 月 23 日之间没有迁移？
答： 那是农历新年时期。 在此期间，我们有一个CCOA（仅限关键更改通知）生效。

问： “为什么必须删除 CE2、CN2、CN3 中的容量？
A: CE2、CN2、CN3 中的专用容量的元数据仍在 CE1 的主区域中。 我们需要删除 CE2、CN2、CN3 中的专用容量，以便元数据流回到 CE1 中的共享容量。 在整理完所有内容后，我们就可以将全部内容从 CE1 迁移到 CN3。 删除每个区域中的专用容量绝对是一个必要的步骤 - 无法这样做将阻止迁移。

问： “为什么在删除容量之前无法将工作区与容量分离？
答： 分离后，你可能会无意中删除专用容量 ，然后再 将所有工作区和内容移回共享容量 - 这会阻止迁移。 可以在删除容量之前通过公共 API 确认所有内容已移回，但我们强烈建议客户在迁移之前直接删除容量，而不是分离工作区，确认，然后删除容量。

问： “迁移后，我无法访问工作区中的内容。
A: 工作区在迁移之前可能使用的是专用容量，因此需要恢复到专用容量。 如果工作区已使用专用容量，并且包含大型文件格式的数据集，则需要在迁移前恢复到迁移前的同一区域的专用容量。

问： “迁移后，我重新将工作区放回专用容量，但拥有免费许可证的用户仍无法访问这些工作区上的报表。
答： 如果工作区重新位于 P-SKU 上，用户具有免费许可证可能需要大约四个小时才能访问报表。

问： “计划刷新是否阻止迁移？”
答: 不是。 在迁移之前，不需要暂停或删除计划的刷新。

问： “删除容量后，具有 Pro 许可证的用户是否可以仍然访问报表和仪表板？
答： 是的，但仅限于小规模存储模式和 < 1GB 的数据集。 对于大型存储模式或≥ 1GB 的数据集，所有用户（包括具有 Pro 或 PPU（Premium Per User）许可证的用户都需要等待父工作区重新回到专用容量。

问： “什么是专用容量？
A：专用容量是指 P-SKU（高级）、A-SKU（Azure - Embedded）、EM-SKU（Office - Embedded）等容量。 这些租户级资源可以托管多个工作区，并集中管理。

问： “什么是高级工作区？
A： 高级工作区位于专用容量（P-SKU、A-SKU 或 EM-SKU）。

问： “什么是 PP3？”
A： 它是用于Premium Per User（PPU）许可证的容量SKU。 如果 Power BI 租户有任何 PPU 许可证，那么会有一个（且只有一个）PP3 SKU。 迁移之前无需删除它。

9. PowerShell 脚本

9.1 保存 A-SKU 容量设置

# ============================================
# Export all Power BI Embedded Capacities in Azure China, does not include P-SKU or EM-SKU Premium capacities
# Need Azure subscription contributor role
# Change $logPath and $outputFile to your path
# Run "Install-Module -Name Az" first to install necessary modules
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# ============================================

# Enable logging, change logpath to your actual path
$logPath = "C:\Users\shita\Logs\export-capacity-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
Start-Transcript -Path $logPath -Append

Write-Host "Connecting to Azure China"
Connect-AzAccount -Environment AzureChinaCloud

# Output file path, change to your path to save the exported data
$outputFile = "C:\Users\shita\A_CapacityMap.json"

# Get all Azure subscriptions you can access
$subscriptions = Get-AzSubscription
Write-Host "Found : $($subscriptions.Count) subscriptions"

$exportData = @()

foreach ($sub in $subscriptions) {
    Write-Host "`n=============================="
    Write-Host "Change to subscription: $($sub.Name) ($($sub.Id))"
    Write-Host "=============================="
    try {
        Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null
    } catch {
        Write-Warning "Change subscription failed: $($_.Exception.Message)"
        continue
    }

    # Get resources with type Microsoft.PowerBIDedicated/capacities
    try {
        $capacities = Get-AzResource -ResourceType "Microsoft.PowerBIDedicated/capacities" -ErrorAction Stop
    } catch {
        Write-Warning "Can't list resources for subscription $($_.Exception.Message)"
        continue
    }

    # Get sku info
    $aCapacities = $capacities | Where-Object {
        # sku info might be under .Sku or .Sku.Name 
        $skuName = $null
        if ($_.Sku -and ($_.Sku.Name)) { $skuName = $_.Sku.Name } elseif ($_.Sku) { $skuName = $_.Sku }
        return $skuName #-and ($skuName -match '^A\d+')
    }

    if (-not $aCapacities -or $aCapacities.Count -eq 0) {
        Write-Host "There's no A SKU capacity in this sub"
        continue
    }

    foreach ($cap in $aCapacities) {
        Write-Host "Processing capacity: $($cap.Name) (resource group: $($cap.ResourceGroupName))"

        # Use Get-AzResource -ResourceId -ExpandProperties to read properties
        $details = $null
        try {
            $details = Get-AzResource -ResourceId $cap.ResourceId -ExpandProperties -ErrorAction Stop
        } catch {
            Write-Warning "Can not get details (Get-AzResource -ExpandProperties) : $($_.Exception.Message)"
            # Fallback to use backup Invoke-AzRest (if your module supports it)
            try {
                # build Path for Invoke-AzRest 
                $relativePath = $cap.ResourceId
                $apiVersion = "2017-10-01"
                $resp = Invoke-AzRest -Path $relativePath -Method GET -ApiVersion $apiVersion -ErrorAction Stop
                $details = $resp.Content | ConvertFrom-Json
            } catch {
                Write-Warning "Calling backup REST API failed too： $($_.Exception.Message)"
                continue
            }
        }

        

        # Use cap.Sku to get SKU name
        $skuVal = if ($cap.Sku -and $cap.Sku.Name) { $cap.Sku.Name } elseif ($cap.Sku) { $cap.Sku } else { "" }

        $exportData += [PSCustomObject]@{
            SubscriptionId = $sub.Id
            SubscriptionName = $sub.Name
            CapacityName = $cap.Name
            ResourceGroup = $cap.ResourceGroupName
            Region = $cap.Location
            Sku = $skuVal
            ResourceId = $cap.ResourceId
        }
    }
}

if ($exportData.Count -eq 0) {
    Write-Warning "Did not find any A SKU capacity"
} else {
    $exportData | ConvertTo-Json -Depth 6 | Out-File -FilePath $outputFile -Encoding UTF8
    Write-Host "`nExported A SKU capacities in all subscriptions to: $outputFile"
}

#Stop logging
Stop-Transcript

9.2 保存基本容量设置和工作区映射

# ============================================
# Run this script in Azure PowerShell to save basic capacity settings and workspace mapping to a local JSON File
# Please use default PowerShell v5.1 to run the script, run with PowerShell v7.0 may fail
# Need at least Fabric Administrator role
# Change $logpath to your path
# Run "Get-InstalledModule -Name Az", if your Az version is not 15.0.0 or above, run "Update-Module -Name Az" to update
# If you do not have az installed, run "Install-Module -Name Az" to install necessary modules, 
# ============================================

#Enable logging
$logPath = "C:\Users\Logs\export-capacity-workspace-mappings-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
Start-Transcript -Path $logPath -Append

Connect-AzAccount -Environment AzureChinaCloud
$accessToken = (Get-AzAccessToken -AsSecureString -ResourceUrl "https://analysis.chinacloudapi.cn/powerbi/api").Token #(Mooncake Cloud)

$ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($accessToken)
try {
    $accessToken = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ptr)
} finally {
    [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ptr)
}

# Define headers
$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type"  = "application/json"
}

# Rate limit delay (200 calls/hour = 1 call every 18 seconds)
$rateLimitDelay1 = 20
$rateLimitDelay2 = 75

# Function to get all capacities with pagination and rate limiting
function Get-AllCapacities {
    $capacities = @()
    $url = 'https://api.powerbi.cn/v1.0/myorg/admin/capacities'
    do {
        $response = Invoke-RestMethod -Uri $url -Headers $headers -Method Get
        $capacities += $response.value
        $url = $response.'@odata.nextLink'
        Start-Sleep -Seconds $rateLimitDelay1
    } while ($url)
    return $capacities
}

# Function to get all workspaces with pagination and rate limiting
function Get-AllWorkspaces {
    $workspaces = @()
    $top = 1000
    $skip = 0
    do {
        $url = "https://api.powerbi.cn/v1.0/myorg/admin/groups?`$top=$top&`$skip=$skip"
        Write-Host "Calling: $url"
        $response = Invoke-RestMethod -Uri $url -headers $Headers -Method Get 
        $batch = $response.value
        $workspaces += $batch  
        $skip += $top 
        Start-Sleep -Seconds $rateLimitDelay2
    }
    while ($batch.Count -gt 0)   
 
    return $workspaces
}

# Main logic
$capacities = Get-AllCapacities | Where-Object { $_.sku -ne "PP3" }

$allWorkspaces = Get-AllWorkspaces

# Group workspaces by capacityId, saving only workspace IDs and full capacity metadata
$groupedData = @()
foreach ($capacity in $capacities) {
    $capacityId = $capacity.id
    $workspaceIds = ($allWorkspaces | Where-Object { $_.capacityId -eq $capacityId }).id

    $groupedData += [PSCustomObject]@{
        CapacityId   = $capacityId
        CapacityName = $capacity.displayName
        Metadata     = $capacity
        WorkspaceIds = $workspaceIds
    }
}

# Output to JSON
$groupedData | ConvertTo-Json -Depth 10 | Out-File -FilePath "CapacityWorkspaceMap.json" -Encoding utf8
Write-Host "Data exported to CapacityWorkspaceMap.json"

#Stop logging
Stop-Transcript

9.3 重新预配 A-SKU 容量

引用之前从 A_CapacityMap.json 中捕获的文件 。 请注意，如果在迁移前 CE1 中具有专用容量，则无法在 CE1 中重新预配新容量，因此请相应地更新 A_CapacityMap.json 。

# ============================================
# Create capacities based on A_CapacityMap.json
# Need to manually set at least one capacity administrator for each capacity
# Need Azure subscription contributor role
# Change $jsonFilePath and $logPath to your path
# Run "Install-Module -Name Az" first to install necessary modules
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# ============================================

#Enable logging, change logpath to your path
$logPath = "C:\Users\shita\Logs\create-capacity-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
Start-Transcript -Path $logPath -Append

Write-Host "Connecting to Azure China"
Connect-AzAccount -Environment AzureChinaCloud

#Change jsonFilePath to your path
$jsonFilePath = "C:\Users\shita\A_CapacityMap.json"
$capacityMap = Get-Content -Raw -Path $jsonFilePath | ConvertFrom-Json

foreach ($item in $capacityMap) {
    $subscriptionId = $item.SubscriptionId
    $name = $item.CapacityName
    $region = $item.Region
    $sku = $item.Sku
    $resourceGroup = $item.ResourceGroup

    Write-Host "`n=============================="
    Write-Host "Creating capacity $name ($sku, $region)"
    Write-Host "Subscription: $subscriptionId"
    Write-Host "Resource group: $resourceGroup"
    Write-Host "=============================="

    Set-AzContext -SubscriptionId $subscriptionId | Out-Null

    $existing = Get-AzResource -ResourceType "Microsoft.PowerBIDedicated/capacities" `
                               -ResourceGroupName $resourceGroup `
                               -Name $name `
                               -ErrorAction SilentlyContinue
    if ($existing) {
        Write-Host "Existing: $name"
        continue
    }

    try {
        New-AzPowerBIEmbeddedCapacity -ResourceGroupName $resourceGroup `
                       -Name $name `
                       -Location $region `
                       -Sku $sku | Out-Null
        Write-Host "Created: $name"
    } catch {
        Write-Warning "Creation failed: $($_.Exception.Message)"
        continue
    }

   
}

Write-Host "`nCreated embedded capacities for all subscriptions"

#Stop logging
Stop-Transcript

9.4 将工作区重新分配到容量

引用之前从CapacityWorkspaceMap.json捕获的文件。 容量名称匹配，因为容量 ID 已更改。

# ============================================
# Assign capacity back to workspaces based on CapacityWorkspaceMap.json
# Change $jsonFilePath and $logPath to your path
# Need at least Fabric Administrator role
# Run "Install-Module -Name MicrosoftPowerBIMgmt" to install necessary modules
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# ============================================

#Enable logging, change logpath to your actual path
$logPath = "C:\Users\shita\Logs\Assign-workspace-back-to-capacity-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
Start-Transcript -Path $logPath -Append

#Sign in to Power BI as admin user
Connect-PowerBIServiceAccount -Environment China

# Change the file path to CapacityWorkspaceMap.json
$jsonFilePath = "C:\Users\shita\CapacityWorkspaceMap.json"

# === Step 1: Read json file ===
$capacityMap = Get-Content -Raw -Path $jsonFilePath | ConvertFrom-Json

# === Step 2: Get all capacities in tenant ===
$allCapacities = Get-PowerBICapacity -Scope Organization

# === Step 3: Get capacity workspace mappings ===
foreach ($item in $capacityMap) {
    $oldCapacityName = $item.CapacityName
    $workspaceIds = $item.WorkspaceIds

    # Convert format
    if ($workspaceIds -is [string]) {
        $workspaceIds = @($workspaceIds)
    }

    # Find new capacity with same name
    $newCapacity = $allCapacities | Where-Object { $_.DisplayName -eq $oldCapacityName }

    if (-not $newCapacity) {
        Write-Warning "Can not find capacity：$oldCapacityName"
        continue
    }

    Write-Host "Processing Capacity: $oldCapacityName (New ID: $($newCapacity.Id))"

    # === Step 4: assign workspace to capacity one by one ===
    foreach ($wsId in $workspaceIds) {
        try {
            Write-Host "Assigning Workspace [$wsId] to Capacity [$oldCapacityName]..."
            Set-PowerBIWorkspace -Id $wsId -CapacityId $newCapacity.Id -Scope Organization
            Write-Host "Completed"
        } catch {
            Write-Warning "Failed：$($_.Exception.Message)"
        }
    }
}

9.5 确认已删除所有专用容量

# ============================================
# Run this script in Azure PowerShell to check capacities in your tenant
# Need at least Fabric Administrator role
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# Run "Install-Module -Name MicrosoftPowerBIMgmt" to install necessary modules
# Change $logPath to your path
# ============================================

# ENABLE LOGGING
$logPath = "C:\Users\Logs\check-existing-capacity-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
Start-Transcript -Path $logPath -Append

# SIGN INTO POWER BI CHINA, WITH AT LEAST FABRIC ADMIN ROLE
Connect-PowerBIServiceAccount -Environment China

# Call ADMIN CAPACITIES API
$capacities = Invoke-PowerBIRestMethod -Url "admin/capacities" -Method GET | ConvertFrom-Json

# Exclude SKU = PP3(PPU)
$filteredCaps = $capacities.value | Where-Object { $_.sku -ne "PP3" }

if ($filteredCaps.Count -eq 0) {
    Write-Output "No capacities found"
}
else {
   Write-Output "Capacities found:"
   $filteredCaps | Select-Object displayName, sku
   Write-Output "`nPlease backup configurations and delete them before migration"
}

# STOP LOGGING
Stop-Transcript

9.6 使用情况指标 - 获取启用了使用情况指标 V2 的所有工作区的工作区 ID、数据集 ID 和数据集所有者

# ============================================
# Run this script in Azure PowerShell to get Workspace-Level Usage Metrics Info
# Need at least Fabric Administrator role
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# Run "Install-Module -Name MicrosoftPowerBIMgmt" to install necessary modules
# ============================================

# SIGN INTO POWER BI CHINA, WITH AT LEAST FABRIC ADMIN ROLE
Connect-PowerBIServiceAccount -Environment China

$apiUri = "admin/datasets?`$filter=name eq 'Usage Metrics Report'"
$result = Invoke-PowerBIRestMethod -Url $apiUri -Method GET
$data = ($result | ConvertFrom-Json).value
$table = ($data | Select-Object name, id, workspaceid, webUrl, configuredBy)
$table | Export-Csv -Path "um.csv" -NoTypeInformation
Write-Host "Data exported to um.csv!"  -ForegroundColor Green

9.7 使用情况指标 - 修复工作区级别使用情况指标 V2

⚠️ 仅在迁移后并确认租户主区域位于中国北部 3区后，才运行此脚本。

# ============================================
# Run this script in Azure PowerShell to repair Usage Metrics for a specific workspace
# Need Usage Metrics Dataset Owner role
# Please use default PowerShell v5.1 to run the script, running with PowerShell v7.0 may fail
# Run "Install-Module -Name MicrosoftPowerBIMgmt" to install necessary modules
# ============================================

# PARAMETERS
$workspaceID = "GUID GOES HERE"
$datasetID = "GUID GOES HERE"

# SIGN INTO POWER BI CHINA, WITH AT LEAST CREDENTIALS OF USAGE METRICS DATASET OWNER
Connect-PowerBIServiceAccount -Environment China

# API URL TO RUN - UPDATE PARAMETERS
$apiUri = "groups/$workspaceID/datasets/$datasetID/Default.UpdateParameters"
$body = @{
    updateDetails = @(
        @{
            name     = "WorkspaceId"
            newValue = $workspaceId
        },
        @{
            name     = "BaseUrl"
            newValue = "https://wabi-mc-north3-a-primary-redirect.analysis.chinacloudapi.cn"
        }
    )
} | ConvertTo-Json -Depth 3

# EXECUTE REST API - UPDATE USAGE METRICS PARAMETER
Write-Host "Updating dataset parameters..." -ForegroundColor Green
Invoke-PowerBIRestMethod -Url $apiUri -Method POST -Body $body
Write-Host "Usage Metrics Dataset parameters updated successfully!" -ForegroundColor Green
Write-Host "Waiting 15 seconds before refreshing Usage Metrics Dataset..." -ForegroundColor Green
Start-Sleep -Seconds 15

# API URL TO RUN - REFRESH DATASET
$apiUri = "groups/$workspaceId/datasets/$datasetId/refreshes"
$Body = @{
    updateDetails = @(
        @{
            name     = "notifyOption"
            newValue = "MailOnFailure"
        }
    )
} | ConvertTo-Json -Depth 3

# EXECUTE REST API - REFRESH USAGE METRICS DATASET
Invoke-PowerBIRestMethod -Url $apiUri -Method Post -Body $Body
Write-Host "Usage Metrics Dataset refreshed!" -ForegroundColor Green
Write-Host "Process Complete!" -ForegroundColor Green

10. 租户迁移和工作区迁移

在租户迁移后，如果想要将工作区放回迁移前的不同区域中的容量，请阅读本部分，因为可能需要额外工作。

10.1 迁移前 CE1 中的工作区容量

除了本文档前面介绍的内容之外，不需要执行任何其他工作。 这是因为 CE1 不支持高级文件。 迁移后，可以将这些工作区重新附加到新配置的 CE2/CN3 专用容量中。 请注意，CE2/CN3 是首选区域，CE3/CN3 被视为备份区域。

10.2 迁移前 CN1 中的资源容量工作区

不可 - CN1 中没有专用容量。 迁移后，可以将这些工作区附加到 CE2/CN3 中新预配的专用容量。

10.3 容量上的工作区在 CE2、CE3、CN2、CN3 中（迁移前）

可能需要其他工作。 请考虑在租户迁移之前在 CE2 上的工作区（WS1），但在迁移后，客户想要将 WS1 重新置于 CN3 中的容量上。 在迁移之前，WS1 中的所有数据集都需要转换为小型文件格式。 这可以通过每个数据集的 UI 来完成，并将文件格式从大到小切换。 但是，对于大小 ≥ 10GB 的数据集，将无法执行此操作。 首先需要将这些数据集的大小减小到 < 10GB，然后才能将其切换到 小型文件格式。 WS1 获得 小型文件格式的所有数据集后，删除 CE2 中的容量，执行租户迁移，然后在 CN3 中分配新容量并将 WS1 附加到此容量。

如果在迁移之前，无论实际数据集的大小如何，在迁移之前，仍保留一个或多个 采用大型文件格式的数据集，则在迁移后，WS1 需要在 CE1 中恢复容量。 如果您尝试将 WS1 附加到 CN3 的容量中，将会遇到警告。 可以将 WS1 暂时重新置于 CE1 中的容量上，收缩任何≥ 10 GB 数据集，将所有数据集切换为 小型文件格式，然后将其置于 CN3 中的容量上。

11. 风险

迁移过程中客户常见的陷阱。

11.1. 在删除容量之前进行工作区迁移

在租户迁移之前，建议简单地删除您的专用容量。 但是，如果将工作区迁移到每用户许可证模式，并且在删除专用容量之前没有等待足够的时间，最终可能会导致工作区和数据集处于孤立状态。 如果发生这种情况，将阻止你迁移。 此外，需要联系Microsoft来修复孤立的工作区和数据集。 在迁移窗口开始之前的指导是要求您简单地删除您的专用资源。

11.2. 位于不同区域的容量上的工作区恢复正常运行

迁移后，如果工作区具有大型文件格式的数据集，则需要返回到迁移前所在的同一区域中的专用容量。 否则，将遇到工作区无法访问的错误。 若要解决此问题，请删除容量，并在迁移前在同一区域中重新预配新容量，并将工作区置于该新容量上。

11.3. 在迁移之前忘记删除容量

在迁移之前，客户可以忘记删除其专用容量。 如果发生这种情况，客户将错过其计划的迁移窗口，我们需要重新计划另一个迁移。

12. 更改日志

3/2/26

• 向风险部分添加了更多内容
• 添加了有关在迁移后修复使用情况指标的更多指南

2/27/26

• 添加了有关使用情况指标的指南
• 对于拥有免费许可证的用户，在迁移后重新将工作区接入到 P-SKU 时，他们可能会遇到访问工作区和内容的延迟。 已从数小时更新为大约4小时。

2/23/26

• 添加了风险部分 - 在删除专用容量之前，请勿将工作区迁移回共享
• 添加了有关在迁移后将工作区重新附加到 P-SKU 时，对具有免费许可证的用户访问工作区和内容的多小时延迟的注释。

2/13/26

• 修复了 PowerShell 脚本中用于确认删除专用容量的 bug

2/12/26

• 迁移后删除实时连接部分 - Power BI语义模型和Excel

2/11/26

• 迁移后添加的实时连接部分 - Power BI 语义模型 & Excel

2/10/26

• 修复了 PowerShell 脚本中用于确认删除专用容量的 bug

2/9/26

• 更新了有关容量删除的客户指南。 在删除容量之前，客户不应将工作区与容量分离。

1/30/26

• 更新了 CCOA （仅限关键更改公告） 农历新年日期
• 更新了语义模型和 BYOK 指南（自带密钥）

1/22/26

• SharePoint - 嵌入链接的更新指南
• 更新了有关在 Excel 中分析的指南 - 连接字符串
• 有关专用网关（PGWs）的更新指南
• 提供的“无能力阶段”时间线示例

12/27/25

• 租户级别专用链接 - 添加了更多详细信息
• 添加了 UI 的屏幕截图，显示如何在迁移之前确定租户主区域
• 添加了 UI 的屏幕截图，展示如何在迁移后确定租户的主区域

12/8/25

• 租户级别专用链接 - 必须在迁移前至少 12 小时禁用和删除它们
• AAS 待处理迁移 - 必须在迁移前至少提前 12 小时删除
• 工作区从 BYOLA/BYOS 分离 - 必须在迁移前至少 12 小时分离工作区
• 在迁移步骤之前添加了日程表图形
• 在迁移步骤后添加了日程表图形
• 向 F&Q 添加了更多详细信息 - 迁移失败时会发生什么情况