Archive for June 9th, 2008

Your personal PowerShell script repository

How do you manage your PowerShell scripts?

Everyone who has more than a couple of scripts have to somehow manage them. After all, you need to store them somewhere. I am storing them right inside the PowerGUI admin console, and let me explain why.

In my opinion, scripts in a good script vault should be:

  1. Easy to find,
  2. Easy to use,
  3. Easy to create and debug,
  4. Easy to share.

Of course simply dumping all your files into your file system seems like the easiest way – but file system simply does not cut it:

  1. Scripts are hard to locate. You really cannot provide any meta-data for your files except in the file names and paths. So you have to come up with some kind of folder hierarchy (e.g. AD, Exchange, OpsMgr, VMware) and then very inventive filenames telling you what each script is doing and on which objects. Creating and maintaining such a taxonomy would have been an impossible task for me. But without it just keeping in mind what was it that you could do with AD users is tough.
  2. This becomes even worse when you factor in usage information. Would you really call your scripts something like: Take-CSV-with-Mailboxes-in-Pipeline-and-Change-Send-Quota-Based-on-a-param.ps1? I would not. But that means that when I need to run this script a few months later I would probably need to open the code and read the script before I figure out how to use it. A very bad experience.
  3. File system obviously does not have anything to help you create and debug scripts. You would need to install some kind of PowerShell IDE for that.
  4. And finally, sharing the scripts is what kills everything completely. How would you share a script? Attach it to an email? Well this just magnifies all the issues above because the recipient would also need to be able to find the script, learn how to use it, and so on – and in addition to that you will quickly get a version nightmare once you modify a few things and start sending a newer version around.

PowerGUI is actually a very elegant solution to all of the above

PowerGUI admin console screenshot

1. Scripts are easy to find

Any node, link or action in the PowerGUI console can be a script (just add a script node/action/link) in the UI – and the location of the script is absolutely intuitive because it follows the metaphor we all know:

  • Nodes are producing objects: so I know that I just need to browse to Exchange/Mailboxes to get a list of mailboxes.
  • Links take me from where I am to some new place: If I am looking on Mailboxes and clicking the Users link I know I will get a list of user accounts associated with the mailboxes I selected.
  • Actions obviously do something with the selected objects: Change Properties, Reset Passwords, Change Mailbox Quota, and so on.
  • The cool thing is that PowerGUI automatically displays the right links and actions based on the type of object you have in the grid. So whenever you are looking on a list of mailboxes (no matter how you got it) you will see everything you can do with them in the right-hand pane. And this is just done for you automatically so there’s no need to manually maintain any fancy taxonomy.

2. Script are easy to use

This automated placement into the UI means that scripts are also extremely easy to use. If you see a list of mailboxes and a Change Send Quota action to the right – I bet you know how to use it! You just multiselect (or filter) the mailboxes you need to change, click the action, and get prompted for a new value – right?

It does not matter how long ago I wrote the script, or even was it me or someone smarter, and whether the script has any comments inside – I just press the button and I know which one to press and what is going to happen.

3. Script are easy to create and debug

PowerGUI ships with a great PowerShell editor and debugger giving you everything you might expect in a development environment: intellisense, F1 help, tooltips, code snippets, breakpoints, variable watch, immediate execution, step-by-step debugging, and much more. Heck, we even have VBScript to PowerShell converter built-in.

4. Scripts are easy to share

If you want to share any part of your PowerGUI interface – you just right-click that action, node, or even a tree section – and click Export. This puts all you scripts in a nice xml file which any PowerGUI user can import.

As I already mentioned, you can be sure that for whoever imports your scripts using them will be a trivial task. If you share your mailbox actions with them you can be sure that they will be just getting them whenever they are managing mailboxes, right when they need them, and where they expect them to be.

In fact you can find a lot of such PowerPacks already shared by the PowerGUI community in the online library.

Or you can take the whole PowerGUI configuration – which resides in an xml file in its profile folder – and push it across your company to all the administrators who need to have this set of functionality. No more email attachments which you have to carefully read before you know how to use them, and uncertainty whether what you are using is the right version.

5. Nice little extras

And there’s more. 🙂

  • No binary format lock in: Open any of the PowerGUI xmls in a notepad and you will see that all it has are indeed your PowerShell scripts with meta information on the columns you chose to display, applied filters, and so on.
  • Standard functionality built-in: Sorting, filtering, column selection, code behind, exports and reporting, built-in cmdlet search and much more simply come with the tool.

If you are already using PowerGUI in a similar way – it would be great to hear about your experience. If not – give it a try now and see how it changes the way you work with your scripts!

Acknowledgments: thanks to Aleksandar Nikolic who gave me the idea for this post.

Tags: ,

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

June 2008

%d bloggers like this: