Virtually Jason

One of my customers had a challenge with a nonpersistent VDI pool.  They were using a web app that required some specialized software in order to work.  That specialized software installs per user, when the web app is executed.  On persistent desktops, it’s not too big of a deal, since the user installs it once and is good to go.  On the nonpersistent pool, it proved to be a pain point, as it was prompting to install every day for every user. After digging into it a bit, it turned out that the key to the install was a .cab file.  Extracting that file didn’t prove helpful, so I went another route.  If you buy VMware View, you get ThinApp along with it.  So, I ThinApped Internet Explorer and set it to WriteCopy isolation mode.  I stuck the executable onto a file share and created a ‘thinstall’ folder alongside it (so that the sandbox for that package would reside on the file share).  Once that was in place, I instructed one of the desktop administrators to execute that ThinApp and per

If you've ever dug into the guts of an ESXi host configuration, you've probably found that there are some settings that you just can't configure without the command line.  An example that I came across recently was for a customer with 3Par storage.  As per the VMware and 3Par Best Practices Guide , you should configure 3 settings on a per LUN basis: the Multipathing Policy, the Queue Full Threshold and the Queue Full Sample Size. The Multipathing Policy is easy to set through the GUI, at least if you really like clicking your mouse.  The Queue Full settings don't exist in the GUI though; to get at them, you must use the command line.  The 3Par guide helpfully provides the ESXCLI command that you need in order to configure those LUNs: esxcli storage core device set --device <canonical name> --queue-full-sample-size 32 --queue-full-threshold 4 So, just run that command on every LUN, from the command line on every Host in your environment.  Yeah, right.  In

Like so many others, I’ve recently been learning just how powerful and useful Microsoft’s PowerShell can be.  One of its best attributes is how extensible it is.  There are a ton of 3rd party plugins and modules that allow you do to amazing things, very easily.  As I use the tool more and more, I’ve found a core set of extensions that are vital for my daily work.  Besides that, there’s some client side configuration that I do in order to automatically load those modules and snapins when I start PowerShell.  Admittedly, it does make the PowerShell window take a little bit longer to open, but when I’m using those tools 90%+ of the time, I figure that it’s better to just grab them by default.  So, here is how I like to configure my administrative workstation’s PowerShell. The first thing that I do is upgrade to PowerShell 3.0.  Microsoft has PowerShell 3.0 Installation Instructions available; make sure that you follow them.  If you don’t have the correct version of .NET Framework, the

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 are just method

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 (this code is specifically wri

One of my customers was transitioning into a cloud service provider, and as such their ESXi infrastructure needed to be changed around to support this decision.  A fairly standard design element of a provider datacenter is to break up the environment into 2 vCenter environments; one for management elements and one for customer VMs.  As such, we stood up the second vCenter server... but then we had the challenge of how do we move the exiting customers into the new customer resource vCenter? It wasn't that hard, although it took a little planning to ensure that we didn't cause any service disruption to the VMs that were already running.  Adding to the complexity of the move was the fact that Distributed vSwitches were in use at this site.  Given that vCenter owns the Distributed vSwitch, we weren't sure how the system would behave if we simply took over ownership of the ESXi servers into the new vCenter, so we settled on the following procedure: Remove vShield components