VMware Logon Monitor

When rolling out a VDI solution (or really, anything that touches on the user experience), it's crucial to understand how the change might impact the users and to ensure that they are left with a good impression of the solution.  They say that first impressions are most lasting, and the first impression that your users are going to see (for most solutions) is logon time.  That means that it's crucial that your solution does not negatively impact logon times, as that will color the entire experience.  So, how do you accurately measure it?

Well, VMware released a Fling called Logon Monitor (and, it's now baked into the Horizon 7.2 agent).  It's a tool that's sole purpose is to measure the logon process and to report on what's happening during a user logon.  After it's installed, it logs (with excruciating detail) everything that occurs during a logon, storing the file in a default location of C:\ProgramData\VMware\VMware Logon Monitor\Logs

It creates a file f…

vSAN RAID Levels and Fault Domains

One of my customers is considering implementing vSAN, so I've been researching it quite a bit lately.  The interactions of vSAN RAID levels (for all-flash configurations) and Fault Domains is fairly complex, so I figured that I should post some notes about what I've learned here.

First, the concept of RAID is a little different in vSAN than it is in a traditional array.  Traditionally, RAID specifies the algorithm used to spread data (or parity data) across a set of disks.  For example, RAID 5 specifies that data will be striped across all of the disks in a set, with a single disk's capacity used for parity.  This means that a 3 disk RAID 5 set will store data on 66% of its disks' capacity.  A 5 disk RAID 5 set will store data on 80% of its disks' capacity.

vSAN treats RAID differently.  There are 3 different RAID types that vSAN supports: RAID 1, 5 and 6.  Like in a traditional array, these RAID levels describe the data redundancy algorithm used, but the members a…

Group Policy Loopback Processing on Windows Server 2012

Every now and then (especially in a VDI situation), I need to enable Group Policy Loopback Processing.  This Group Policy setting can do a lot of things; I usually use it to allow me to create Group Policy Objects that contain User Configuration settings that only apply when the users log into a certain subset of computers (such as my VDI desktops).  When that setting is enabled, it basically instructs windows to process its computer GPOs again at user logon, so as to catch any User Configurations that are specified.

This is a setting that I configure once for each VDI deployment that I do, and I always need to look up where it is (who bothers to memorize where specific settings are amongst the thousands of options!?).  No problem, that's literally what google was made for.  So, a quick search for Group Policy Loopback Processing is in order, which brings me to a technet article about Windows Server 2003 that calls the setting simply Loopback processing.  Well, Loopback Processin…

Finding Stale Brocade Zone Configurations

I recently wrote about a situation where I was creating a zoning configuration and had to figure out which fiber channel devices were active.  After we finished that project, we decided that we should go through and actually remove the inactive aliases and zones.  We had a list of active devices, so we were all ready to move forward and say "delete everything that isn't on this list!".  That'll work great, right?

Of course not; we needed the opposite.  "Delete everything that is on this list" is a far better instruction that is way less likely to lead to painful mistakes.  Even better is "run these commands to delete all of these unnecessary objects" and I know one good way to generate such a list of commands: a script (I feel like I'm developing a battle-cry...).

I put together a script that does a few basic things.  First, it uses the nsshow command to get a list of all of the active WWNs on a given Brocade fiber switch.  Then, it compares a…

Decommissioning Specific SAN Datastores En Masse

One of my customers recently purchased a new SAN, with the goal of decommissioning the old one.  They used Storage vMotion to migrate all of their VMs over to the new SAN and adjusted all of the ESXi hosts to put their scratch space on a new LUN, and were ready to proceed.

Many people, at this point, would just turn off the old SAN... and they might be ok.  Maybe.  At that point, the ESXi hosts are going to seriously freak out, because they just encountered an unexpected SAN failure... and we've all seen that sometimes, ESXi doesn't respond well to losing datastores unexpectedly.

So, the more cautious people would right click on each datastore and unmount it, then turn off the old SAN.  While not as bad as just turning off the SAN, the ESXi hosts still expect those LUNs to be there (even if they're no longer mounted as datastores) and can still run into issues.

Miss Manners insists that people follow the procedure detailed in KB 2004605.  That article includes a lot of im…

Getting Active Brocade Fiber Switch Aliases via PowerShell

A while back, I posted a quick script to create commands for 1:1 Zoning on a Brocade Fiber Switch.  I was recently helping someone go through that exact process on a set of switches that had a lot of aliases already defined on them.  Their challenge was that they weren't sure which aliases were for their current SAN vs. a retired SAN.  Rather than just creating zones for both SANs, I decided to put together a quick script that would scrape their current Aliases and check which ones have active WWNs currently in the system.  They could then use this information to prune the Aliases that are no longer needed, in addition to only creating the required zones for our project.

In order to do this task, I had to do some quick string parsing into PowerShell objects.  Good thing I already know how to do that ;)  So, I put together this script which does two things:
1) It parses the Brocade Fiber Switch's configuration to look for any Aliases
2) It checks the WWNs for those Aliases agai…

Nested Progress Bars in PowerShell

I've been working on some scripts lately and just learned about nested progress bars, which are really cool!  In fact, progress bars are a tool that I'm going to use far more often in my scripts, for a few reasons.  First though, let's talk about script output.  In my opinion, there are three basic types of output that a script generates: information as the result of the script, run-time errors, and information about the progress of the script.  We're going to ignore the run-time errors and just talk about the output that is generated by a successful script execution: information about what the script is doing right now, and information that the script has retrieved as a result of its actions.

In general, it's super helpful to be able to store the results of a script in a variable for future manipulation/archival/whatever.  I do this by using syntax like $a = ./myScript.ps1.  That will take whatever output the script generates and store it in the variable $a, which…