Top 10 Symantec Best Practices - Deploying Symantec Endpoint Protection Architecture

Article:TECH92051  |  Created: 2009-01-27  |  Updated: 2013-05-27  |  Article URL
Article Type
Technical Solution


These are Symantec's best practices for deploying Symantec Endpoint Protection.


1. Ensure all SEP clients and SEPMs are running the latest Maintenance Release

  • To take advantage of the latest enhancements, optimization and fixes added to the product.
  • Download the latest product releases at FileConnect.

2. For remote sites with between 10 and 10,000 machines, consider using the Group Update Provider functionality of the Symantec Endpoint Protection client for content distribution

  • When migrating from SAV CE, one way to do this is simply install a regular SEP client to each Parent server (will replace Parent server), then configure the new SEP clients via the SEPM console, to become GUPs.
  • Configure the Symantec Endpoint Protection clients at the remote sites to only bypass the Group Update Provider if it is unavailable (not reachable) for a period of 3 days.
  • For remote sites with less than 10 machines, it may make most sense to have the local SEP clients connect directly to their SEPM for content updates or to Symantec Liveupdate on the internet.
  • When there are over 50 machines at the remote site, ensure to run the GUP on an always-on machine running a Server OS (such as a local Windows file server).
  • For a remote site with more than 10,000 endpoints, you may also consider an additional SEPM site (with replication or load-balancing).

3. Change the number of content revisions stored by the SEPM database to at least 10.

  • This allows SEP clients which are out-of-date by approximately 3-4 days to still get incremental content updates.
  • It is not uncommon to set the content revisions to as high as 42 (this covers approximately 2 weeks for incremental content updates).

    Note: Increasing the number of content revisions for the Symantec Endpoint Protection Manager will increase disk space usage in the SEPM install directory by approximately 6GB per 10 content revisions stored. 42 Content Revisions would use about 21GB of storage space on the drive where SEPM is installed to store updates.

4. Minimize the number of SEPM sites and replication that will be implemented. A single SEPM site should be sufficient for most environments with less than 25,000 machines

When should you consider multiple SEPM sites and replication:

  • Endpoints are dispersed across different regions and each region must have local SEPM console access. If the WAN link between the regional site(s) and the central site goes down, local teams can still access a local SEPM console at each region.
  • If a regional site contains over 10,000 endpoints, a SEPM site (SEPM and database) may be more suitable than utilizing the Group Update Provider functionality. The other alternative is to set up a LUA 2.x distribution center.
  • If you will implement replication:
    • Minimize the number of sites you will replicate between (consider whether using the Group Update Provider functionality would make more sense at any of these sites)
        Note: Best practice is to keep the number of replicated sites below 5, and it is strongly recommended to not go over 10 replicated sites.
    • Do not replicate content and client packages. Best practice is to have each SEPM site retrieve its content updates from Symantec Liveupdate on the Internet.
    • Where possible, if replicating logging data, ensure this occurs in only one direction (e.g. 3 regional SEPM sites forwarding logging on one way to central SEPM site).
    • Do not replicate more frequently than once per hour.
    • If more than 3 SEPM sites are replicating, no more frequently than once per day is recommended (with the scheduled replication times during the day selected so they don’t overlap with either another site replication or a scheduled Liveupdate session).

5. For large environments (1000+ endpoints), configure the communication settings of managed SEP clients to a minimum of a 30 minute (preferably 1 hour) heartbeat in PULL mode

  • This provides a good balance between the length of time it takes client data to reach the SEPM and the amount of network traffic that is generated to and from SEP clients
  • Keep the download randomization enabled and increase it from the default of 5 minutes. This default is suitable for small environments. Larger environments should increase this relative to bandwidth available and size of deployment.
      Note: A single content revision averages 1-2 MB. Multiply this by the number of clients for an approximate figure of the bandwidth required for definition updates. Clients that are offline for an extended period may require 3 content revisions for each day they are off.

6. For very large environments (10,000+ endpoints), use a MS-SQL database and deploy at least 2 SEPMs for each SEPM site, configuring them as load-balancing partners.

  • This will ensure that if one SEPM goes offline, the other can manage the SEP clients.
  • Regular database backups should be mandatory and, if you want the database to not be a potential single point of failure, you can implement clustering with 2 database (MS-SQL) machines.
  • Embedded database is not recommended for sites over 5,000 endpoints.

7. If utilizing MS-SQL for the database, ensure the database machine is on the same LAN as the SEPM or at least they can communicate at LAN link speed and quality

8. Do not deploy isolated SEPMs (no local database) on remote sites, which connect across a WAN to a SEPM database machine which resides at a central (separate) site.

9. If utilizing MS-SQL for the SEPM database, it is preferable to run this on a physical machine (as opposed to a virtual machine).

  • This will ensure less chance of Disk I/O and other resource bottlenecks

10. For more than a total of 5,000 endpoints, it is recommended to use MS-SQL for the SEPM database


Legacy ID


Article URL

Terms of use for this information are found in Legal Notices