So far this week, we’ve taken a look at creating an inventory of a XenApp 6 farm and explored sending email reports of what we’ve gathered. We also took a look at checking out application consistency and publishing settings, one of the most common issues we find at customer sites. Now we’re going to jump into basic networking and logging with PowerShell, and how you can use it to make sure your servers are up. We’ll also touch on the topics of error catching and piping.
The good news is that, if your health check tests are working well, this script shouldn’t uncover much new (it will alert you to servers that have logons disabled), but the concepts can be combined with other scripts or other server types.
One new thing that you’ll notice below is the section with “Out-File” and the pipe symbol ( “|” ). The pipe symbol essentially means: take the output from the left side, and send it to the cmdlet on the right. In this case, the output is pure text and it’s being sent to a cmdlet called “Out-File”, which writes the content to a file. We write the echo command twice so that we see the output in both the console and the log file.
We’ll start off with the easiest way to see if a server is up: the ping. We’ll test two methods – by IP and by DNS host name. If DNS isn’t properly resolving, then depending on how you have your environment set up you may run into issues.
To ping the server, we create a Ping object, and we’ll grab the DNS and IP name from the server properties. We’ve set the second parameter for the $ping.send method to 100, which means that the script will wait 100 milliseconds before assuming it won’t receive a response. If your environment is latent, you might want to increase this. Please note that the script will wait that amount of time for a ping to return before continuing – setting it to ten seconds will mean that the script will either go as soon as it gets a response, or it will hold for 10 seconds and not do anything.
In this section of the code, lets make sure the server has logons enabled. We can do this by checking the server properties.
If you’re paying close attention, you’ll notice I used a different command to output the information to console: Write-Host. This command gives us more control over the visuals of how text should appear – in this case, we’ve changed the text color to Red to make it more visible in the console.
So now we’ve confirmed logons are enabled and the server is up. Let’s make sure the port is open:
We see a couple of things here – first off, we’ll only continue if the ping resulted in a success. We’ll then attempt to make a connection – if it fails, the script will throw an exception, so we want to make sure we catch it instead of just aborting the script as would normally occur. We check to see if the port is open by creating a new TcpClient object with the IP of the server and the ICA port number.
Now, if it manages to connect, we’ll almost definitely be in the clear, but just to make sure let’s check to see whether it’s actually ICA listening on that port and not some other service.
Looks scary! Let’s break it down. First off, if the socket did connect, we’ll get the stream of what’s happening. First we set $stream to the socket stream, $buffer to act as a holder, and $encoding to help us translate the text. Then we’ll wait a half second for a response from the port. If we get any kind of a response, $stream will be storing the data and we can pass that to a temporary variable called $read. We can then translate the response using $encoding to a regular string. Phew.
Now the fun stuff – we’ve seen “-eq” and “-ne” before to compare variables, but now we see “-like”. This operator allows us to grab partial strings, which we want to do in this case. If ‘ICA’ appears anywhere in the string (the asterisks act as wildcards), we’ll get a true response. Notice we output that to the console in green text.
If we take a look at the log file, we’ll see the same output as we saw in the console. This is useful for tracking linear information, but it’s also great for creating tabular data (.csv’s, for example) that we can then analyze in something like Excel. This is where PowerShell can become extremely powerful – the possibilities become vast for things like analytics or inventories.
More posts are going up the rest of the week – if you want to learn more, keep watch on the Citrix blogs, follow me on Twitter (@mcbogo), and sign up for next week’s TechTalk that will go over both XenApp and XenDesktop programming. Go sign up for the Essentials for using Windows PowerShell with XenApp and XenDesktopset for Tuesday, August 24 from 2pm to 3pm EST. And if you’re interested in PowerShell scripting for XenDesktop, make sure you check out Ed York’s XenDesktop blog series. It’s great!