Nostalgia is ruling movies and TV these days. Mystery Science Theater 3000 has returned from the dead to Netflix. I’m still getting through he first episode, so I’m still withholding judgement. In the spirit of going back to the well and rehashing old ideas, I’ve revisited my XenApp Load/Report script again.
- I’ve moved the code to my Github account
- I’ve removed the Logon Status column and replaced it with the server’s worker group
- I’ve sorted the report by the Worker Group
- I fixed the formatting to display all the columns even if the first server was down. Before, if the first server queried by the script was down, then only the servername and status would show for all servers.
The report can be generated and sent to your browser of choice (the script defaults to Internet Explorer). In addition, you can set the SMTP information in the script have have it emailed.
Get the script from Github
If your environment leverages Provisioning Services and is fairly large, you may run into issues with servers coming up but not allowing any users to login. The fix we implemented is to reboot those servers after it’s clear that they will not allow users to login (usually sometime mid-morning when most of our users have logged in). This was a manual process and I wanted to find a way to automate this until we could change our reboot schedules or find a resolution. In this post we’ll explore using a script to catch these unresponsive servers.
Your reboot script ran last night and you find that the next day there are a handful of servers that report to the farm, but do not have any users attached. You’ve checked the obvious problems/issues and the event log isn’t any help. The only solution seems to be another reboot. Once the system comes up, users are able to connect.
In order to automate the reboots, we have to determine the criteria that identifies a server as having a problem and not just an idle server.
- It is mid-morning and most of our users are logged in and using Citrix. The server has no users connected even though the load evaluators and login behavior should allow users to connect.
- The server is marked as ‘Online’ when using the PowerShell Cmdlet get-xaserver.
- The server is a not in our excluded list (more on this below)
- The server has a high load even though it is hosting no users.
one two words for you…Worker Groups
You will have to edit the $WORKERGROUPS variable to list the Citrix Worker Groups (WG) you wish to check for zero-user servers. The list can be separated by commas. Optionally you can also edit $EXCLUDESERVERS to have the script ignore servers you do not want checked for zero-users.
The script will iterate though the servers in each WG. This is done with 2 nested foreach loops.
The script confirms the Worker Group is valid and then iterates through the servers in the WG. It checks that the server is considered Online and not a member of the $EXCLUDESERVERS list. It then confirms the server has no users connected and then checks to see if the load is greater than or equal to 3500. In our farm, this was a common characteristic for these zero-user servers. You may need to change this to better reflect your environment. I setup a scheduled task to run this script every day around 10Am and it has automated an administrative task freeing me up to write blogs about PowerShell.
NOTE that this script does not actually reboot the server. We have another script that runs all day looking for servers that are set to ProhibitNewLogOnsUntilRestart. This secondary script checks that no users are logged into a server set to ProhibitNewLogOnsUntilRestart and then reboots it. You could edit the script above to add this.
What about reporting?
If you wish to receive an email report of which servers were set to ProhibitNewLogOnsUntilRestart uncomment the above lines in the script. You will have to provide an SMTP server and a single or list of email addresses. Here’s an example of the email report:
You can download the script from Github.
Thanks for reading,