Product Documentation

Managing Company Settings

Oct 16, 2015

Company settings allow you to manage the configuration of companies hosted on a Citrix EdgeSight server. All company settings are located on the Configure tab under the Company Configuration menu item.

Company settings allow you to perform the following tasks:

  • Managing User Profiles
  • Managing Company Properties
  • Managing Departments, Devices, and Groups
  • Managing User Groups
  • Managing Roles
  • Creating Users and Assigning Roles
  • Managing Access to XenApp Farms
  • Creating Alert Rules and Actions
  • Managing Application Categories and Vendors
  • Managing Reports
  • Managing IP Ranges
  • Managing Real-Time Dashboard Configurations
  • Setting Agent Properties
  • Configuring, Scheduling, and Running Workers

Managing User Profiles

Each EdgeSight Server Console user has a profile stored on the server which includes name, title, and contact information. Users can edit their own profiles. Click on My Settings > Profile to display the profile matching the username under which you logged in to the console.

You can display the profiles of other EdgeSight Server Console users on the Users page (Company Configuration > Security > Users). For more information on the creating and managing users, see "Creating Users and Assigning Roles".

Managing Company Properties

A company is the primary organizational unit on an EdgeSight Server. A single server can support multiple companies. If there are multiple companies on the server, use the Company drop-down menu at the top right hand corner of the console to switch between companies. Company settings are administered separately from server settings, allowing server administrators to control which users are authorized to display reports or change settings for a specific company. To display company settings, navigate to Company Configuration > Settings.

Time Zone and Daylight Savings Time

There is a time zone for each company on an EdgeSight Server. The time zone is used by the server when displaying times in reports, when scheduling and running maintenance jobs, and for timestamps associated with events, such as alerts and upload times. All data for a company is consolidated based on the day boundary for that time zone. This ensures greater data consistency when agent machines are in a number of different time zones. In addition to the time zone setting, you can specify whether or not to adjust times for Daylight Saving Time.

When EdgeSight is installed, an initial company must be created, including a time zone setting. The Company Settings page allows you to change the company time zone as required. When creating new companies using the console, you must specify a time zone.

Agent Registration Settings

Agent registration settings control how EdgeSight Agents make themselves known to the server. (Agents initiate communication with the server in all cases except for explicit requests for agent data, as in the case of displaying a real time report from the console.) Use the menus to enable or disable each setting, then click Save Changes to apply the new settings. Enabling all the client registration settings is recommended. Allowing EdgeSight software to handle agent registration, department creation, and duplicate instances can save you time and effort that would otherwise be spent on manually resolving these events. The following table describes how each setting affects client registration.

Registration Setting Controls...
Automatically Register Agents When an agent connects to a server, it passes Company and Department configuration information. If this information matches an existing company defined on the server and this setting is enabled, then the agent is enlisted into the company. Otherwise, the agent is an unmanaged instance and only appears on the Unmanaged Devices page. (For more information on moving unmanaged devices to a company and department, see Handling Unmanaged Devices.)
Automatically Create Departments When an agent connects to a server, it passes Company and Department information. If the Department does not exist, then it will be created if this setting is enabled. If the setting is not enabled, the device is placed in the root department for the company. (For more information on departments, see "Managing Departments, Devices, and Groups".)
Coalesce Duplicate Instances

If an EdgeSight Agent database becomes corrupt, as part of the repair process the machine will be matched up with its historical data on the server if this setting is enabled. If the feature is disabled, then there will be a duplicate record of the device in the system. You are notified of the creation of a duplicate record by a message on the Messages page similar to the following:

EdgeSight - New Instance (DUPLICATE) - Machine: 'sysname' Domain: 'domain_name'

An internal identifier (a globally unique identifier or GUID), rather than the machine name, is used to match duplicate instances.

Managing User Groups

In addition to groups of devices, you can also create groups of users. The user group capabilities of EdgeSight enable you to create collections of users by selecting users by username, IP address or IP range, or by running a SQL query against the EdgeSight database. The users can be XenApp, XenDesktop, or endpoint users. Many reports containing data on user experience can be filtered by user groups, allowing you to monitor system performance for a group of users with specific characteristics.

To manage user groups, go to Company Configuration > User Groups. User groups have the following settings: name, public/private setting and members. User groups can be public (available for use by all console users who have a role of Administrator) or private (available only to the user who created the group).

Members can be explicitly selected from a list of users (identified by user name or by IP address), selected based on a range of IP addresses, or selected based on a SQL query run against the EdgeSight database. Note that when a user group cache is updated, if the group membership is controlled by a query, the query is rerun and any new users matching the query will be added to the user group. This greatly simplifies the maintenance of query-based groups. For detailed instructions on creating user groups, see the “User Groups” topic in online help.

Managing Roles

When users are configured on a Citrix EdgeSight Server, they are assigned one or more roles. Roles define a set of permissions which control what operations a user can perform. An EdgeSight Administrator can define new roles and edit existing custom roles. There are two non-editable system-defined roles, Administrator and Report Viewer. The Administrator role has all permissions and the Report Viewer has a limited set of permissions that enables the user to view all EdgeSight reports. Creating a role involves selecting the permissions associated with the role. Optionally you can assign the roles to existing users. For more information on creating roles, see the "Add New Role" topic in online help.

Creating Users and Assigning Roles

A user is an individual (or group of individuals) for which an account is created on the EdgeSight Server Console. When the initial server configuration is performed, a Superuser account is created. This account has access to all companies hosted on the server and can create other users. The Superuser can create an account for one or more administrators for a company, and then the administrators can continue with the creation of additional user accounts as required. You create and manage users on the Users page (Company Configuration > Security > Users). After you create a user, an email is sent to the user which includes login instructions and a temporary password. For detailed instructions on creating users, see the “Users” topic in online help.

User access to the EdgeSight Server Console is controlled through login authentication, while a user’s capabilities to display and edit data and perform administrative operations are controlled by a system of roles and permissions.

User logons are authenticated by either the built-in EdgeSight provider (user email address and password) or Active Directory (AD). (See Managing Authentication Providers and the “Authentication” topic in online help for information on creating an AD authentication provider.)

New users can be assigned one of the built-in roles (Administrator or Report Viewer) or assigned a previously created custom role. Each role is defined by a set of permissions. Assigning a role to a user automatically grants the associated permissions to that user. For detailed instructions on creating roles, see the “Roles” topic in online help.

To display the full set of permissions which can be assigned using a role, navigate to Company Configuration > Security > Roles, click on the information icon for the Administrator role, and then select the Permissions tab in the detail pane.

Note that the Manage Server Settings permission does not appear on the list. This permission must be explicitly granted when a user is created or edited rather than granted by role. While other permissions allow users to perform operations at the company level, this permission allows a user to view server-wide settings.

Managing Access to XenApp Farms

Use the Farm Authentication page to create and maintain default credentials used in accessing XenApp farms. The credentials consist of a farm name, user name, password, and domain name. The credentials are used when querying farms directly while searching for active sessions. (The report is accessible from the Troubleshooting tab.)

To find user sessions and display this report, you must select a query method. The Query one or more farms directly method is the recommended method for locating an active session for a specific user. Because this method requires existing credentials for logging in to the selected farms, you must specify a set of credentials for each farm in order for reports to be generated based on this query method.

Note: Credentials cannot be saved for a department which has no devices.

Creating Alert Rules and Actions

This topic outlines basic real-time alert concepts and provides strategies and guidelines for implementing alert rules in EdgeSight. For detailed instructions on creating real time alerts and actions, see the “Alert Rules” and “Alert Actions” topics in online help.

Real-time alerts allow you to monitor mission-critical applications and devices and notify designated people in your enterprise in the event of a problem. By default, alert data and statistics are collected by the agent on each desktop and uploaded to the server on a daily basis. When you explicitly configure an alert by creating an alert rule, you are requesting real-time notification that a specific alert condition has occurred.

The purpose of real-time alerts is to provide timely notification of critical events that require immediate attention. For example, alert rules ensure that data is available for display in the Farm Monitor. The Farm Monitor allows you to browse through a XenApp Farm and display real-time alerts and system context for one or more devices. When developing an alert rule strategy, ensure that alert rules are only created for events that have an associated resolution. Real-time alerts are not intended for data collection; agents collect relevant data whether or not an alert rule exists, and historical reports are the most effective means of displaying availability and performance data.

Proper alert configuration is critical to effective real-time alert notification on the health of distributed devices and applications. It enables you to quickly identify which issues are truly critical and require immediate attention and which issues can wait. In order to achieve an effective alert configuration, you must have an alert strategy in place. When designing your strategy, you will need to do the following:

  • Identify which applications are critical to your business or service - Focus on critical applications and define alerts only for problems that must be resolved in a short period of time.
  • Identify which departments have mission-critical applications running on their systems - Associate alerts only with the departments or groups where the alert condition is most critical. This allows you to isolate and respond to problems that are relevant to a specific portion of your business.
  • Identify which alert types are most important - Some alerts, such as NT log alerts, are generated in large numbers by some applications and are generally transparent to the end user. As a result, prior to defining an NT log alert, verify the risk level of the alert condition by examining historical alert reports.
  • Identify what response is required to resolve specific alerts - Responses may include performing a specific set of actions or notifying responsible individuals in the associated department. If no response can be identified for a condition, the event does not require a real-time alert.
  • Identify who is responsible for responding to the alert - Determine who should respond to a specific alert condition.
  • Establish and publish guidelines for alert rule creation - Determine who is responsible for new alert rule creation. Define best practices, such as creating descriptive names for alert rules and avoiding duplicate alert rules. A user must have the Manage Alerts permission in order to create or edit an alert rule.

Once you have established an alert strategy, you can configure the required real-time alerts using the Alert Rules page in the EdgeSight Server Console (Company Configuration > Alerts > Rules).

Alert Features

A number of features enhance the ability to configure alert rules specific to a condition warranting an alert, and thus reduce the number of extraneous alerts generated by the agent. These precise alert rules should result in an actionable response if the alert is ever generated. The following is a list of some of the improved scenarios:

  • Performance alert rules can be specified on complex parameters. For example, send a System Performance alert if the CPU is over x% and there is less than y free memory on the machine.
  • Application alert rules can be defined to specify the company name of the process from which to generate alert rules. For example, if a process written by the specified company crashes, send a Process Fault alert to the company’s internal support team.
  • Windows Event Log alert rules can be specified to include the application and event writing the event to the event log. For example, if a group policy violation occurs, send an alert to the Security team.
  • Negation logic (implemented as a Not like checkbox) can now be used in the definition of certain alert rules. For example, send an application terminated alert notification only if the terminated process was not written by the Internal Tools Team.

Alert Categories and Types

Real-time alerts can be broken down into two distinct categories: event driven and polled. Event driven alerts are generated whenever the associated event occurs in the system, while polled alerts are based on queries of the agent database on a periodic basis. In general, polled alerts are used as notifications of performance problems with an application, a system, or the network. For a description of how polled alerts function, see “Sampling, Polling, and Re-alerting Parameters” later in this topic.

When setting up alert rules using the Alert Rules Wizard, alerts are grouped into the following types based on the type of event or condition with which they are associated:

  • Application alerts
  • System alerts
  • Network alerts
  • XenApp performance alerts
  • XenApp error alerts
  • Session performance alerts
  • XenDesktop error alerts

To help ensure that real-time alert data is available for XenApp Servers, the following alerts are preconfigured and assigned to the XenApp Farms subdepartment:

  • Configuration Logging Database Unavailable
  • Farm Data Store Connection Failure
  • Health Monitoring and Recovery Action Failure
  • Health Monitoring and Recovery Test Failure
  • IMA Service is Unresponsive
  • License Server Connection Failure
  • Number of Servers in a Zone is Too High
  • Published Application Concurrent Usage Limit
  • Session in Down State
  • Terminal Server Client Connection Error
  • Terminal Server License Server Discovery Failure
  • Zone Data Collector Election Triggered
  • Zone Elections Too Frequent

The parameters for these alerts can be edited. Descriptions of each alert rule and parameter set is provided in the Alerts Rule Creation Wizard.

Active Application Monitoring Alerts

The EdgeSight Server Console displays real-time alerts received from Citrix Active Application Monitoring (AAM) software. This software allows you to record and create virtual user scripts and define tests. When the tests are run, virtual user ICA sessions are generated on the target XenApp servers. The results of the tests provide application response and availability information.

Important: The EdgeSight for XenApp Agent 5.0 or later running in Advanced Mode is required for the generation of Active Application Monitoring alerts.

The Active Application Monitoring alert rules are as follows:

  • The Application Response Failure alert is generated when a monitored transaction has failed.
  • The Application Response Time alert is generated when the time to execute a monitored transaction has exceeded the specified threshold.

These alerts are grouped under XenApp Performance alerts. For more information on installing the software, see "Setting Agent Propeties". For more information on creating and launching tests, see the online help included with the Active Application Monitoring software.

Notes on Specific Alerts

The following information on specific alerts is provided to help you understand under what conditions these types of alerts are triggered.

  • New process alert -The new process alert only fires for processes which are used for the first time after the New Process Grace Period has expired. The grace period is set in the agent properties (for more information, see ). For example, the default grace period on XenApp agents is 7 days. If you install an agent and then start a process, the agent records this as a process, but not as a new process because the agent database is less than 7 days old. Once the database is more than 7 days old, then any new process (any process that is not already in the agent database) being run will trigger an alert. This avoids a large group of alerts being triggered at once because an agent was installed. Note that the grace period is relative to the agent database age, not the actual date of initial agent installation. If an agent database is recreated for some reason, then the grace period is reset.
  • Process hung alert - This alert type corresponds to the “not responding” alerts shown in reports. EdgeSight software uses the Windows API (the IsHangAppWindow call) to determine if an application is not responding. An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called the PeekMessage function within the internal timeout period of 5000 milliseconds (5 seconds).
  • Process fault and process snapshot alerts - These types of alerts may generate crash reports, if conditions on the managed device allow for crash data to be captured. In some cases, the system is unable to support the collection of data. In the case of process fault alerts and the resulting crash reports, there are several factors to consider:
    • If the crash file cannot be written, a message to that effect is logged to the zcrash_loader log file. Navigate to Server Status > Server Script Host, locate es_zcrash_loader, click on the menu icon and select View Log.
    • What is the age of the crash report? Crash report grooming is distinct from database grooming, and the time that crash reports are retained is controlled by the Max Keep Days setting. Navigate to Server Configuration > Settings and select the Crash Processing tab.
    • What is the limit for number of logs collected, and how much space is allocated to crash reports? (See Server Configuration > Settings.) If either the maximum number of crash logs or the maximum disk consumption limit is exceeded, application crash processing is disabled until the limit is increased. There is no reset operation that can be used to remove existing payloads.
  • Published Application Single Use Failure and Published Application Concurrent Usage Limit - When enabling logging of connection control events on the XenApp server, the Log over-the-limit denials setting must be enabled to allow these SMA-based alerts to fire. (For XenApp 6 systems, use the Logging of logon limit events policy setting.) See the XenDesktop documentation for more information about configuring connection control events.

Sampling, Polling, and Re-alerting Parameters

Sampling is the periodic collection of data from the system being monitored. Polling is when the agent runs a query against the database to compare alert rule parameters to the data collected.

Each rule for a polled alert includes the following parameters:

  • Percent of samples required
  • Poll interval
  • Re-alert

Most polled alert rules also include a non-editable Data sample window parameter, usually set to Poll interval plus one minute.

These parameters allow you to fine tune the frequency with which alerts of a specific type can be triggered. Sampling is performed as frequently as every 5 seconds, depending on the alert type. During sampling, the required data for the alert type is collected. When polling occurs, the collected data is compared to the conditions specified in the alert rule. The poll interval value determines how often polling is performed. The percent of samples required determines what percentage of the collected samples must be across the threshold (either higher or lower depending on the alert type) before an alert is triggered. If the alert defined by the alert rule has already been triggered within the re-alert period, another alert is not generated until the period expires and the alert condition reoccurs. The data sample window indicates how far back in time samples are included in the polling.

Note: The default poll interval is designed to provide timely generation of alerts while minimizing the impact of queries run against the database. Decreasing the poll interval (increasing the frequency with which queries are run) can have an adverse effect on system performance and should be done with caution.

Polled Alert Example

The following illustration shows an alert rule for detecting system slowdowns due to high CPU usage.



The alert functions as follows:

  • EdgeSight Agent software samples the percentage of CPU time used. For the purposes of this example, the sampling rate is assumed to be every 5 seconds.
  • Every 90 seconds, the software polls the sampled data to see if the percentage of CPU time has exceeded 40 percent in at least 10 percent of the total number of samples. Because the data sample window is defined as the poll interval (90 seconds) plus one minute (60 seconds), the samples gathered over the last 150 seconds are included. This means that 30 samples will have been gathered. If 3 or more samples out of 30 have a percentage of CPU time used over 40, an alert is generated.
  • The re-alert parameter is set to Every poll interval, so if the percentage of CPU time exceeds the threshold in the data included in the next polling, another alert is generated.

When to Configure a Real-Time Alert Rule

EdgeSight does not require that you configure certain alert types for the EdgeSight Agent to collect data on the conditions which would generate the alert. If you are configuring an alert rule, you should only do so if you are in a position to respond to the alert within a matter of hours. If there is no appropriate response to the alert condition within several hours from alert generation, a historical report should be used to determine if an item of significance has occurred. Creating excessive numbers of alert rules can reduce the effectiveness of monitoring tools such as the Farm Monitor by flooding it with alerts, making it more difficult to identify truly critical events.

Performance Impact of Real-Time Alerts

Regardless of the alert rule type, there is some processing overhead for each rule configured for an agent. At a minimum, the agent must determine if the alert should be generated, and if so, it must send the alert to the server. In some cases, the agent must run an SQL query against the database to determine if alertable conditions are present; when the conditions are too broad, the agent is required to process large datasets to generate the alerts and send them to the server.

Since each alert rule configured for a given agent incurs processing overhead, and this processing may occur when the end-user is attempting to perform an important task, care should be taken to only configure alert rules which are both targeted and actionable. If there are concerns about the overall impact of the agent on a system, and a significant number of alert rules have been defined for that agent, you may want to reevaluate the defined rules to determine whether a historical report would be more appropriate than real-time alerts. The following list provides some general guidelines as to when a set of alert rules will negatively impact the end user:

  • If more than 3 or 4 application or network performance alerts are defined.
  • If process or network performance alerts are defined to trigger for common conditions, such as CPU usage over 5%.
  • If process or network performance alerts are defined for very complex conditions (for example, populating a value for more than 2 or 3 performance thresholds). In these cases, the SQL queries run by the agent to determine if an alertable condition exists could themselves consume significant database cycles.
  • If “Not Like” is defined on process or network performance alerts.
  • If multiple textual “Like” or “Not Like” operations are defined on process or network performance alerts.
  • If performance alert rules are defined which will never fire (for example, setting up a process performance alert for an application whose execution is blocked via group policy).

When Will the Server Show a Real-Time Alert?

Real-time alerts are not generated until the following conditions are met:

  • Alert rules are created and assigned to a department.
  • Devices have run the Init Worker or the Configuration Check Worker.
  • The condition or event specified in the alert rule has occurred.
Note: Some XenApp alert rules are preconfigured and assigned to the XenApp Farms department as described in “Alert Categories and Types” earlier in this topic.

No alerts of any type are sent to the server until the agent has completed its startup sequence, which may take several minutes. Init and Configuration Check workers are run after the startup sequence completes, and worker execution is spaced out over several minutes. Once an alert is generated, it is batched for delivery to the server. Alerts are batched for up to one minute, and assuming there is a network connection, sent to the server. If there is no network connection, or if the agent is stopped before the alerts can be sent, the queued alerts will not be received by the server, and will not be re-sent. (Real-time alerts are not guaranteed to be received by the server.) However, because the agent does not require real-time alerts to be configured for data collection, the alert condition is still captured and can be seen in the historical reports once a data upload occurs, even though they were not sent to the server as real-time alerts. Unsent alerts are also shown in the real-time alert reports that display data directly from the agent database.

Managing Alert Actions

The Alert Actions page (Company Configuration > Alerts > Actions) allows you to configure an alert action to be performed when a specific alert condition occurs. Alert actions can be used to:

A single action may be associated with multiple alert rules. For example, there are multiple cases where an IT manager should be notified in case of an alert condition, so an action resulting in an email message being sent to the manager is associated with each applicable alert rule.

Note: Although only an EXE file can be launched using the “Launch an external executable process” alert action, you can launch cmd.exe and use command line arguments to call a non-EXE file such as a BAT or VBS file.

For information on creating alert actions, see the “Alert Actions” topic in online help.

Managing Alert Suppressions

The Alert Suppressions page (Company Configuration > Alerts > Suppressions) displays alerts that have been suppressed. As an administrator, you can edit or clear any alert suppression.

Any user can create an alert suppression from the Alert List located on the Monitor tab. Suppressions prevent the EdgeSight Server Console from displaying a specific type of alert based on source, device, or user, or by a combination of these criteria. Note that suppressions are only effective for the user creating them; other users are still able to view the alerts. For more information on alert suppressions, see the “Current Alert List” and “Alert Suppressions” topics in online help.

Managing Application Categories and Vendors

EdgeSight includes extensive application category and vendor listings for use in reporting by type of application or by software manufacturer. In many cases, the program fits into an existing category and matches an existing vendor. If necessary, you can create a new category or a new vendor for the new process. See the “Edit Categories” and “Edit Vendors” topics in online help for detailed procedures for creating and editing categories and vendors.

Managing Reports

EdgeSight provides a wide range of standard reports. These reports are available once EdgeSight Server has been installed and the connection to Reporting Services has been configured.

Managing Report Subscriptions

A subscription is a standing request to distribute a report in a selected format at specified times. Report distribution (subscription type) is done by email or by transfer of a file to a file share. Subscriptions can be public or private. Public subscriptions are displayed on the Subscriptions tab of the report details pane. Private subscriptions are only displayed to the subscription creator or an administrator. A subscription is a useful method of distributing targeted data to people in your organization without having to give them access to the EdgeSight Server Console. To display existing public subscriptions, navigate to My Settings > Subscriptions.

You can create a subscription while viewing the report using the Subscribe link in the filter bar. You can also create a subscription from any report list by displaying report properties and selecting the New Subscription button from the Subscriptions tab. See “Working with Reports” in online help for a detailed procedure for creating subscriptions.

By default, as an administrator, you are granted the required permissions to manage all subscriptions, both public and private. (See “Creating Users and Assigning Roles” or descriptions of permissions and their relationship to roles.) This allocation of permissions allows you to control the distribution of data within your organization and also help you manage the impact on the Report Server.

Uploading Reports

Navigate to the Custom Reports page (My Settings > Custom Reports) and click on the Upload a Report button to transfer an RDL file for a custom report to the Report Server.

Always use a unique name when uploading a new report. Also, you should define and publish naming conventions for custom reports. Use the Public or Private radio buttons to determine whether the report is shared within your company. Public reports are displayed to all users unless the ability to view the report is restricted based on the selected permissions. Private reports are only displayed to the user uploading the report. The Public/Private attributes cannot be changed once the report is uploaded. To change any of these attributes, you must delete the report and then upload the report again.

If you make additional changes to the report, use the Update link on the Properties page to upload the RDL (Report Definition Language) file. For more information, see the “Custom Reports” and “Upload Custom Reports” topics in online help.

Managing IP Ranges

Setting IP ranges enables you to define the corporate network for use in filtering the network by corporate or external network hosts. Ranges of IP addresses defined on this page are represented as corporate network sites. This option is only required when the IP address you use is not defined in the private, non-external IP address range. For instructions on setting IP ranges, see the “IP Ranges” topic in online help.

Managing Real-Time Dashboard Configurations

EdgeSight provides a dashboard that allows you to display real-time information for specific devices and counters, based on a saved configuration. The dashboard is displayed on the Monitor tab.

Note: Devices must be running an EdgeSight Agent of version 4.2 or later in order to be displayed on the dashboard.

The Real Time Configurations page allows you to create and edit named configurations for the dashboard. Configurations include:

  • A unique name
  • Timeouts for queries and connections
  • An update interval
  • Counters to display for the selected devices

You can select a maximum of 20 devices and 8 counters for the configuration. See the "Real Time Configurations" topic in the online help for detailed instructions on creating and editing configurations.

Once a configuration has been created, it is added to the drop-down menu on the Dashboard page, allowing users to select the configuration for viewing on the dashboard. The dashboard is populated with data based on direct queries to managed devices; no dashboard data is stored on the server.

Setting Agent Properties

The EdgeSight Agent stores configuration data in two locations. The Windows registry on the managed device is used to store configuration items which are machine specific and are required for successful communication with the EdgeSight Server. For example, the name of the company the agent belongs to, the name of the server to contact, and any proxy information required to perform the communication are all stored in the registry. All other configuration items are stored in the EdgeSight Agent database.When the agent is running on virtual desktops in a pooled environment, the agent database is located on a remote server.

The items stored in the Windows registry are typically set once, and are supplied during agent installation. All other configuration items are supplied by the associated EdgeSight Server, and any changes in configuration are performed using the Agent Properties page. By default, an agent obtains its initial configuration shortly after the agent first runs and then queries for configuration changes. The default schedule for configuration checks is set to 6:30 AM agent local time every day for endpoint devices and every hour for XenApp servers. Agents running on virtual desktops in a pooled environment will perform configuration checks based on actual usage.

Care should be taken when changing agent properties. These parameters control the way the agent works and could result in users perceiving data loss or an increased CPU usage by the agent. In most cases, you will not need to customize agent properties. Use the default configuration at first and adjust it over time based on user requirements and system performance.

Agent property configurations are displayed on the Agent Properties page (Company Configuration > Agents > Properties). When creating a new set of agent properties, you must choose a default configuration (Endpoints Default, XenApp Default, or Virtual Desktop Default) to use as a template. Provide a unique configuration name and description, and edit the parameters as required.

Note: If you have performed an upgrade from an EdgeSight Server version prior to 5.0 SP2, the Virtual Desktop Default configuration is not initially displayed in the list of agent property configurations. To create agent property settings for virtual desktops, select New Properties Configuration and then select the Default Properties for Virtual Desktop Agents radio button. Configure the properties as described in the “Agent Properties Wizard” topic in online help.

Once a custom set of agent properties has been created, it must be explicitly mapped to a department before it is provided to agents as part of a configuration check. (See “Managing Departments” for information on associating a set of agent properties with a department.)

For information on the individual parameters that make up agent properties, see the “Agent Properties Wizard” topic in online help.

Minimal Data Collection Mode

In order to support busy XenApp server environments, the EdgeSight agent has a Minimal Data Collection Mode feature that, when enabled, limits the data collected on the agent and thus the overall impact the agent has on the XenApp server.

When a XenApp server is consistently experiencing heavy load, or the XenApp server slows considerably under load, it is time to consider using this feature. Use EdgeSight reports to note the number of sessions and processes at which a considerable slow down occurs. These numbers are used to establish when Minimal Data Collection Mode is initiated on the agent.

Note: Minimal Data Collection Mode should be considered a temporary measure to ensure that critical data is collected while long term measures are taken to reduce or redistribute the load on the affected XenApp servers.

The Minimal Data Collection Mode is disabled by default. To enable it, edit the agent properties and display the advanced settings. Set Manage Data Collection to True and enter values that you collected in the Process Count Threshold and Session Count Threshold fields. Then assign this set of agent properties to the XenApp server experiencing the problem.

When Minimal Data Collection Mode is enabled, the agent periodically monitors the process and session counts against the configured thresholds. If either threshold exceeds its specified value, the agent enters Minimal Data Collection Mode. At this point an operational alert is sent to the server, “The Citrix System Monitoring Agent has entered Minimal Data Collection Mode.” When both process and session counts return below the threshold settings for 5 minutes, the agent will leave Minimal Data Collection Mode and normal data collection will be resumed. A bullet is sent to the server to indicate that the agent has left Minimal Data Collection Mode.

Minimal Data Collection differs from normal data collection in the following ways:

  • No module data is collected or persisted
  • No network data is collected or persisted
  • No light trace events are persisted
  • No image or principal events are persisted (currently not visible)
  • No task details used in fault reports will be persisted
  • Hung application detection is disabled
  • Image and session performance data is persisted at a 2 minute granularity
  • Custom performance counter collection is disabled
  • Performance, network, and event trace alerts are disabled

Other configuration changes that exist on EdgeSight for XenApp include:

  • System, image, and session performance fine grain data is persisted at 15 second intervals.

    If the scheduler detects more than 5 concurrent sessions running, it will not use idleness to gate when scheduled items such as consolidation can run. Instead the assumption is made that this is a server system and therefore there may never be best idle moments for schedules to run.

    Individual workers can be configured on the server to similarly ignore idleness when making a determination for a best time to run.

Configuring, Scheduling, and Running Workers

Workers are tasks that run on EdgeSight Agents. Default worker configurations and schedules are created during EdgeSight Server installation. You cannot edit or delete default configurations and schedules, but you can use them as templates using the Copy operation and then editing the parameters as required.

Although workers are scheduled to run at certain times, the actual execution of workers takes into account when a user is actively using the system. If possible, workers are run when the system is idle. See “Configuring Workers” later in this topic for more information scheduling workers.

As with agents configurations, care should be taken when changing worker configuration parameters. These parameters control when and how often workers are run and could result in users perceiving increased CPU usage by the agent. In most cases, you will not need to create custom worker configurations. Use the default configuration at first and adjust it over time based on user requirements and system performance.

Once a custom worker configuration has been created, it must be explicitly mapped to a department before it is provided to agents as part of a configuration check. (See “Managing Departments” in for information on associating worker configurations with departments.)

The EdgeSight workers that you can configure are as follows:

  • Asset History—Collects the asset history for managed devices. This worker can be disabled.
  • Configuration Check—Checks for configuration changes to be downloaded to managed devices from the server.
  • Database Maintenance—Performs database maintenance tasks on the agent database.
  • Drive Space Calculation—Calculates the drive space used on managed devices. This worker can be disabled.
  • Fault Report Cleanup—Maintains and cleans up files created for fault and snapshot reports.
  • Performance Upload—Uploads agent data to the EdgeSight Server.

Configuring Workers

A worker configuration has the following components:

  • A configuration name and description—The name and description should be complete enough to allow administrators to accurately select a configuration.
  • A set of enabled workers—Only the Asset History and Drive Space Calculation workers can be disabled. All other workers are required to run for proper system operation.
  • A set of run conditions—In addition to the worker schedule, a set of run conditions is used to control the behavior of the worker.
  • One or more schedules—Each enabled worker must have at least one schedule configured that, along with the run conditions, determines when the worker is run.

The run conditions for workers are as follows. Not all run conditions are set for each worker.

  • Days before the worker will force itself to run—This setting indicates that the worker will run after the specified number of days, even if other conditions (such as user idle time) are not met. If the worker cannot run due to communications problems, it will run as soon as communications are restored.
  • Randomize the start with a window of—To facilitate system and network performance, worker execution times can be randomized within a time window. This prevents situations such as a large number of agents attempting to upload performance data at the same time.
  • Consider system idle after all users are idle for—This setting helps to run workers when users are not actively using systems. (The worker schedule has a similar option called Wait until all users are idle before starting the worker.)

Note that a run condition must contain a non-zero value to be enabled. Entering zero as the value for a run condition automatically disables that condition. For more information on configuring workers, see the “Workers Configuration Wizard” topic in online help.

Monitoring Workers

Some workers log information into log files. The SYS_EVENT_TXT.txt file indicates which workers have run and at what time. It is located by default in your installation path:

%ALLUSERSPROFILE%\Citrix\System Monitoring\Data for Microsoft Vista and Windows 2008 systems

%ALLUSERSPROFILE%\Application Data\Citrix\System Monitoring\Data for all other systems

For agents running on virtual desktops in a pool, the log files are copied to an agent data file share specified during agent installation.

It also logs any errors that may occur when a specific worker tries to run, which is helpful when diagnosing issues. Not all workers create a log file, however, because they are internal to the product and provide product maintenance. The following lists group the workers by the type of task they perform:

Workers that interact with the server:

  • worker 101: Performance Upload—uploads Agent data to the EdgeSight server
  • worker 104: Init Worker—runs on the initial database creation, connects to the server, and downloads initial agent property information
  • worker 105: Configuration Check—checks for configuration changes
  • worker 109: Trace Route Worker—executes a network trace
  • worker 150: Bullet Worker—uploads alert information to the EdgeSight Server

Workers that collect data:

  • worker 102: Drive Space Calculation—calculates drive space on the device
  • worker 103: Asset History—collects the asset history of the device

Workers that maintain the agent:

  • worker 1: Database Tuning—internal maintenance, no log is created
  • worker 2: Database maintenance—internal maintenance, no log is created
  • worker 106: AD Worker—runs an Active Directory script
  • worker 107: Fault Report Cleanup—maintains and cleans up files created for fault and snapshot reports
  • worker 108: Fault Report Preparation—builds fault reports and uploads them to the server
  • worker 110: RISH Log Cleanup—maintains and cleans up logs created from RISH
  • worker 126: Database Sizing—database size tuning

You may also see other logs different than the ones described above in this directory. This is because some alerts run as scripts and log their activities.

The worker log files contain information that can be useful in troubleshooting issues that can occur relating to the various work functions performed by the agent. You would first look in the SYS_EVENT_TXT.txt file to see if a worker has experienced any issues. Based on the information there, you would then look to the specific worker log for more detailed information.

For example, if the SYS_EVENT_TXT.txt file makes a reference to the following error message:

Running worker 101 - 'Performance Upload' with trigger 1071

Then you would look in the log folder for the text file that begins with Worker101_Trigger1071.

The most useful logs tend to be the ones associated with the upload and configuration workers, as they help to resolve connectivity issues between the agent and server. For that reason, the logs for workers 101, 104, and 105 are typically the most useful in troubleshooting these sorts of problems. For example, you can verify that agent communication with the server is failing if you examine the SYS_EVENT_TXT file, locate Worker 104 running with trigger 24 and see a status of anything other than 0x0.