Virtually Jason

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, whi

One thing that we always have to do (and people often overlook) when planning a VDI project is to understand the user environment and how to gracefully recreate their current desktop environment on the virtual desktop.  This is a big challenge, as you can tell from the fact that there are so  many tools available to solve it. In my experience the best solution is usually a combination of purpose built tools, of Group Policy Objects, and of the occasional login script.  Before you can even start figuring out which combination of tools and techniques might be most appropriate, you need to understand what currently exists in the environment... and you need a fairly accurate picture of that.  If the environment is already sophisticated with heavy use of GPOs for drive mappings, printer mappings, and critical registry settings, transitioning into VDI will be far easier than if new desktops are configured by an IT guy walking over and making all of those things by hand.  Of course, most

This is just a heads-up to hopefully save someone else a bit of time and pain... but the HP Virtual Connect doesn't support SPAN or RSPAN to mirror traffic from a physical device into the chassis to, for example, a Virtual Machine.  Basically, Port Mirroring, such as through SPAN or RSPAN, uses unicast to duplicate network traffic from a source port or ports onto a destination port.  This technique is useful for troubleshooting, in case you can't get a packet capture running on either end of a network flow, or for monitoring (as was our intended use case). IANANG (I Am Not a Networking Guy), but my understanding is that the problem is due to the nature of a SPAN port and how those packets look to the Virtual Connect.  When Port Mirroring is configured, all traffic is duplicated and sent out to the Virtual Connect.  These packets are not changed in this process, keeping their original source and destination MAC addresses; the SPAN port is forwarding these packets to the VC de