Citrix EdgeSight for Endpoints and Citrix EdgeSight for XenApp provide centralized monitoring and proactive management of desktops and XenApp servers in the enterprise. This article contains frequently asked questions about these products, divided into sections as listed below:
Support
Agent
Administration
Report Services
Migration
Licensing
Compatibility
Q: What versions of EdgeSight are currently being sold and supported?
A: EdgeSight 4.1 is no longer being sold, and is no longer supported. EdgeSight 4.2 was released on October 2, 2006, and is currently supported. EdgeSight 4.5 is currently sold and supported. For other Citrix product lifecycle phases please see the Citrix Product Matrix Table at http://citrix.com/English/SS/supportThird.asp?slID=5107&tlID=5110
Q: Which versions of Microsoft Active Server Pages (ASP) and ASP.NET are required for the EdgeSight Web server?
A: EdgeSight 4.2 and EdgeSight 4.5 use ASP.NET 2.0 and does not require ASP server to be enabled.
Agent
Q: Which operating systems are supported by EdgeSight for Endpoints?
A: The Endpoint Agent is supported on Microsoft Windows XP, Microsoft Windows 2000 Professional or Server Service Pack 3 or later, and Microsoft Windows Server 2003.
Q: Does the endpoint or EdgeSight for XenApp require a restart after the installation?
A: Yes, a restart is required at some point after the installation to complete the installation process.
Q: What happens to the data if the client crashes? Do you loose the complete five-minute snapshot or just the data collected up to that point?
A: No. The agent is very resilient and much has been put in place to prevent as well as recover from behaviour like this (that is, crashes). An EdgeSight for Endpoints Agent maintains 5-second level detail and an EdgeSight for XenApp Agent maintains 15-second level detail for the most recent 4 hours. After this point the data is aggregated up to 5-minute detail. So if the agent does happen to crash, it recovers and/or restarts reliably and quickly. The nature of the crash affects this whole scenario (bad spot on disk, disk full, and so on). A crash may result in a missing data sample (or two), which in effect is seconds worth of data.
Q: Does the agent monitor itself?
A: Yes. The agent does monitor its own individual processes (fbserver.exe, rscorsvc.exe, and so on) so that you can understand the impact and performance of EdgeSight itself.
Q: How often does the agent check or query the EdgeSight server for configuration changes?
A: This depends on the worker configuration schedule you have in the environment. The default schedule checks once a day at 6:30 a.m.
Q: After installing the agent, when does it appear in the EdgeSight Server Web Console?
A: Assuming that the EdgeSight Server was installed prior to the installation of the EdgeSight Agent, the agent must perform a number of steps before it performs its initial communication action. On most computers, these steps are completed within 10 minutes of the agent startup. These steps are only performed on the initial installation, not on upgrades.
Note: While it is possible to “force” an upload to occur during this initialization phase, doing so is not recommended. Depending on the phase of the startup, the agent may not yet have collected required configuration data. Any configuration of the agent the server may wish to make is based in part on the configuration the agent. An example of this type of configuration data is the version of XenApp an EdgeSight for XenApp Agent is running on.
Q: How do you know that an agent has contacted its EdgeSight Server Web Console for the first time?
A: When the agent performs its initial communication with the EdgeSight Server, the EdgeSight Server receives back a data payload. This data payload contains a number of collected data items that the EdgeSight Server loads into its database and effectively registers the agent to the server. As a final step, it sends a New Instance email to the EdgeSight Server administrator and adds an entry to a status table that can be viewed from Server Settings > Messages. If an error occurs while processing the payload, these entries are also written. The entries include potentially useful information for resolving the problem.
Q: The agent has successfully contacted its EdgeSight Server Web Console, but the agent is not in the device list. Why?
A: When the agent uploads its data, one piece of the data is the company the agent is configured with at installation time. If this company name does not match the name of the company on the EdgeSight Server, the agent is listed as an unmanaged device. Unmanaged devices are listed under Server Settings > Configuration > Unmanaged Devices. You can then locate the agent device by name and manually assign it to the proper department.
Note: Company names cannot contain any of the following characters: @#$%
Q: The agent doesn’t contact its EdgeSight Server Web Console as expected. What should be verified?
A: The agent keeps a series of detailed logs about its execution. When it performs an upload, it is doing so using a function known as a worker. Each worker has its own log, which provides detailed information about worker execution.
As a first step in validating agent communication, the network settings should be verified. One of the most common issues occurs when the EdgeSight Server name is not specified as a Fully Qualified Domain Name (FQDN), but the network requires FQDNs, or that the server must be specified by an IP address.
Another common configuration problem is a proxied network where proxy configuration is automatic. The EdgeSight Agent supports a fixed proxy server, if proxies are required on the network. If network changes are required, they can be made while the agent is running. The agent retries the communication every two minutes.
If the network settings appear correct and the agent is still unable to communicate, the next step is to inspect the various log files.
The first file is located by default in C:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data, and is called SYS_EVENT_TXT.txt. Open the file and look for the last entry for Worker 104 running with trigger 24. The entry provides a status; if it is all zeros, the communication was successful from the perspective of the agent. If it is not all zeros, the last sentence of the error message provides the most relevant information. Under certain circumstances, the message directs you to look in the script log file. The log file for this worker is located in the EdgeSight\log subfolder, and is called Worker104_Trigger24_Inst0.log. Very detailed information can be found in this log.
If the communication was successful from the perspective of the agent, you must inspect the Internet Information Services (IIS) logs to determine if there is a Web server error in processing the request. All other upload processing errors are logged in the EdgeSight Server database and viewable from the Server Settings > Messages page.
Q: The agent is not reporting to the EdgeSight console. Can you force an update so the agent registers right away if it hasn’t?
A: ”Forcing” an upload to occur for the initial communication is generally a bad idea. The agent automatically uploads its data within 10 minutes of the initial agent startup. Any problems with the initial upload prevent any forced upload from completing. Additionally, the initial upload has “retry upon failure” logic to ensure that uploads proceed automatically once network and configuration problems preventing uploads from occurring are resolved.
Note: During the initial 10-minute period, various configuration changes are made. The agent determines its Active Directory membership and operating environment. If an upload is attempted prior to these items being processed, the agent may not register correctly with the server, or it may receive an incorrect configuration. There is also the potential for incomplete data to be associated with the agent device.
Q: Which XenApp versions are supported by EdgeSight for XenApp?
A: The XenApp Agent is supported on XenApp 3.0 or later, including XenApp 4.5 on a 64-bit Windows Server 2003 platform.
Q: Are the Endpoint or XenApp Agents supported on Windows 2000 Server or Windows Server 2003 running Active Directory, SQL, Exchange, IIS, or other roles?
A: No. The XenApp Agent is only designed to monitor and report on XenApp functions. The Endpoint Agent is only designed to monitor and report on end-user systems.
Q: How does the agent collect data on the device it is monitoring?
A: The agent runs as a service and collects performance and reliability data from a number of sources, including (but not limited to) performance counters and Windows Management Instrumentation (WMI). The data is persisted to a local database and periodically uploaded to the centralized EdgeSight Server database.
Q: How does the agent send data to the EdgeSight Server?
A: The agent periodically uploads a payload of data to the EdgeSight Server using standard HTTP protocol. It can also be configured to use SSL. The agent can be configured to immediately send real-time alerts to the server.
Q: Which ports need to be open on the firewall between the agent and the EdgeSight Server?
A: By default, port 80 (or port 443 for SSL) is used by the agent when sending its data payload.
Q: Which ports need to be open on the firewall between the EdgeSight Server Console and the agent?
A: Port 9035 is used to make a remote device connection to the agent. This includes running the Dashboard, Real Time reports, or Remote Workers.
Q: How often is performance data collected and sent to the EdgeSight Server?
A: The Endpoint Agent collects performance data every 5 seconds and periodically consolidates this data into five-minute samples. The XenApp agent collects performance data every 15 seconds and periodically consolidates this data into 5-minute samples. The data uploaded to the EdgeSight Server is consolidated into an hourly granularity. By default, this data is uploaded to the EdgeSight Server once a day.
Q: Are these data collection and payload intervals configurable?
A: No, the 5/5/60 and the 15/5/60 data persistence schedules are not configurable. The data upload schedule can be configured in the Company Settings > Agent > Worker > Configuration page in the EdgeSight Web Console.
Q: How much CPU and memory does the agent consume on the remote devices?
A: Although there may be CPU spikes, the average CPU use is only 1 or 2 percent. The Endpoint agent typically consumes 20 to 30 megabytes (MB) of RAM. The agent for XenApp varies based on the number of concurrent connections to the server.
Q: How much disk space does the agent consume on the remote devices?
A: The client-side database typically uses anywhere from 50 to 250 MB of disk space.
Q: How much network traffic is generated between the agent and the EdgeSight Server?
A: The data payload is typically 35 to 100 kilobytes (KB). The real-time alerts are approximately 200 bytes.
Q: What is required to make a remote device connection from the EdgeSight Web Console?
A: The Remote Data Viewer ActiveX control is used to connect from the browser to the remote device running the agent. ActiveX controls must be enabled in the browser. Microsoft Excel 2000, XP, 2003, or 2007 must be installed on the console computer to view the data. Port 9035 must be opened in your firewall, inbound on the client. The user running the console must be a local machine administrator on the remote device.
Q: Where does the Agent store its configuration information locally? Is it in the registry, or a file?
A: The EdgeSight Agent stores configuration data in two locations. The Windows registry is used to store configuration items that are machine specific and are required for successful communication with the EdgeSight server. Examples of this are 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. All other configuration items are stored in the EdgeSight Agent database. The items stored in the Windows registry are typically set once, and are supplied during Agent installation. All other configuration items are sourced from the EdgeSight server the Agent is configured to communicate with, and any configuration is performed using the EdgeSight server console. By default, the EdgeSight Agent obtains its initial dynamic configuration within 10 minutes of the initial run of the Agent, and queries for configuration changes once per day. The default schedule for configuration checks occurs at 6:30 AM Agent local time every day.
Q: How do you export reports that you’ve pulled out from the local agent database?
A: Press the F12 key on the keyboard and it gives you an option to save reports into various formats, including Excel.
Q: Where do you find a list of default set of reports?
A: You can see the list from the EdgeSight Console in the ALL REPORTS section. Also reference CTX111282 - List of Standard Reports Included in EdgeSight 4.5 for EdgeSight 4.5 reports.
Q: When Active Directory is chosen as the authentication provider, what is the proper logon format?
A: Domain\username must be used.
Q: How do you find out the version of the report services you are using?
A: To identify which version of Reporting Services you have installed, type the URL of the report server (for example, http://<exampleWebServer>/reportserver). Version information is located at the bottom of the page.
Q: Can you modify the existing reports?
A: Yes. Refer to Citrix Knowledge Center article CTX111022 – How to Modify Existing EdgeSight Reports and Save Them as Custom Reports.
Q: Can custom reports be created from the EdgeSight database?
A: It is possible to create custom reports using Microsoft Reporting Services and SQL technologies. The EdgeSight database schema and the relevant views are available in the product documentation. Custom reports can be uploaded to the EdgeSight Server using the Upload a Report page and can be viewed in the Custom Reports node in the EdgeSight Console. The maintenance and accuracy of the custom reports are the responsibility of the customer. For additional information see CTX111018 – The Process for Creating a New Custom EdgeSight Report.
Q: Does EdgeSight 4.2 support SQL Express 2005?
A: No.
Q: Does EdgeSight 4.5 support SQL Express 2005?
A: No.
Q: What is the process of upgrading the EdgeSight for XenApp and EdgeSight for Endpoints Agents? Is it an in-place upgrade or an uninstall/reinstall?
A: It is an in-place upgrade.
Q: Does a version 4.2 agent work with a 4.5 EdgeSight Server? What limitations come with this scenario?
A: Version 4.2 agents work with 4.5 EdgeSight Servers as expected. This has been thoroughly tested and is fully supported. The only limitation is that you cannot set up any Citrix XenApp alerts for a version 4.2 agent running on XenApp.
Q: What is the migration/upgrade process for 4.2 EdgeSight Server implementations to version 4.5?
A: This procedure is listed in the version 4.5 installation manual. Version 4.5 has almost all the same requirements as the version 4.2 server. Use the following procedure:
1. Install .NET 2.0 if you have not already.
2. Install the Citrix License Server.
3. Install version 4.5 and select the existing version 4.2 server database, which is upgraded with all its contents preserved.
NOTE: EdgeSight 4.5 uses SQL file groups and require a substantial amount of space during the upgrade. As a best practice, allow 100% free space of the current size of the EdgeSight database, for example, if the current database is 70 GB, have another 70 GB available. This does not include the size of the transaction logs, which can grow over 100% of the database size. In addition, backup the current database, and restart the EdgeSight server just prior to the upgrade to free any running processes from memory.
Q: Can the early release program (ERP) version of EdgeSight 4.5 be upgraded to the release to manufacturing (RTM) version?
A: By design, the ERP server cannot be upgraded to the RTM server. You should completely uninstall the ERP server and agents and then reinstall the 4.5 RTM version.
Q: What about Microsoft licensing for the SQL server? Do you need a client access license (CAL) for every agent?
A: CALs are not required for every agent. EdgeSight only requires a SQL license on the EdgeSight Server if using the per-processor license model. The amount of full SQL licenses depends upon your implementation of SQL Server and SQL Reporting Services. If you have a single-server architecture for the EdgeSight Server, a single full SQL license is required.
Single-server architecture is when IIS, SQL Server, SQL Reporting Services and EdgeSight are installed all on one physical server. If IIS and SQL Reporting Services are installed on one physical server and SQL Server on a second physical server, two separate and full SQL licenses are required. If using a per-device model for SQL, a CAL is needed for every agent.
Q: When is the endpoint license released from the license server?
A: The endpoint license is “released” on the EdgeSight Server when the device is deleted or removed from the server. This is done automatically and by default if a device has not reported up to the server for 30 days or more. You can also manually remove them in the Company Settings > Server > Device Management > Devices page.
Q: How is the client identified for licensing? Does it use a Media Access Control (MAC) address, unique identifier (UID), NetBIOS, or hostname?
A: The client uses these device characteristics in addition to a UID to correctly identify each device. This helps uniquely identify each device and merge duplicates if they occur. This may happen if a device is re-imaged and re-deployed.
Q: How is EdgeSight 4.5 licensed?
A: See CTX117241 - Overview of the Licensing Model for EdgeSight
Compatibility
Q: Is a full version of Microsoft Excel required on the EdgeSight server? Could the Microsoft Excel Viewer or Open Office be used instead?
A: The Excel Viewer has been tested and it does not work because EdgeSight requires full write permissions to update the spreadsheet. Hence, EdgeSight requires Excel 2000 or later.
