Virtually Jason

One of my customers ran into a situation where they had lost track of the root passwords for their vCenter and Platform Services Controller appliances.  As they logged into devices with expired passwords, they changed them, but they had lost track of which devices had had their passwords changed and which password each device was using.  Since there was a decent sized list of potential passwords and quite a few devices, I decided that we'd all be better served by writing a script to test them for us, rather than trying them all by hand.  Aside from the boredom that would come from running the tests by hand, I was concerned about human error introducing false negatives to our results. Well, such a script is pretty trivial - I can just make an array of server names and an array of potential passwords, then nest a foreach inside of another foreach to try each password against each server.  And that's true, but then I got to thinking about security.  I really didn...

PowerShell does a lot of hand holding for you, which generally makes using it really easy.  For example, the concept of "true" is very important when building logical structures in a script, and PowerShell does its best to help you out.  And it generally does a good job, but there are some details that you should probably be aware of.  The below are all true statements: "true" -eq $TRUE "false" -eq $FALSE "false" -ne $TRUE if("true"){$TRUE} if("false"){$TRUE} So, what's happening with that last one, if we know that "false" does not -eq $TRUE?  Well, -eq is your buddy, and when you ask it if a string that reads "true" is equal to the boolean $TRUE condition, it says, "sure!".  Same thing, when you ask it if a string that reads "false" is a boolean $FALSE, it knows what you're asking and will tell you that it is indeed $FALSE.  It reads your string and figures that, if yo...