【IT168 专稿】如何在一个企业部署 Symantec Endpoint Security 11.0? 在一个小型的局域网如何部署？客户端数目是 100 个，1000 个，10000 个，甚至 100000 个？客户端分布1个区域，3 个区域，10 个区域，30 个区域，全国各 地？硬件配置参差不齐？网络带宽有限，访问受限，专线连接，广域网连接？用户想把 Symantec Antivirus10.1 升级为Symantec Endpoint Protection11.0, 是否就是把所有的Symantec Antivirus服务器转换为SEPM?
此文档所要说明的也正是在部署和实施 Symantec Endpoint Protection 时，根据企业实际情况的非常好的实践建 议，以及避免在部署和实施过程中碰到由于产品局限，方案错误，策略配置不妥导致的各种各样的错误，失败 可能性和潜在的风险。
在设计 Symantec Endpoint Protection 部署架构时，最重要的考虑因素就是网络体系结构。下列因素会影响需 要使用的站点数目，管理服务器，更新服务器等的数目：
企业中的客户端数目
企业中的客户端分布的地理位置数目，以及不同地理位置之间的通信链路类型
企业中的功能部门或者管理组的数目
企业中的数据中心的数目
内容更新的频率
需要保存的客户端日志的类型，需要保留的时间和数据量，以及数据需要储存的位置。
任何根据企业的具体情况而定的企业管理和IT安全管理考虑事项。
我们根据以上的考虑因素，在设计 Symantec Endpoint Protection 部署架构时主要有下面的四种解决方案：
单站点，单服务器
单站点，多服务器
多站点，复制
多站点，不进行复制 当然根据具体的实际情况，我们有可能需要在实施的时候对于以上的解决方案混合使用，以及设计更为灵活的一些补充解决方案。
本文档的目标读者是对 Symantec Endpoint Protection 有比较深的了解，具有比较多的部署和实施经验的使用者。
单站点 — 单服务器解决方案
什么样的情况适合此部署模式？
这是最简单，也是成本最低的 Symantec Endpoint Protection 部署方式。企业只需要部署一个站点，包括一台 管理服务器
(SEPM)，使用光盘中提供的 embedded 数据库，或者使用用户自己的 SQL server 以提高性能。
必要条件：所有客户端都可以与 SEPM 进行通信。
但是绝不是说满足必要条件就一定可以使用此部署方式，一般来讲，对于一个企业，客户端数目不是很多，服 务器性能高，网络环境比较简单且带宽比较充裕，没有更多的负载均衡，故障转移需求时，建议使用此方案。
服务器系统要求：关于最低系统要求，请参考 Installation Guide。基于常见的一些问题，有以下建议：
1、推荐使用 SQL server 2005 64 bit。
2、服务器硬件：如果使用 SQL server 数据库，推荐使用多 CPU, 16G 内存剩余硬盘空间 40G 以上。
3、操作系统推荐采用Windows server 2003 sp2（如果是 R2，需要使用 IE7）
带宽要求：
带宽要求比较高，有以下常见情况：
1、局域网内；
2、专线；
3、一般电信网络
管理方式要求：
在这种单站点，单服务器方式下，总部集中维护硬件，并进行统一管理，统一的日志收集；各授权分支机构也可以通过登录远程控制台的方式进行授权范围内的客户端组的管理，但是只有系统管理员拥有对服务器级别的 管理（包括 Enforcer 管理）。
支持多少客户端？
理论上，使用 embedded 数据库的 SEPM 支持的客户端上限是 5000 个；使用 SQL server 数据库的客户端数目 上限是 50000 个。但是任何部署都不可能达到理论上的上限值，建议如果客户端数目超过 1000 时，采用 SQL server 数据库。
备份与恢复：
关于 SEPM 的备份和恢复的具体操作，请参考 Administration Guide，或者其他的内部文档例如《SEP11 系统 灾备和维护计划操作指导手册》，以及 Symantec 知识库文档。此文档仅限于非常好的实践建议，避免操作过程和 操作方式带来的可能的风险。
备份前的检查与日常维护： 由于最主要的备份是对于数据库的备份，因此在备份之前我们需要检查数据库里面的内容是否可用，是否 受到损坏。如果备份的数据库内容本身受损，那么此备份将没有任何意义。
建议的操作：
一是DBValidator 检测。在 SEPM\tools 目录里面，点击 dbvalidator.bat 文件，此操作完成后会产生一个日志文件dbvalidation.log 在 SEPM\tomcat\logs 目录里面。保证里面有如下的成功语句：
2008-12-04 15:53:11.000 INFO: Database validation passed.
2008-12-04 15:53:11.000 INFO: Finished
二是在 SEPM 的 SEPM\tomcat\logs 里面的 scm-server-0.log 里面，保证没有一直不断重复发生的 SEVERE级别的错误 (exception)。
备份什么：
一是数据库的备份。这是需要定期去做，建议一个月一次，并且在所有的对于服务器的升级，更新，以及 其它有可能带来风险的操作以前都要做备份。至于数据库的备份方式，可以使用 SEPM 自带的数据库备份 和恢复向导；另外如果是使用 SQL server，也建议使用 SQL server 自带的备份工具来备份sem5数据库，或 者使用类似 NBU for SQL server, BE for SQL server 等方案，同时获得并保留对 sem5 数据库的备份。
二是 Keystore，这是 SEPM 和客户端之间的证书文件。建议在配置好 SEPM，并且与客户端通信正常时， 通过 SEPM 控制台，进行备份并导出，妥善保管。
三是 SEPM 备份参数文件，包括 SEPM IP 地址， SEPM 计算机名，站点名称，共享密钥（安装 SEPM 时设 定），Domain ID（每个域的 ID），keystore 密码（在备份的 keystore 文件里面）。
恢复方式：
一是有数据库恢复，通过备份的数据库，使得 SEPM 恢复到备份前的状态。
二是无数据库恢复，可以恢复与所有客户端的通信关系，但是需要重新建立所有的组和策略。
客户端内容更新方式：
在单站点单服务器模式下，所有的客户端都会到 SEPM 更新包括病毒定义，扫描引擎，主动式威胁防护引擎， 主动式威胁防护定义，以及入侵防护特征，对服务器的性能和带宽带来影响。举个例子，一个完全的病毒定义 包大约是 35M，一个增量的病毒定义更新包大约 100k，每天 Symantec 会提供 3 个病毒定义更新，主动式威 胁防护定义和入侵防护特征大约 3 天更新一个。以下有三种针对客户端内容更新的补充解决方案，可以使一部 分组的客户端通过其它的方式进行内容更新，减少服务器的负担，以及网络的负担。
1、客户端通过 Liveupdate 到 Symantec 进行内容更新。 优点是减轻 SEPM 的负担，以及 SEPM 所在网络的 负担。缺点是每个客户端所在的网络需要 Internet 出口，并且该客户端所在网络对外的通信流量没有减少。
2、客户端通过组更新提供者更新。优点是减轻 SEPM 的负担，以及 SEPM 所在网络的负担，合理的规划组更 新提供者可以有效的减少总体上的网络负担。
组更新提供补充解决方案：
客户端与 SEPM 心跳通信方式和周期：
由于 SEPM 利用 IIS 与所有客户端进行基本心跳通信（包括检查是否在线，策略推送，日志收集，以及当选择 客户端从 SEPM 获得内容更新时的内容更新的推送），因此当客户端数目越多，通信周期越短时，对 SEPM 服 务器的 IIS 的负担越大。
1、推模式和拉模式：在推模式下，客户端首先发起与 SEPM 的通信，进行一次心跳通信后客户端与 SEPM 建 立永久的通信通道直到客户端服务停止。在这种模式下服务器对客户端的命令可以第一时间到达客户端， 但是每一个在线的客户端都会占用 SEPM 的 IIS 的一部分资源。而与之对应的拉模式下，每个客户端与 SEPM 完成一次心跳通信后就会断开与 SEPM 的 IIS 的连接，而下次通信后重新在建立连接。因此我们建 议当一个 SEPM 所管理的客户端数目达到或者超过 200 个时，采用拉模式进行通信。
2、心跳周期：默认的心跳周期是 5 分钟一次。心跳周期越短，对 SEPM 的 IIS 的负担越重，以及对企业的网 络负担也会越重。建议对于客户端数目超过 1000 台以上的 SEP 部署，增加心跳周期为 1 小时以上（但是 不要超过 3 个小时）。
在单站点，单服务器模式下，所有的客户端都与 SEPM 通信，以维持心跳状态，上传日志，下载内容更新。在 这些通信当中，下载内容更新无疑是数据量最大，占用带宽比例最大的通信。另外，很多 Symantec Antivirus 的老用户有在各个分支机构部署二级 SAV 服务器，各个分支机构的客户端从该地的二级服务器获得病毒定义更 新的管理习惯。根据以上的情况和需求，在 Symantec Endpoint Protection，引入了组更新提供者。组更新提供者是一个特殊的 SEP 客户端，起到对小规模的 SEP 客户端提供内容更新的作用。
下面是对于组更新提供者的非常好的实践建议：
1、对于每一个客户端组，只能设置一个组更新提供者（当然可以不设置组更新提供者，这样的话所有客户端 直接向 SEPM 获得更新），而这个组更新提供者必须是这个客户端组的一个客户端。
2、在一个客户端组设置了组更新提供者以后，这个客户端组的客户端还是会以心跳周期与 SEPM 进行通信， 维持心跳状态，上传日志等等。客户端一旦发现 SEPM 中有更新的内容更新，会联系组更新提供者要求下 载内容更新。
3、当客户端无法连接到组更新提供者时，默认情况下会重新连接 SEPM 获得内容更新。SEP11.0 MR3 以后， 有组更新提供者 Bypass 高级选项，以设定即使连不上组更新提供者，也不连接到 SEPM。这样，可以保 证客户端永远只能从组更新提供者获得内容更新，保证 SEPM 的通信性能。
4、在一个客户端组设置了组更新提供者以后，可以做到这个客户端组中只有组更新提供者一个客户端向 SEPM 获得内容更新，而其它的客户端都向组更新提供者获得更新。因此组更新提供者一般使用在客户端数目不 是很多的分支机构，以减少分支机构与总部 SEPM 之间的通信数据量。
5、毕竟组更新提供者只是一个客户端，性能有限，建议一个组更新提供者最多为 100 个客户端提供更新。如 果一个分支机构有不超过 100 个客户端，可以划分为一个客户端组，并且从一个组更新提供者获得更新； 如果有超过 100 个客户端，建议划分为多个客户端组，每个组有不同的组更新提供者。
6、在SEP11.0.5000版本以后，会对于组更新提供者，在功能上和性能上有非常大的提升，使得组更新提供者 能够满足更多的需求。但是以上的建议还是可以满足基本的组更新提供者的需求，并且使用上比较稳定，建议用户使用。
什么样的情况适合此部署模式？
这种部署方式下，Symantec Endpoint Protection 只有一个站点，也就是只有一个 SQL server 数据库（通常是 在总部），然后根据需要添加多台 SEPM 与此 SQL server 数据库连接。
通常情况下，有以下两种需求时可以使用单站点，多服务器解决方案。一是用户有负载均衡，容错的需求；二 是用户的客户端集中分布于若干个地理位置，有统一管理的需求以及各地的服务器之间通信链路比较好。
服务器系统要求：
关于最低系统要求，请参考 Installation Guide。基于常见的一些问题，有以下建议：
1、数据库必须使用 SQL server。 推荐使用 SQL server 2005 64 bit。推荐使用 SQL server Cluster 以提高性 能。
2、数据库所在的服务器，推荐使用多 CPU，16G 内存，至少 60G 剩余空间。
3、其他 SEPM 服务器使用双 CPU，4G 内存，20G 剩余空间。
4、操作系统推荐采用 Windows server 2003 sp2 （如果是 R2，需要使用 IE7）
网络要求：
对于容错和负载均衡的需求，建议 SQL server 和一个 SEPM 在本地，并且其它的 SEPM 和 SQL server 在局域 网内。
对于企业的客户端分布在多个地理位置，并且有需求在不同的地理位置建立不同的 SEPM。要求有较好的网络 带宽，建议 4M 以上的的带宽。
一个 SQL server 支持多少个 SEPM：
由于 SQL server 需要对每一个SEPM的连接要分配不同的 Pool，并且每一个 SEPM 每 2 秒钟就会有 query 命 令与 SQL server 交互。因此 SEPM 数目越多，对于 SQL server 的负担就会越大。一个 SQL server 支持的 SEPM的最大极限是 10 个，但是为了增强可用性，建议一个 SQL server 连接不高于 4 个 SEPM。
管理方式要求：
在这种单站点，多服务器方式下，由于所有的数据都是保存在总部的 SQL server，因此可以做到第一时间内所 有数据的共享：
1、可以做到日志集中，统一报表；
2、只要任何 SEPM 进行内容更新，会把内容更新放入 SQL server 数据库，所有的 SEPM 都会自动获得此内 容更新。
3、客户端安装包共享，任何一个 SEPM 添加客户端安装包以后，所有 SEPM 都可以获得此安装包。
4、系统管理员拥有所有的管理权限，包括对客户端组和策略的编辑，以及所有SEPM服务器的策略编辑，以 及所有的连接的 Enforcer 的策略编辑。
域管理员或者受限管理员只有对本域的客户端组和策略的编辑权限，没有对于 SEPM 服务器和 Enforcer的策略编辑权限。因此对于分部的管理员赋予何种权限需要预先考虑。
非常好的实践建议
数据库维护建议：由于在这种单站点，多服务器的架构下，所有的数据都会保存在总部的 SQL Server 中，并且几乎所有的对于SEPM 的操作都会有与 SQL server 的数据交互，因此对于 SQL server 的日常维护工作非常重要。
1、备份和恢复：请参考第二章单站点，单服务器的备份和恢复建议。
2、日常维护：
经常将数据库备份到磁盘中，不是 SQL server 所在的电脑的磁盘；分开各个备份文件；定期删除旧的 备份文件，但是保留升级之前做的备份文件。
对于管理数据库 sem5，删除事务日志中的非活动部分。如果使用 SQL server 的备份功能，不备份 sem5事务日志文件。
将数据库文件大小维持在规定的级别上，设置 sem5 数据库中每个逻辑库的最大容量为不受限制（需要 有足够的硬盘空间）；定期观察当发现数据库文件大小突然间有较大增长时，及时分析原因并采取措 施避免。
利用 SQL server 2005 或者 SQL server 2000 提供的数据库设置向导，根据以上的原则，设置合理的数 据库维护计划。并将数据库维护报告以电子邮件的方式发送给数据库管理员。
管理服务器列表：
既然存在多个 SEPM，用户自然会存在容错和负载均衡的需求，而 Symantec Endpoint Protection 可以很容易 做到这点，其关键是建立合理的管理服务器列表：
1、默认的管理服务器列表是所有的SEPM服务器同一优先级，也就是说，在单站点，多服务器模式下，所有 客户端会随即连接到任何一个 SEPM，起到负载均衡的作用。
2、如果有其他的客户端连接 SEPM 方式的需求，需要人为的编辑一个新的管理服务器列表，并且把这个管理 服务器列表分配给客户端组。
3、对于客户端组而言，一个管理服务器列表中可以包含不同站点的 SEPM 服务器（前提条件是这些站点是复制的关系）；但是一个管理服务器列表也可以分配给一个 Enforcer 组，建议这里的管理服务器列表只包含 同一个站点的 SEPM。
多站点 — 复制解决方案
什么样的情况适合此部署模式？
在这种部署方式下，每一个站点表示拥有一台独立的数据库，以及一个或者多个SEPM，这是一种分布式管理体系结构。而且所有的站点之间的组和策略，客户端信息等关键数据通过复制做到同步，共享。
一般来讲，有以下两种需求时可以采用这种多站点，复制解决方案。一是对于多个地理位置之间WAN的连接带 宽比较差，SEPM 无法管理远端的客户端或者SQL server 与远端 SEPM 的通信受限；二是企业有多个数据中心，每个数据中心需要完整的完全网络和安全相关数据的高可用性需求。除此之外，对于单站点，多服务器方 案下SEPM数量太多，SQL server负担太大，我们也建议分为不同的站点，以减少每个站点的 SEPM 数目。
服务器系统要求：
关于最低系统要求，请参考 Installation Guide。基于常见的一些问题，有以下建议：
1、数据库必须使用 SQL server。推荐使用 SQL server 2005 64 bit。推荐使用 SQL server Cluster 以提高性能。
2、数据库所在的服务器，推荐使用多 CPU，16G 内存，至少 60G 剩余空间。
3、其他 SEPM 服务器使用双 CPU，4G 内存，20G 剩余空间。
4、操作系统推荐采用 Windows server 2003 sp2（如果是 R2，需要使用 IE7）
网络要求：
对于这种多站点，复制的解决方案， 对于网络带宽的要求低于单站点，单服务器的解决方案和单站点，单服务 器的解决方案。并且一个优势在于，不同的地理位置之间的站点之间的复制（也就是数据交换）的时间可控。
支持多少个站点的复制？
两个站点之间的复制会交换包括组和策略（必选），内容更新，客户端安装包，日志等内容。因此建议尽可能 的减少需要复制的站点数目。互相复制的站点数目的最大极限是 20 个，但是建议在企业实际部署过程中，尽 量不要超过 5 个互相复制的站点。
管理方式要求：
在这种多站点，复制方式下，总部可以进行统一管理，统一的日志收集；各授权分支机构也可以进行授权范围 内的客户端组的管理；除此之外，由于各系统管理员可以并且只能管理本站点，可以做到分支机构的系统管理 员管理该地理位置的 SEPM 服务器和 Enforcer 服务器。
SNAC 扩展的要求：
在这种管理模式下，因为一台 Enforcer 只能和本站点的 SEPM 服务器进行通信（虽然可以通过 Management Server List 增加其它站点的 SEPM 的地址，但是不建议）。因此需要保证各站点的客户端数据进行复制以后， 一个客户端可以通过远程站点的 Enforcer 的验证。
如果客户端的 GUID 值不能即时地在各个站点之间复制和共享，客户端在其它的站点有可能不能通过验证。 对于 Gateway Enforcer，一个可能的解决方案是使用 On-demand 方式。
非常好的实践建议
复制的拓扑结构：
对于有多个站点需要复制的情况，有以下几种常见的拓扑结构：
1、中心 - 分支型：
在这种结构下，一需要首先保证中心站点的高可用性。并且建议不要超过 4 个站点与中心站点建立复制关系。
2、三级模式，汇聚到中心： 这种管理模式下，最大的弊端是站点的数目有可能会很多。不推荐这种复制模式。如果已经建立，建议断 开二级和三级分支机构之间的复制关系。
3、双中心站点（两个中心站点进行复制，每个中心站点分别与其分支站点复制）： 这种拓扑结构是对于企业拥有两个或者多个数据中心，以及在第一种复制结构中分支站点数目过多的情况 的一种补充。
4、链状结构（站点 1 与 2 复制，站点 2 与 3 复制，站点 3 与 4 复制）： 在这种模式下，优点是只要设置好复制调度时间，由于复制方向单一，每个复制性能上会比较高；缺点一 是任何站点的损坏都有可能造成全部复制关系的打破，二是位于两端的站点之间数据同步的周期太长。
5、建议任何两个站点之间，复制关系只能有一条复制路径可达，不要有环路。这样可以保证复制关系的唯一 性和避免重复的复制带来的资源浪费和潜在的风险。
有效的的复制调度
总体来讲，复制站点之间对于网络带宽的总体要求低于单站点，单服务器解决方案和单站点，多服务器解决方 案。除此之外，在不同的站点之间没有复制操作时，没有数据量的传输；但是一旦在进行复制作的时候，由于需要复制的数据量比较大，可能会造成此期间的网络负担较重，以及复制时间较长，甚至复制失败的情况。
1、第一次复制时，需要复制所有的数据库内容，此后的复制是增量的把数据库中更新的内容进行复制。因此 这个调度周期不应太长也不应太短。 建议每天进行一次复制，并且把进行复制的时间设置为夜里网络负担较轻的时候。如果是只有两个站点，并且有较好的网络状态和较高的复制需求，可以设置为默认的每小时复制一次。
2、当一个站点与多个站点进行复制时，需要把每一个复制调度设为不同的时间段。并且预估每一次复制所需 的时间，做到不存在一个复制没有结束但是另一个复制调度开始的情况。
3、建议复制的调度和进行复制的 SEPM 的 Liveupdate 的调度设为不同的时间段。并且预估复制和 Liveupdate所需的时间，做到在同一个时间段内两个动作不同时进行。
复制哪些内容？
1、第一次进行站点安装并且添加到复制站点的时候，必须复制所有的内容。
2、如果用户没有日志集中，统一报表的需求，建议取消对于日志的复制。
3、建议取消客户端安装包的复制。各个站点的客户端安装包手动添加。
4、从 SEP11.0 MR3 开始，建议取消对于内容更新的复制。各个站点通过 Liveupdate 从 Symantec Liveupdate站点或者内部 Liveupdate 服务器进行内容更新的下载。
多站点，复制解决方案和单站点，多服务器结局方案的整合
SEPM 数目过多：
有的企业的客户端地理位置的分布非常多，设计上需要大量的SEPM服务器。在这种情况下，一个站点能够支 持的 SEPM 的数目是有限的（极限是 10 个，建议不多于 4 个），以及复制站点的数目也是有限的（极限是 20 个，建议不多于 5 个）。这种情况下会出现 SEPM 数目过多，那种设计都不满足的情况。此时可以采用多站 点，复制与每个站点多服务器的解决方案。
一般情况下有：
3（站点）X 3（每站点 SEPM）
3（站点）X 4（每站点 SEPM）
3（站点）X 5（每站点 SEPM）
4（站点）X 4（每站点 SEPM）（中心 — 分支型）
4（站点）X 5（每站点 SEPM）（中心 — 分支型） 这些比较简单的解决方案。
Symantec Endpoint Protection 的架构中，SEPM 的处理能力很强，因此在方案设计时，尽可能的减少所需要的 SEPM 是一个好的做法。
用户有容错和负载均衡的需求
对于在复制结构中的某些站点，用户出于容错和负载均衡的需求，也会要求增加 SEPM 的数目。一般这种情况 下，一个站点的 SEPM 数目不会超过 3 台，而且这些 SEPM 在同一个局域网内。对于中心—分支型的复制拓扑结构，我们建议对于中心站点建立多个 SEPM 以进行容错，负载均衡。
什么样的情况适合此部署模式？
在这种部署方式下，每一个站点表示拥有一台独立的数据库，以及一个或者多个SEPM。但是各个站点之间的 数据不进行复制，也就是不需要同步；或者只有一部分站点之间的数据进行复制，其他站点之间的数据不进行 复制。这是一种松散的，开放的管理方式。
一般来讲，如果企业的客户端位于多个地理位置，且各个地理位置之间网络带宽比较小；用户并没有日志集 中，统一报表的需求，或者日志可以通过SSIM，或者第三方日志收集工具（Syslog服务器等）可以做到集中， 统一报表；而且在以后的SNAC扩展中，Enforcer不验证客户端的GUID。在这种情况下，建议采用这种多站 点，不复制解决方案。
服务器系统要求：
关于最低系统要求，请参考 Installation Guide。基于常见的一些问题，有以下建议
1、推荐使用 SQL server 2005 64 bit。
2、服务器硬件：如果使用 SQL server 数据库，推荐多 CPU, 16G 内存剩余硬盘空间 40G 以上。
3、操作系统推荐采用 Windows server 2003 sp2 （如果是 R2，需要使用 IE7）
4、如果有的站点需要多个 SEPM，对于没有数据库的 SEPM，推荐使用双 CPU，4G 内存，20G 剩余硬盘空 间。
网络要求：
对于这种多站点，不复制的解决方案， 对于网络带宽的要求是最低的。只需要网络可达，管理员可以使用远程 控制台进行管理即可。如果部分站点之间需要复制，或者部分站点的 SEPM 之间需要容错和负载均衡，需要相应部分的网络带宽满足相应的“单站点，多服务器”或者“多站点，复制”的需求。
管理方式要求：
在这种方式下，由于没有大规模的服务器之间数据交换的需求，部署所面临的风险相对于单站点，多服务器方 式和多站点，复制的方式要小很多；但是相应地来讲，某些依赖于这种服务器之间数据交互的功能就会受到限 制：
1、每个站点之间不能共享客户端安装包。每个站点的客户端安装包需要管理员手动添加（而即使站点可以复 制，手动添加客户端安装包也是推荐的做法）。
2、每个站点的内容更新需要独立下载。可以通过 Symantec Liveupdate 服务器下载；如果用户有从总部下载内容更新的需求，可以在总部建立内部 Liveupdate 服务器以供每个站点下载内容更新。
3、每个站点的日志只能在这个站点范围内汇总，而不能做到所有独立的站点之间的日志和报告的汇总。如果 用户有所有站点的日志集中，统一报表的需求，可以借助于其它产品，比如 SSIM，Syslog 服务器；或者 认为的对于导出的日志和报表做编辑以进行汇总。
4、Symantec 给出的一个解决方案 Master Console 适用于这种部署方式。在这种部署方式下，使用 Master Console，可以更加简单和有效地对各个独立的站点进行策略的分发，管理和监控，以及日志的统一收集 和报表的生成。
什么样的情况适合此部署模式？
SNAC 扩展的要求：
在这种方式下，由于各站点的数据是独立的，各站点之间客户端的 GUID 没有办法共享，会造成 Enforcer 不能 验证通过其它的站点的客户端的 GUID，因此客户端出差到不同的站点进行准入的时候遇到一定的困难。漫游 到其他站点的客户端无法通过其 Enforcer 的验证。
以下几个方法可以解决这个问题：
1、使用 Gateway Enforcer 的 On-demand 方式。
2、临时采用使用 SylinkDrop.exe，来给来访的客户端替换本地站点服务器的 Sylink.xml。
3、采用 Gateway Enforcer 的本地验证，并且让 Gateway Enforcer 平时不与 SEPM 通信，这样就不会验证客 户端的 GUID。
ymantec 预警解决方案
Symantec 全面提供各种服务以使您能够充分利用您对 Symantec 产品的投资，并拓展您的知识、技能和全球 视野，让您在管理企业安全风险方面占据主动。现有下列企业服务：
这些解决方案提供计算机攻击的预警、全面的威胁分析以及防止攻击发生的应对措施。
安全托管服务
这些服务消除了管理和监控安全设备和事件的负担，确保能够对实际威胁快速响应。
咨询服务
Symantec 咨询服务由 Symantec 及其可信赖的合作伙伴提供现场专业技术指导。Symantec 咨询服务提供各种预先包装和可自定义的服务选项，其中包括评估、设计、实施、监控和管理功能，每种功能都注重于建立和维 护您的 IT 资源的完整性和可用性。
教育服务
教育服务提供全面的技术培训、安全教育、安全认证和安全意识交流计划。
