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