Desktop Director started its journey with XenApp and XenDesktop 7.0 with an aim to provide a single best monitoring and troubleshooting solution. Over ensuing releases, many features were added based on inputs from various partners and customers. The PowerShell command-lets and a generous OData layer along with Director’s self-enhance plug-in model allows customers to write plug-ins to extend Director to their custom needs.

While subsequent releases promise to add even more features, we spent some time pondering over existing customer experience, reliability and performance over varying scenarios and database sizes. Today, we are happy to have taken the first step and re-architecture a few pieces to get you the best mileage out of the box!

Support for larger scale exports

Reporting through Director is one of the most loved pieces where an administrator can choose a time range and a reporting format (i.e. PDF, Excel or CSV) based on the case, for example one may go for a PDF report for sharing and collaborating, whereas Excel and CSV serve as a format in case an administrator wants to do some data analysis or troubleshooting.

A Director report usually has two parts, the trend part where the aggregated information is neatly displayed in a graphical representation and second, a table which represent the actual data on which the trend information is aggregated. With earlier versions, by default, the entire table was being exported for the selected time range. This had an impact in few big environments where about a million sessions were being launched in a day, here, the number of rows for a small time range of a week itself would grow out in tens of million. This caused an unexpected behavior of Director reporting APIs taking a huge time to process this data and often failing, denying administrator of a report.

We chalked out the use cases for each report format, re-architected the reporting piece and placed certain caps on the number of concurrent reports and amount of data that can be exported based on the type of report and ensured an administrator does get a report every time one clicks on the Export button in Director.

Here, are the changes introduced considering the most common use cases for each reporting format in general. However, these are kept fully configurable for customers to adjust based on their case.

Property Description Default value How to re-configure?
# Concurrent reports Number of concurrent reports across all Director sessions (logins). 2 Web configuration settings:
Key: UI.ConcurrentExportLimit
Value: Integer value
# Rows in Pdf report Maximum drilldown depth i.e. number of table data rows exported to Pdf report format. First 500 rows Web configuration settings:
Key: UI.ExportPdfDrilldownLimit
Value: Integer value
# Rows in Excel report Maximum drilldown depth i.e. number of table data rows exported to Excel report format. First 100,000 rows Web configuration settings:
Key: UI.ExportExcelDrilldownLimit
Value: Integer value
# Rows in CSV report Maximum drilldown depth i.e. number of table data rows exported to CSV report format. First 100,000 rows Web configuration settings:
Key: UI.ExportCsvDrilldownLimit
Value: Integer value
# Rows in CSV report (Sessions) Maximum drilldown depth i.e. number of table data rows exported to CSV report format for Historical sessions. First 10,000,000 rows Web configuration settings:
Key: UI.ExportCsvDrilldownLimit
Value: Integer value

Since the most common use case for a Pdf report is for sharing and collaboration, a lower limit is applied to let admins generate a quick report with graphical trends to summarize the selected time range and drill-down to a depth of 500 rows. Whereas, Excel and CSV can be used for more elaborate troubleshooting and/or exporting the data to secondary data stores for specific processing, hence, they support a much higher drill-down limit.

Faster API responses and data searches

A lot of OData method APIs in the Monitoring service are re-worked to give a better response time in Director. We hope you’d see significant improvements especially on Sessions, Connections and Logon duration pages and trend views while querying for historical data.

Faster, better processing for alert policies

Proactive Notifications and Alerting is another cool feature that has trended on the popularity list at a rapid pace. While working on enhancing its capabilities we also put in an effort to fill in certain cracks. Till previous release, alert engine in every controller (Citrix Monitoring Service) worked in isolation, with every controller processing all the alert conditions. This had an impact on CPU and Memory consumption on the controller machine and a bigger one on SQL server based on the number of controllers in-play.

We re-worked the design of alert engine, it now runs as a site service, where only one controller evaluates alert conditions as compared to all the controllers. Also, in-case if the controller evaluating the alert conditions goes down, the alerting engine in the fallback controller picks up the role and starts evaluating the alert conditions.

Apart from this, there are a significant number of query optimizations made which allows alerting engine to process rules faster. As a result, CPU utilization by alert engine has reduced by half or more, not just on the controller, but also on the SQL server.

With XenDesktop 7.11 release, the new alert conditions and policies would be available for on-premise customers as well. Refer this blog for details on how these new conditions and policies would help pro-active monitoring of your environment.

More in-sync data with XenDesktop Studio console

In the current architecture, Monitoring service gets to know about a new session being launched by Broker via. an operational event triggered by Brokering service. The operational events are written to event viewer and are read by monitoring service to create appropriate objects in monitoring database. However, in several large environments it was observed that some operational events were missed and hence, there were data inconsistencies between data displayed in Director Console and Studio.

These inconsistencies gets addressed as Director does a sync-poll every couple of hours or with a midnight full-poll. With the new changes Monitoring service is provisioned with handling larger number of operational events, which means Director would display quicker and consistent information with respect to Studio.

Please keep sharing your feedback and we hope to get you more in coming editions!