As of May 14, 2024, Knowledge Base (KB) articles will only be published and updated in our new Trellix Thrive Knowledge space.
Log in to the Thrive Portal using your OKTA credentials and start searching the new space. Legacy KB IDs are indexed and you will be able to find them easily just by typing the legacy KB ID.
Best practices for performance and stability of your ePolicy Orchestrator environment
Technical Articles ID:
KB90961
Last Modified: 2022-05-11 10:06:35 Etc/GMT
Environment
ePolicy Orchestrator (ePO) 10.x, 5.9.x
Summary
The following best practices are broken down into three groups.
Contents:
Click to expand the section you want to view:
Scalability
The number of systems that your ePO server manages dictates the number and size of the additional Agent Handlers and repositories needed. We recommend one Agent Handler for every 50,000 systems.
For environments managing more than 10,000 nodes, installing ePO and SQL on physical systems is recommended for best performance. The main limitation is the SQL Server performance, specifically disk performance. (IOPS - 10 per second). As the node count increases, you might experience slower disk performance. See the Recommendations for ePO deployment on Virtual Platforms Installation Guide.
To install the ePO server on a virtual machine (VM) and solve this disk performance problem, you must perform the following actions:
Dedicate physical disks to the ePO server in the VM.
Assign priority for the CPUs to the ePO server.
Sizing Recommendations:
Fewer than 10,000 managed systems — You can install the PO server and SQL database on the same physical server or VM. You can use the Microsoft SQL Express database if you have fewer than 1,500 managed systems.
10,000–25,000 managed systems — Install ePO and SQL servers onto separate servers.
25,000–75,000 managed systems — Install ePO, an Agent Handler, and distributed repositories, and a separate physical SQL Server.
75,000–150,000+ managed systems — Install ePO server, a separate physical SQL Server, three Agent Handlers, and properly placed distributed repositories.
System Requirements
The number of managed systems also dictates the recommended server sizing needed to manage these systems."
NOTE: The requirements detailed in the documentation are the minimum requirements. But, your ePO (or SQL) server might need to be more powerful than these requirements. It depends on environment size and complexity or the number of products installed and managed. We recommend that you exceed the minimum recommendations wherever possible.
ePO Server CPU
Node Count
CPU Cores
<10,000
4
10,000–25,000
4
25,000–75,000
8
75,000–150,000
8
150,000+ 16
16
ePO Server Memory
Add 16 GB of RAM for every 25,000 nodes.
The Java Virtual Machine (JVM) runs the ePO Application Server. The JVM represents the set of memory that the ePO Application Server can use. The metrics describe both the heap (runtime objects) and non-heap (metadata and local method objects) utilization.
NOTE: After adding more RAM to ePO, look at the JVM allocation and make adjustments as needed to increase the JVM allocation. The JVM memory setting is in the Windows registry: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2. 0\MCAFEETOMCATSRV530\Parameters\Java\JvmMx.
SQL Server
The SQL database, where the ePO server data is stored, and the SQL Server determines the performance of your ePO server. This database is the main workhorse behind the ePO server. The three items that affect SQL performance are CPU, RAM, and disk performance. These three items control the responsiveness of the ePO server from an SQL perspective. We recommend that you exceed the minimum recommendations wherever possible.
Don't install the ePO server SQL database on a shared SQL Server if you're managing more than 25,000 nodes. The ePO server is expected to perform thousands of SQL database disk reads and writes every few seconds. As a result, performance can be negatively impacted on an overused SQL Server.
You can share your existing fully clustered, redundant, and centrally managed SQL environment if the criteria below are met:
The shared SQL Server isn't already overused.
Your ePO server manages fewer than 25,000 nodes.
Other SQL database functions don't cause spikes that can slow the ePO server SQL database reads and writes.
If an AV solution, such as VSE or ENS, is installed on the SQL Server hosting the ePO database, make sure to apply the AV exclusions needed. These exclusions prevent potential performance loss while scanning. Set these exclusions for both on-access scans and any scheduled on-demand scans.
Distributed Repositories
Distributed repositories work as file shares that store and distribute security content for your managed client systems; use them to help take load off the ePO server itself. The ePO server always acts as the Master Repository. It keeps the primary copy of all content needed by your agents and ePO, and replicates content to each of the repositories throughout your environment. As a result, your agents can retrieve updated content from an alternate and closer source.
SuperAgent repository type is the most efficient type of distributed repository because it can be configured to use LazyCaching. The Lazy Caching feature allows SuperAgents to retrieve data from the ePO server only when requested by a local agent node. Creating a hierarchy of SuperAgents with lazy caching further saves bandwidth and minimizes the wide-area network traffic.
Typically, you can create a repository for each large geographic location. But, you must avoid having too many or too few repositories and overloading your network bandwidth.
It's not advisable to add a distributed repository on an Agent Handler. The Agent Handler already caches a copy of the Master Repository content. If a managed agent contacts the Agent Handler for software packages, the Agent Handler retrieves the package from the ePO server Master Repository.
System Tree Management
When possible, use Active Directory (AD) to synchronize the System Tree. This feature helps make sure that all systems in your domain are brought under ePO management. Within the AD sync settings, you can choose to configure Agent deployment to the system discovered during the sync.
This feature works as long as you have a well-maintained AD structure. If not, you end up with excessive unmanaged systems or placeholders in your System Tree. These unmanaged systems or placeholders are ones that have been imported from your AD server but have never received a McAfee Agent (MA). You can filter out unmanaged systems in your reports. But it's much better to make sure that your ePO environment includes only managed systems. Delete unmanaged systems using an ePO server task regularly.
It's recommended to also add the MA to your corporate image. Adding the MA during the imaging process is a good compliance strategy. It makes sure that all new systems have an MA installed. It also helps provide maximum security coverage for all systems in your environment.
NOTE: See the product guide for the MA for your version of the Agent to install on a non-persistent virtual image, or in Virtual Desktop Infrastructure (VDI) mode.
Agent to Server Communication Interval (ASCI) guidelines
Node Count
Recommended ASCI
100–10,000
60–120 minutes
10,000–50,000
120–240 minutes
50,000+
240–360 minutes
When configuring the ASCI setting, the main consideration is to reduce the strain on the ePO server with every communication from every agent in larger environments.
For organizations with fewer than 10,000 nodes, the default ASCI setting isn't a concern at 60 minutes. But, for organizations with more than 10,000 nodes, change the default setting of 60 minutes to about 3–4 hours. For organizations with more than 60,000 nodes, the ASCI setting is much more important. If your ePO server isn't having performance issues, you can use the four-hour ASCI interval. If there are any performance issues, consider increasing your ASCI to 6 hours, and possibly even longer. This increase reduces the number of agents that simultaneously connect to the ePO server, and improves the server performance.
Database Mirroring - Server Settings
The database mirroring feature helps improve efficiency on LDAP lookups on ePO and Agent Handlers in relation to User-Based Policies. This feature works with the LDAP sync task. When the LDAP sync task runs, it pulls information from registered LDAP servers and stores it in the ePO database.
When a client is configured to use a User-Based Policy, the ePO server or Agent Handler must perform an LDAP lookup. It does so to determine the group membership of the user to see whether a user-based policy applies.
The LDAP query can take a significant amount of time to complete. So, it can drive up session times and lead to maximum connection issues on the Agent Handler. This situation is once in which database mirroring can help.
When the database mirroring feature is enabled, the Agent Handler changes LDAP queries into SQL database queries. The Agent Handler follows the same algorithm as when the database mirroring feature is disabled. But, instead of querying LDAP, it queries the database tables populated by the LDAP sync task to look up information about the users. The SQL query for the user information typically completes more quickly than the LDAP lookup.
For more information, see KB84683 - Explanation of how the ePolicy Orchestrator database mirroring feature works.
Policy and Task Retention - Server Settings
Policy and Task Retention is a fail-safe feature that can be enabled with the ePO Server Settings. Enable this feature to help preserve policy and task configuration data in the rare event that a fatal problem occurs with a specific management extension.
This feature is to be used in addition to completing the regular Recommended ePO and SQL backups:
Maintaining SQL Database
Your ePO databases require regular maintenance to promote optimal performance and protect your data. Perform these tasks regularly, either weekly or daily. These tasks aren't the only maintenance tasks available. See your SQL documentation for details about what else you can do to maintain your database.
Regularly back up the ePO SQL database and its transaction log. If the ePO server must be rebuilt or restored, current backups make sure that a safe copy is available.
Use the Simple recovery model for your database. The Simple recovery model allows SQL to manage the transaction log for you, avoiding transaction log growth. Review details in this Microsoft document.
Run Client Task Now and Task Scheduling
The Apache server has a limitation of 245 simultaneous connections. The following scenarios can contribute to maximum connections being reached on the ePO server, resulting in an outage:
Product Deployment tasks configured to run too frequently on multiple systems
Using "Run Client Task Now" on a large group of systems (more than 245)
Configuring a low ASCI for a larger environment
Configure the client task schedules in a way that doesn't overload the capacity of the systems hosting the repository content. For example, if a client task is assigned to all systems, make sure that you include sufficient randomization to vary the start time of the task across the network. Sufficient randomization avoids a denial-of-service issue on the ePO server or system hosting the distributed repository.
The Run Client Task Now feature isn't intended to be used in place of scheduled tasks for Product Deployments or Product Deployment Projects. The Run Client Task Now feature is best used for running a specific task on a single system or small group of systems at a time.
Account Management
Avoid using the global administrator account for day-to-day management of ePO.
Defining a user and assigning a permission set for each ePO administrator user improves audit logging. It also makes it easier to track which user has made a specific change.
Configure at least one other ePO global administrator account with the password stored securely to prevent lockout of ePO.
In the event the administrator password is lost, ePO Pre-Installation Auditor 2.0.0 allows you to change your ePO administrator password. You're prompted for the SQL Server database user account information to complete the password reset. For details, see KB60112 - How to reset a password in ePolicy Orchestrator 5.x.
Disable logons instead of deleting users.
In ePO, all owned objects for a user are deleted when the account is removed from ePO. The owned objects include server tasks because server tasks run in the permission context of the user that creates them. If ePO allows transfer of ownership for server tasks, the results of those server tasks can potentially differ. The reason is because the permissions of the current owner might not match the permissions of the user who created the server task. For details, see KB65775 - User accounts deleted from ePolicy Orchestrator remove the associated server tasks created by those accounts.
