PowerShell considerations for OMS automation

Summary: In this article I talk about Windows PowerShell considerations to take into account prior to reusing existing code for Operations Management Suite automation.

 

Good morning everyone, Ed Wilson here. Well I have been getting ready for a couple of talks to be delivered to the Windows PowerShell (DevOps summit) in Bellevue next week, and this has gotten me thinking about reusing Windows PowerShell code for Operations Management Suite automation.

Reusable PowerShell code

One of the great things about Windows PowerShell is the idea that I can write code once and use it again and again and again. There is still code that I wrote years ago on Windows PowerShell 1.0 that would work today if I wanted to run it. There may be a better way to do things, but by and large things written years ago still work in today’s Windows PowerShell environment.

External input causes failure

But if I want to reuse that code for automation, then I may need to look for problem areas. Basically, any script that requires external input will fail in automation. It was common in the old days to write a script that solicited and used external input. For example, a prompt about which computer to connect to, a prompt about which functions in the script to run, or even a prompt as to what kind of output to create. These scripts were often called help desk scripts. These basically were applications used in troubleshooting that were written by experienced scripters and provided to the help desk to assist in solving some kind of rudimentary problem. The “I can’t print” question, and so the help desk runs a script that finds the default printer, attempts to connect and looks for various errors from the printer.

To use a script such as this in automation, it will require removing anything that solicits input from the user or anything that prompts the user prior to going on to the next section of code.

Output can cause failure

Not all output will cause failure … for example writing to a standard log or to a database probably will not fail, but writing to text files might fail … or it just may go somewhere you don’t know where it went. Write to the screen will definitely not work. So things like Write-Host will definitely fail. Things like Format-Table, Format-Wide, Format-List can likewise cause unexpected results. The Out-GridView will definitely be a non-starter.

For OMS automation, the best way to output from your script is to write to a log that is already being collected by OMS and then you can easily do a query and obtain your results. A technique like that leverages the best of both worlds: OMS and PowerShell.

Be aware of user context

One potential problem area is user context. For example, if I run a script while I am logged in, am I using my user context? What about if I elevate my Windows PowerShell prompt? Then what context am I running in? Ok, what about when I automate the script using OMS automation? Now what context is it running in? This is more than about rights to perform an action. It also takes into account location of modules, access to various locations: registry, file system, mapped drives, and so forth all of which can be user dependent. These types of things are the same issues I have to deal with when I simply use the task scheduler to run a script on my local computer … I need to know operating context and access to resources. Now move it to the cloud, and run it against 1000 different computers … some virtual machines, and some cloud based applications … and you can easily see where complexity can come into play. My recommendation? Keep it simple, and add logging at various critical steps in the script, and log to collected OMS logs to provide some decent diagnostic information.

Dust off the old code

So, it might be possible to reuse that old dusty Windows PowerShell code, but it is also possible that I will need to do a quick once and over to ensure that the script runs as expected. But don’t throw away the old code. I still take techniques for accessing things from old VBScripts I wrote more than a decade ago. For example I often find a registry key, or WMI class that I have forgotten about in old code. I remember the technique, and then quickly update it to using the latest cmdlets from Windows PowerShell. This is not complete code reuse, but it still saves hours of research.

That is all I have for you today. Join me tomorrow when I’ll talk about more cool stuff.

I invite you to follow me on Twitter and the Microsoft OMS Facebook site. If you want to learn more about Windows PowerShell, visit the Hey, Scripting Guy Blog. If you have any questions, send email to me at scripter@microsoft.com. I wish you a wonderful day, and I’ll see you tomorrow.

Ed Wilson
Microsoft Operations Management Team