windows更新补丁分组审批本身不导致客户端无法获取补丁，真正决定适用性的是设备分组、上报状态与补丁元数据三者匹配逻辑；常见问题源于设备误入分组、筛选器配置错误或targeting criteria不匹配，需通过日志、注册表和可用更新列表验证实际适用性。

补丁分组审批本身不导致客户端“因分组错误无法获取正确补丁”——真正卡住的是 windows update 服务在执行时对目标补丁的适用性判断逻辑，而这个判断依赖于三类关键信息：设备所属的更新分组（update ring）、设备上报的合规状态（如 os 版本、架构、功能启用状态），以及补丁元数据中定义的适用条件（如 targeting criteria）。所谓“分组错误”，通常不是审批环节出错，而是设备被错误归入某个分组，或该分组策略配置与实际环境不匹配。

确认设备是否真被错误分组

Intune 中的更新分组（如 “Pilot Ring”、“Production Ring”）本质是基于 设备筛选器（Assignment Filters） 或 设备群组成员关系 动态决定的。常见误判场景包括：

• 设备仍处于旧版 Windows（如 22H2）却被分配到仅面向 24H2 的补丁分组，而该分组未设置版本兼容回退
• 筛选器中使用了自定义属性（如 device.devicePhysicalIds 或 device.osBuildNumber），但设备未上报或上报值为空/异常
• 设备属于多个重叠群组，而 Intune 按优先级顺序应用策略，高优先级分组覆盖了本应生效的补丁策略

检查补丁策略的 Targeting Criteria 是否匹配设备实际状态

每个 Windows 更新策略（如 Feature Update、Quality Update）都自带隐式或显式的目标条件。例如：

Windows-Android_SSH_Remote_Control

通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。

下载

• 一个 Quality Update 策略若设置了 Minimum OS Build = 26100.1，那么运行 26100.0 的设备即使在该分组内也不会收到此补丁
• Feature Update 策略默认只推送给已启用 Windows Update for Business 并完成“升级准备检查”的设备；若设备禁用 WUfB 或磁盘空间不足，状态会显示为“Not applicable”而非“Failed”
• 部分补丁（尤其是 .NET Framework 或 Cumulative Update）要求特定组件已安装，比如 KB5037771 需要先有 KB5034441，否则客户端会跳过安装并记录 0x800f0950 错误

验证客户端本地 Windows Update Agent 行为

设备端是否真的“无法获取”，需排除本地服务异常干扰：

• 运行 Get-WindowsUpdateLog 导出日志，搜索关键词 Applicability 和 TargetGroup，确认客户端识别的分组名与 Intune 后台一致
• 检查注册表项 HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update 下的 Ring 和 BranchReadinessLevel 值是否被策略正确写入
• 执行 usoclient StartScan 强制触发扫描后，用 Get-WUList -IsInstalled:$false 查看客户端实际看到的可用更新列表——如果为空，大概率是适用性不满足，而非分组没生效

审批环节可做的实质干预

审批动作本身不修改分组逻辑，但可在发布前做两件事降低风险：

• 对 Pilot 分组启用 预览补丁（Preview Builds） 或 延迟质量更新（Defer Quality Updates by 7 days），让策略在真实环境中暴露兼容性问题
• 在审批前，导出该补丁的 Applicability Report（Intune 控制台 → Devices → Windows → Windows Update for Business → Reports），查看目标设备中“Applicable”和“Not Applicable”的比例及原因分类
• 若发现大量设备因“OS version too low”被排除，不要强行审批，而是先调整策略中的最低版本要求，或为旧系统单独建一个兼容性分组并推送历史补丁