Virtually Jason

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 Process

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 compa

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

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 Aliase