PowerShell: Friday Script Blitz

everyone-gets-powershell

Intro

In my current position I’m getting to do a lot of PowerShell scripting. Typically these are quick scripts for maintenance or finding information about our Citrix environment. I’m posting several here to share.

NOTE: These scripts were written against a XenApp 6.5 environment.

get-xacmdln.ps1

Lists active published applications’ command lines and working directories based on a search word.

psscriptblitz1a

Get it from GitHub.

get-xawgapps.ps1

Lists active published applications from a designated XA 6.x Worker Group

psscriptblitz1b

Get it from GitHub

get-xasessions.ps1

Displays total, active, and disconnected sessions from a XA 6.x farm

psscriptblitz1c

Get it from GitHub

Happy Friday!
Alain

Advertisements

PowerShell: Drain users from a XenApp Server

drain-xaserver

Intro

Citrix has provided XenApp administrators several tools to control server access. Applying load evaluators and login modes allows us to establish reboot and maintenance schedules. At times, however getting users off a server becomes urgent. In this post we’ll cover a script designed to automatically drain users off a XenApp server with different levels of “aggression”.

Scenario

Your ever-intrepid security team informs you that a user on one of your Citrix servers went to a malicious web site. While everyone is reasonably sure that the web security filters prevented anything bad from happening, you err on the side of caution and implement a standard procedure to remove the system from production, perform a security scan, get the connected users off, and reboot the server (because you’ve naturally implemented PVS and rebooting will remove any changes that have occurred since the image was last sealed). Depending on your idle and disconnection policies, this could take a while. If only there was a way to get users off a system in a timely manner without inconveniencing them too much. Oh wait…PowerShell

Why So Aggressive?

The purpose of the drain-xaserver script is to look for disconnected ICA sessions and log them off your server. But what if your users are busy working away or if you have liberal idle session timeouts? Well, in order to add some urgency to this script, I included a switch parameter that determines how long a session can be idle before it is disconnected and then logged off.

If you choose Green (the default value), then your normal idle timeouts will occur. If you choose Yellow, the idle timeout gets reduced to 30 minutes. If you choose Red, the idle timeout is further reduced to 15 minutes. You can, of course, modify these settings to be longer or shorter. Just to be clear, these settings will override your Farm-wide idle session timeouts on the server you run this script against only while the script is running.

This script checks that a compatible Logon Mode was assigned to the server before sessions get logged off. In this case, the following Logon Modes will allow the script to proceed:

  • ProhibitLogOns
  • ProhibitNewLogOns
  • ProhibitNewLogOnsUntilRestart

Otherwise, the script will not run.

While True…Do Stuff

The script checks the number of ICA sessions and as long as it isn’t zero, keeps checking every 10 minutes (adjust for your environment) for new disconnected sessions. If you have set a Red or Yellow aggression level, line 15 (above) shows how the script calculates the user’s idle time. The LastInputTime value comes from running Get-XASession with the “-full” switch. This queries Citrix for session details that are usually omitted when using Get-XASession.

The Script

I went through a lot of revisions while testing, so please let me know if you run into any issues using this script in a XenApp 6.x environment. You can get the script from GitHub.

Thanks for reading,
Alain

PowerShell: Cleanup Reboot script

cleanup-reboot

Intro

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.

Scenario

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.

  1. 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.
  2. The server is marked as ‘Online’ when using the PowerShell Cmdlet get-xaserver.
  3. The server is a not in our excluded list (more on this below)
  4. The server has a high load even though it is hosting no users.

I got 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:cleanup-reboot

The Script

You can download the script from Github.

Thanks for reading,
Alain