Citrix Edgesight 5.0 thoughts and impressions

Just received this great write up from David Paoleschi on his impressions of the new version of Citrix EdgeSight 5.0.


The biggest item is the security model implemented in ES 5.0 vs. prior versions. In previous versions of ES, pass-through credentials were used when connecting to Citrix servers to retrieve real-time data. In other words whatever credentials you used to log into the ES console were passed to the server when you requested a connection to the local DB to retrieve real-time data. As long as you were a member of an AD group that had local admin rights, you could connect to the server and run real-time reports.

In the new version of ES (5.0), the model has been changed to a NTLM challenge (CTX118478). Much like creating drive mappings to file shares on different hosts, you are now prompted to provide credentials to make a connection to each and every XenApp box. So, if you create a real-time dashboard with 60 XenApp servers, you will be prompted 60 times for credentials. Due to the nature of NTLM, and the hash created when you make a connection, you cannot (as far as I can tell) “cache” the credentials and use them for all the resources you need to access during a single ES session. Much like file shares, you can check “save my password” so you aren’t prompted repeatedly to re-authenticate to the same resource; however, I have found that even with checking that box, as you navigate around in ES real-time reports and tabs, you will be prompted repeatedly to connect to the same network resource. Citrix’s response was that this is not a bug, but the nature of NTLM and represents the security model of the product going forward. They suggested I try running the ES console from a XPSP3 or a box with a server OS to see if the NTLM prompts and “save” feature worked better.

Bottom line is that the new security model makes the product unusable (in my opinion) and forces you to set REMOTE_SECURITY=0 to essentially disabled ES security altogether.

Other issues encountered:

If you create multiple companies (not a best practice) and then try to delete one of the companies without removing all the login credentials associated with the company, you will orphan records in the SQL DB and have to manually clean them out (not documented by Citrix) before you can delete the company. Submitted to Citrix and got confirmation that this is a bug in the program.

When adding AD groups to ES to grant individuals the right to login to ES, the order in which you add the AD groups determines what rights they will have in ES. For example, if you are a member of two AD groups, ESAdmins and ESReporters, if you add ESReporters (ES report viewer only) and then add ESAdmins (full rights) you will get report viewer rights only. If you reverse the order of the AD groups, you will get full admin rights. Basically, ES is not “smart” enough to determine that you are in two AD groups and give you the least permissive of the two. Submitted to Citrix and got confirmation that this is a bug in the program.

Sporadic timeouts of the agents when invoking remote access (real-time, etc.) functions.  This includes dashboard, real-time reports, or queries to the local database behind the agents for viewing recent alarms, performance stats, sessions and application information, etc.  What seems apparent at this time is that:

First, the problem may be latency-dependent — that is, the agent database connection is more prone to timeouts when accessing EdgeSight from a workstation across the WAN vs. from a management consoles or the ES host itself in the data center (that is, when the client browser accessing EdgeSight is running on the same local subnet as the Citrix server agent being hit).

Second, the access problems can be significantly reduced, but not eliminated, by upgrading to the latest version of the Flash control (10.x now I believe) on the client browsers.  The impact of this was most noticeable for the good in browsers launched in the data center, possibly because of the latency reduction I just discussed.

You can restore agent connectivity by disabling and re-enabling the unresponsive agent using the service control button on the agent’s control panel applet.


Thanks for the great write up Dave!