The first time I heard about PowerShell, I immediately looked for how it could fit into an overall IT management platform, from Microsoft or anyone else. Key to this is having remote access in PowerShell, which it still doesn’t have in a released version, but has in the “alpha” (or CTP) for the next version.
Once PowerShell can be done remotely, I expect to see a lot more IT management platforms take it up for scripting/execution use in Windows-land.
Remote Access, Agents & Friends
By “remote access in PowerShell” I mean being able to execute PowerShell scripts/commands over the network, on machines other than the one you’re running PowerShell on. PowerShell is, of course, Microsoft’s new, “real” shell with a new scripting language that has object-like access to everything (?) in Windows. That is, it’s finally a shell admins can use in Windows. At the moment, the production release is limited to local access only. So, for example, you can’t execute PowerShell scripts over 50 different machines on the network, or even remotely.
Why would I care about this? Well, primarily so that other IT management vendors could start using PowerShell for automation in their frameworks where they favor remote management versus agent management.
Remote management means that – more or less – you don’t need to install extra software on the boxes that your managing, where as agent management means that you need to install extra software on each managed computer/server/host. Remote management is typically more “lightweight” and limited in functionality by network bandwidth, where-as agent management is typically more “heavyweight” has more functionality because it’s not throttled by the network.
It looks like /n software’s NetCmdlets are using SNMP and some other networking stuff to hybrid out remote access.
RedMonk customer, Spiceworks, for example, does remote management; and I wager being able to execute PowerShell scripts on remote Windows boxes would make their users happy. You can imagine a little dialog box in Spiceworks – or any other platform – that allowed admins to execute PowerShell scripts, maybe even interactively, on remote machines.
Automating the use of that fantasy dialog box such that humans didn’t ever have to be involved would be the real gem.
Automation
In the interview I did with Jeffrey Snover, he mentioned FullArmor who’d sort of fallen into using PowerShell to do automation. From what I understand, FullArmor did security checking and patching, and started using PowerShell to that end. However, I’d imagine, along with PowerShell scripts, once you have the sort of job scheduling and “policy” engines that come with any sort of management (here, security), you’d probably start to think that you could have a general “if (system in some [bad] state) then (run some [PowerShell] script to fix it)” framework. Or, a Run-book Automation product.
Now, it’s sort of a gross over-simplifications, but most “low level” IT management comes down to having:
- a status checker (“is the database down or up?”)
- a “policy,” or rules engine (“if the database is down, then attempt to restart it”)
- the runtime that executes the processes and commands dictated by the policy/rules engine (“attempt to restart it” results in a script being executed).
Of course, you need all the stuff for humans: reporting that goes along with those three items, a way of configuring it all, and all sorts of other nice things, like automatically discovering all the IT things on your network.
Outside of Microsoft-land, Puppet, also with it’s own scripting language, has emerged as an interesting offering in this area, though more from a provisioning and configuration angle instead of the scripting/execution side like PowerShell.
Back to PowerShell, I can see that it’d be a nice thing to have to satisfy the “go fix it” part for Windows machines. It’ll only work in Windows, of course. But having to write that execution engine per platform is just the way things go in IT management land. At least with PowerShell, that messy landscape has the opportunity to be just a little tidier, if only for Windows.
Disclaimer: Microsfot’s STB unit is a client, paid for my travel to IT Forum and also commissioned the videos mentioned here. Spiceworks is also a client.
Technorati Tags: PowerShell, automation, puppet, windows, Barcelona, remote, itmanagement, FullArmor, itforum07, TechEd- ITForum
I’d be interested in this to the extent that it can be smart about turning plain text files into structs or rules based objects. (Like say I have a file with a number of tab seperated columns, can I pipe that as an array of arrays, or an array of structs [based on the names in the first row] and also, possibly attach some logic to this struct?)
Past that, if you have to break the object oriented mindset to handle all your stuff that isn’t built for powerset, that just doubled the number of shell programming paradigms you have to use.
This, to me, is the problem that people run into when they start talking about making a command line based around Ruby or Python.
My general impression is that it's more of a scripting programming language rather then a shell.
To me a shell is a day-to-day operating environment.. one were I can whip up quick scripts that take advantage of deceivingly 'simple' command line applications. For a admin a shell is probably more comfortable and effective UI then a GUI for most tasks.
Powershell lacks the sort of history and wealth of tools that I can take advantage of. Sure I can replicate 'ls' or 'cat' or 'grep' in a nice way with a few lines of code.. but there are always corner cases and issues that you don't expect when working on a script for 30 seconds versus a small GNU C-based utility that has been around for 15 or more years.
So it's not so much on the same level as Bash or Ksh for quick-n-dirty scripting, but more like a executable environment for Perl or Python.
Something more like:
http://ipython.scipy.org/moin/ that tries to be a in-between a shell and a scripting environment.