Powershell Script to monitor Citrix XenApp and XenDesktop 7.x Health

by Stan Czerno October 11, 2019 10:07 CST

Like my previous script for monitoring a XenApp 6.5 Farm, this script is based on the scripts written by David Ott and Jason Poyner. I decided to add to these foundations and make it something that can be used throughout the day.

I created this as an easy way for Citrix Admins and others Admins and/or Users to get a quick look of the current XenDesktop and XenApp usage as well as the basic health of the XenApp Servers, Sessions, Latency, etc. I use it as an augment to Citrix Director. 

This is in no way meant to be used for a deployment of more than 10 XenApp Servers or 50 XenDesktop Computers, but it's up to you, of course.

The page will provide with some basic reporting. Some of the reports may not be useful for Dynamic Deployments that use Provisioning Services or Machine Creation Services. 

The script features the following:

  • Shows a table of the each XenApp Servers stats, such as average CPU and Memory usage, sessions, Server Uptime, Registration State, Maintenance State, Agent Version, and Pending Reboot. 


  • Shows if the Application or System Event Logs on the XenApp Servers has any Critical or Errors Events during a configurable time span. The events can be filtered based on key phrases in the messages portion of the Event. There is a text file named EventstoIgnore.txt used for excluding Event Descriptions that you want to ignore. Partial entries can be used, examples provided. Clicking on the field will pull up a window showing snippets from the logs.


  • Shows how many Services are not running, per server. This can be configured to monitor which services are important to you. There is a text file named ServicestoMonitor.txt used for adding names of the service(s) to monitor. Partial names are accepted, examples are provided. Clicking on the field will pull up a window showing which services are not running.

  • Shows Total XenDesktop and XenApp Sessions and License Usage as well as how many session failures have occurred in the last 15 minutes and how many unregistered computers that are not in maintenance mode. Alerts will be emailed if there are more than 5 session failures or 5 unregistered computers, by default. This can be changed.

  • Shows a Graph for current Sessions, Total, Active and Disconnected. Clicking on the chart will show a window with the current sessions. There is a chart for XenDesktop Sessions and one for XenApp Sessions.


  • Shows a graph of the Top 10 Latency in any of the Sessions over 10ms. There is a chart for XenDesktop Sessions and one for XenApp Sessions.


    I find this useful when a remote user, or sometimes a local user, calls and says everything is responding slowly in their Session. The first thing I look at is the latency chart since I support remote users that connect via the Internet.

    In addition to the charts, the script will alert you if there are 5 or more sessions that are over 300ms latency. The number of sessions and the latency value can be changed via a variable in the User Variables section. I use this as a heads up that there is either Internet congestion and/or Cluster issues, usually disk related.

  • Includes basic reports such as XenDesktop and XenApp usage, Citrix Receiver Versions, XenDesktops not used in last 60 days, all XenDesktop and XenApp Delivery Groups, and all XenApp Published Applications, etc.

 

Before you begin: 

The User Variables Section has values that need to be set before running the script. Each variable is annotated in the script.

The script has several arguments that I broke up to increase the speed at which you can collect stats. The Latency and XenApp info can take some time to run depending on the number of Servers, Desktops and/or Sessions.

What I do is schedule the different arguments to run at different time spans. For example, I run the Latency arguments once a minute. I run the "XAInfo" once every fifteen minutes and the "Current" argument once every two minutes.

Valid Arguments for the script are: FirstRun, RunReports, XDLatency, XALatency, XAInfo or Current. 

A description of each is listed below:

  • FirstRun: This will run all routines of the script. This will run every part of the script in order to populate all required files for the HTML page to display correctly. This only needs to be ran once.

    Usage: XDandXAHealth.ps1 FirstRun
    Task Schedule Note: This does not need to be scheduled, it is ran manually one time. Be sure to run it from the folder in which it is located.

  • RunReports: This will run Daily Reports such as XenDesktop and XenApp Usage for Yesterday, Last 7 days, and Last 30 Days as well as Client Version Reports and XenDesktop Delivery Groups idle for x days. This should be ran at least once per day, preferably at 12AM.

    Usage: XDandXAHealth.ps1 RunReports
    Task Schedule Note: Only needs to be ran once a day, sometime after midnight.

  • XDLatency: This will collect XenDesktop Session Latency and create a graph to display in the final HTML output page.

    REQUIREMENT: Remote Registry must be enabled on the XenApp or XenDesktop Computer in order to read the Performance Counters. This can be achieved with a Group Policy.

    This argument can be scheduled to run once per minute, it'll probably take longer than a minute to run, but Task Scheduler will just run it at the next scheduled time. 

    If you do not want to collect latency counters at all, just do not schedule these arguments and simply set the "$CollectLatency" variable to "$false" so the FirstRun argument skips it.

    Usage: XDandXAHealth.ps1 XDLatency
    Task Schedule Note: Can be scheduled to run once every minute.

  • XALatency: This will collect XenApp Session Latency and create a graph to display in the final HTML output page. 

    REQUIREMENT: Remote Registry must be enabled on the XenApp or XenDesktop Computer in order to read the Performance Counters. This can be achieved with a Group Policy.

    This argument can be scheduled to run once per minute, it'll probably take longer than a minute to run, but Task Scheduler will just run it at the next scheduled time. 

    If you do not want to collect latency counters at all, just do not schedule these arguments and simply set the "$CollectLatency" variable to "$false" so the FirstRun argument skips it.

    Usage: XDandXAHealth.ps1 XALatency
    Task Schedule Note: Can be scheduled to run once every minute.

  • XAInfo: This will gather all of the XenApp Servers metadata, such as CPU Usage, Memory Usage, Active and Disconnected Sessions, Critical or Error Events in the Event Logs, etc.

    This could be ran at least once every 10 minutes, for small deployments. If you have a large deployment of XenApp, you may need more time for this portion of the script to complete. Again, this solution is not for deployments with more than 10 XenApp Servers and more than 50 XenDesktop computers.

    If more time is needed for your Scheduled Task be sure to update the User Variable named, $EventLogCheck, to match your Scheduled Task Interval. This is how far back the script looks for Critical or Errors in the Event Logs and before it displays an error in the HTML that the script has not been updated recently.

    Usage: XDandXAHealth.ps1 XAInfo
    Task Schedule Note: Can be scheduled to run at least once every 15 minutes. 

  • Current: This will gather all current XenApp and XenDesktop Sessions and creates the HTML output page.

    This can be ran has often as you like as it just polls the DDC and updates two graphs, four text fields and creates the HTML.  I schedule it to run every two minutes.

    The routines for the "Current" argument will always run, regardless of which argument you choose. 

    Usage: XDandXAHealth.ps1 Current
    Task Schedule Note: Can be scheduled to run at least once every 2 minutes. 
Latency Data
You have the choice of saving the Latency data in a SQL DB. There is a CSV file created if you do not want to use the SQL option. If you choose to use the Database feature to save Latency Data, there is a Text File included named "CreateSQLDBandTable.txt" that can be used to create the DB and Table for storing the latency data. Just run the query on your SQL Server to create the DB and table. Assign the appropriate permissions to the user running the script.
 
Fill in your SQL Server name in the variable $SQLDBName
 
A Basic SSRS Report is also included name "Average Latency Report.rdl". You'll need to edit it to change the data source and upload it to your SSRS report server.
 
If the SQL portion is overkill for you and you do not want to use the SQL option, simply set the "$UseCustomDB" variable to "$false" and the data will only be saved to a CSV file. You can always tackle the SQL part later.
 
Again, if the latency is not needed at all, you can simply set "$CollectLatency" variable to "$false" so it is not run on the FirstRun argument and then you would not schedule the XDLatency or XALatency arguments to run at all.

One final note, you may receive 500 errors, when the page auto refreshes, if the refresh coincides with the file copies. Just refresh the page if you get a 500 error and it should display properly.

Getting it ready to run:
Unzip the file into it's own folder and run it from there. There will be sub-folders and log files created so it is important to run the script from the folder it is in.
 
The Citrix Powershell modules are required so it is easiest to run this from a Delivery Controller.
 
When scheduling the task, be sure the "Start in" folder is set to the folder where the script is located.
 
The user running the scheduled task will need Citrix Admin permissions, Citrix Director permissions and any folder permissions to where you will copy the files to as well as appropriate Workstation and Server permissions to utilize the latency data counters, if using the latency data.
 
Task Scheduler command line example: 
Program/Script: powershell.exe
Add arguments: -executionpolicy bypass -file C:\Scripts\Monitoring\XDandXAHealth.ps1 XAInfo
Start in: C:\Scripts\Monitoring
 
Zip file: XAXD7xMonitor.zip.zip (74.3KB)

Tags: , , ,

Catergories: Citrix | XenApp | XenDesktop | Powershell

Add comment