问题

在 SEPM 上修改策略后，某些组无法获取新的策略，并且客户端的病毒定义也无法获取更新。

环境

SEP11

原因

被破坏的策略导致 SEPM 在编译组策略和更新文件信息失败，导致编译中断。

解决方案

可以通过以下方法来定位受损的客户端组：

1.      开启 SEPM 的 debug

编辑 :\\Program Files\Symantec\Symantec Endpoint Protection\tomcat\etc下的conf.properties 文件，并在最后添加一行 scm.log.loglevel = finest，然后保存退出。

2. 重启 SEPM 的服务

3. 在一段时间后，或者可以尝试在一段时间内修改策略来触发服务器进行编译。每一次编译都是从My company 组开始，我们可以通过查看 My Company 组的策略序列号的前四位，然后在到:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\ 下找到前四位相同的文件夹，该文件夹的名称就是 My Company的组 ID，然后在日志PackagePublisherTask-0.log 中过滤 My Company 组的 ID 信息，如以下样本。

SEPM 每次都是从组 CF4CA5B8A5CA348201B249AE4E1A2F98 开始编译，最后一个组为051E4F56A9FE9D9601B340DA66D77060

4. 如果在第三步中发现被编译组的数量比实际的组要少，那么就需要找到最后一个编译的组名。在知道最后一个组的组 ID 是 051E4F56A9FE9D9601B340DA66D77060 后，可以在:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\outbox\agent\下找到跟这个组同名的文件夹{051E4F56A9FE9D9601B340DA66D77060.ZH_CN} ，然后用 IE 打开文件 profile.xml，可以从这个文件中获取到相对应的组的名称。

5. 在 SEPM 上创建新的策略文件，将该组的所有策略替换。

From Symantec

专家点评

    本来刚开始看这个题目挺有兴趣的，但是最后发现是策略损坏造成的SEPM也客户通信异常，而且解决方法还是新建策略。我认为如果根据客户端异常进行统计来判断哪个组有问题实际上更方便，而且分组多了用以上方法的话查找PackagePublisherTask-0.log时一定会死人。我测试时短短几分钟日志就达到了400多K。