“Go away or I will replace you with a very small shell script”

[T-shirt slogan from an attendee at tonight’s Windows PowerShell for IT administrators event.]

I’m back in my hotel room having spent the evening at one of Microsoft UK’s TechNet events and this time the topic was Windows PowerShell for IT administrators. I’ve written previously about PowerShell (back when it was still a beta, codenamed Monad) but tonight’s event was presented by Richard Siddaway from Perot Systems, who is not only an experienced infrastructure architect but also leads the PowerShell UK user group and thinks that PowerShell is one of the best pieces of technology ever (maybe a touch OTT but it is pretty powerful).

The event was demo-heavy and I didn’t grab all of the example commands (Richard plans to publish them on the user group website this week) so this post concentrates on what PowerShell can (and can’t) do and I’ll link to some more examples later.

What is PowerShell?
According to Microsoft, PowerShell is the next generation shell for Windows that is:

• As interactive and composable as BASH/KSH.
• As programmable as Perl/Ruby.
• As production-oriented as AS400 CL/VMS DCL.

In addition to the attributes described above, PowerShell is extensible with snapins, providers and scripts. The provider model allows easy access to data stores (e.g. registry, Active Directory, certificate store), just as if they were a file system.

Scripting is accomodated in various forms, including text (Microsoft’s interpretation of the traditional Unix scripting model), COM (WSH/VBScript-style scripting), Microsoft.NET or commands (PowerShell cmdlets, emitting Microsoft .NET-based objects). As for the types of data that PowerShell can manipulate – it’s extensive, including flat files (CSV, etc.), .NET objects, XML (cmdlets and .NET), WMI, ADSI, ADO/ADO.NET and SQL.

So, PowerShell is a scripting interface with a heavy interface on Microsoft.NET – are programming skills required?
Not really. As Richard described, just because you can use native .NET code doesn’t mean that you should; however the more that you know, the more you can do with PowerShell.

Basically, simple scripts will need some .NET functions such as [STRING] and [MATH] and advanced scripts can use any .NET object but cmdlets provide an excellent administrative and scripting experience and are easier to work with – writing .NET code can be thought of as a safety net for when something isn’t possible using another method, rather than as a first port of call.

Where can I get PowerShell?
Although it a core element of the Windows Server System, providing automation and integration capabilities across the various technology platforms, PowerShell is a separate download for Windows XP (SP2)/Server 2003 (SP1 or later, including R2)/Vista and will be included within Windows Server 2008. Note that PowerShell is not supported on Windows 2000.

How can I learn to use PowerShell?
PowerShell’s documentation includes a getting started guide, a user guide, a quick reference guide and help text. Microsoft Switzerland has also produced a short Windows PowerShell book that’s available for download free of charge, there are plenty of other books on the subject and a “young but keen” community of administrators exists who are discovering how PowerShell can be put to use; however it’s probably best to just get stuck in – practice some ad-hoc development:

• Try things out in an interactive shell.
• Stitch things together with utilities and put the results in a script file (then realise that the tools are unsuitable and restart the process).
• Once happy with the basic concepts, generalise the code (e.g. parameterise it) and clean it up (make it production-quality).
• Once tested, integrate the PowerShell scripts with the infrastructure to be managed and then share scripts with the community.

One more thing – remember that it’s better to have many small scripts that each do one thing well than to have a behomoth of a script that’s very inflexible.

Is there anything else I should know before getting started?
There are a few concepts that it’s worth getting to grips with before launching into PowerShell:

• Cmdlets are a great way to get started with PowerShell. Based on a verb-noun naming, they each provide specific functionality (e.g. get-help and make the resulting code self-describing (hence suprisingly easy to read).
• The pipeline (think Unix or MS-DOS) – allows the output of one instruction to be fed into the next using the | symbol; however, unlike Unix/MS-DOS, .NET objects are passed between instructions, not text.
• There is a text-based help system (cf. man pages on Unix-derived operating systems).
• PowerShell is not case-sensitive (although tab completion will sometimes capitalise cmdlets and parameters); however it’s worth understanding that whilst double quotes (" ") and single quotes (' ') can be used interchangably, variables enclosed in double-quotes are resolved to their value, whereas the single-quote variant is treated as a variable.

There are also some issues to be aware of:

• The default installation will not run scripts (not even the user’s profile) and scripts need to be enabled with set-executionpolicy.
• There is no file association with PowerShell (for security reasons), so scripts cannot be run automatically or via a simple double-click. Scripts do normally use the .ps1 extension and although PowerShell will recognise a command as a script without this, using the extension helps PowerShell to work out what type of instruction is being issued (i.e. a script).
• There is no capacity for remoting (executing code on a remote system) but workarounds are possible using .NET and WMI.
• The current working directroy is not on the path (as with Unix-derived operating systems), so scripts are launched with .\scriptname.ps1. Dot sourced scripts (e.g. . . \scriptname.ps1) run in the context of the shell (rather than in their own context).
• Although PowerShell supports use of the entire Microsoft.NET framework, not all .NET assemblies are loaded – some may need to be specified within a script.

Are there any other tools that work with PowerShell?
Various ISVs are extending PowerShell. Many of the tools are currently available as trial versions although some are (or may become) commercial products. Examples include:

• Quest Management Shell for Active Directory (which will be included in a future version of ActiveRoles Server).
• Quest PowerGUI (providing a GUI front-end to PowerShell script generation).
• PowerGadgets (providing graphical output from PowerShell scripts).
• PowerShell community extensions.
• PowerShell Analyzer tool (editor and IDE).
• FullArmor Workflow Studio PowerShell add-ins (integrate PowerShell with the Windows Workflow Foundation).

Where can I find out more?
The following links provide more information about PowerShell:

• Microsoft PowerShell team blog.
• Microsoft PowerShell FAQ.
• PowerShell UK user group (get-psuguk).
• Richard Siddaway’s blog.
• microsoft.public.windows.powershell newsgroup.
• Windows PowerShell Wiki.
• Microsoft Script Center: Scripting with Windows PowerShell.
• Thomas Lee’s PowerShell Information Centre.

Back in June 2004, I got in a panic because I heard that VBScript was about to be phased out. Don Jones commented that VBScript will still be there in Windows, it just won’t be developed any further, then later I heard about the new Microsoft scripting host (MSH) shell (codenamed Monad).

At yesterday’s IT Forum ’05 highlights (part 2) event, Thomas Lee gave a preview of Monad. Although I am enrolled on the Microsoft command shell beta program, pressures of work and family life have left very little time to do anything with it up to now, but having seen Thomas’ demo, I’ve installed MSH beta 3 on my day-to-day notebook computer and will try to use it instead of cmd.exe, regedit.exe and some of my other everyday tools.

Those of us who have worked with Windows since… well since MS-DOS… will remember the command prompt, as will those who use other operating systems. Graphical user interfaces (GUIs) are all very well (and a well designed GUI can be remarkably intuitive), but a command line interface (CLI) is my preference. Despite a whole load of new and powerful commands in recent Windows releases (like netsh.exe), Windows still lags behind Unix in many ways when it comes to command line operations and MSH is an attempt to catch up with, and then exceed, the tools provided by other operating systems.

MSH is a next-generation shell that is intended to:

• Be as interactive and scriptable as BASH or KSH.
• Be as programmatic as Perl or Ruby.
• Be as production-oriented as AS/400 CL or VMS DCL.
• Allow access to data stores as easily as accessing file systems.

It sounds like a tall order but amazingly, Microsoft seem to have cracked it. MSH is also pretty easy to use and, it’s secure by default, avoiding many of the issues associated with VBScript. So secure, in fact, that before running MSH you may wish to execute the following registry change:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSH\1\ShellIds\Microsoft.Management.Automation.msh]
"Path"="C:\\Program Files\\Microsoft Command Shell\\v1.0\\msh.exe"
"ExecutionPolicy"="Unrestricted"

(There’s more on MSH security below).

MSH is instantly recognisable. If I was to type cmd, I would be greeted with something similar to the following:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>

If I type msh instead, everything is very familiar:

Microsoft Command Shell
Copyright (C) 2005 Microsoft Corporation. All rights reserved.

MSH C:\>

Type dir and guess what happens? For that matter, type ls! If you want to see the contents of a file then either type filename or cat filename will work too. get-history returns a list of commands, to re-run, save, or edit.

Whereas Unix (and Unix-like) systems tend to store configuration in text files, Windows configurations are incredibly complex with multiple data stores (the registry, text files, DNS, Active Directory, etc.). These data stores normally fall into one of two categories: hierarchical, highly recursive data structures (file system directories, registry keys, Active Directory organizational units, etc.) or fairly flat structures (e.g. DNS zones and records). MSH makes them all easy to navigate using a system of data providers.

For example, I can type cd hklm: followed by dir to see all the HKEY_LOCAL_MACHINE keys, navigating the registry as though it were a file system. This simplicity is both elegant and incredibly powerful. There are no AD or DNS providers yet, but the next version of Exchange (codenamed Exchange 12) will include MSH support, treating Exchange databases as just another data store (get-mailbox, etc.). Exchange 12 support is not implemented as a data provider, but as a commandlet (cmdlet), because its data structure is not really hierarchical (at least down to the mailbox level) – the full list of Exchange commands can be found using get-excommand.

For example, if I want to see the details of my system, I can use get-wmiobject command. That’s a bit long to type, so I can actually use get-w and then complete the command with the tab key (as can in cmd.exe these days). get-wmiobject win32_computersystem returns the details of my system as an object with attributes, that I can assign to a variable (e.g. $mysystem=get-wmiobject win32_computersystem). After that, $mysystem.name returns the name of my computer, $mysystem.manufacturer returns Fujitsu Siemens and $mysystem.model returns Lifebook S7010. That would have been so much harder to obtain in VBscript. Take it to the next level and you can see how the data can be queried and actions taken according to the results (e.g. if ($mysystem.model -eq "Lifebook S7010") {"Do something"}).

MSH has built in help (e.g. get-wmiobject -?) and more is no longer an external command so get-wmiobject -? | more works too.

Some commands will return an array of objects, for example get-wmiobject -list. That’s a pretty long and unmanageable list but if I use $wmilist=get-wmiobject -list, I can use $wmilist.length to see how many objects were returned, $wmilist[objectnumber] to view a single object and of course I can also use $wmilist[objectnumber].attributename to refer to a single item.

On a typical Unix system, pipes are used to pass text between commands. Scripts can be used to split strings and extract data (also known as prayer-based parsing, because if the command output is changed, the scripts break). MSH pipes are .NET objects with metadata. That means that a hierarchy of objects can be passed between commands. So, I can also show my WMI array as a table by piping it through format table (ft), i.e. $wmilist | ft (fl is format list).

Having looked at how simple to use, yet powerful, MSH is, let’s look at some of the product specifications:

• MSH is intended to support a number of different administrative levels:

• Operators – command line only.
• Simple scripters – simple sequences, untyped variables and functions with unnamed parameters.
• Advanced scripters – typed variables and functions with named parameters.
• Sophisticated scripters – scoped variables, functions with initialised parameters, function cmdlets and scriptblocks.

• Text – .NET interpretations of the traditional Unix scripting model.
• COM – Windows script host (WSH)/VBScript-style scripting.
• .NET – for manipulating any native .NET object.
• Commands – MSH cmdlets emitting objects.

MSH is intended to be tremendously customisable and it will eventually allow dispense with the style separation between GUI, CLI and systems programming skills so that even an infrastructure bod like me will be able to issue a GUI command (or use a Win32 program) and see what the MSH equivalent command is, so that I can build my own scripts and run a task repeatedly! Unfortunately this GUI-CLI functionality has been dropped from the first release, but hopefully we’ll see it in a service pack later.

From a security perspective, MSH is extremely secure, with four operational modes:

• Restricted mode allows interactive operations only, with no script execution.
• AllSigned mode requires that scripts must be signed by a trusted source.
• RemoteSigned mode requires that scripts from the Internet must be signed by a trusted source.
• Unrestricted mode will allow any script to run, but will always warn before remote scripts are executed.

Other security measures include:

• No file association for .msh files.
• The current folder (.) is not on the path by default.

So when can we get MSH? Beta 3 is available for download now and the final release is expected with Exchange 12. Although MSH will not included with Windows Vista, I’m told that it does work on a Vista/Longhorn platform.

Finally, for one more example of how easy Monad can be to use, try this:

"Monad Rocks " * 200

Links
Thomas Lee’s Monad information centre
Monad on Channel 9
Monad product team blog
MSH on Wikipedia
microsoft.public.windows.server.scripting newsgroup

Another gem gained from my anonymous colleague is the use of the %0 environment variable (which returns the current command name in the same way as %1, %2, etc. return any arguments passed to the command) to avoid using hard coded paths in scripts. For example, %0\..\ refers to the directory in which the file is located, and can be used where a pathname is required, but the drive letter may vary, e.g. %0\..\scripts\ (where the scripts folder could be on any available drive, but always the same drive as the calling command).

One of my colleagues (who wishes to remain anonymous) gave me a great tip this morning – how to delete registry keys and values using a .REG file.

To delete a value, set its contents to – in the .REG file, e.g.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\MyKey]
"MyValue"=-

Or to delete a key, add a – sign after the leading [ in the .REG file, e.g. [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\MyKey]

Apparently this works on all version of Windows from Windows 2000 onwards, although I’ve only tried it with Windows XP Professional.