1. Ensure all SEP clients and SEPMs are running a minimum of Maintenance Release 4 To take advantage of the latest enhancements, optimisations and fixes added to the product. 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 can also consider if an additional SEPM site (with replication) or a local LiveUpdate Administrator 2.x distribution center is more appropriate. 3. Change the number of content revisions stored by the SEPM database to at least 42 This allows SEP clients which are out of date by approximately 2 weeks to still get 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 3 GB per 10 content revisions stored. 42 Content Revisions would use about 10-12 GB of storage space on the drive where SEPM is installed to store updates. 4. Minimise 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 you should consider multiple SEPM sites and replication between them: If 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 utilising the Group Update Provider functionality. The other alternative is to set up a LUA 2.x distribution center. If you will implement replication: Minimise 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 ideally below 5, and it is strongly recommended to not go over 20 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. Configure the communication settings of managed SEP clients to a minimum of a 30 minute (preferrably 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 Leave the download randomisation enabled and set to the default of 5 minutes. This is suitable for most environments. 6. If utilising MS-SQL for the database, deploy a minimum of 2 SEPMs for each SEPM site, and configure the clients to load-balance between the SEPMs. 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. If you are using the Embedded Database, you can achieve a similar level of fault tolerance by setting up a 2nd SEPM site (on another single machine) with the Embedded Database, then replicate between the sites on daily basis. 7. If utilising 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 utilising 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 5000 endpoints, it is recommended to use MS-SQL for the SEPM database (Source = http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009012721190648)