Summary: Learn how to use Windows PowerShell to pass parameters to VBScript scripts and to console applications. Microsoft Scripting Guy, Ed Wilson, here. This week we will have one guest blogger for the entire week. Sean Kearney has written a series of blog posts about Windows PowerShell and the Legacy. I am not going to be redundant by reposting his biography each and every day.

Integrating Windows PowerShell with Legacy Environments—Part 3

Note: this is part three of a five part series on interacting with legacy systems. Part one talked about retrieving exit codes, part two discussed working with exit codes. Ah yes… where were we? Oh yes. The classroom, the Scripting Guy, a rather sopping wet, energetic student… …and some Windows PowerShell stories. With a spin that would have challenged the power of most cyclones, the scruffy, mostly bald, little fellow dried himself off. “Please Scripting Guy, please tell me more. You suggested Windows PowerShell could pass parameters to VBScript scripts and to console applications as well. Oh you must tell us!” he chittered like a grey squirrel. The Scripting Guy nodded. “Well then, because you are so well behaved this time, I shall finish,” he said as he casually tossed our now well-behaved friend a bag of cooked spaghetti. “Sit down, relax, and enjoy the rest of the show…” The final script was invoked:

GET-CONTENT C:PowershellLegacy3.txt | more

Because we know that console applications and VBScript scripts normally can receive parameters, it isn’t such a far stretch to suggest that Windows PowerShell could pass them along as well. We can, but just as when we communicate to Windows PowerShell from the console, we need to be equally aware of some ever so slight differences. Remember one thing about Windows PowerShell…what does it work in all the time? The numbers, the strings, the arrays? It works in objects, not in text. Even if it is working with a string, it is still an object. This means that before we send that data to the console world, we may have to sanitize it a bit. For example, here we call up a batch file within cmd.exe from Windows PowerShell and pass some simple parameters:

$value1=’Scripting Student’

$value2=GET-DATE

$value3=$TRUE

cmd.exe /c C:CaveBat1.cmd $value1 $value2 $value3

When Windows PowerShell sends this information to the batch file or console application, it sends its “best guessed” string format (similar to when you use Export-CSV) of the same data. Our first value, ‘Scripting Student’, will actually come across to the console application as follows because this is its default output converted as a string:

Scripting Student

But $value2 might come across as follows because this is what its default output will be:

Friday, May 06, 2011 11:34:00 AM

What if we wanted it to be something more useful? Say we used Get-Date from Windows PowerShell (or an application passed down a [DATETIME]-based .NET output), and we wanted something cleaner—say only the day, month, and year? We would want to convert it, and then for good measure, possibly tack on a .tostring() to ensure that we were only sending string-based output from Windows PowerShell. Or perhaps we just want the month? Or we may possibly want to pull only a ShortDate out of this information. These are things we need to consider before “dumping” that data to the console application. Here is an example:

$value2.toshortdatestring()

In this case, our console application will now receive more sensible text, as shown here.

05/05/2011

Similarly, sending a Boolean $TRUE might be a useless gesture for our console application. Perhaps numbers might be more useful to us? Again, first take the information and choose “how” it is going over.

[BYTE]$value3

So with a simple change to our values like so

$value1=’Scripting Student’

$value2=(GET-DATE).toshortdatestring()

$value3=[byte]$TRUE

cmd.exe /c C:CaveBat1.cmd $value1 $value2 $value3

We can ensure that not only are we passing parameters to console applications, but that the parameters are useful. Incidentally, we didn’t really mention VBScript did we? That’s because your VBScript application will receive the data in the exact same manner as the console application. Run it as follows in Windows PowerShell.

CSCRIPT.EXE VbScriptName.vbs $value1 $value2 $value3

The only trick to all of this is knowing that when you send data from or receive data to Windows PowerShell, you should prepare it going out or upon receipt. There you have it. You can send and receive data between the different systems, and you can return exit codes.   What does this mean to the administrator? You don’t need to scrap your existing infrastructure just to leverage Windows PowerShell.  You can simply add the piece that you need to your existing scripts. And similarly, if you have a newer setup with Windows PowerShell, but you have a vendor application that can only be managed by VBScript or that provided console-based executables, you can still work with them from your newer setup. This also means that a newer world has opened up to us. We can take our existing console applications and do new and even more interesting things with them by leveraging Windows PowerShell. And this can only mean one thing for the administrator…getting home earlier to enjoy life! “Well?” the Scripting Guy looked at his little friend. The formerly fidgety fellow was stunned. His mouth was agape. His eyes were as wide as saucers. He was, for the first time in his life, speechless. He stood up slowly and walked to the Scripting Guy, bowing down to a single knee, “Teach me your ways, O master…” Guest blogger week will continue tomorrow when Sean will continue to talk about Windows PowerShell and the Legacy. A special thank you to Sean for writing this week’s blog posts. Hope you enjoy them. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy