Power BI 实现计划：租户管理

注意

本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 工作负载。 有关该系列的介绍，请参阅 Power BI 实施规划。

本文介绍管理 Fabric 租户的关键注意事项。 本文面向：

• Fabric 管理员：负责监督组织的 Fabric 的管理员。
• IT 和系统管理员：与 Fabric 管理员协作的负责监督和集成组织中的系统的其他管理员。
• 卓越中心 (COE) 和 BI 团队：负责监督 Power BI 并为组织中的 Power BI 用户提供支持的团队。 这些团队会做出关键决策并与 Fabric 管理员协作。

管理 Power BI 服务是系统监督的一个关键方面。 有关详细信息，请参阅系统监督一文。 与系统监督相关的常规活动通常称为“系统管理”。 系统管理活动对于帮助确保内容使用者和内容创建者始终具有良好的 Power BI 体验至关重要。

正如 Fabric 采用成熟度级别一文中描述的，组织采用是指为了支持和实现企业 BI 和托管的自助式 BI 而采用的治理和数据管理实践的有效性。 因此，管理分析和 BI 平台的管理员可能会对分析采用工作的成功产生相当大的直接影响。

注意

管理 Fabric 容量（或高级容量）和管理 Power BI 服务是不同的概念。 虽然大多数组织只有一个 Power BI 租户，但组织可以为不同的工作负荷或业务部门预配多个容量。

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

定义职责范围

Fabric 管理员角色没有统一的定义，这意味着 Fabric 管理员的角色和例行职责在不同组织之间可能有所不同。 不变的是，随着组织优先级和目标的变化，角色可以（并且应该）随着时间推移而演变。

从战略角度来看，Fabric 管理员应关注：

• 治理：制定治理准则和策略以支持企业 BI 和托管的自助式 BI。
• 用户授权：在遵守组织规定和要求的同时，实现和支持内部过程和系统，尽可能地为内部用户社区提供支持。
• 采用：通过有效的治理和数据管理实践，让组织更广泛地采用 Fabric。

试图在治理、用户授权和采用目标之间取得平衡，必然会导致优先级的竞争。 理想情况下，这会引发关于优先级的富有成效的辩论。 澄清和传达你对各种角色和职责的期望有助于避免不可接受的摩擦和冲突。

请考虑以下三个 Fabric 管理员示例。

• 高度关注用户授权：Riley 是一名服务于大型全球性组织的 Fabric 管理员，该组织在托管的自助式 BI 方面投入了大量资金。 为了对整个组织的用户启用自助式 BI 功能，Riley 花费了大量时间与卓越中心 (COE) 和其他管理员协调决策和操作。 如果需要，Riley 会介入以支持现有 BI 解决方案。
• 高度关注治理和合规性：Parker 是一名 Fabric 管理员，为一家受到严格监管的组织工作。 在此组织中，大多数 BI 开发由集中式企业 BI 团队中的 BI 开发人员处理。 Parker 的管理职责主要集中在审核、信息保护和安全等领域。
• 高度参与内容创建：Morgan 是一位服务于小型组织的 Fabric 管理员，该组织刚刚开始构建其数据文化。 目前，该组织只有少数内容创建者。 除了系统监督责任外，Morgan 还是一名 BI 开发人员，需要经常创建和发布内容。 有时，Morgan 会参与共同开发项目来指导同事的工作，这有助于在组织中推广 BI 专业知识。

清单 - 规划职责范围时，关键决策和操作包括：

• 确定战略重点：确定 Fabric 管理员应关注的战略重点。 明确需要做出决策（和权衡）时使用的目标和优先级。
• 确认特定角色和职责：确定对 Fabric 管理员的具体期望。 清楚地记录其角色和职责，并在适当时候通过人力资源部门更新职位描述。

任命管理员

Fabric 管理员的操作将对用户体验、数据文化工作、治理工作、内容所有者和管理者以及组织采用工作产生重大影响。 因此，必须任命合适的人员担任管理员角色。

以下是选择管理员时需要考虑的一些要点。

• 始终能够意识到这是一个具有高度特权的角色。 管理员角色是一个高特权角色，因为它有权管理各种租户设置、工作区访问权限和个人工作区访问权限，并且还可以查看所有租户元数据。 有关详细信息，请参阅 Power BI 管理。
• 请仔细挑选最适合成为管理员的人员。 管理员通常需要与用户和 COE 协作。 因此，他们应该了解商业智能概念以及用户需要完成哪些任务。 性格专横或倾向于严格限制用户可执行操作的人员可能不太适合管理自助式 BI 平台。
• 选择 2 到 4 名管理员。 因为它是一个高特权角色，所以只能任命几名管理员。 保持适当的平衡：管理员过多会增加发生未经批准的更改的风险，而管理员太少会增加系统得不到充分支持的风险。
• 允许任命临时管理员。 如果有用户偶尔需要 Fabric 管理员权限，请考虑实现 Privileged Identity Management (PIM)。 PIM 可用于分配实时角色权限，该权限会在几小时后过期。 此过程提供了一种平衡风险（拥有过多的全职管理员）与可用性（允许取得进展）的有用方法。 这在较大的分散式组织中尤其有用。 使用 PIM 时，会记录管理员角色的委派，并且可以选择性地设置审批工作流来授予权限。
• 使 Fabric 管理成为优先事项。 通常，管理 BI 平台只是管理员的多项职责之一。 考虑如何确保用户得到有效的支持，系统得到充分的管理。
• 定期审查分配给所有相关角色的人员。 有三个角色允许管理 Power BI 服务：Fabric 管理员、Power Platform 管理员和全局管理员。 请务必定期审核这些角色的成员身份。

有关更多信息，请参阅 Microsoft 365 管理中心中的管理员角色。

清单 - 任命管理员时，关键决策和操作包括：

• 确定当前 Fabric 管理员：审查当前分配了 Fabric 管理员角色的人员。 此外，请在此审查中考虑 Power Platform 管理员和全局管理员角色。
• 任命 Fabric 管理员：若要降低风险，请任命 2 到 4 人担任 Fabric 管理员角色。 如果当前分配了 4 名以上的人员，请减少分配了 Fabric 管理员角色的人数。
• 对临时管理员应用 PIM：确认是否存在合法但偶尔需要 Fabric 管理员权限的人员。 实现 PIM 以分配将在几小时后过期的实时角色权限。 记录并传达过程的工作方式，其中可能包括审批工作流。
• 指定后备人员并进行交叉培训：检查交叉培训的状态以及是否有用于描述 Fabric 管理职责的文档。 确保培训后备人员，以便能够以一致的方式及时满足优先用户的需求。
• 定期审核管理员：定期验证分配了 Fabric 管理员角色的人员。

与其他管理员协作

尽管 Fabric 管理员是高特权角色，但它仅限于管理 Fabric。 因此，有时还需要与其他管理员协作。

下面是 Fabric 管理员与其他系统管理员协作的一些常见原因。

• 设备设置和安装：可能需要与 IT、基础结构团队或桌面支持团队合作才能安装、更新或管理用户设备。
• 订阅和许可证购买：需要使用 Microsoft 365 中的计费管理员角色才能管理订阅和购买许可证。 计费管理员还可能负责成本分析和管理。 有关管理许可证的集中式和分散式（自助服务）方法的详细信息，请参阅用户许可证。
• 许可证分配和用户管理：需要使用 Microsoft 365 中的许可证管理员角色才能向特定用户分配（已购买的）许可证。 用户管理员角色是管理用户属性所必需的。 当你计划基于用户属性（例如，自动许可证分配或自动组分配）实现自动化时，与用户管理员合作会很有帮助。 有关详细信息，请参阅常用 Microsoft 365 管理中心角色。
• Microsoft Entra 管理员：需要与 Microsoft Entra（以前称为 Azure Active Directory）管理员合作的原因有很多。 通常，这些原因包括需要设置或管理用户、组和服务主体。 有关详细信息，请参阅租户级安全性计划。
• 源数据访问：可能需要与系统管理员或数据库管理员合作才能代表内容创建者访问数据。 有时，当语义模型（以前称为数据集）基于内容使用者的标识强制实施数据安全性时，可能还需要代表内容使用者请求访问权限。
• 数据丢失防护和数据分类：可能需要与 Microsoft Purview 管理员协作进行治理和信息保护。
• Teams 集成：将 Power BI 与 Microsoft Teams 集成时，可能需要与 Teams 管理员协作。
• OneDrive 与 SharePoint 集成：将 Power BI 与 OneDrive 或 SharePoint 集成时，可能需要与其他管理员协作。
• 工作区管理：可能需要与 Fabric 工作区管理员协作，才能计划、组织或保护特定工作区中的内容。
• 生命周期管理：部署和管理对内容的更改时，可能需要与部署管道管理员或 Azure DevOps 管理员协作。
• 高级容量管理：管理高级容量时可能需要与容量管理员协作。
• 数据网关管理：可能需要与网关管理员协作才能管理和保护本地数据网关。 有关详细信息，请参阅管理网关。
• Power Platform 管理：可能需要在 Power BI 和其他 Power Platform 应用（如 Power Automate 或 Power Apps）之间集成解决方案。
• Azure 管理：可能需要与 Azure 管理员协作才能设置、访问和保护要与 Power BI 集成的其他 Azure 服务。
• 安全管理和审核：组织可能具有特定的合规性、安全性或隐私要求。 在这种情况下，可能需要与安全团队协作来识别和降低风险。
• 网络：连接到不同的数据源和系统时，出于性能和安全原因，可能需要与网络管理员合作。
• 移动设备管理：可能需要与 Intune 管理员协作才能管理移动设备的策略和安全性。

重要

Fabric 管理员不应自行做出决策或采取措施（例如更改租户设置）。 应对所有关键决策进行讨论、计划和记录。 除了与其他管理员协作外，请务必让 COE 和 BI 策略工作团队充分参与。 可能还需要让执行发起人参与策略决策。

清单 - 与其他管理员协作时，关键决策和操作包括：

• 确定将管理设备设置和安装的人员：确保了解谁在管理组织的设备。 熟悉其过程和要求。 准备好根据需要与他们协作。
• 确定将管理订阅和许可证的人员：确保了解谁在管理组织的订阅和许可证。 熟悉其过程和要求。 准备好根据需要与他们协作。
• 确定将分配许可证并管理用户、组和服务主体的人员：确保了解谁在管理组织的用户、组和服务主体。 熟悉其过程和要求。 准备好根据需要与他们协作。
• 确定要咨询的任何其他管理员：在完成实施规划过程期间，请确定其他相关管理员。 邀请他们参加相关的会议并参与相关的决策过程。 根据需要更新文档和过程。

治理 Power BI 服务

治理和管理 Power BI 服务是 Fabric 管理员的主要职责之一。 本部分介绍如何在 Fabric 管理门户中治理和管理多个常见设置和功能。

• 租户设置
• 域
• 工作区
• 嵌入代码
• 组织视觉对象
• Azure 连接

治理租户设置

租户设置是控制启用哪些 Power BI 功能以及对组织中的哪些用户启用这些功能的主要方法。 管理租户设置是 Fabric 管理员最重要的职责之一。

由于内容创建者和内容使用者可以轻松地（从文档中）了解 Power BI 中的可用功能，因此当他们无法执行预期操作时，可能会感到沮丧。 用户还可能会因此感到不满意，并降低组织采用、用户采用和解决方案采用的有效性。

下面是一些感到困惑和失望的用户提出的常见问题。

• 为什么我不能创建工作区？
• 为什么无法导出数据？
• 为什么自定义视觉对象不起作用？
• 为什么无法认证语义模型？
• 为什么无法分配敏感度标签？
• 为什么无法将应用推送到特定最终用户？

重要

每个租户设置都应与组织中的治理准则和策略保持一致。 如果 Fabric 管理员自行决定启用或禁用设置，这通常是一个明确的指示，表明你需要改进和优化治理过程。

本部分的其余内容介绍了以下管理租户设置的过程。

1. 审查租户设置
2. 确定租户设置
3. 更新租户设置
4. 记录租户设置
5. 管理租户设置
6. 审核租户设置

步骤 1：审查租户设置

请务必审查每个租户设置，以清楚地了解租户的当前状态。 虽然应审查所有租户设置，但可以优先考虑特定的关键设置，以便首先根据风险评估进行审查。

以下是在审查过程中需要考虑的一些因素。

• 设置：当前是否已启用或禁用特定的租户设置？
• 权限：特定租户设置是否适用于整个组织？ 或者它是否适用于特定安全组？

注意

默认情况下会启用某些租户设置，而其他设置则默认处于禁用状态。

可以通过以下两种方式之一编译租户设置的当前状态。

• 在管理门户中查看租户设置状态。
• 使用获取租户设置 REST API 以编程方式提取租户设置状态。

下表演示了如何记录租户设置的当前状态。

上次审查日期	租户设置	当前值	允许的安全组	不允许的安全组	委派给其他管理员的租户设置
2023 年 10 月 15 日	创建工作区	为特定安全组启用	Power BI 工作区创建者、Power BI 管理员、Power BI COE、Power BI 支持人员	空值	空值
2023 年 10 月 15 日	导出到 Excel	为整个组织启用，但特定安全组除外	不可用	销售团队 - 欧洲	不可用
2023 年 11 月 1 日	跨工作区使用语义模型	为整个组织启用	空值	不可用	空值
2023 年 11 月 1 日	认证	为特定安全组启用	Power BI 认证中小企业	不可用	域管理员可以启用/禁用
2023 年 11 月 5 日	允许特定用户打开外部数据共享	为特定安全组启用	Power BI 外部数据共享	空值	空值

有关安全组的其他注意事项，请参阅规划 Power BI 组。

有关允许的租户设置状态的详细信息，请参阅如何使用租户设置。

注意

有时，当管理员监视租户时，他们会发现情况并不理想。 例如，他们可能会在用户活动数据中看到过多的数据导出。 在此实例中，管理员可能会尝试禁用相关的租户设置。 但是，在完全禁用某个功能之前，首先必须了解用户依赖某些技术的原因。 这是因为禁止功能可能会让用户感到沮丧，从而诱使用户创建临时解决方法。 作为替代方案，可以考虑是否需要重新设计解决方案，或者是否可以通过对用户进行深入的教育和培训来缓解问题。

步骤 2：确定租户设置

审查当前租户设置后，就可以检查决策过程了。 对于每个租户设置，请以研讨会形式积极讨论并确定应允许或禁止哪些功能，以及应为哪些用户允许或禁止这些功能。

请记住，每个租户设置都表示一个治理决策。 因此，需要与他人协作才能做出正确的决定。 根据你的情况，决策过程可能涉及与 COE、执行发起人、安全团队、BI 团队或其他人员（如利益干系人或拥护者）的协作。

提示

最大的挑战之一是，当遇到现有租户设置与你的目标和有目的的决策不一致时，决定该怎么做。 要做好解决冲突的准备，以防万一。

以下是在决策过程中要考虑的一些因素。

• 哪些治理决策已经存在？ 如果可能，请参阅已做出的现有决策。 始终以一致和高效为目标。 此外，还需要了解内部或外部合规性要求。 如果适用，租户设置应与更广泛的治理策略保持一致。 例如，当前可能有一个治理策略，用于指定何时、谁以及如何在组织外部共享数据。
• 谁将做出新的治理决策？ 当需要确定租户设置时，请让对话中的所有相关方参与进来。 通常，Fabric 管理员一个人是无法就租户设置做出决策的。 有关组建工作组和举办研讨会的信息，请参阅 BI 战略规划。
• 决策是临时的吗？ 有时，租户设置仅在短时间内有效。 通常，这样做的目的是让 COE、BI 和 IT 团队在某项新功能在整个组织中广泛发布之前，熟悉此新功能。 这样，就可以验证与治理准则的一致性，并且用户社区将得到很好的支持。
• 根据部门或团队的不同，处理方式是否不同？ 在较大的组织中，单一方法很难起到作用。 若要适应不同团队的需求和技能，有时可能需要为不同的受众设置不同的租户设置。 始终尝试让有能力的团队在治理准则允许的范围内尽可能灵活地运作。
• 是否有审批过程？ 取决于具体主题，可能需要审批。 当租户设置与安全性或合规性相关时，尤其如此。
• 重新审查每项决策的时间安排是什么样的？ 应定期安排对每个租户设置决策进行审查。 每年两次是一个很好的安排。

下表介绍了如何记录决策。

决策日期	决策内容	参与决策的决策者	决策批准者	受影响的租户设置	待执行的操作
2023 年 10 月 15 日	COE 将针对创建和管理工作区的最佳做法培训已批准的内容创建者。 批准的创建者可以来自任何业务部门。	COE 和利益干系人	Ellis Turner（执行发起人）和 Taylor Phillips（COE 负责人）	创建工作区	审查 Power BI 工作区创建者组的现有成员
2023 年 10 月 15 日	将允许导出到 Excel。 COE 将跟踪活动日志中的操作，并联系过度使用该操作的用户。 由于当前正在调查的问题，欧洲销售团队将受到临时限制。	COE 和安全部门	Ellis Turner（执行发起人）和 Jessie Irwin（首席技术官）	导出到 Excel	60 天内跟进欧洲问题
2023 年 11 月 1 日	我们强烈建议使用共享语义模型来鼓励数据重用、尽量减少数据孤岛并减少数据重复。	COE	Ellis Turner（执行发起人）	跨工作区使用语义模型	不可用
2023 年 11 月 1 日	COE 将针对认证报表和数据资产的过程和要求培训已批准的内容创建者。 批准的创建者可以来自任何业务部门。	COE 和利益干系人	Ellis Turner（执行发起人）和 Taylor Phillips（COE 负责人）	认证	审查 Power BI 认证中小企业组的现有成员
2023 年 11 月 5 日	组织的数据共享策略介绍了如何在组织外部共享数据。 所有用户都需要每年审查和确认此策略。 来自 COE 的培训将有助于用户在 Power BI 中工作时遵守要求。	COE、安全性与合规性	Jessie Irwin（首席技术官）	允许特定用户打开外部数据共享	审查 Power BI 外部数据共享组的现有成员

请考虑包括用于解释决策原因的其他上下文信息。 此外，还应包括指向现有相关文档或策略位置的链接。

注意

表中提供的示例专门演示了如何在用户授权、合规性和内部要求之间保持平衡。 有关其他注意事项，请参阅治理。

步骤 3：更新租户设置

现在，你的现有租户设置和有目的的决策已经可用，你可以更新租户设置了。

更新过程中的注意事项包括：

• 谁将处理更新？ 如果你有多个 Fabric 管理员，最好由一或两名 Fabric 管理员主要负责更新租户设置。 目标是确保过程一致、易于理解且控制良好。
• 有什么测试过程？ 根据租户设置，更改租户设置时可能会产生其他影响。 应在进行广泛更改之前进行测试。 例如，请参阅跨工作区控制语义模型的使用。
• 是否有变更管理过程？ 应考虑如何避免决策、文档和最终更新之间的差异。 团队之间的沟通是变更管理的关键成功因素。 根据审核要求，可以选择维护内部更改日志，以跟踪谁进行了什么更改、何时进行了更改以及为什么进行更改（以记录活动日志中捕获的内容之外的更多详细信息）。
• 如何处理与用户的沟通？ 如果执行的更改将影响用户能够执行的操作，请务必告知用户有关更改。 应始终避免用户出现沮丧情绪及提出不必要的支持请求。

步骤 4：文档租户设置

此时，请确保有一个可重复的方法来记录租户设置值。 有关简化的示例，请参阅前面步骤 1 中有关审查租户设置的表。

下面是做记录时需要注意的一些方面。

• 提取快照数据：记录租户设置值时，建议定期创建新的时间点快照。 为此，每周创建一次快照是比较理想的频率。 使用获取租户设置 REST API 自动执行该过程。
• 提供对快照数据的管理员访问权限：管理员、COE 和内部审核员应有权访问所有快照数据。 若要确定任何已更改的租户设置，请比较两个快照（例如，将本周快照与上周快照对比）。 活动日志中的数据是对快照数据的补充，能够提供有关更改内容、更改时间和更改者的完整信息。 有关详细信息，请参阅下面的步骤 6，它将审核租户设置。
• 向用户提供当前设置的摘要：租户设置值是一种可在集中式门户中提供给用户社区使用的文档。 例如，对于那些不理解为什么某个功能对他们不可用的用户来说，这是一个有用的参考。 文档还可以帮助用户了解如果他们想要使用某项功能，应请求加入哪个安全组。 为了减少手动工作量，REST API 的最新快照结果可以作为 Power BI 报表分发给用户。 根据需求不同，可能需要将数据快照与手动维护的其他数据（例如租户设置的说明、设置的理由、其他信息的链接或请求访问的表单链接）合并。

注意

如上述步骤 2 中所述，你还需要提供与决策过程相关的文档。 通常，该类型的文档仅适用于 COE 和管理员（而不是所有 Power BI 用户）。 有关简化的示例，请参阅步骤 2。

步骤 5：管理租户设置

租户设置需要持续关注。 以下是需要注意的一些方面。

• 新租户设置：如何知道新租户设置何时可用？ 由于 Fabric 是一项持续演变的云服务，因此会定期引入新的租户设置。 了解新租户设置的一种方法是查看管理门户中租户设置页面顶部的消息。 另一种方法是将从当前快照提取的数据与上一个快照进行比较（如上面的步骤 4 中所述）。
• 对现有租户设置的更改：如何知道现有租户设置的行为何时发生更改？ 租户设置更改通常在 Power BI 博客或 Fabric 博客中发布。 请务必关注这些博客以了解所有通知。
• 持续的用户请求：如何管理用户请求？ 例如，想要认证内容的用户知道要提交请求，才能成为允许该操作的特定安全组的成员。 通过发布租户设置的文档供用户参考（如上面的步骤 4 中所述）可使这成为一个有效的工作流。 可以选择使用表单来收集这些类型的请求。 或者，你也可以通过技术支持发送请求。
• 新建安全组：如果要将租户设置限制为特定安全组，则是否已存在适用的安全组？ 是否需要创建一个新的安全组？ 必要时你将如何协调创建新的安全组？ 有关详细信息，请参阅使用组的策略。

步骤 6：审核租户设置

最后，必须有一个定期审核租户设置的过程。 以下是审核租户设置时需要识别的一些操作。

• 租户设置已更改：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的值。 此活动仅指示某些内容已更新（无论是已启用或禁用，还是已分配不同的安全组）。 若要了解更改的内容，需要将当前快照与上一个快照进行比较（如上面的步骤 4 中所述）。
• 引入了新的租户设置：在管理门户中查找消息，或将你从当前快照提取的数据与上一个快照进行比较（如上面的步骤 4 中所述）。
• 组成员身份已更改：在某些情况下，仅了解分配了哪个安全组可能还不够。 可能需要确定安全组成员身份，这些成员身份可以构成单个用户和服务主体。 可以使用 Microsoft Graph 获取组成员身份数据。 有关详细信息，请参阅用户和组数据。

此外，你可能希望在租户设置更新时收到警报通知。 可以使用 Microsoft 365 或 Microsoft Defender for Cloud Apps 中的审核日志警报功能在租户设置发生更改时收到通知，并且还可以使用 UpdatedAdminFeatureSwitch 审核日志事件了解谁进行了更改。 有关启用警报的详细信息，请参阅租户级审核。

清单 - 规划和管理租户设置时，关键决策和操作包括：

• 对所有当前租户设置进行审查：通过审查所有租户设置来确定当前状态。 确定分配给每个设置的安全组。
• 确定现有策略和决策：编译现有治理策略或以前的决策，使其随时可用。
• 讨论和决定：安排研讨会，考虑并确定应允许或禁止哪些设置，以及针对哪些用户执行。 确保所有决策都符合数据文化目标、治理准则和内部策略。 请务必让所有相关决策者和利益干系人参与每个主题。 适当时获取其他审批。
• 创建计划以重新审查决策：设置计划以定期重新审查决策和租户设置（例如每年两次）。
• 进行更新：根据研讨会中做出的决定更新租户设置。
• 使用 API 提取快照数据：使用“获取租户设置”REST API 使该过程更高效，并有可能按计划自动创建快照。
• 为用户创建文档：为用户社区创建租户设置的文档。 将文档发布到集中式门户。 包括用户访问某个功能所必须属于的安全组。
• 创建处理用户请求的过程：设置一个过程，说明用户如何请求访问某个功能。
• 设定租户设置常规管理过程：创建计划，以便尽早识别新的租户设置。
• 设置审核：创建审核过程，以便跟踪租户设置何时发生更改以及由谁更改。

治理域

域在 Fabric 中用于将具有类似特征的两个或多个工作区组合在一起。 例如，可以创建域以将所有销售工作区组合在一起，并为财务工作区创建另一个域。 域表示单个管理边界。 域的使用还可以实现在整个组织中分发工作区所有权和管理责任。

有关规划域的详细信息，请参阅工作区域。

提示

本部分中所述的 Fabric 域与 Microsoft 365 中的域是不同的概念。

步骤 1：审查域

第一步是审查现有域和租户环境，以便了解当前状态。 以下是在审查过程中需要考虑的一些因素。

• 域：存在哪些域（如果有）？ 每个域的名称和说明是否明确指明了其用途？
• 权限：每个域的域管理员是谁？ 每个域的域参与者是谁？ 所有分配的管理员和参与者是否符合域的预期用途？
• 分配的工作区：为每个域分配了哪些工作区？ 所有分配的工作区是否符合域的预期用途？
• 委派的租户设置：哪些租户设置已委派给域管理员（或容量管理员），以便他们可以替代默认设置？

步骤 2：确定域

审查域后，是时候检查决策过程了。

对于现有工作区，请考虑如何将其组合在一起以形成单个管理边界。 有关组织相关工作区的详细信息和方法，请参阅工作区域。

以下是在决策过程中要考虑的一些因素。

• 哪些治理决策已经存在？ 如果可能，请参阅现有决策。 目标是实现一致且高效的工作区和域设置。
• 内容所有权和管理的分散程度如何？ 考虑一下内容所有权和管理当前在整个组织中是如何实现的。 有时，分散式方法称为分布式、联合式或数据网格体系结构。 分析将工作区分配到域中的需求时，请考虑该信息。
• 什么样的“域分组”效果好？ 可通过多种方式将工作区分组到单个管理边界。 例如，可以选择按主题领域、团队、业务部门或项目组织域。 请记住，一个工作区只能分配给一个域。 有关详细信息，请参阅工作区域。
• 应允许谁管理每个域？ 理想情况下，域管理员是直接拥有和管理域内容的用户。 而且，域管理员应该熟悉主题领域的内部、区域和政府法规。 他们还应该熟悉所有内部治理和安全要求。
• 谁可以将工作区分配给域？ 域参与者角色包括允许向域分配工作区的用户。 域参与者还必须是工作区管理员才能将工作区分配给域。 应考虑要将多少控制权委托给组织中的自助服务用户。
• 是否会以不同的方式处理不同的域？ 在较大的组织中，某些域可能有不同的策略。 准备好根据不同团队的需求和技能调整决策。 有关详细信息，请参阅替代租户级设置。

步骤 3：更新域

此时，现有域设置和有目的的决策已经可用。 现在可以添加、更改或移除域了（如有必要）。

请务必遵循现有的变更管理做法，并通知所有将受到任何更改影响的用户。

步骤 4：记录域

根据所拥有的域的数量，可以创建文档来扩充管理门户中提供的信息。 文档可以包括：

• 更多上下文或详细信息，例如域用途，以及为什么单独的域很有用。
• 谁批准了域，以及何时批准的。
• 域所有者或专员是谁（如果与管理门户中设置的域管理员不是同一个人）。
• 与域相关的任何其他合规性或法规要求。

步骤 5：管理域

应在管理门户中定期审查域。 每季度一次或每年两次应该可以很好地实现此目的。

此外，还应考虑如何管理想要创建新域、更改现有域或向域添加工作区的用户发出的请求。

步骤 6：审核域

你应该有一个定期审核域及其设置的过程。 以下是使用活动日志审核域时需要识别的一些操作。

• 已创建新域：查找 InsertDataDomainAsAdmin 活动。
• 现有域已更改：查找 UpdateDataDomainAsAdmin 活动。
• 工作区已分配给域：查找 UpdateDataDomainFoldersRelationsAsAdmin 活动。
• 域管理员或域参与者已更改：查找 UpdateDataDomainAccessAsAdmin 活动。

清单 - 规划和管理域时，关键决策和操作包括：

• 审查当前域：通过审查管理门户中的所有域来确定当前状态。
• 讨论并决定：确定哪些域分组最能满足你的需求。 考虑如何管理域时，应让相关的决策者和利益干系人参与进来。
• 验证是否需要审批：确定在创建新域时是否应存在一个允许获得他人审批的过程。
• 创建计划以重新审查：设置定期重新审查域的计划。
• 进行更新：在出现新需求时更新域。
• 创建文档：如果需要记录其他信息，请为域创建文档。
• 创建处理用户请求的过程：设置用户如何请求新域的过程。
• 设置审核：创建审核过程，以便可以跟踪何时创建新域或何时发生更改。

治理工作区

工作区是 Fabric 中的基本概念。 工作区充当用于存储和保护内容的容器。 工作区主要用于内容创建、协作和内容分发。

管理门户中的工作区页允许 Fabric 管理员审查和管理租户中的所有工作区。

下面是 Fabric 管理员可能参与管理工作区的几个原因。

• 获取对标准工作区的访问权限。 例如，当内容的主要所有者在休假时，Fabric 管理员可能需要协助处理某种情况（例如数据刷新失败）。 在这种情况下，他们需要为自己分配工作区角色。
• 获取对个人工作区的临时访问权限。 Fabric 管理员可以访问其他用户的个人工作区，但只能访问 24 小时。 当工作区所有者离开组织或休假时，临时访问个人工作区是很有帮助的。
• 管理工作区角色。 Fabric 管理员有权管理租户中所有工作区的工作区角色。 如果工作区访问权限由集中式团队管理，这会非常有用。 当工作区处于孤立状态（表示没有工作区管理员）时，这也很有用，这种情况可能是由雇佣终止或工作调动造成的。
• 重新分配工作区。 若要解锁其他功能，有时需要更新工作区的工作区许可证模式。 例如，Fabric 管理员可以将工作区从 Pro 或 Premium Per User (PPU) 更改为容量。
• 确定工作区的类型。 Fabric 管理员可以查看为工作区分配的 SKU 层。 例如，管理员可以快速确定租户中当前有四个工作区分配给 PPU。
• 找到和/或恢复已删除的工作区。 工作区状态可以指示工作区已被删除。 在短时间内，如果工作区被错误删除，Fabric 管理员可以恢复该工作区。 或者，他们可以将已删除的个人工作区还原为标准工作区。 有关详细信息，请参阅工作区保留。
• 更新工作区名称。 Fabric 管理员可以重命名工作区，这可能是因为它的名称不符合已创建的命名约定。

注意

管理工作区的参与程度取决于分配给 Fabric 管理员的角色和职责。 内容所有权和管理策略还可以影响 Fabric 管理员参与工作区管理的程度。

步骤 1：审查工作区

第一步是审查现有工作区和租户环境，以便了解当前状态。 以下是在审查过程中需要考虑的一些因素。

• 当前工作区：审查当前存在的所有工作区。 还应查看每个工作区的角色分配和设置，以确保它们是适当的。
• 当前租户设置：审查“创建工作区”租户设置的当前设置。

可通过两种方式编译当前工作区的列表。

• 在管理门户中查看工作区列表。 可以将列表导出为 CSV 文件。
• 通过使用管理员 API 以编程方式提取租户清单：
  • “元数据扫描”API（也称为“扫描程序 API”）。 通过这组 API，可以异步查找已更改的工作区。 因为它能够提取逐步更改的工作区，因此最适合拥有大量工作区的大型组织。 有关详细信息，请参阅元数据扫描 API。
  • 以管理员身份获取组 REST API 或 Get-PowerBIWorkspace PowerShell cmdlet。 这些方法会返回租户中所有工作区的数据，因此最适合数据量较小的组织。 有关详细信息，请参阅组 API 或工作区 cmdlet。

步骤 2：确定工作区

审查工作区后，是时候检查决策过程了。

以下是在决策过程中要考虑的一些因素。

• 哪些治理决策已经存在？ 如果可能，请参阅现有的工作区治理决策。 目标是实现一致且高效的工作区设置。
• 应允许谁创建工作区？ 应考虑工作区创建权限是一种数据文化和治理决策。
• 是否应该有一个创建工作区的特定过程？ 建立一个简单且方便用户遵循的工作区创建过程非常重要。
• 应如何命名工作区？ 确定工作区命名约定是否有利于组织。
• 如何组织工作区？ 按主题和范围组织工作区通常很有用。 将内容组织到工作区的方法可能因部门而异。
• 个人工作区中包含多少内容？ 应考虑在组织中什么是适当地使用个人工作区。
• 谁应该有权访问工作区？ 应该主要限制创建和管理内容的用户对工作区的访问。 有关的详细信息，请参阅内容创建者安全性计划。

有关更多注意事项，请参阅租户级工作区规划和和工作区级工作区规划。

步骤 3：更新工作区

此时，现有工作区和有目的的决策已经可用。 如果发现有要重命名或重新组织的工作区，现在可以进行任何必要的调整。

更新过程中的注意事项包括：

• 谁将处理更新？ 如果有多个 Fabric 管理员，请确定工作区是由一名还是两名特定管理员管理。 确保过程一致、易于理解且控制良好。
• 是否有变更管理过程？ 应考虑如何避免决策、文档和最终更新之间的差异。 团队之间的沟通是变更管理的关键成功因素。 根据审核要求，可以选择维护内部更改日志，以跟踪谁进行了什么更改、何时进行了更改以及为什么进行更改（以记录活动日志中捕获的内容之外的更多详细信息）。
• 如何处理与用户的沟通？ 如果执行的更改将影响用户能够执行的操作，请务必告知用户有关更改。 应始终避免用户出现沮丧情绪及提出不必要的支持请求。

步骤 4：记录工作区

根据拥有的工作区数量，可以创建文档来扩充管理门户或 REST API 中提供的信息。 这种类型的文档是租户清单的关键部分。 文档可以包括：

• 更多上下文或详细信息，例如工作区的预期用途（如果这一点尚未在工作区说明中提及）。
• 谁批准了工作区，以及何时批准的。
• 指定为工作区所有者的人员（如果所有者与工作区管理员不同）。
• 与工作区中存储的内容相关的合规性或法规要求。
• 工作区是否包含特别敏感的信息。
• 工作区的治理要求。
• 适用于工作区的生命周期管理过程。

步骤 5：管理工作区

持续管理工作区主要涉及：

• 创建新工作区。
• 更新工作区元数据（如名称或说明）。
• 更新工作区角色。
• 恢复已删除的工作区。
• 重新分配工作区（例如，从 Pro 分配到 PPU）。
• 管理“创建工作区”租户设置。

根据角色和职责，辅助管理员活动可能包括：

• 将内容（如语义模型或报表）发布到工作区。
• 排查与现有工作区内容相关的问题。

重要

Fabric 管理员角色是一个高特权角色，可以执行许多高级功能。 值得注意的是，该角色不会自动授予对租户中的所有数据的访问权限。 但是，由于管理员有权管理租户中的工作区，因此他们可以向包括自己在内的其他用户授予访问权限（通过工作区角色）。

步骤 6：审核工作区

你应该有一个定期审核工作区的过程。 以下是使用活动日志审核工作区时需要识别的一些操作。

• “创建工作区”租户设置已更改：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的租户设置值。 项名称为 CreateAppWorkspaces。
• Fabric 管理员已获取对用户个人工作区的访问权限：查找 AddAdminPersonalWorkspaceAccess 活动。 工作区名称的格式为 PersonalWorkspace-NameOfUser。 当系统自动撤销访问权限时（24 小时后），不会记录任何活动。
• 已创建新工作区：查找 CreateFolder 活动。
• 现有工作区已更改：查找 UpdateFolder 活动。
• 工作区的访问权限已更改：查找 UpdateWorkspaceAccess 活动或 UpdateFolderAccess 活动。
• 已重新分配工作区：查找 MigrateWorkspaceIntoCapacity 活动。
• 工作区已分配给域：查找 UpdateDataDomainFoldersRelationsAsAdmin 活动。

提示

除了使用活动日志，我们建议定期创建租户清单。 这是一个时间点快照，描述了所有工作区及其内容（例如语义模型和报表）。 它还可以捕获有关工作区访问的详细信息。 有关详细信息，请参阅租户清单和访问租户清单数据。

清单 - 规划和管理工作区时，关键决策和操作包括：

• 审查当前工作区：通过审查管理门户中的所有工作区和相关租户设置来确定当前状态。
• 讨论并决定：确定如何治理和管理工作区。 在决定谁有权管理工作区时，应让相关的决策者和利益干系人参与进来。
• 验证是否需要审批：确定在创建新工作区时是否应存在一个允许获得他人审批的过程。
• 创建计划以重新审查：设置定期重新审查工作区的计划。
• 进行更新：在出现新需求时更新工作区，包括角色分配。
• 创建文档：如果需要跟踪补充信息，请为工作区创建文档。
• 创建处理用户请求的过程：设置用户如何请求新工作区的过程。
• 设置审核：创建审核过程，以便可以跟踪何时创建新工作区或何时发生更改。

治理嵌入代码

使用发布到 Web 功能时，Power BI 将生成嵌入代码。 嵌入代码用于将报表嵌入到任何人都可以在 Internet 上访问的网页中。 此功能可用于特定目的：它主要用于包含匿名受众无需身份验证即可查看的公共数据的数据新闻或报表。

定期审查和管理嵌入代码是 Fabric 管理员的主要责任。 这是一项特别关键的责任，因为它涉及到验证已在 Internet 上公开发布的报表。

注意

一些管理员错误地认为内部应用程序或 Intranet 站点是嵌入“发布到 Web”报表的安全位置。 我们强烈反对以这种方式使用此技术，因为通过“发布到 Web”发布的报表（无论其嵌入何处）都可以通过搜索引擎被发现。 为内部受众嵌入 Power BI 内容的适当做法是使用 API 嵌入功能或使用无代码嵌入技术。 有关详细信息，请参阅为组织嵌入内容使用方案。

步骤 1：查看嵌入代码

第一步是查看现有嵌入代码和租户环境，以便了解当前状态。 以下是在审查过程中需要考虑的一些因素。

• 当前嵌入代码：在管理门户中审查所有工作区中的每个嵌入代码。 记下每个嵌入代码的状态（如活动或已阻止）。
• 当前租户设置：审查“发布到 Web”租户设置的当前设置。

步骤 2：确定嵌入代码

审查嵌入代码后，是时候检查决策过程了。 让相关决策者和利益干系人参与讨论哪些内容（如果有）可以发布到 Web。

此外，还需要确定允许哪些用户将报表发布到 Web。 如果存在治理策略或安全策略，请尽可能参考它。

重要

强烈建议仅为少数用户启用“发布到 Web”租户设置。 由于意外发布包含敏感数据的报表的风险很高，请考虑禁止或限制内容创建者发布到 Web。

步骤 3：更新嵌入代码

此时，现有嵌入代码和有目的的决策已经可用。 现在，你可以对现有嵌入代码进行临时或永久更改了。

若要确定必要的更新，可能需要做一些深入研究。

• 审查具有活动嵌入代码的所有报告，确认没有不适当的信息发布到 Web。 此外，请验证基础语义模型不包含机密或专有信息。
• 请与发布报表的用户联系，以明确其用途。
• 请与内容所有者协作，根据需要将内容重新定位到适合该用途的非个人工作区。 应考虑使用明确表明其中包含公开可用内容的工作区。 例如，“财务报告 [公共]”工作区名称清楚地指明了其用途。
• 审查分配给内容的敏感度标签。 验证敏感度标签是否指示目标受众是公共受众。

步骤 4：记录嵌入代码

根据具体情况，你可以创建一些文档来补充管理门户中提供的信息。 文档可以包括：

• 更多上下文和详细信息，例如用途、预期受众和理由。
• 谁批准了公开发布的内容，以及何时发布的。
• 内容所有者是谁（如果与发布内容的用户不是同一个人）。

步骤 5：管理嵌入代码

应定期在管理门户中监视嵌入代码。 此外，请考虑如何管理要将报表发布到 Web 的用户发出的请求。

注意

并非所有报表都支持与“发布到 Web”一起使用。 用户可能会遇到与使用该功能相关的支持问题。

步骤 6：审核嵌入代码

请务必制定定期审核嵌入代码的过程。 以下是使用活动日志审核嵌入代码时需要识别的一些操作。

• 已创建新嵌入代码：查找 PublishToWebReport 活动。
• “发布到 Web”租户设置已更改：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的租户设置值。 项名称为 PublishToWeb。

清单 - 规划和管理嵌入代码时，关键决策和操作包括：

• 审查当前嵌入代码：通过审查管理门户中的所有嵌入代码来确定当前状态。
• 审查当前租户设置：审查“发布到 Web”租户设置的设置。
• 讨论和决定：确定哪些内容（如果有）可以公开发布，以及哪些用户可以发布。 适当时，让相关决策者和利益干系人参与进来。 请尽可能参阅现有的治理策略。
• 验证是否需要审批：确定将报表发布到 Web 时是否应存在一个允许获得他人审批的过程。
• 创建计划以重新审查：设置定期重新审查嵌入代码的计划。
• 进行更新：根据需要更新当前嵌入代码。 根据做出的决策更新“发布到 Web”租户设置（如果它们与当前发布的不同）。
• 创建文档：如果需要跟踪补充信息，请创建嵌入代码的文档。
• 创建处理用户请求的过程：设置一个过程，说明用户如何请求将其报表发布到 Web，或是否有权将自己的报表发布到 Web。
• 设置审核：创建审核过程，以便可以跟踪何时创建了新的嵌入代码，以及何时更改了“发布到 Web”租户设置。

治理组织视觉对象

Power BI 报表创建者可以在 Power BI 报表设计中使用多种视觉对象。

• 核心视觉对象：Power BI Desktop 和 Power BI 服务中内置的默认现成视觉对象。
• 来自 AppSource 的非认证自定义视觉对象：由第三方软件供应商或全球 Power BI 社区的成员开发的自定义视觉对象。
• 来自 AppSource 的认证自定义视觉对象：由第三方软件供应商或全球 Power BI 社区的成员开发的且已通过 Microsoft 定义的认证过程的自定义视觉对象。

组织可以选择通过注册允许使用的特定视觉对象（和版本）来限制自定义视觉对象的使用（将报表发布到 Power BI 服务时）。 允许的视觉对象称为组织视觉对象。

Fabric 管理员负责在管理中心注册和管理组织视觉对象。 他们可以注册：

• 来自 AppSource 的认证和非认证视觉对象。 在已启用阻止未认证的（或全部）视觉对象租户设置但特定视觉对象已经过验证并批准在你的组织中使用时，注册特定视觉对象尤其有用。
• 内部开发的专有视觉对象。
• 直接从供应商购买的自定义视觉对象。

注册组织视觉对象有很多优点。

• 某些或全部自定义视觉对象将自动在所有报表创建者的可视化效果窗格中提供。
• 内容创建者无需导入 Power BI 视觉对象 (.pbiviz) 文件。
• 自定义视觉对象的版本对所有报表都是一致的。
• 报表和仪表板将在组织视觉对象更新时自动更新。
• 新的和已更改的自定义视觉对象可以在广泛用于组织之前进行系统的测试和预先批准。
• 如果现有自定义视觉对象不再满足组织的要求，可以快速禁用或删除该视觉对象。

有关在用户设备上分发自定义视觉对象（用于 Power BI Desktop）的更多注意事项，请参阅自定义视觉对象。

本部分的其余内容将重点介绍如何管理组织视觉对象。

步骤 1：审查组织视觉对象

第一步是审查现有的组织视觉对象和租户环境，以便了解当前状态。

• 当前组织视觉对象：审查已添加到组织视觉对象存储库的自定义视觉对象。
• 当前租户设置：查看 Power BI 视觉对象租户设置的设置。

步骤 2：确定组织视觉对象

审查组织视觉对象后，是时候检查决策过程了。 应做好充分准备，以便能够就如何管理自定义视觉对象做出谨慎决策。

以下是在决策过程中要考虑的一些问题。

• 组织是否允许使用自定义视觉对象？ 组织在使用自定义视觉对象时需要特意进行选择有几个原因。
  • 对质量和稳定性的预期将因开发自定义视觉对象的用户而异。
  • 免费提供的自定义视觉对象可能没有技术支持。
  • 对于数据隐私问题非常敏感的组织（或对数据泄露问题极其敏感的组织），使用自定义视觉对象可能与其风险状况不兼容。 这是因为自定义视觉对象有权访问从语义模型查询的数据。 此外，自定义视觉对象可能会将数据传回 Web 服务（通常出于合法目的，例如调用 API 或运行 AI 算法）。
• 如何验证和批准使用自定义视觉对象？ 所有自定义视觉对象都应经过测试和预先批准才能在组织中使用。 此验证过程可降低使用不可信视觉对象的风险。 它还允许管理员指定已测试和批准使用的版本。
• 谁有权使用自定义视觉对象？ “允许通过 Power BI SDK 创建视觉对象”租户设置控制允许添加、共享或与自定义视觉对象交互的人员。 如果组织已决定限制此功能（从 AppSource 或导入的 .pbiviz 文件），则你可能会依赖组织视觉对象来允许特定的自定义视觉对象。
• 是否需要经过认证的视觉对象？ 如果允许 AppSource，某些组织倾向于将其限制为仅经过认证的视觉对象。 这是通过设置“只添加和使用经过认证的视觉对象”租户设置来完成的。 在这种情况下，可以使用组织视觉对象来分发已被组织批准使用的未经认证的视觉对象。
• 是否应集中管理自定义视觉对象？ 当个别报表创建者从 AppSource 下载视觉对象时，可能会出现版本不匹配的问题。 通过使用组织视觉对象存储库集中管理自定义视觉对象，可以使报表创建者的过程更简单，因为它允许租户中的所有 Power BI 报表创建者使用相同的已批准版本。 但是，它确实需要 Fabric 管理员参与进来，这可能会导致延迟。
• 允许使用哪些源？ 组织视觉对象可以来自 AppSource 或 .pbiviz 文件。 AppSource 通常是最佳源，尤其是在想要使用经过认证的视觉对象时。 当视觉对象是从供应商处私下获取，或由内部开发时，适合使用 .pbiviz 文件。
• 自定义视觉对象应何时出现在可视化效果窗格中？ 在许多情况下，可以允许自定义视觉对象显示在可视化效果窗格中，以便所有报表创建者都可以自动使用它。

步骤 3：更新组织视觉对象

此时，现有的组织视觉对象和有目的的决策已经可用。 现在，你可以对现有组织视觉对象进行临时或永久更改了。

你可能还需要修改与自定义视觉对象相关的租户设置（如果允许报表创建者下载和安装不在组织视觉对象存储库中的自定义视觉对象）。

注意

与自定义视觉对象相关的租户设置仅适用于已发布的报表，不适用于 Power BI Desktop 中的报表。 若要确保报表创建者在 Power BI 服务和 Power BI Desktop 中都有一致的自定义视觉对象选项，需要使用组策略管理本地计算机自定义视觉对象（适用于 Power BI Desktop）。 有关详细信息，请参阅用户工具和设备。

步骤 4：记录组织视觉对象

根据具体情况，你可以创建一些文档来补充管理门户中提供的信息。 文档可以包括：

• 更多上下文和详细信息，例如自定义视觉对象实现了什么。
• 谁创建了自定义视觉对象（例如内部开发人员或供应商），或者要联系谁才能获取详细信息。
• 为验证视觉对象而执行的测试，以便在视觉对象更新时可以重复这些测试。
• 谁批准的自定义视觉对象，以及何时批准的。

步骤 5：管理组织视觉对象

组织视觉对象应定期在管理门户中进行监视。 此外，请考虑如何管理想要使用在线找到的新自定义视觉对象的用户发出的请求。

有时，还应审查每个自定义视觉对象的最后更新时间。 调查是否有新版本可用。 如果有新版本可用且已通过测试，可以更新组织视觉对象。

步骤 6：审核组织视觉对象

必须有一个定期审核组织视觉对象的过程。 以下是使用活动日志审核组织视觉对象时要识别的一些操作。

• 添加了新的组织视觉对象：查找 InsertOrganizationalGalleryItem 活动。
• 更新了现有组织视觉对象：查找 UpdateOrganizationalGalleryItem 活动。
• “允许通过 Power BI SDK 创建视觉对象”租户设置已更改：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的租户设置值。 项名称为 CustomVisualsTenant。
• “只添加和使用经过认证的视觉对象（不允许未经认证的视觉对象）”租户设置已更改：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的租户设置值。 项名称为 CertifiedCustomVisualsTenant。

清单 - 规划和管理组织视觉对象时，关键决策和操作包括：

• 审查当前组织视觉对象：通过审查管理门户中的所有组织视觉对象来确定当前状态。
• 审查当前租户设置：审查每个 Power BI 视觉对象租户设置。 确定它们如何影响你对组织视觉对象的依赖。
• 讨论和决定：确定在组织中应如何使用自定义视觉对象以及由谁使用。 考虑如何使用组织视觉对象、AppSource 和 .pbiviz 文件时，应让相关的决策者和利益干系人参与进来。
• 创建计划以重新审查：设置计划以定期重新审查组织视觉对象。
• 进行更新：根据需要更新当前组织视觉对象。 根据做出的决策更新“Power BI 视觉对象”租户设置（如果它们与当前发布的不同）。
• 管理用户计算机：设置组策略，确保管理自定义视觉对象的方式与 Power BI 服务中的 Power BI Desktop 相同。
• 创建文档：如果需要跟踪补充信息，请创建组织视觉对象的文档。
• 创建处理用户请求的过程：设置一个过程，说明用户如何请求使用自定义视觉对象（一般情况）或请求访问特定自定义视觉对象。
• 设置审核：创建审核过程，以便在新的自定义视觉对象注册为组织视觉对象时以及任何 Power BI 视觉对象租户设置发生更改时进行跟踪。

治理 Azure 连接

Power BI 可以与 Azure 服务集成，以扩展功能并提供其他功能。 使用 Azure 连接有三个主要原因。

• 数据流的数据存储 (Gen1)。 可以直接在 Azure 中访问 Power BI 数据流 (Gen1) 的数据。 工作区可以连接到在租户级别定义的存储帐户，也可以连接到特定于工作区的存储帐户。 此方法有时称为自带湖 (BYOL)。 如果想要通过允许其他过程或其他用户查看或访问数据在 Power BI 以外重用数据流数据，BYOL 策略的灵活性非常有用。 有关详细信息，请参阅配置数据流存储以使用 Azure Data Lake Storage Gen2 和自助服务数据准备使用方案。

• 语义模型备份和还原。 出于灾难恢复目的，可能需要备份和还原语义模型，以满足数据保留要求或实现数据模型迁移。 有关详细信息，请参阅使用 Power BI Premium 备份和还原语义模型。

• Azure Log Analytics 集成。 可以分析语义模型活动、性能和趋势。 可以使用 Log Analytics 集成审查 Analysis Services 引擎（用于托管 Power BI 语义模型）生成的诊断数据。 有关详细信息，请参阅数据集事件日志。

  注意

  数据集名称更改已在 Power BI 服务和文档中推出，但可能存在一些尚未发生更改的情况（例如事件日志操作）。

如果使用 Azure 连接的主要用例是进行数据存储（上述第一点中所述的 BYOL），建议改为考虑使用数据流 Gen2 和 OneLake。 尽管两者都使用 ADLS Gen2 进行数据存储，但它们提供的功能不同、用途略有差异，并且使用的存储选项也不同（具体取决于数据的写入方式）。 例如：OneLake 以开放式 Delta Parquet 格式存储表格数据和数据流 Gen2 数据，而 Power BI 数据流 (Gen1)（使用 Azure 连接）的输出以通用数据模型格式存储数据。 有关详细信息，请参阅从第 1 代数据流迁移到第 2 代数据流。

本部分的其余内容将重点介绍如何治理管理门户中的 Azure 连接。

步骤 1：审查 Azure 连接

第一步是审查现有 Azure 连接和租户环境，以便了解当前状态。 有两个方面需要审查。

首先，审查管理门户中的现有设置。

• 当前租户级存储设置：审查租户级存储当前是如何设置的。 它提供工作区管理员可以选择在其工作区设置中连接到的默认 Azure 连接。
• 当前工作区级存储权限：审查是否启用了工作区级存储权限。 启用后，允许工作区管理员将工作区连接到自己的 ADLS Gen2 帐户。

其次，审查“工作区管理员的 Azure Log Analytics 连接”租户设置的设置。 启用后，它允许工作区管理员将工作区连接到 ADLS Gen2 帐户，以便为语义模型发送诊断数据。

步骤 2：确定 Azure 连接

审查 Azure 连接后，是时候检查决策过程了。

以下是在决策过程中要考虑的一些问题。

• Azure 连接的使用情况是否符合数据策略和用户需求？ 考虑 Azure 连接是否对数据流 (Gen1) 的存储有用。 确定是否需要使用语义模型备份和还原功能。 考虑是否需要 Azure Log Analytics 集成。
• 什么是集中式数据存储与分散式数据存储？ 了解分散式团队的需求，以及个人或部门当前是否维护有自己的 Azure 存储帐户。 确定是允许工作区管理员连接自己的 ADLS Gen2 帐户，还是希望对所有工作区（租户级存储）使用一个 ADLS Gen2 帐户。
• OneLake 如何与 Azure 连接一起使用？ 随着 OneLake 的引入，请考虑是否选择逐步迁移到使用 OneLake 进行数据存储 (BYOL)。

有关详细信息，请参阅工作区与 ADLS Gen2 的集成。

有关详细信息，请参阅工作区与 Azure Log Analytics 的集成。

步骤 3：更新 Azure 连接

此时，现有的 Azure 连接已经可用，并且你已就是否打算将数据湖与 Power BI 集成做出了有目的的决策。 现在，你可以根据你的发现来调整设置了（如有必要）。

步骤 4：记录 Azure 连接

根据具体情况，你应该创建一些文档来补充管理门户中提供的信息。 文档可以包括：

• 已批准使用的租户级数据湖位置。 包括谁是数据湖的所有者和管理者，以及要获取详细信息需要联系谁。
• 是否可以集成工作区级数据湖。 应记录其他信息（如做出的关键决策和原因）以供将来参考。

步骤 5：管理 Azure 连接

应在管理门户中不定时监视 Azure 连接。

请考虑如何在组织中支持多个 ADLS Gen2 帐户（如果允许工作区级 Azure 连接）。

此外，请考虑如何管理想要将工作区连接到 Azure Log Analytics 的用户发出的请求。

步骤 6：审核 Azure 连接

请务必制定定期审核 Azure 连接的过程。 使用活动日志审核 Azure 连接时，有几个需要识别的操作。

• 工作区已连接到 ADLS Gen2：查找 AddLinkToExternalResource 活动。 ResourceType 将指示它是存储帐户还是 Log Analytics。
• 工作区已与 ADLS Gen2 断开连接：查找 DeleteLinkToExternalResource 活动。 ResourceType 将指示它是存储帐户还是 Log Analytics。
• 已启用或禁用租户级存储：使用 AddExternalResource 或 DeleteLinkToExternalResource 活动查找活动日志中已更改的值。
• 已启用或禁用工作区级存储：使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的值。 项名称为 storageAccountAttachForWorkspaceAdminsEnabled。 SwitchState 为 true 或 false。
• “工作区管理员的 Azure Log Analytics 连接”租户设置已更改：此租户设置允许部分或所有工作区管理员集成自己的 ADLS Gen2 帐户。 使用 UpdatedAdminFeatureSwitch 活动查找活动日志中已更改的租户设置值。 项名称为 LogAnalyticsAttachForWorkspaceAdmins。

清单 - 规划和管理 Azure 连接时，关键决策和操作包括：

• 查看当前的 Azure 连接：通过在管理门户中审查 Azure 连接的租户级和工作区级设置来确定当前状态。 还需审查“工作区管理员的 Azure Log Analytics 连接”租户设置的设置。
• 讨论并决定：确定是否打算将 Azure 连接与 Power BI 集成。 然后，再确定将 OneLake 用于 Azure 连接 (BYOL) 进行数据存储的最佳用途。
• 验证是否需要审批：确定是否应存在一个过程来获取使用工作区级存储帐户的审批。
• 创建计划以重新审查：设置计划以定期重新审查 Azure 连接。
• 进行更新：根据需要更新当前 Azure 连接，以修改租户级和工作区级存储权限。 此外，还需要根据做出的决定更新“工作区管理员的 Azure Log Analytics 连接”租户设置（如果它们与当前设置的内容不同）。
• 创建文档：如果需要跟踪补充信息，请创建 Azure 连接的文档。
• 创建处理用户请求的过程：设置一个过程，说明用户如何进行请求才能使用 Azure 连接。
• 设置审核：创建审核过程，以便可以在工作区设置 Azure 连接或设置更改时进行监视。

审核 Power BI 的使用情况

租户级审核数据可用于分析采用工作、了解使用模式、指导用户、支持用户、降低风险、提高合规性、管理许可证成本，以及监视性能。 请务必尽早提取和存储 Power BI 审核数据，即使现在尚未准备好分析数据。

有关在 Power BI 中审核用户、活动和解决方案的信息，请参阅租户级审核。

监视 Power BI 服务

监视是告知你正在发生的情况的持续进行的活动。 监视通常是一个被动活动，涉及警报和自动化，但有时它会主动完成。

有关监视 Power BI 的信息，请参阅租户级监视。

相关内容

有关有助于做出 Power BI 实现决策的更多注意事项、操作、决策标准和指导，请参阅 Power BI 实现计划。