通过

多个管理员位于同一Microsoft Intune租户中的分布式 IT 环境

  • 项目

许多组织使用分布式 IT 环境，其中具有具有多个本地管理员的单个Microsoft Intune租户。 本文介绍缩放Microsoft Intune支持多个本地管理员的方法，这些管理员在单个Microsoft Intune租户中管理自己的用户、设备并创建自己的策略。 租户中有多少管理员没有正确或错误的答案。 本文重点介绍具有许多本地管理员的租户。

在大量本地管理员连接到单个Intune租户的系统中，需要分布式 IT。 例如，某些学校系统已组织，以便为系统或区域中的每个学校提供本地管理员。 有时，此分布式环境可能是 15 个或更多不同的本地管理员，他们汇总到同一中央系统或Microsoft Intune租户。

每个本地管理员可以设置组以满足其组织需求。 本地管理员通常按地理位置、部门或硬件特征创建组并组织多个用户或设备。 本地管理员还使用这些组来管理大规模任务。 例如，本地管理员可以为许多用户设置策略，或者将应用部署到一组设备。

需要知道的角色

  • 中心团队：中心团队或组包括租户中的全局管理员或主管理员。 这些管理员可以监督所有本地管理员，并可以为本地管理员提供指导。

  • 本地管理员：本地管理员是本地管理员，专注于其特定位置的策略和配置文件;学校、医院等。

基于角色的访问控制

本部分简要介绍不同的模型，并为每个模型下提供用于管理中央团队与本地管理员之间的策略、配置文件和应用的准则。 模型包括：

  • 分部委派模型
  • 完整委派模型
  • 中心模型
  • Devolved 模型
  • 混合模型

分部委派模型

部分委派模型为中央团队和本地管理员之间的策略管理提出了以下准则。

✔️ 权限

  • 中心团队应拥有策略、注册配置文件和应用的创建、更新和删除权限。
  • 仅向本地管理员授予读取和分配权限。

✔️ 再使用

  • 通常配置的策略、注册配置文件和应用应提供给本地管理员尽可能重复使用。
  • Microsoft Intune使用许多属于几个类别的常见配置。 查看为 应用保护策略列出的建议。
  • 当本地管理员加入时，他们应查看现有策略并根据需要重复使用它们。

✔️ 异常

  • 中心团队可以根据需要代表本地管理员创建某些新策略、注册配置文件和应用作为例外。 通常，这些异常包括需要唯一参数的任何类型的配置文件。

在以下两个方面提出了分部委派模型：

本地管理员的组和分配指南：通过Microsoft Intune组织设备管理组时，本地管理员应采用哪些最佳做法？ 若要了解详细信息，请阅读文章Intune分组、定位和筛选：实现最佳性能的建议 - Microsoft Tech Community

功能特定准则：中央机构与具有不同功能特定权限的本地管理员之间如何管理策略/配置文件/应用。 有关详细信息，请转到 功能特定指南部分。

完整委派模型

完整委派模型为中央团队和本地管理员之间的策略管理提出了以下准则。

  • 每个本地管理员应有自己的范围标记，以分隔他们完全管理的每个对象。
  • 如果本地管理员不需要创建、更新或删除，则向本地管理员授予具有读取和分配权限的角色，并避免向其分配具有完全权限的任何其他角色。 使用此方法，可以避免跨范围标记组合权限。
  • 有时，本地管理员可能需要创建自己的策略、配置文件和应用，同时共享一些常见的策略、配置文件和应用。 在这种情况下，请创建一个特殊组，并将通用策略、配置文件和应用分配给此组。 此组不应包含在任何本地管理员的范围组中。 范围组。 此方法可防止分配给本地管理员的创建、更新和删除权限应用于这些常见策略、配置文件和应用。

中心模型

在中心模型中，单个本地管理团队 (父) 管理多个子组织。 地理位置、业务部门或规模等因素可以关联子组织。

  • 只有一个范围标记用于涵盖所有托管本地管理员。

  • 如果可能，本地管理员团队应跨本地管理员标准化分配，并将其所有设备放入单个Microsoft Entra组中进行分配。 如果无法创建单个Microsoft Entra组，本地管理员团队可以创建不同的Microsoft Entra组进行不同的分配。

  • 如果其他本地管理团队管理或移动组织，则必须执行以下步骤：

    • 所有组织的设备和用户都必须从原始本地管理员团队范围内的常见Microsoft Entra组中提取。

    • 为该组织唯一分配的所有策略/应用/配置文件必须为新的本地管理团队更新其范围标记。

Devolved 模型

在下放模型中，多个本地管理员 (子级) 由其专用本地管理员管理，也由中间本地管理团队进行监督。 父级和子级管理员都有自己的范围标记来表示管理边界。

  • 如果子级管理员少于 50 个，则可以通过将所有子级范围标记分配给中间本地管理员团队 RBAC 角色分配来授予中间本地管理员团队的访问权限。
  • 如果有超过 50 个子级管理员，应向中间本地管理员团队授予其自己的范围标记，以表示他们监督的子级管理员的整个集合。
  • 子管理员范围标记下新建的策略必须具有由全局管理员角色添加的中间标记，以防止中间本地管理员团队失去可见性。

混合模型

在混合模型中，中心模型和 Devolved 模型中同时使用同一父管理员。 此模型没有特殊建议。

功能特定指南

根据每项功能的业务要求，本部分中提供的指南可能会建议你为每个本地管理员创建策略和/或将创建对象所需的权限委托给本地管理员。

注意

本节中提供的指南并不涉及每个功能，但仅涵盖我们提供了特别说明的那些领域。

应用保护策略

应用保护策略是可确保组织数据在管理的应用中保持安全或受到控制的规则。 有关详细信息，请转到应用保护策略。

应用保护策略的准则分为中央团队和本地管理员，如下所示：

中心团队 - 任务

  • 查看整个组织的安全和业务需求，并为本地管理员生成一组常见的应用保护策略。
  • 在创建任何应用保护策略之前，请查看列出的建议以确定哪些安全控制措施合适。
  • 建立一个既定的方法，供本地管理员根据需要请求自定义应用保护策略，以满足现有通用策略无法满足业务要求的特定业务需求。
  • 有关每个配置级别和必须保护的最低应用的具体建议，请查看使用应用保护策略的数据保护框架，转到应用保护策略

本地管理员 - 权限和任务

  • 提供读取和分配权限，但不对托管应用创建、更新、删除权限，因此他们无法创建自己的应用保护策略。
  • 向其应用提供应用程序配置策略分配的读取和分配权限。
  • 仅当托管设备和非托管设备有不同的保护策略时，才提供读取和分配权限。 如果中心团队选择只为两者提供一个策略，则不需要应用程序配置策略。
  • 如果使用应用程序配置策略，建议毫无例外地将应用程序配置策略分配给所有应用实例。
  • 从常见应用保护策略中进行选择。 本地管理员可以请求 Central 团队创建自定义应用保护策略作为例外，并且仅在必要时。
  • 有关详细信息，请转到应用保护策略

合规性策略

Intune中的合规性策略定义用户和设备必须满足的规则和设置才能合规。 有关合规性策略的详细信息，请转到 合规性策略。

中心团队

中心团队应创建常见的合规性策略，供本地管理员选择，并且仅在必要时创建异常策略。 有关详细信息，请转到 合规性策略。 创建策略包括创建自定义合规性策略脚本，因为它们受制于与普通合规性策略相同的规模。

有关如何创建合规性策略的详细信息，请转到 合规性策略。

本地管理员

为本地管理员提供读取和分配权限，但不能针对合规性策略创建、更新或删除权限。 读取和分配权限允许他们从中心团队创建的常见合规性策略中进行选择，并将其分配给其用户和设备。

设备配置

本节内容：

  • 设备限制和常规配置
  • 资源访问
  • Windows 更新通道
  • 功能更新
  • 质量更新

设备限制和常规配置

  • 授予本地管理员在其自己的范围内创建、更新和删除的权限。

  • 尽可能使用设置目录和安全基线，而不是在配置文件列表中创建的配置文件，以缓解Microsoft Intune管理中心的规模。

  • 通常，中心团队应尝试集中监视配置的内容，并在可能的情况下将大量重复配置文件替换为共享配置文件。

资源访问

建议使用 完整委派模型 。

Windows 更新通道

  • 我们建议集中管理 Windows 更新通道。 中心团队应创建任意数量的常见 Windows 更新圈策略，以支持本地管理员的差异。
  • 本地管理员不应创建自己的 Windows 更新通道。 当委托给大量管理员时，对象的总数可能会变得很大且难以管理。 每个功能的最佳做法各不相同。 有关详细信息，请转到 Windows 更新通道。

功能更新

建议使用 完整委派模型 。

质量更新

建议使用 完整委派模型 。

证书

  • 建议根据需要通过 Central 团队使用权限加入/卸载连接器。 为每个本地管理员载入连接器以支持证书颁发。

  • 不要向本地管理员授予 UPDATE 或 DELETE 连接器的权限。

应用程序

向本地管理员授予在其范围内管理应用的完整权限。

本节内容：

  • Apple Volume Purchase Program

  • Windows

  • Android

有关详细信息，请转到 管理应用。

Apple Volume Purchase Program

目前，对于支持的批量购买计划令牌数量，没有规模问题。 有关详细信息，请转到 我可以上传多少个令牌。

Windows

Android

  • 本地管理员应从现有应用商店应用中进行选择，或要求中心团队添加新的 Android 应用商店应用。 本地管理员不应创建新的 Android 应用商店应用。 对象的总数可能会变得很大，难以管理。

  • 本地管理员可以根据需要在跨平台业务线应用和 Web 链接限制内创建 Android 业务线应用。

  • 中心团队必须添加托管的 Google Play 应用。

    • 中心团队只能看到托管的 Google Play 应用在其租户所在的国家/地区可用。 如果中心团队需要托管的 Google Play 应用仅在某些国家/地区可用，他们可能需要与应用开发人员合作才能使其正确列出。
    • 中心团队应管理与托管的 Google Play 应用相关的所有内容，包括专用应用、Web 应用和集合。 例如，如果客户计划使用 托管 Google Play iframe 发布专用应用，则必须使用中心团队拥有的单个开发人员帐户执行此操作。
    • 中心团队可以选择单个范围标记作为托管 Google Play 范围标记。 它在托管 Google Play 连接器页中具有一个特殊下拉列表。 在中心团队将托管 Google Play 应用添加到主机后，范围标记将应用于所有托管 Google Play 应用，但不会追溯到已添加的应用。 强烈建议中心团队在添加应用之前 设置范围标记， 然后为每个区域团队分配该范围标记。 否则，区域管理员可能无法查看其托管的 Google Play 应用。

  • 每个设备仅支持一个 OEMConfig 策略，Zebra 设备除外。 对于 Zebra 设备，强烈建议尽可能少的策略，因为强制实施策略的时间是累加的。 例如，如果分配六个策略，假设它们相互分层，则开始在设备上工作所需的时间比单个策略长约 6 倍。

注意

在许多不同的应用和组上设置高优先级更新模式时，请谨慎考虑。 这是出于多种原因：

  • 尽管许多应用可以设置为高优先级模式，但一次只能安装一个应用更新。 在完成大型应用安装之前，一个大型应用更新可能会阻止许多较小的更新。
  • 根据应用发布新更新的时间，如果应用发布一致，网络使用量可能会突然激增。 如果 Wi-Fi 在某些设备上不可用，则手机网络使用量也可能激增。
  • 尽管已经提到了中断性用户体验，但随着越来越多的应用被设置为高优先级更新模式，问题就会增加。

有关使用高优先级更新模式的托管 Google Play 应用更新的规模问题的详细信息，请转到此 Techcommunity 文章。

注册配置文件

本节内容：

  • Autopilot
  • ESP) (注册状态页
  • Apple Business Manager (ABM)
  • Android Enterprise 配置文件
  • 注册限制
  • 设备类别

Autopilot

  • 向本地管理员授予读取 Autopilot 设备和上传新 Autopilot 设备的权限。
  • 本地管理员不应创建 Autopilot 配置文件。 当委托给大量管理员时，对象的总数可能会变得很大且难以管理。 最佳做法因功能区域而异。 有关 Autopilot 的详细信息，请转到使用 Autopilot 在 Intune 中注册 Windows 设备。

注册状态页

  • 本地管理员应从现有注册状态页配置文件中进行选择以分配，或者仅在必要时请求 Central 团队创建异常配置文件。
  • 本地管理员不应创建注册状态页配置文件。 当委托给大量管理员时，对象的总数可能会变得很大且难以管理。 最佳做法因功能区域而异。 有关注册状态页的信息，请转到 设置注册状态页。

Apple Business Manager

如果可能，不应向本地管理员授予对注册配置文件的创建、更新或删除权限。 如果向本地管理员授予创建 Apple Business Manager 配置文件的权限，则还会授予他们在 Autopilot 中创建、更新和删除权限。 但是，本地管理员不应创建 Autopilot 配置文件。

当委托给大量管理员时，对象的总数可能会变得很大且难以管理。 最佳做法因功能区域而异。 有关详细信息，请转到使用 Apple Business Manager 在 Intune 中注册 Apple 设备。

Android Enterprise 配置文件

  • 中心团队应为每个本地管理员创建 Android Enterprise 公司拥有的专用设备注册配置文件，以便进行设备分组。
  • 如果可能，不应向本地管理员授予在 Android Enterprise 设备上创建、更新或删除权限。 这些限制阻止本地管理员修改租户范围的 Android Enterprise 设置和全局完全托管的注册配置文件。

注册限制

  • 同一组权限同时控制设备配置和注册限制。 授予创建设备配置的权限时，还会授予创建注册限制的权限。 但是，不应向本地管理员授予创建注册限制配置文件的权限。 因此，应指示他们不要创建新的注册限制配置文件。

  • 注册设备限制定义每个用户可以注册的设备数。 注册设备限制应涵盖本地管理员共享的所有可能的设备限制。 有关详细信息，请转到 什么是注册限制。

  • 中心团队应尽可能标准化设备类型限制，并添加新限制，但仅在本地管理员查看现有限制后才将其作为特殊例外。

设备类别

设备类别 (设备>类别) 功能没有自己的权限系列。 相反，其权限由“组织”下的权限集管理。 转到 租户管理 > 角色。 选择自定义或内置角色，然后选择“属性”。 可以在此处分配权限，其中一个权限是“组织”。 因此，如果需要设备类别的读取权限，请在“组织”中设置读取权限。

中心团队可以创建设备类别。 但是，不应允许本地管理员创建、更新或删除设备类别，因为这需要向他们授予对组织的权限，从而允许他们访问受组织权限管理的其他租户级功能。

有关详细信息，请转到 设备类别。

终结点分析

  • 中心团队应创建任意数量的常用 Endpoint Analytics 基线，以支持本地管理员的差异。
  • 如果可能，本地管理员不应创建自己的 Endpoint Analytics 基线。 当委托给大量管理员时，对象的总数可能会变得很大且难以管理。 最佳做法因功能区域而异。
  • 有关详细信息，请转到 在终结点分析中配置设置。