Intune 仍然无法对设备进行裸机映像，以及其他没人告诉 IT 的事情

该命令来自领导层，而非IT部门

目前管理混合环境的几乎每位管理员都听过同样的问题：“为什么我们还没有完全迁移到 Intune？”这通常伴随着一种不言而喻的假设，即拖延是由于惯性，或者是IT团队习惯于旧工具，不愿意学习新工具。

事实并非如此。那些花了几个月时间测试 Intune 作为 组策略 完全替代方案的管理员们，得出了相同的结论：Intune 还没准备好。它确实有其优势，但作为组策略的等效替代品，它还不够成熟。

Intune 仍然无法做到的事情

无裸机映像。

组策略配合任务序列让管理员能够擦除设备并从头重新加载干净的操作系统，包括需要中途重启的复杂多阶段安装。Autopilot 并不替代此功能。它配置的是已经安装了操作系统的设备。管理员报告说，发送给最终用户的“干净”机器仍然预装了制造商的臃肿软件，因为没有类似任务序列的机制先将其剥离。

服务器从未包含在范围内，这没问题。

Intune 管理客户端设备。它从未被设计用于管理 Windows Server，因此条件访问策略和合规性执行在工作站处按设计停止，而非意外。这不是路线图中的漏洞；这是有意划定的边界。

这在实践中很少会让人困惑的原因是混合环境已经在其他地方覆盖了服务器管理。SCCM 仍然负责本地 Windows Server 的补丁和裸机构建。Azure Arc 将策略和合规性执行扩展到服务器，无论它们位于本地还是其他云。VMware vSphere 通过模板和克隆处理配置和映像。Ansible（或 AWX Tower）接管了以前由组策略负责的持续配置执行。这里没有任何缺失，只是分散在大多数基础设施团队已经运行的几种工具中。

减少层级，增加变通方案。

Active Directory 的 OU 结构让管理员能够按照部门、地点或设备层级来反映企业的组织方式，干净地嵌套例外情况，并在每个层级委派管理员权限。Entra ID 组也可以嵌套，但微软自己的指导建议管理员避免这样做：在一个 Intune 目标内嵌套一个大型组，会迫使 Intune 重新同步其下的每个组和成员，将一个小的例外变成性能问题，而不是一个干净的继承模型。

分配过滤器和范围标签继承了基于OU的委派曾经执行的一些功能，在不完全嵌套的情况下确定可见性和目标定位。两者都不是真正的继承，但委派式控制比乍看之下更接近。

Intune 中仍然存在动态分组，只是比组策略管理员习惯的范围更窄。Entra ID 动态设备组可以根据制造商和型号等属性进行筛选，Intune 分配筛选器在此基础上添加了操作系统版本和 CPU 架构等设备属性。缺少的是基于已安装软件的动态分组或筛选，这是组策略环境中的常规查询，但目前在 Intune 中没有本地等效功能。

覆盖范围更近，但不完整。

组策略支持大约4,000个ADMX设置。Intune的设置目录现在涵盖了所有平台上的18,000多个设置，仅管理模板这一直接从GPO继承的部分就约占2,500个。纯粹的数字已不再是关键。剩下的是一组特定的GPO行为，这些行为在Intune中尚无直接对应：组策略首选项、某些遗留的基于脚本的配置，以及依赖于Intune基于CSP模型尚未公开的功能的设置。这个差距通过脚本和手动配置文件来填补，手工重建了过去的复选框功能。

组策略首选项没有归属。

映射驱动器、打印机连接以及GPP自动处理的数十个小偏好设置现在需要通过脚本或第三方工具来复制。

缓慢且不可预测的政策执行。

组策略可以在几秒钟内应用更改，而 Intune 依赖 Windows 通知服务将策略传递给设备，这个流程实际上是一个黑盒。管理员记录了相同策略的同步时间从即时到72小时不等，当截止日期紧迫时，没有可靠的方法强制执行。

故障排除正在赶上，还没完成。

组策略具有RSoP和gpupdate，这些工具专门用于在几分钟内回答“为什么没有应用”。Intune现在有大致等效的功能：同步强制执行按需策略签到，每个设置的策略状态显示哪些策略应用到了设备以及原因。Intune中的Copilot在此基础上增加了错误代码分析器和并排设备比较，并且从2026年中期开始，这些功能捆绑在Microsoft 365 E5中，无需单独许可。

仍然缺乏的是成熟度，而不是概念。这些工具较新，管理员报告在基础之外的任何方面结果不一致。组策略在“为什么没有应用”方面领先了20年，这一差距尚未完全弥合，但差距比看起来要小。

没有本地带宽控制。

运行 SCCM 的组策略环境可以使用 BranchCache 或 PeerCache 安排部署，以避免单个站点反复下载相同内容而压垮慢速 WAN 链路。Intune 按设备从互联网拉取，没有点对点缓存来分散站点的负载。对于带宽受限的地点，这意味着部署速度更慢，在某些情况下甚至完全失败且无本地修复方案。

需要原始SID和第三方工具的应用程序控制。

细粒度的应用程序允许列表，类似于组策略环境中使用AppLocker处理的那种，在Intune中更为复杂。引用安全主体通常意味着指定原始SID而非友好名称，且针对Windows更新之外的任何第三方补丁需要完全独立的工具。

如果您是云优先，Intune 是合适的

这并不意味着 Intune 是一个糟糕的产品。它确实非常适合简单的云优先环境。微软提供每月操作系统更新的基础设施非常出色。问题更狭窄且更具体：作为对组策略所做一切的完整替代品，Intune 还未达到那个水平，而假装已经达到只会把问题从路线图幻灯片转移到帮助台队列。

这正是为什么许多组织将他们的Intune部署描述为“再混合几年”，而不是“完成”。这不是人员问题，而是工具上的缺口，Netwrix PolicyPak 正是为了解决这个问题而打造的。

PolicyPak如何扩展Group Policy已经做得好的功能

PolicyPak 不要求团队拆除组策略重新开始。它建立在现有基础设施之上，并将相同的策略逻辑扩展到每个端点，无论是加入域的、远程的，还是已注册到 Intune 的。

• 完整的ADMX深度，而非子集： 管理模板管理器基于ADMX，因此组策略支持的数千个细粒度设置仍然可用，而不是被手工重建为脚本。
• 组策略首选项，仍然自动化： GPP 管理器继续处理映射驱动器、打印机和其他首选项设置，默默地保持桌面一致，无需脚本。
• 真实的层级和整合： 庞大的GPO被整合以减少膨胀并提升性能，同时保持管理员已经理解的基于OU的目标模型。
• 证明执行的合规报告： 组策略合规报告为团队提供了一种展示整个环境中执行内容的方法，而不仅仅是配置内容，这对于审计和周二下午的故障排除会议同样重要。
• 覆盖范围跟随终端，而非域： 对于从未接触域控制器的设备，PolicyPak Cloud及其GPO导出管理器将相同的策略应用于通过Intune或其他MDM和UEM平台管理的终端。注册到Intune的远程笔记本电脑获得与域加入办公室中的计算机相同的最小权限规则和桌面配置。
• 为端点构建的安全控制： 本地管理员权限被取消，而标准用户仍然获得安全、特定的提升路径。基于文件所有者的允许列表通过单一策略阻止不受信任的应用程序和脚本，DLL劫持保护解决了旧版桌面软件中常见的一类漏洞。应用程序、浏览器、Java和可移动设备控制完善了覆盖范围，所有管理均来自一个控制台。
• 简化的部署和补丁： 软件部署、自动补丁和移除在Windows、WinGet和基于网络的来源上运行，填补了Intune仅针对Windows更新留下的第三方补丁空白。
• 不仅限于Windows的最小权限： 最小权限管理器将管理员批准和文件夹权限控制扩展到Mac，而不仅仅是Windows，因此混合端点环境可以通过一个控制台获得最小权限管理，而不是使用Windows工具加上单独的Mac进程。

PolicyPak 不试图成为的东西

直接说明界限：PolicyPak 不执行裸机映像或任务序列，也不是当前处理 OSD 的工具的替代品。它所做的是确保一旦设备存在，无论是通过映像、Autopilot 还是通过 Intune 注册，都能使用相同的策略引擎和团队已经信任的相同深度级别进行配置、锁定和报告。

团队无需在组策略的成熟度和 Intune 的覆盖范围之间做出选择。PolicyPak 保留了花费 20 年构建的层级结构、细粒度和报告深度，并将其扩展到 Intune 现在管理的每个端点。查看它如何适应您当前的环境。