The Technical Adventures of Adam Weigert

Ever wanted to build native .NET objects to use while in a PowerShell script? Well I certainly have, and finally took the time to figure out how easy it is to actually do! Enjoy!

As a system administrator, I write a lot of utility scripts, and I love using PowerShell. However, I cannot always use the local scheduler with a service account to run a script, sometimes I have to provide a username and password to an application or service. I hate storing them in plaintext, and while I don't fully like storing the encrypted text, key, and IV in the script, it is one step better than the plaintext solution. While the ultimate solution would be to have it stored as part of the user profile for the job, this is an issue when I don't have direct access to the production system to be able to run as the service account and I just need an encrypted file / text to later decrypt and use.

So, I happened to come across a need for the using statement from C#. I basically didn't want to use Try...Finally when I am so used to the short-hand using statement. Thank goodness I already have a Try..Catch..Finally statement/function for PowerShell, I can just use that existing framework and make a using statement/function pretty easily.

To build on the threading library I mentioned here, I've added some functionality to make it easier to communicate with the seperate thread. Still, keep in mind that PowerShell will only allow one pipeline to be executing in a runspace at any given time. So, these new functions can only be used while the thread is inactive. But, they provide power into setting up the thread to be run and communicating with the original runspace.

Ok, so this solution really isn't threading, but a neat way to get async scripts to run! The important thing to remember is that each "thread" is actually a PowerShell "runspace". Meaning, scripts run within the thread don't have access to objects or functions defined outside the thread. The script is composed of the following commands:

I highly recommend, if you are running Windows Server 2008 or Windows Vista, to disable the network scalability features. If you don't, you run the chance of one day running into "slow" performance of an application between one client or server and another. You will spend countless hours trying to debug why the network communication is so slow to that feature from that one client when it works fine for you and serveral others in the same area and with the same configuration. As far as I am concerned, TCP offloading has been a failure since the beginning, and I am not sure who is to blame, Microsoft or the hardware vendors. Oddly enough, I even saw the "symptoms" on a virtual server.

I don't know about anyone else, but I found it annoying to have to put on three-lines of code (or one ugly one-line of code) for an IF statement for argument validation. Mostly, I want to check a simple condition and if true, throw an exception. Well, lambda to the rescue! I find the lambda version much more readable than a one-line IF statement, but that is just me -- mainly because I dislike one-line IF statements.

I will find many, many uses for this ... maybe someone else will too!