在 ePO 中,您可能要针对 ePO 系统树中的给定系统有多个条目。 这些条目通常称为
重复系统。 本文介绍不同类型的重复系统、这些系统在系统树中的创建方式以及如何进行故障排除。
托管与非托管 (第一种类型)
处理 ePO 中重复的系统时,首先要问一个问题: 所有重复的条目都显示为 托管 还是 有的条目显示为 非托管 ?
- 托管
系统仅在 ePO 中显示为 托管 ,如果安装了代理,并且至少已与 ePO 通信一次。
- 非 托管
这些系统是通过其他方法在系统树中创建的条目。 例如,通过 Active Directory 同步任务,或通过 新建系统 功能手动添加。
当系统首次与 ePO 通信时,ePO 会尝试匹配树中的现有非托管条目。 当非托管条目存在,但 ePO 无法匹配时,它会在系统树中创建新条目。 现在,您具有包含两个条目(其中一个为非托管)的系统副本。
有关更多详细信息,请参阅以下部分中的 ePO 产品手册 :
如何将系统添加到系统树.
要解决以上问题,您必须查看如何将系统添加到树中。
示例: 如果您使用 Active Directory 同步任务,请验证是否正确配置了同步设置。 选项
存在于系统树中其他位置的系统您可以创建重复条目。
单个系统树条目的多个行(第二种类型)
重复系统的第二种类型是
不严格复制。 这是一个场景,即使 ePO 中仅有一个实际系统,系统树中也显示同一系统的多个行。
此情况症状为:
- 所有条目的代理 GUID 和上次通信时间列相同。
- 如果为其中一个系统选择复选框,则系统将自动选择其他系统。
如果 ePO 认为系统安装了多个版本的同一产品或产品系列,则会发生此问题。 在系统树中,存在一列,显示安装了哪些产品版本:
在上例中,ePO 认为系统有两个 VirusScan Enterprise8.8.0.2232和8.8.0.2233安装,这是不可能的。您可以通过从系统树视图中删除相关列来解决此问题。 在这种情况下,
产品版本 (VirusScan Enterprise)列。
注意: 上述只是一个修复,不能解决基础问题:若要正确解决根本原因,请参阅
KB93129 - 为单个系统显示重复的托管产品条目.
不得为(第三种类型)时创建的新系统树条目
第三种类型的重复系统是诊断最复杂的系统。 当托管系统在系统树中已有条目时,会发生此问题。 然后与 ePO 通信,而不是更新现有条目。 在这种情况下,ePO 会认为它是一个新系统,并为此创建了一个条目。
此场景的缓解症状如下:
- 代理 GUID 和上次通信时间在每个条目中有所不同。
- 如果为其中一个系统选择复选框,则不会自动选择其他系统。
- 只有一个条目处于活动状态。 例如,客户端系统通信时,上次通信时间仅更新到其中一个重复的系统上。
此场景的示例可能如下所示:
注意:以上图像显示了上次通信和代理 GUID 值之间的所有不同。
要针对此场景正确排除重复系统问题,您需要了解 ePO 何时需要为系统创建新条目。
每次系统与 ePO 通信时,ePO 都有两种操作计划:
- ePO 已了解该系统。 在这种情况下,ePO 需要更新其属性,并查看是否有新的策略或任务。
- ePO 不知道该系统。 在这种情况下,ePO 必须在系统树中为此创建新条目。
ePO 会询问以下问题,以确定系统是否已知:
- 第一个问题就是"此系统是否为 VDI 模式客户端?"
- 如果回答为 是 ,则 ePO 会以不同方式处理系统。 此主题在以后的详细介绍了。
- 如果系统不是 VDI 客户端,则下一个最重要的问题就是"代理 GUID 是否已经在数据库中?"
- 如果 GUID是在数据库中,ePO 已了解该系统,并且按照"更新属性操作过程。
- 如果 GUID不为在数据库中,可能为新系统,因此 ePO 开始遵循"create a new entry路径。
系统可以更改其 GUID。 最常见的原因包括:
- 代理已卸载并重新安装,或者使用命令选项重新安装 /forceinstall.
- 已从映像重建系统。
- 系统发生硬件更改。 例如,硬盘驱动器从一台笔记本电脑拍摄到,放置在另一个机箱中。 该操作会造成SMBiosUUID以在下次启动代理时不同。 因此,代理会创建新的代理 GUID。
如果 ePO 仅验证 GUID 为已知 GUID,只要系统合法收到新 GUID,ePO 就会为此创建新条目。
注意: 这是早期版本的 ePO 使用方法。 在频繁重建系统的环境中,此行为导致创建重复条目数量无法接受。 因此,ePO 的行为已更改。
添加了另一个检查作为 "
create a new entry' 路径。 系统与 ePO 通信时,系统发送的第一条消息包含 (除其他内容外):
如果 ePO 不知道代理 GUID,它会查看数据库中是否有使用相同 MAC 地址的条目。 如果答案为 是 ,则 ePO 会假设这是一个已与 ePO 通信并已更改其代理 GUID 的系统。 因此它跳回
更新属性路径,然后使用新的代理 GUID 更新具有相同 MAC 地址的现有条目。
以上是一个重要点。 MAC 地址检查只会查看客户端报告的特定 MAC 地址是否位于数据库的任意位置。 ePO 仅为任何给定系统存储一个 MAC 地址,并且每次系统通信时都会更新该地址。 ePO 存储的 MAC 地址是客户端上次通信时报告的地址。
在某些情况下,多个系统可使用相同的 MAC 地址。 常见示例包括:
- 通过虚拟专用网 (VPN) 集中器连接的系统
- 存在虚拟 MAC 地址(如服务器群集)的系统,以及网络接口卡 (NIC)。
在上一方案中,额外的 MAC 地址检查会造成问题。 尤其是重复系统的确切反方向。 相反,您最后使用 ePO 中的单个条目,该条目会持续更新与上次通信系统的详细信息。 这似乎让系统出现了,并且从树中消失。 要解决此问题,您可以通过多种方式替代 MAC 地址并签入。
- 首先,您可以通过设置注册表项并重新启动 ePO 服务,在 ePO 中暂时全局禁用 MAC 检查。 此方法在团队的 NIC 方案中是最常用的。MAC 地址检查已禁用,并且允许团队的 NIC 群集的两个节点与 ePO 通信。 由于 GUID 不同,每个节点在系统树中创建的条目。 然后,会重新启用 MAC 地址检查,以便更改 GUID 的其他系统不会创建重复条目。
要禁用 MAC 地址检查,请参阅KB57886 - 共享 MAC 地址时,无法查看 ePolicy Orchestrator 目录中的两个群集节点.
- 对于通过 VPN 连接的系统,可以将 ePO 配置为根据组织唯一标识符 (OUI) 选择性跳过 MAC 检查。
注意:OUI 是 MAC 地址的前六个字符,用来标识网络设备的供应商。
您可以向 ePO 添加多个 OUI,当具有未知 GUID 的系统与 ePO 通信时,系统会将系统的 OUI 与数据库中的列表进行比较。 如果发现匹配,则 ePO 会跳过 MAC 检查,并创建系统的新条目。 有关详细信息,请参阅添加虚拟 MAC 供应商在 ePO 产品手册中。
假设 MAC 地址检查尚未禁用。 系统 OUI 不在 ePO 已知列表中。 如果 MAC 地址检查的回答是 否 ,则 ePO 会确定计算机是新系统,并完成
create a new entry路径。 如果系统实际上在系统树中创建了一个条目,则此为创建副本的点。
显示上述情况的示例:
- 想象一下,我们安装了一台安装了代理的笔记本电脑。 代理与 ePO 谈论时没有任何问题。
- 其代理 GUID 为 11111111。
- 它通过 Wi-Fi 连接到网络,MAC 地址为 11:11:11:11:11:11。 此时,在 ePO 数据库中,该系统的 GUID 为 11111111。 由于上次通信时,它使用无线 NIC ePO 将该系统的 MAC 地址记录为 11:11:11:11:11。
- 安装时出现致命软件崩溃,您的 IT 部门必须重新映像。
- IT 工程师使用笔记本电脑的有线 NIC 将笔记本电脑连接到网络。 NIC 的 MAC 地址为 22:22:22:22:22:22。 该工程师重新安装操作系统和代理。
- 由于这是一款全新的安装,代理首次启动时会生成一个 222222222 的新代理 GUID,并与 ePO 通信。
- ePO 首先在数据库中搜索 GUID 为 22222222 的条目。 它找不到,因此会继续进行 MAC 检查。
- 然后,ePO 在数据库中搜索 MAC 地址为 22:22:22:22:22:22 的条目。 该条目也找不到,因此 ePO 会创建一个 GUID 222222222 的新条目和 MAC 地址 22:22:22:22:22:22。 现在,我们具有重复的条目。 同一系统的两个条目,其中只有一个处于活动状态。
注意:如果 IT 工程师已使用 Wi-Fi 连接到网络,将不会创建重复的条目。 由于数据库中不存在新的 GUID,因此第一个 GUID 检查将会失败。 但 MAC 地址检查会成功。 这样 ePO 会跳回
更新属性路径,然后使用新 GUID 更新现有条目。
以上是需要注意的重要点。 要创建副本,系统不需要报告新的 MAC 地址。 只是与上次与 ePO 通信时不同的通信。
VDI 模式客户端的特殊情况
对于非永久 VDI 环境,代理可以在称为 VDI 模式的特殊模式下运行。 此模式允许 ePO 确保 VDI 客户端始终使用同一 GUID。 这可让 ePO 在取消配置和配置周期中跟踪特定客户端。
有关 VDI 模式详细信息,请参阅
KB87654 - 在虚拟桌面基础架构系统上配置和部署 McAfee Agent.
总结:
- VDI 客户端关闭后,代理会向 ePO 发送特定消息。
- 然后 ePO 将该系统标记为已取消在数据库中配置。
- VDI 模式代理与 ePO 通信时,会通知 ePO 在通信开始时处于 VDI 模式。
- ePO 会检查数据库中是否有具有相同的完全限定域名的条目。 然后 ePO 会标记为已取消配置。
- 如果找不到,则 ePO 会为系统创建新条目。
- ePO 不会查看 GUID 或 MAC 地址是否存在。 在非永久 VDI 环境中,这两者不相关。
以上内容意味着:在 VDI 环境中:
- 如果阻止 ePO 接收取消配置消息,则下次设置客户端时,ePO 会创建一个重复条目。
- 最常见的原因是 VDI 客户端未完全关闭。 例如,如果系统崩溃,或主机强制关闭系统。
以下流程图显示了每次系统与 ePO 通信时 ePO 都遵循决策树:
故障 排除
现在,我们了解 ePO 如何决定何时创建新条目。 现在,您可以对创建它们的原因进行故障排除。
我们了解,若要 ePO 决定创建新条目,它必须
不知道 GUID。 因此,第一个问题就是"客户端 GUID 为何更改?
以下是客户端创建新的 GUID 的最常见方法:
- 代理已卸载并重新安装。
- 代理已使用/forceinstall切换,或从 ePO 部署,具有Force installation over existing version选项被选中。
- 代理检测到新的SMBiosUUID,表示硬件更改。 例如,硬盘驱动器从一台笔记本电脑移动到另一台。
- 代理运行状况检查失败。 导致其重新生成数据库文件并创建新的代理 GUID。
第一个故障排除问题为"
此 GUID 更改是否预期?".
示例: 我们已在任一时间创建新 GUID:
如果新 GUID 不是预期的,则第一步是调查其更改原因。
- 查看代理安装日志(frminst.log).
- 是最近与/forceinstall选项?
- 如果是这样,则 McAfee 不建议一般使用此选项。 必须仅在特定情况下使用。 例如,如果您尝试使用/instdir开关。
- 查找mascvc log文件。
- 查找 GUID 更改证据。
- 例如,如果 MAhealthcheck失败。 系统会显示一条错误消息,显示maconfig.Error: MA databases integrity check failed.
下一个故障排除步骤是确定 ePO 无法将 MAC 地址与之前条目匹配的原因。
首先需要确保 ePO 未配置为跳过 MAC 检查:
- 请确保代理错误地未安装在 VDI 模式中。
- 查看 ePO 中系统的系统属性。 查看属性列表底部,了解 VDI 属性所在的位置。 如果代理以 VDI 模式安装,则其必须为 是 。
- 如果代理不注册为 VDI 模式,请先卸载它,然后重新安装,无需使用/EnableVDIMode开关。
- 请确保 MAC 搜索未全局禁用。 参阅KB57886 - 共享 MAC 地址时,无法查看 ePolicy Orchestrator 目录中的两个群集节点。
注意: 上述设置按代理处理程序应用。 因此,如果您有多个代理处理程序,请仔细查看它们,并确保未禁用 MAC 搜索。
- 如果系统未通过 VPN 连接,请确认错误地将代理 MAC 地址的 OUI 添加至 ePO 的虚拟 MAC 供应商列表中。 如果存在,请删除相关的 OUI。
如果上述均不为 true,则 ePO 数据库中将找不到客户端系统提供的 MAC 地址。 这会造成 ePO 创建新条目。
- 检查 ePO 审核日志,在 快速查找 过滤器中输入客户端系统名称。 您看到ASCI - New System事件。 您看到的事件的详细信息是客户端报告的 MAC 地址。
- 将最新的重复条目在系统属性中的详细信息与 MAC 地址进行比较。 此条目是创建副本前系统所使用的 MAC 地址。
上述内容可能有助于说明 ePO 无法与 MAC 地址匹配的原因。 例如,前一条目可能具有无线适配器的 MAC 地址,审核日志条目具有坞站适配器的地址。
总结
- 最后,在客户端系统上不必要的 GUID 是出现 ePO 重复条目的最常见原因。
- 又进而导致此问题的最常见原因是:使用/forceinstall开关。 视为计划服务器任务或登录脚本的一部分。
- 要了解重复条目来自何处,首先要发现 GUID 变化的原因。 在了解原因后,会非常简化识别问题源。
重要说明:
- 除非在知识库文章中指明了用于解决问题的问题,否则不得使用 McAfee Agent /forceinstall 开关。
- 将 /forceinstall 开关用作常规进程可能会导致 McAfee Agent 问题,这会导致 ePolicy Orchestrator 系统树中出现重复条目。这可能会导致系统收到错误的策略分配。
《 McAfee Agent 产品手册》中所述的标准用例是仅将 /forceinstall 开关用于以下任一种情况: