Virtually Jason

I've been working with PowerShell a lot recently and stumbled a little bit with String Manipulation.  So, I've decided to post some details of what I've learned, to hopefully help others avoid my mistakes. String manipulation can be very important when scripting, especially if the purpose of the script is to output a human readable report.  First, there's a great TechNet article on string manipulation in PowerShell .  It covers the basics in great detail; my intent is to supplement that article with some of the pain points that I came across while using those techniques. How to Trim a String Trimming a string simply means removing characters from the ends of that string.   There are 3 Trim commands: .Trim() .TrimStart() and .TrimEnd().  As the names imply, TrimStart() removes characters from the start of a string, TrimEnd() removes characters from the end of a string, and Trim() removes characters from both ends of the string.  Those Trim commands ar...

I've done some work lately to improve my desktop restart script from earlier in the month. I've made a few important changes - now the script will wait (by default 10 seconds) between restart commands so as to not overwhelm the environment. That wait time is a configurable parameter; just invoke the script with the -wait # option to set it to wait for that number of seconds. This is especially useful for nonpersistent pools, as you can pass it a highish number (such as 45 seconds) in order to ensure that the bulk of the desktops in a floating pool remain available at any one time. I've also improved the script's session handling logic. It will now restart systems with Disconnected sessions (but will still not restart desktops with Connected sessions). It is also no longer sensitive to the domain suffix of the desktops. Finally, I found a condition where it would fail to issue a hard reset for a frozen desktop, if that desktop was so frozen that the VMTools compl...

Quite a few of my customers use Firefox as their web browser.  In a VDI environment, it becomes important to customize Firefox's behavior in order to comply with corporate standards.  There's an enterprise version of Firefox , but if you're not inclined to go that route, VDI solutions make it very easy to push enterprise configurations to all of the endpoints that are using Firefox. Firefox is great because it uses config files for just about everything.  Through those files, you can make all of the commonly required configurations.  You can disable automatic updates for Firefox.  You can set a default home page (and enforce it so that the user can't change it).  You can disable the first run "Import Settings" wizard and "welcome to firefox" page.  You can disable the default browser check.  Basically, you have full control over how Firefox works and what its settings are. There are 3 files that you'll need to create: C:\Program Files (x86)\M...

One of the biggest challenges associated with VDI is supporting applications.  In the server world, we've pretty thoroughly moved to a "one application per server" mentality, so application conflicts don't really happen.  If there's a problem, it's immediately obvious which application is involved.  In general, it makes management much easier. Desktops, of course, are in the far opposite situation.  We shove as many applications into a desktop as the user needs.  This means that, when there is an issue, it can be very difficult to diagnose which application is misbehaving.  I've recently been helping a customer who has been suffering from random disconnects in their VDI environment.  The View Administrator shows the desktops with a status of either "Invalid IP" or "Agent Unreachable" and the Agent logs on the desktop haven't been particularly helpful. Eventually, we installed Liquidware Labs Stratusphere on the desktops, in orde...

Earlier, I published a quick note about basically using SSH from one ESXi host to manipulate settings across all ESXi hosts in the environment.  I've realized that it might be helpful if I include this note, around how I easily turn SSH on or off across an arbitrary number of ESXi hosts in the environment. This script is super basic - run it after connecting your powerCLI session to whatever vCenter servers you're interested in.  Then, pass it the "-h" option and a regular expression that matches the hosts that you want it to manipulate (such as *esx1* or a specific hostname or even just *).  That's it; it'll turn on the SSH service on all of those hosts, which should open the required firewall ports automatically and everything will just work. Turning SSH off again when you're done is just as simple.  Use the command the same way, but with the "-o" switch... and now the script will sweep through, turning SSH off for all hosts that match ...

As a quick followup to my note around the Full netGP Heap Issue , we've found ourselves in need of a way to easily monitor the netGP status across many hosts in the environment while we await the patch that fixes the issue.  I've searched high and low for a way to access vsish or the netGP Heap stats from PowerCLI but haven't had any luck.  So, I've put together a quick and dirty solution... but it gets the job done. All that I've done here is put together a quick PowerCLI script that generates a Shell Script (just redirect the output to a file).  That Shell Script can then be executed from one of your ESXi servers (ensure that SSH is enabled!) in order to pull information from all of the servers in your environment. $AllHosts = Get-VMHost foreach ($ThisHost in $AllHosts) { write-output "echo Host $ThisHost" write-output "ssh $ThisHost 'vsish -e cat /system/heaps/netGPHeap-0x4100013cc000/stats' | grep 'percent free of max si...

As part of the ESXi vCenter Migration  that I performed recently, we had to convert the ESXi hosts back to Standard vSwitches (from the Distributed vSwitch).  The built-in Wizards make the transition from Standard to Distributed nice and easy, but I don't know of any such path for easily moving the other direction.  We determined that we'd manually create the Standard vSwitch with all of the port groups from the Distributed vSwitch... but there were about 20 port groups that needed to be transitioned for each of the hosts in the cluster.  Aside from the arduous labor involved in that process, I was concerned about typos that might be introduced by depending on manual labor to accomplish that process.  So, I wrote a quick PowerCLI script to take care of it. This script takes 3 arguments; Host, Source and Destination.  The Host is the ESXi Host on which the operation should be performed.  The Source is the Distributed vSwitch that should be copied (thi...