This script started life because I became aware that my (former) colleagues in customer technical support were performing manual checks for customers at the start of the working day so it seemed obvious to me to automate as much as possible.
There are already some great scripts out there that will give you very detailed machine by machine health but I wanted something that would give an overview of the environment(s) given that many I work in have many hundreds of machines so one or two being unavailable at any one time isn’t necessarily a disaster but wading through an email with a list of 200+ machines trying to get a feel for overall health can be error prone.
The email that the script sends starts with a summary:
and then below that there are a series of tables to give specific details on each of these items as well as a per-delivery group summary, including scheduled reboot information, but separately for XenApp and XenDesktop since you probably want to see different information for these.
In addition it will also show the following in separate tables together with delivery group and catalogue information for each machine:
- PVS devices with the highest number of retries, which might suggest problems with storage, networking or both if the numbers are high.
- File share usage and percentage free space for a list of UNCs passed to the script.
- Availability metrics for application groups and desktops which are tag restricted since the high level per-delivery group statistics can’t give this information.
- Machines not powered on (a -excludedMachines option is available if you want/need to exclude machine names which are expected to be powered off such as PVS maintenance mode masters).
- Unregistered powered on machines which are not in maintenance mode.
- Machines with the highest number of sessions.
- Machines with the highest load balancing indexes.
The “powered on machines failed to return boot time” table may indicate where machines are in a bad state of health such as having fallen off the domain, stuck at boot, hung, etc.
The “users disconnected more than xxx minutes” table is designed to show users whose sessions have failed to be terminated by settings in Citrix policy, which I have seen at some customers, and I have a separate script to help rectify this, available on GitHub. It will also show, by cross referencing the user’s session to the User Profile Service event log on the server where Citrix thinks they have their disconnected session to see if they do still have that session as I have seen issues where this session has already been logged off. I call these “ghost” sessions and this can cause a problem if an affected user tries to launch another application that would session share on that server as they will get an error since there is no session to share. I came across a workaround for this, by setting the “hidden” flag for that session which means that it won’t try and session share in that specific session and, yes, there is a script for that on GitHub too.
If your machines are not power managed by Citrix, so the Power State shows as “unmanaged” in Studio, the -vCentres option can be used, along with a comma separated list of vCentres, which allows the script to get the power state from VMware instead. VMware PowerCLI must be installed in order for this to work.
Options wise, the script accepts the following although not all are mandatory and many take defaults (there are a few others but I’ve omitted these as they’re not especially interesting) plus you can tab complete them if running interactively and only need to specify enough of the option for it to not be ambiguous:
|-ddcs||Comma separated list of Delivery Controllers (only specify one per SQL connection)|
|-pvss||Comma separated list of PVS servers (only specify one per SQL connection)|
|-vCentres||Comma separated list of VMware vCentres|
|-UNCs||Comma separated list of file shares to report on capacity & free space|
|-mailserver||Address of SMTP server to use to send the email|
|-proxyMailServer||If the SMTP server does not allow relaying via the machine where you run the script, use this option to proxy it via an allowed machine|
|-from||The sender of the email. The default is the machine running the script but this may fail as it isn’t a valid email address|
|-subject||The subject of the email. The default includes the date/time|
|-qualifier||Prepended to the subject. E.g. “Production” or “Test”|
|-recipients||Comma separated list of email recipients|
|-excludedMachines||A regular expression where matching machines are excluded|
|-disconnectedMinutes||Report sessions disconnected over this time which should be greater than any setting in Citrix policy. Default is 480 (8 hours)|
|-lastRebootedDaysAgo||Report on machines which have not been rebooted in more than this number of days. The default is 7 days|
|-topCount||Report this number of machines per category. Default is 5|
|-excludedTags||Comma separated list of Citrix tags to exclude if machines are tagged|
It must be run where the Citrix Delivery Controller and PVS PowerShell cmdlets are available locally which can be anywhere where the Studio and PVS consoles are installed. I tend to have these installed on dedicated management servers so as not to risk compromising the performance of production servers like Delivery Controllers.
If you don’t have scheduled reboots set and don’t want to report on workers not rebooted in a given timeframe then pass zero to the -lastRebootedDaysAgo option.
I tend to schedule it to run it at least a couple of times a day for customers – once early in the morning so issues spotted can be rectified before the busier periods and again at just before midday when I think usage will be at its maximum so overloaded servers, etc can more easily be spotted and capacity increased if necessary. A typical command line to run it as a scheduled task is:
-ddcs ctxddc001 -pvss ctxpvs001 -UNCs \\clus01\AppV,\\clus01\commonfiles,\\clus01\usersettings -mailserver smtp.org.uk -recipients firstname.lastname@example.org -excludedMachines "\\(win10|win7)"
The script is available on GitHub here , requires version 3.0 of PowerShell as a minimum and is purely passive, other than sending an email, so risks associated with it are very low although you do use it entirely at your own risk. Note that it also requires the “Guys.Common.Functions.psm1” module which should be placed in the same folder as the script itself and is available ion the same GitHub repository.