Gallery

Shell power for Windows

Posted on 29 Jun 2006 at 11:22

Thomas Lee looks at microsoft's cool new administration shell and scripting tool, powershell, and finds out how it fits into the .NET framework

PowerShell is designed to work the way administrators, as opposed to end users, work, using interactive shell commands and scripts. However, you can still employ the MMC GUI for some tasks - perform some functions in the MMC, then press a button and there's a script that carries out those same functions. PowerShell overcomes the limitations of cmd.exe and provides all the functions needed for automating day-to-day operations.

How PowerShell works

PowerShell's remarkably tiny installation MSI does all the normal installation things, creating an installation folder called %programfiles%\Windows PowerShell\v1.0 and copying the core PS files and support tools into it. You also get some Registry entries set up under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 to manage versioning (note that 'v1.0' in the program files and that \1 in the Registry key).

PowerShell Scripts have a file extension of PS1, the idea being that the final numeral, here 1, will change with each version. So you can have side-by-side installations of v1 and v2, and scripts will target the right version. The installer also adjusts the system Path entry, adding "C:\Program Files\Windows PowerShell\v1.0\" so that the system can find powershell.exe, the main executable. powershell.exe is in fact an unmanaged application that merely determines the environment that's required and then dynamically loads the correct version of the CLR and the shell itself, which is all managed code.

The PowerShell host is implemented by microsoft.powershell.consolehost.dll, a small DLL that supports the PowerShell console interaction: consolehost.dll calls the PowerShell engine to display a Command Prompt and collect user input for processing. The bulk of PowerShell's functionality is implemented by system.management.automation.dll, located in the PowerShell installation folder (%Programfiles%\windows PowerShell\v1.0 by default).

One of the things that excited me early on was that a key design goal of this product is to enable administrators to access the power of .NET in an admin-centric, as opposed to programmer-centric, way. But what does that actually mean? When you use almost any admin tool, you first get an object or objects to manage; you use the tool to establish context and point to a Registry key or an OU. Then you do something to that object, say, adding some new keys to the Registry, changing a password or whatever. This second action may also include reporting on the objects and their statuses.

Here's a script fragment that checks a series of folders to see if a particular file is present, and if not prints a message:

$root = ls C:\ | Where {$_.PSIsContainer}

$folderok = 0

foreach ($dir in $root){

$nam = $dir.name+"\md5OK"

$ok = ls $nam -ea silentlycontinue

if (! $ok){ write-host "MD5 Check missing in $($dir.name)"}

else {$folderok++}

}

write-host "$($root.count) checked, $folderok are OK"

This script first scans the root folder of my C drive, selects just the folders in the C drive and assigns this set of entries to the variable $root, an array of directory entry objects. Then the script looks at each folder object in this array to see if it contains a file called MD5OK (a short flag file indicating that all the files in this folder have had their MD5 Checksum validated). The script displays a message for any folder where this file isn't present, and finally prints out a summary of the results. The objects to be acted on were first selected, then processed, with some summary reporting. Of course, this is a highly simplified example, bereft of error handling (for example, what happens if the C drive had no directory entries?), but it illustrates an administrative approach. I developed and use a set of scripts similar to this one to manage a large file store (around 1,500 folders, each with between five and 50 files, 50MB to 500MB in size).