The Windows agent regularly communicates with both its managed endpoints and Core Services. When the agent manages a large number of endpoints by proxy, the agent consumes valuable resources on the computer. The size of reports and how frequently you run them also affects agent performance. This section provides tips for optimizing the Windows agent performance to reduce CPU usage and ensure accurate report results.
As a best practice, the Windows agent should manage endpoints with operating systems similar to the agent computer’s operating system. As Microsoft improves operating system capabilities, older versions might not have the same features as newer versions. For example, Windows Server 2008 R2 might not have the same advanced Audit settings as Windows Server 2012 R2. If you use a Windows Server 2008 R2 agent to monitor a Windows Server 2012 R2 endpoint, the agent might not report the audit settings accurately. In general, an agent can manage endpoints with older Windows operating system than the agent computer’s operating system.
To optimize agent performance, assign endpoints to agents according to the following table.
|
Agent Computer |
Endpoint Managed by Proxy |
|---|---|
|
Windows Server 2019 |
|
|
Windows Server 2016 |
|
|
Windows Server 2012 R2 |
|
|
Windows Server 2008 R2 |
|
|
Windows 10 |
|
|
Windows 8.1 |
|
|
Windows 7 |
Windows 7 |
For optimal agent performance, limit the number of endpoints in a domain that a single agent manages. A ratio of 50 endpoints to one Windows agent works well in most environments. Agent performance might vary depending on processor speeds, memory, locations, and network bandwidth on the agent and endpoint computers.
You can manage the CPU resources the Windows agent requires by adjusting settings in Secure Configuration Manager and on the agent computer. Review the following methods for optimizing the Windows agent.
When Core Services asks a Windows agent to run a policy template, the agent processes the template for each endpoint the agent manages. If the agent manages 50 endpoints, it is the same as Core Services submitting 50 templates to the agent. The agent then processes the 50 policy templates multiplied by the number of security checks within the template. For example, if the template contains 100 security checks, the agent processes 5,000 checks (50 endpoints x 100 checks). Also, some security checks require more processing time than others. For example, a security check querying a registry value can process more quickly than a check looking at the entitlement for a directory with a large number of files.
By default, the Windows agent must process all policy template queries and respond to Core Services within a two-hour window. If you regularly run large policy templates against a large number of endpoints, you can reduce the likelihood of delays or canceled policy template runs. In the Windows console for Secure Configuration Manager, schedule the date and time for regular policy template runs to occur when the Windows agent computer is least active.
You can modify the number of threads the Windows agent and any installed agent components use. If the agent or component consumes too much CPU when processing policy templates, particularly for a large number of endpoints, you might consider increasing the thread count. NetIQ recommends synchronizing the thread counts for the agent and the component to ensure that they have equal processing capability. If you plan to adjust the Windows thread count, you should make the agent thread count match the value selected for the Windows component.
To modify thread counts:
Modify the thread count in the SCM GUI:
Go to IT Assets > Agents > OS > Windows.
All the endpoints running on the Windows agent are displayed.
Right-click the endpoint for which you want to modify the thread count, and then select Properties.
Agent Component Properties window is displayed.
Modify the value of the Maximum Concurrent Requests field. Default value is 5.
Click OK.
Modify the thread count value in the registry keys files:
Open the registry editor using the following command:
regedit
Go to the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NetIQ\VigilEnt\providers\windows registry.
Modify the value of the threadPoolSize field.
Restart the Windows agent.
The Heartbeat Automatic Polling feature in Secure Configuration Manager ensures Core Services knows whether an agent and its endpoints are active. By default, Core Services sends a heartbeat request every 60 minutes. The agent then forwards the request to all its endpoints to determine their status. If the agent monitors a large number of endpoints, the heartbeat queries can add to the already considerable number of tasks the agent performs at any given moment. For example, the agent might be processing a high volume of queries for a policy template.
To mitigate the number of tasks the agent must perform, you can increase the interval between heartbeat requests. For more information about configuring the Automatic Polling Interval, see the Help for the Core Services Configuration Utility.
Enable Remote Administration and Windows Remote Management in the Windows firewall settings on all endpoints for inbound and outbound communication. Typically, firewall settings do not include exceptions for the proxy agent, which blocks the agent from gathering data and might cause security checks to report endpoints as Offline. Enabling Remote Administration and Windows Remote Management in the firewall settings for endpoints ensures more accurate security check reporting of your endpoints.