Allonby IT Limited
Solving real problems with creative technology

Powershell

Building Reliability with PowerShell

 Do something once, use the GUI, do it more than once script it…

What i’m going on about…

As a contractor and previously in outsourcing I have been blessed with visiting many IT departments over the years and there are some things that seem to bite more bums than others…
here is my list of beastly binary butt biters:

  1. “How is that configured?”, “Well that depends who built it…”

  2. “Could i have the documentation for server ABC?”, “We haven’t written that yet as as soon as it went live we were shifted to project XYZ”

  3. “Ah well Bert knows about that server but he is on holiday / on sick leave / left the company / eloped with his next door neighbours pet dolphin”

  4. “I did it that way because we always do it that way…”

  5. “Can you give me the resultant configuration you were running with at the time of the crash / fire / flood / zombie attack ?”, “what do you mean resultant configuration?”

You get my point i’m sure but you may be wondering what this has to do with PowerShell. Stay with me , if you will, for all will become clear / clearer / slightly less opaque. I think one of the really big problems we have is that we for the most part don’t know what we have and how it is set up. We may have great project documents that were created when a solution went live but have they been updated as part of the change control system so that the reflect the current configuration? There never seems to be enough time to update documentation so we must find a way of updating it without the use of time…

Configuration management does seem to be such a problem defining what it is, what needs to be stored, how it is stored and how it is kept up to date. Perhaps that is why most rely on a backup or two to reestablish systems, but can we do things better? Certainly with serverless computing and all that jazz there will be opportunities to look at things differently. Maybe some day we will Grab a BPM system hook it up to a configuration management system , desired state management, a capacity management system, an automation system and then be able to run our IT provisioning, management and scaling as a automated process (yikes!!!)

Until then we have scripting, and it is more relevant than you might think. Plainly if we are raising a change and we can script the change in some manner then this is far more accurate then fumbling with the gui. we can also record the script into our change log and whilst this won’t give us a point in time configuration matrix for a box it will give us the steps to get to it. If we consider further what we can add to source control, at what level we interact with configuration we see that a solid understanding of scripting is essential for configuration management.

But enough of that high brow pontificating on the whys and wherefores of configuration management, lets talk code…

How I write powershell

Powershell is a belting tool, it is very flexible and extensible and so is written in as many styles and variations as there are folk writing it.

Here I would like to show the way I do it, not that I think it is better than anyone else’s but so can follow my scripts and see what i’m doing with them. The powershell pipeline of glory was trumpeted as the be all and end all of scripting constructs and it is very powerful, however, I find it sometimes a little too powerful, too confusion inducing, and prefer to modularise my code with functions, Boolean logic, loops and all that old fashioned stuff. I guess it just comes back to our motivation for scripting. I script because I want to do a task with accuracy, reliability speed and scalability. I like my scripts to be inherently easy to understand, especially when coming back to them after a couple of weeks vacation. i like to reuse parts of a script in similar scripts and i like have the program flow de-cluttered by the use of functions.

In the next code snippet i show the general layout i use when writing scripts.

By creating the guts of the script as functions they can be individually tested and also the main program flow, in the main function, can be simplified for clarity and brevity. With powershell you can only call a function after you have declared it and so as i wish to call my sub functions from my ‘Main’ function and i wish to see my Main function at the top (or as near as dammit to the top) I can declare the ‘Main’ function near the top but only call it as one of the last actions in the script after everything else has been done.

If you prefer to view the script in your regular editor then feel free to download it here.