Best practices for installing Symantec Endpoint Protection Manager (SEPM) to a VMware image or wedge, with recommendations for memory, CPU, and hard drive performance settings.
Symantec Endpoint Protection Manager can be I/O intensive, and subject to random spikes of heavy resource usages when dealing with clients, HTTP traffic, and disk I/O transactions.
As a result, a minimally designed VMware may suffer performance issues, and fall behind in logs or requests for content, policies, and definitions. Therefore, Symantec strongly recommends the following settings as a functional minimum set of system requirements:
The VMware image should be static in its MAC address and IP address.
The VMware image should not be compressed or use compression in the hosted OS.
The VMware image should have access to a full Gigabit network interface card.
The Vmware image should not be subject to vmware live migration.
The minimum settings for a VMware image in a small environment (1-5,000 endpoints) should be as follows (in the Resources tab):
2 CPU cores minimum at all times
The cores should be set to a minimum speed of 2GHz and a maximum of infinity.
Memory allocation should be set to 4 GB minimum at all times for the SEPM alone. Count the SQL server separately.
The SQL database should not reside in the same ESX cluster for better I/O handling.
Drive space for the image should be 150 GB based on content retention policies.
For larger or transactionally noisier environments, you may need to increase the minimum settings significantly. This helps ensure that the SEPM does not fall behind in log processing and definitions processing, which could lead to the SEPM stalling or preventing you from logging in locally or through the Remote Management interface.
Since every VM\hyper-v drive cluster and hardware cluster varies along with work load types, Symantec cannot explicitly predict or define a hardware level that is sufficient for your environment. Therefore, Symantec strongly recommends over-engineering the virtual devices, and then trimming down individual facets until you have a balance between performance and reliably.
An example baseline for a medium deployment (5,000-10,000 endpoints):
4 dedicated CPU cores with 2 GHz minimum speed
8 gigabytes of RAM + 8 gigabytes of pagefile space
300 gigabytes of disk storage strictly for the SEPM
If the listed specs do not sufficiently keep up with high demand or load situations, tune the VMware to have more resources: first, increase the system RAM, and then increase the CPU core count.
If you find that the SEPM is not able to keep up with sustained load, even with large amounts of CPU cores (8 or more) and RAM (16 GB or more), you may need to increase the availability of more disk I/O operations per second. Or, see if there is another application on the computer or RAID cluster that is consuming too many IOPS (input/output operations per second) to allow the SEPM to work properly.
SEPM SQL database considerations
By default, several tables within the SEPM database are capable of auto-growing to prevent stalling of definition publishing. Allow the SEPM to install and create the database if your security policies permit. If your security policies do not allow for automatic database creation by third party applications, manual database creation is another option for automatic table growth.
Other considerations and reducing load to extend reliability
With the SEPM being a heavy I/O and memory intensive application to host in VMware, there are other things that you can do to help improve reliability under extended high load situations (such as a virus outbreak or mass migration).
Contact your support team at Symantec and discuss what log types (from clients) and reports you actually need to store in the database. Reduce the amount of things stored in the database to reduce traffic to the VMware image. This reduces the total I/O load and allows the SEPM to be more responsive in a extended high load situation.
Reduce data retention times of logs, reports, and content to help reduce the overall size of the database. This should decrease the time required to generate a report in the interface.
Evaluate and better manage the definition revision count. Review with your Symantec support team the number of definition revisions you keep. By properly setting the definition count and retention, you can better manage the amount and flow of definitions from your SEPM. By setting a lower value, you can have situations where clients request full updates when a micro update could be possible. Keeping too many may consume large amounts of space on the IIS directory structure and in the SEPM database (SQL).
Set up Group Update Providers (GUP). By setting up group update providers, you will have the second most significant impact on SEPM performance in a VMware environment. Instead of having all clients update from their respective manager, have a GUP update from the SEPM, then have the remaining clients update from the GUP. This will dramatically reduce the amount of I/O on the SEPM, reduce load from SEPM to SQL, reduce the load from the client to the SEPM, and reduce HTTP traffic to the SEPM. With this setup, the I/O and HTTP traffic load of updating definitions can be spread to a larger base, and enhance SEPM performance and longevity in a VMware environment.
Set up an internal LiveUpdate server. Similar but not the same as a GUP, use a LiveUpdate Administrator to update clients, instead of the clients updating from the SEPM. This reduces HTTP traffic to the SEPM to check in for updated definitions, and reduces the I/O of the SEPM having to create and store definitions. Additionally, it reduces traffic from the SEPM to the SQL database to mirror the definitions, and reduces the size of the SQL database.
Isolate high I/O processes. For processes that use large amounts of I/O resources (i.e., SEPM database backup, Reporting, and Notification), consider using a VM on a separate physical computer. For Reporting and Notification, set the server as the first server in Site properties, so that clients requesting processing are not affected by notification tasks.
Lower the priority of replication servers in management server lists. By doing this, replication servers can process fewer client requests and focus on replication. If a site only has a few servers, the LiveUpdate, backup, reporting, notification, and replication servers can share the same VM image server.
These steps help ensure optimal SEPM performance within a virtual environment. While not as responsive as a true hardware device, this keeps the SEPM healthy in long term virtual usage.
CAUTION: With the SEPM being I/O intensive, also consider the I/O needs of other VM systems—such as mail servers or database servers—on the host OS. Installing such applications along with the SEPM can result in I/O bottlenecks in either drive channels or networking.
Imported Document ID: TECH132456
Subscribing will provide email updates when this Article is updated. Login is required.