From the PerformanceGuard web interface's list of existing agent configuration groups (ADMINISTRATION > Agent Configuration > Configurations) you can edit individual agent configuration groups.
Settings are split across three tabs: (Agent configuration, Application Pings and Advanced). Each tab is described in the following:

Agent Configuration

The Agent configuration tab contains many options for editing the selected agent configuration group, so the options are grouped into several sections:

Process Report

• Enable Process and Dynamic Machine Reports: If selected, collected reports are automatically sent to the PerformanceGuard server.

  

  This setting must be enabled for the other Process Report settings to work.

• Sampling interval in seconds: The frequency with which process and system counters are sampled. If you change this, make sure that you enter an integer; you can't specify a decimal value.

  Make sure that your PerformanceGuard system's report interval (that is the frequency with which agents store and aggregate data, see Aggregation of Data) is dividable by the sampling interval. This way you'll get an equal amount of samples per report interval. You can view your system's report interval by selecting ADMINISTRATION > Setup > Parameters and then selecting the Status tab).

• Report % CPU usage higher than: Only processes with a higher CPU usage than the specified value will be included in the process data report.

• CPU usage top ? list: Only the CPU usage top (entered value) number of processes will be included in the process data report. 

  Example: If you enter 10, you'll get a top 10 list. If you enter a value of zero, the Report % CPU usage higher than value (see the previous) will be used. If you enter a value that's higher than zero, then at least the specified number of processes will be shown together with all processes that match the Report % CPU usage higher than value.

• Memory usage top ? list: Specifies how many processes, ordered by amount of memory allocated, that'll be included in the process data report. If you enter a value of zero (that is no memory allocated), no processes will be selected.
• IO usage top ? list: Specifies how many processes, sorted by amount of memory allocated, that'll be included in the process data report. If you enter a value of zero (that is no memory allocated), no processes will be selected based on their input/output usage.

• List of Observed Processes: If required, enter the names of executables that you want to make sure that the agent always reports process information about.

  Example: If you enter winword.exe, the agent will report all occurrences of Microsoft Word. You can specify multiple executables by using spaces or commas to separate their names. The .exe extension after a process name is optional. Examples: winword.exe,OUTLOOK.exe winword,OUTLOOK winword OUTLOOK.exe

  Listed processes will be included in the process data report even if they use less CPU than specified in the Report % CPU usage higher than field (see description in the previous).

• Enable Disk I/O reports: Lets you control whether you want collection of Input/Output data for the system on which the agent is installed. Note that I/O data collection for individual processes will be performed even if you disable this setting.
• Enable Server Performance Counters: If selected, the agent will collect and send statistics about the number of context switches performed on the computer as a whole. The agent will also collect and send Input/Output statistics regarding the network interface card.

What's a context switch?  A context switch is the process of storing and restoring the state of a process so that execution can be resumed from the same point at a later time. Simply put, if a computer has a lot of context switches, it needs to remember a lot of states, and that can affect its performance negatively.

• Enable process based context switch measurement: If selected, the agent will collect and send context switches (see the previous) for individual processes. This setting may be enabled independently of the Enable Server Performance Counters setting (see the previous).

  This measurement may increase the agent's CPU load significantly.

• Utilization Index Interval: If selected, the agent will start measuring the utilization index CPU/Memory/Harddisk/Network parameters if the value is different from zero. The value defines the measuring interval in seconds (the value can't be lower than the report interval).

Startup and Login Reporting

These settings play important roles in startup and login time measurement. See also Startup and Login Measurement Facts.

1. Enable Startup and Login Reports: Enables reporting on startup and login events.
2. Enable Detailed Startup Report: Controls whether a detailed startup report (that is one that includes process details) will be generated.
3. Startup Condition: When this condition is met, the operating systems startup measurement is stopped. In other words, you can use this setting to specify exactly when you consider a computer to be started.
4. Startup Timeout in seconds: When this number of seconds has elapsed, PerformanceGuard will stop looking for the startup condition. The value also controls the point in time where the detailed startup report is collected.
5. Login Start Condition: When this condition is met, the login measurement is started.
6. Login End Condition: When this condition is met, the login measurement is stopped.

For details about how to set up the Startup, Login Start and Login End conditions, see Startup/Login Condition Expression Syntax.

Network Report

1. Enable IE Reports: Enables automatic sending of Internet Explorer web page response time reports.

If you don't get any Internet Explorer response time data even though this setting is enabled, it could be due to an incompatibility with Internet Explorer. You can solve the incompatibility by changing a single setting in Internet Explorer. See Transaction Filters Don't Work.

1. Enable TCP Reports: Enables automatic sending of TCP response time data reports.
2. Enable UDP Reports: Enables automatic sending of UDP data reports.
3. Enable Multicast UDP Reports: Enables automatic sending of reports about multicast UDP traffic.
4. Enable Advanced TCP Client Socket Reports: Enables automatic sending of TCP client socket data reports.
5. Enable Advanced TCP Server Socket Reports: Enables automatic sending of TCP server socket data reports.
6. Servers for Advanced TCP: Lets you limit advanced TCP server socket data reports so that they're only sent for the specified computers.

If we look at the illustration, you're able to control which of the computers in the gray area that are included in the advanced TCP server socket measurements (click thumbnail to view image in full size):

If we look at the illustration, you're able to control which of the computers in the gray area that are included in the advanced TCP server socket measurements:

You can specify a single computer, a single named host, all computers in a network, or a combination thereof (separated by commas or spaces).
Examples:Single computer: 10.10.110.14Single named host: www.host.comAll computers in a network: 10.10.110.0/24Combination (comma-separated): 10.10.110.0/24,www.host.comCombination (space-separated): 10.10.110.0/24 www.host.com

1. Advanced TCP Reports AdvancedTCPStatInterval: Sampling interval—in seconds—for advanced TCP activity. That is the frequency with which advanced TCP data are sampled. With this setting you can control the granularity of the collected data.

The shorter a sampling interval you specify, the more work the agent will have to do. This can lead to increased resource consumption on the computer that has the agent installed.

1. Enable Protocol Transaction: Enables agent collection of protocol transaction information. See Protocol Transactions in the Technical Reference section for a description of the concept.See the Technical Reference Manual for a description of the concept. When you enable this, protocol transaction information will be selectable as a type of data to view on the IP traffic time view graphs.
2. Automatically discover local TCP server ports: If you enable this setting, the agent will automatically exclude all local ports from the network report.
3. Berkeley Packet Filter Expression: Lets you specify exactly what agents should monitor. You typically use packet filters to tell agents to only monitor packets to and from specific hosts. This way you can limit the scope of your agents, so that they only monitor traffic to and from particular servers. If you don't use a packet filter, agents will basically monitor any packet. Using a packet filter can thus be an excellent way to avoid collecting unnecessary data. See Packet Filter in the Technical Reference section for details about Berkeley packet filter syntax.See the Technical Reference Manual for a description of the concept.
4. List of Excluded local TCP ports list: Comma-separated list of local TCP ports that should be excluded from the network report.

To quickly specify a range of ports, write the range. Example: 2401-2405. This also applies for the following UDP port lists.

1. List of Excluded local UDP ports list: Comma-separated list of local UDP ports that should be excluded from the network report.
2. List of Included Remote UDP ports list: Comma-separated list of remote UDP ports that should be included in the network report. If the list is empty, all remote UDP ports are included.
3. List of Excluded network adapters: Comma-separated list of network adapters that the agent should not connect to. The ability to exclude some network adapters can be useful because some network adapters have incompletely implemented NDIS (Network Driver Interface Specification) layers that can result in unwanted behavior.

Citrix Report

1. Enable Citrix Reports: If this setting is enabled, the agent will collect Citrix performance data and send it to PerformanceGuard. This setting has no effect if the configured agent isn't installed on a Citrix server.
2. Sampling interval in seconds: Specifies how often the agent will collect Citrix performance data.
3. Allow test of Citrix WFica.ocx If this setting is enabled, PerformanceGuard will test if the Citrix WFIca component can be used to make Citrix login measurements.

This setting must be enabled if you wish to perform Citrix login measurements.

User Interface

These settings control if agent-related options will be available in the operating system taskbar on computers that have the agent installed.

1. Enable Task Bar Icon: If this setting is enabled, a small PerformanceGuard agent icon (or in newer agent versions) will be shown in the taskbar notification area (also known as the system tray) of computers with running agents.

The icon is by default not shown. This is based on the assumption that you don't necessarily want your end users to be able to view the status and/or details of their agents.

1. Enable Exit Menu Item: If the agent taskbar icon (see the previous) is enabled, this setting controls if the taskbar icon's context menu will contain an Exit command. When that's the case, users can select Exit to hide the taskbar icon. Exit will thus not stop the agent.
2. Enable Send Report Menu Item: If the agent taskbar icon (see the previous) is enabled, this setting controls if the taskbar icon's context menu will contain a Send Report command. When that's the case, users can select Send Report to force the agent to send collected performance data to PerformanceGuard.

Agent Service Parameters

These settings control the communication capabilities of the agent, including its built-in Telnet server.

1. Socket Timeout (ms): This setting controls the timeout used for the communication between the agent and the server. The value must be 5000 or above. If you specify a value less than 5000, a value of 5000 will be used.

The value of this setting may be overruled by a local Windows registry value for individual agents. See Agent Registry Keys in the Technical Reference section for details about such registry keys and their default values.See the Technical Reference Manual for descriptions of registry keys and their default values.

1. List of allowed telnet clients: A specification of the hosts and networks that are allowed to access the Telnet server. If the list is blank, the agent won't start its Telnet server. This list must be a comma-separated list of IP addresses, hostnames and networks. A network is specified as <IP-address>/<net-mask-length>, for example 192.168.1.0/24.
2. Telnet TCP port: The TCP port that the agent's Telnet server will make itself available on. If this setting is blank, the agent will attempt to run the Telnet service on TCP port 4003.
3. List of allowed web clients: See List of allowed telnet clients in the previous.
4. Web Server TCP port: The TCP port that the agent's web server will make itself available on. If this parameter is blank, the agent will attempt to run the HTTP service on TCP port 4007.
5. Agent Service Restart Configuration: This setting is used to make the PerformanceGuard Agent service restart automatically. It has the following syntax (BNF):

List ::= ([<Day>] <Time>*)*Time ::= <hour> [':'<min>]Hour ::= integerMin ::= integerDay ::= 'sun' | 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat'
All times are local times on the computer that has the agent installed.
<span style="color: #003366"><strong>Example:</strong></span> <span style="color: #003366"><em>02:30 wed 05:00 sat 05:00</em> would restart the agent service every day at 02:30 and also restart it at 05:00 on Wednesdays and Saturdays.</span>

Error Handling

1. Minimum severity level of error reports that are sent: Lets you prevent irrelevant error reports by specifying a minimum severity level that such reports must contain before they are sent. Errors generated by agents are in the ranges:

   1. Informational: [0-10]

   2. Minor error: 128
   3. Severe error: 129
   4. Blocking error: 130

Example: If you specify a value of 11, error reports won't be generated by informational events because informational events have severities from 0-10.

1. Include details in error reports: If this setting is enabled, complete error information will be included in error reports.

Filters

Any transaction filters that you have defined can be selected. Selected transaction filters will be appended to the agent configuration and distributed to agents that are members of the agent configuration group in question.

1. lets you edit the transaction filter definition.
2. (in the right side of the Filters section) lets you view all of your existing transaction filters and their configurations (which you can edit if required).

Custom Counter Templates

If you want your agents to collect data from Windows performance counters, you can create custom counter templates and append them to the agent configuration group. PerformanceGuard even features a small utility that helps you quickly create custom counters with the right syntax. See Custom Counter Templates: Collect Data from Any Windows Performance Counter.

Application Pings

If you have defined application pings (that is traceroutes as well as pings), you can select them on the Application Pings tab. Selected application pings will be appended to the agent configuration and distributed to agents that are members of the agent configuration group in question.

1. lets you edit the application ping.

Advanced

On the Advanced tab you are able to control the periods (also known as keep periods) for which PerformanceGuard will keep different types of agent data, such as:

1. Agent process lists
2. Individual resource data, that is the local performance metrics and the detailed response time data for each agent
3. Performance data for individual processes running on the computer that has an agent installed
4. Traffic data for each agent
5. Utilization index data for each agent

Values are defined in minutes.
A value of 10080 minutes equals one week. 5040 minutes equals 3,5 days. 1440 minutes equals one day.

Overlap with General Setup Parameters

The advanced agent configuration group settings overlap with some of the more general PerformanceGuard setup parameters (ADMINISTRATION > Setup > Parameters > Status tab). If the value of such a parameter in the agent configuration group settings isn't the same as on the Status tab, PerformanceGuard will always use the highest value.
These are the parameters that overlap:

See also Database Retention Periods
How do I limit my agents so that they only monitor traffic to and from selected servers?  Use a Berkeley Packet Filter. See Agent Configuration > Network Report in the previous.

Startup/Login Condition Expression Syntax

The startup and login timing conditions are configured using condition expressions.
You can only do this if you're a PerformanceGuard administrator.
Conditions are used for the following agent configuration parameters:

1. StartupCondition controls when the computer startup measurement ends
2. LoginStartCondition controls when the user login measurement starts
3. LoginEndCondition controls when the user login measurement ends

Timing of computer startup is controlled by measuring the time between the moment when the first parts of the operating system start and the moment when the expression StartupCondition becomes true.
The login time is the period between the moment when the LoginStartCondition becomes true until the moment when LoginEndCondition becomes true.
A condition expression consists of condition terms combined with logical operators. Supported logical operators are:

1. and
2. or
3. not

You can use parenthesis (...) to control the order of evaluation.
The following types of condition terms are available:

1. Winversion
2. Process
3. Service
4. Session

Condition terms are not case sensitive.
Condition terms are enclosed in brackets <...>.
Example: ( (<Winversion; WIN7> or <WINVERSION; WIN2008R2>) and <PROCESS; wdm; started>) or ( (<WINVERSION; VISTA> or <WINVERSION; WIN2008>) and <PROCESS; explorer; started> )  
This expression becomes true when wdm.exe starts on a Windows 7 or on Windows Server 2008 R2, but on Windows Vista or on Windows 2008 it becomes true when the explorer process starts.
Condition Term Overview

When specified <process name>s are compared to running processes, extensions are removed and comparison is case-insensitive. This means that it's optional whether you want to specify, for example, the .exe extension.
Winversion Condition Terms
Winversion terms are used to make a single condition behave differently depending on the operating system on the target computer. This way you can deploy a single condition expression throughout an entire organization, even if different Windows versions are used.
The term is always true on a computer that runs the specified Windows version.
Process, CPU, MEM and IO Condition Terms
The process condition terms take a number of different forms. You can use a term may be used to check if a named process has been started or stopped, or you can use it to check the CPU, memory or I/O usage of a named process
If multiple instances of the specified process are running, the term will be attached to all instances. For example, <CPU, svchost; above; 10> will become true if any of the running instances use more than 10% CPU.
Service Condition Terms
The service condition term is used to check if a particular service is running.
The term <SERVICE; svchost; STARTED; EventSystem> becomes true when the EventService service is registered as started with the Service Control Manager within svchost. Note that the names of services may be different depending on the locale of the operating system. The name that you supply for the service is checked by comparing it with the service names registered for the given process. If the specified name appears as part of the name, the term evaluates to true. If you specify TCP as the service name, it will match any service that contains TCP in its name.
Session Condition Terms
The session condition terms change values when user sessions change state, that is when users log in or log out, or when they connect to or disconnect from a session. When sessions are locked or unlocked, sessions also change state. Session condition terms that become true when a user logs in are:

1. <SESSION; connect>: A session was connected to the console terminal.
2. <SESSION; logon>: A user has logged in to the session.
3. <SESSION; lock>: A session has been locked.

Label Expressions
When specifying expressions for the login start and stop expressions, PerformanceGuard will by default generate labeled values. This is used to ensure that PerformanceGuard is able to handle asynchronous logins correctly. Multiple asynchronous logins can be an issue on multi-user Windows computers, typically servers running as application servers or XenServers (Citrix).
Expression labeling is supported for the session, process and CPU, MEM and IO conditions.

If required, you can disable labeling for a term by appending [-].

Examples:

1. <SESSION; connect[-]>

2. <SESSION; logon[-]>

3. <SESSION; lock[-]>

4. <PROCESS; guardagent[-]; started>

5. <PROCESS; winlogon[-]; stopped>

6. <CPU; guardagent[-]; above; 10>

7. <MEM; explorer[-]; above; 10>

8. <IO; explorer[-]; below; 10>

When labeled expressions are used, PerformanceGuard will be able to distinguish between events generated by different users, and match labels in the start and end conditions correctly. It's perfectly fine to mix labeled and unlabeled expressions. In such cases an unlabeled expression will be treated as if it was generated simultaneously by all possible labels.
BNF for Temporal Condition Terms
condition-term ::= metric-condition | process-condition | version-condition | service-condition

metric-condition ::= '<' metric ';' process ';' operatorspec '>'process-condition ::= '<' 'PROCESS' ';' process ';' operatorp '>'service-condition ::= '<' 'SERVICE' ';' process ';' 'started' ';' service-name '>'session-condition ::= '<' 'SESSION' ';' session-con-event [-'] '>'version-condition ::= '<' 'WINVERSION' ';' versionid '>'

operatorspec ::= complexop complexop ::= operatorc ';' threshold metric ::= 'CPU' | 'MEM' | 'IO' versionid ::= 'vista' | 'xp' | 'win2003' | 'win2008' | 'win2008R2' | 'win7' operatorp ::= 'started' | 'stopped'

operatorc ::= 'below' | 'above' threshold ::= integer ['%']session-con-event ::= 'connect' | 'disconnect'session-con-location ::= 'console' | 'remote'session-log-event ::= 'logon' | 'logoff' | 'lock' | 'unlock'process ::= identifier [ '[-]'] service-name ::= identifier

identifier ::= alfa [alfa-digit]*alfa ::= 'a' |'b' ... 'z' | 'A' | 'B' ... 'Z' | '_' | '.' | '-'alfa-digit ::= alfa | digitinteger ::= [digit]float ::= [digit] '.' [digit]*digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'