Windows PowerShell

Started spending some time with Windows PowerShell, an next generation command shell and scripting environment for Windows. It can be downloaded from Microsoft's site. It's essentially finally an update to the classic DOS commands, providing simple commands for interacting with WMI, the file system, the registry, etc. The syntax is closer to .Net, and return values are actually rich .net data types.

After PowerShell is installed, you get a new 'console' (type 'powershell' in the run box to access) The syntax of PowerShell commands is verb-noun and has a fairly intuitive layout, I think this contrasts nicely from the DOS commands with vestiges of the 8.3 file names. In PowerShell, the following two commands will likely be the first you run:

• get-command (lists all available commands)
• get-help {command name} (lists further details on the given command)

DOS vs. VB Script vs. PowerShell
If DOS commands are the 1.0 version of an admin's 'console', powershell could be considered 2.0, and perhaps VBScript (or, yes, any WSH compatible scripting language) would be 1.5. While DOS relied on imperative commands, the admin using it didn't really have to 'think' like a programmer. To do any work with the file system or registry, without having a very obscure DOS batch file, VBScript had to be used. Also to do any work with WMI, VBScript had to be used. However to use VBScript, the admin really did have to think like a programmer, with looping, conditionals, object instantiation and disposal, etc. being for many tasks, critical for use. I've introduced a number of non-programmers to VBScript (WMI, etc.), and the barrier is two-fold, they have to learn the steps to accomplish the task at hand (i.e. retrieving, or setting something through WMI), as well as learn a modest amount of programming concepts they may have never dealt with. Sometimes that is a reason to stick with a DOS batch file to accomplish a step of the task, such as copying a file using 'xcopy' vs. using VBScript where the process may be more elegant and allow for more structure such as error handling (albeit in a rudimentary form)

PowerShell moves back to the DOS batch file type usage scenario, where an admin (non-programmer) can focus on the task at hand, with modest understanding of programming concepts , such as looping , conditionals and variables, and nearly no necessity of understanding objects lifetime concepts. In PowerShell, most commands return and accept objects as simply as they would accept string values.

The first advantage of PowerShell that struck me was the ease of interacting with WMI, even on a remote computers. Note that PowerShell is not a 'replacement' for WMI, any more that VBScript/WSH was WMI. WMI is still the underlying data structure to expose information about a computer. The syntax and library around it is what's changing here. The implicit functions (called cmdlets - "command-lets") provide much of it, and the adoption of a .net style syntax, where basically more stuff can be done on a single line of code helps

For example, this script I had sitting around to determine how much memory was on a remote computer
In VBScript:

strComputer = "ComputerB"
Set wbemServices = GetObject("winmgmts:\\"
& strComputer)
Set wbemObjectSet =
wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")

For Each wbemObject In wbemObjectSet
WScript.Echo "Total Physical Memory (kb): " &
wbemObject.TotalPhysicalMemory

Next

In PowerShell:

Get-WmiObject Win32_LogicalMemoryConfiguration –computername ComputerB

Albeit, I'm not a fan of terse-ness for terse-ness sakes (or else we would just write everything in Perl :)), but the ability to have a single command do what the most obvious intent, and having the ability to send that output into other commands.

Platforms
PowerShell is support in Windows XP or newer. However, at this point, PowerShell does not ship natively with any Microsoft OS, although it appears it will be an optional install on Windows Server 2008. Since it's not native on my client computers, I anticipate it primarily being used in admin 'push'-style scripts vs. something end-user facing.

Projection
At a very early glance, I'm seeing PowerShell replace the utility of DOS batch files and VBScript/WSH solutions as soon as the platforms ubiquitously support it. Right now, the barrier is computer running Windows 2000 or earlier (with no support for PowerShell), and the fact that even Windows XP computer already have support for DOS batch files and have WSH, while they don't have PowerShell.

For the short to mid-term, there will still be a number of DOS batch files and VBScript solutions for end-user facing needs: Functions that can run without admin privileges, ran by the user on demand, or during their log on or similar event. this will be simply because they most likely already have everything they need to run it.

However, for admin-driven scripts, where you as an IT person will be pushing something from your computer 'out' to other computers, or querying other computers, install PowerShell and try it out, starting with the replacements for some of the basic DOS commands you might now, and evolving into WMI and replacing your VBScript, if you have any. I think you will find it a productive environment to accomplish many common admin tasks.

In a future article, I will detail a line-by-line conversion from one of my more complex VBScripts into PowerShell, and also evaluate some of the PowerShell editors that provide some advanced edit/view features.

Further Reading
Free Windows PowerShell workbook: server administration
Windows PowerShell Getting Started Guide

Filling in form letters from Access

I ran across a few Access apps earlier last year where the customer had some very simple requests - to update the header, addresses, logos, etc. on the form letters their apps produced. Upon investigating the application, discovered that the original developer had essentially designed Access reports that simply mimic-ed the template the customer used. Textboxes, labels, images, etc. A seamingly reasonable approach, but in this case, with the end users have no Access experience, the text was essentially 'locked' from their point of view... and even if they had, whenever the template changed, the Access developer would have to reproduce their changes. A colleague, not a programmer, asked a simple question and made a simple suggestion - why couldn't they just use their existing Word template, the app could fill it in from the current record.

In digging, found this article, http://msdn2.microsoft.com/en-us/library/aa140082(office.10).aspx, to accomplish just that. Modified it slightly to sit in an code module and take an RecordID to allow the request record to be used, and toggle the template used based on other fields in the record (in this case, the templates could be assumed to contained the same form properties, only the boiler-plate text differed) We shipped the Document Templates in a folder called 'Templates' sitting next to the application.

Advantages

• The customer can update their own templates using Microsoft Word
• Further ability to lock down modify access to the application, without risking cutting off manage-ability in the future (i.e. even if all existing staff leave or forget about the app, the template is sitting out for anyone with appropriate permissions to edit)

Disadvantages

• Having the seperate 'Templates' folder is an extra dependency that could be deleted, forgotten to be moved, etc.
• A uncareful Word editor could accidentally delete or modify form properties instead of just the boilerplate text
• Dependency on Word on the end-users side

Alternatives I have used in the past for similar scenarios:
-Scanning in the form and using as a background (more typical with 3rd party forms than the form letters I was dealing with here, can get out of hand in file size)
-The whole embedding the form letter as a Access report
-In the software BriefCase, used a model of exporting data to a text file, then kicking off Word documents with the Mail Merge feature bound to the text file. The user could modify their own templates, or even create new ones using a master list of merge fields (this is probably the richest model I've used yet, just certainly less quick-and-dirtythan the others, a little bit beyond basic Word training needed)
-In SQL Server Reporting Services, laying out a report to emulate a form letter (while having the fewest dependencies, assuming an SSRS environment exists, very awkward to design, as the tool is much more geared to tabular or matrix based reports, and flow layout vs. a fixed paginated layout needed) FWIW, I haven't really ran across a web-based solution that produces good fixed-layout, paginated reports, in any app I've built...

I've used the Word Form.Properties fill method in 3-4 Access applications, where I've needed to tack in a quick form letter reporting solution, was able to ship and control a whole 'folder', vs. having to ship a single file and/or had to prepare a more full-fledged installer package. I would recommend it in closed environments where you can assume that Word is standard (which is probably a good bet if Microsoft Access available)

Future steps, are to tie the model into .Net apps, which is hopefully where some of the Access apps will be going for other reasons. In Access, I could see pursuing some paths such as storing the templates in the db as BLOBS, or building something that would automatically download the templates if missing or updated... Not sure what bang-for-buck there is there. In a .Net app in the same environment, ClickOnce would manage the templates as dependencies.

Remote Desktop Gadget 2.1

Remote Desktop Gadget 2.1

Grabbed the updated version of the Remote Desktop Gadget for the Vista Sidebar. The 1.x version was really the only alternative I found that worked for me. Other tools out there that have features for looking up an OU, etc.: great concept, but they always seem to lockup. This tool seems very simple and clean. The 2.x version added 'History', in the form of a drop-down box when you expand the gadget. Still very lightweight, with this new feature.

Installing the AD Admin pack in Vista

http://blogs.msdn.com/nickmac/archive/2007/03/06/installing-adminpak-on-windows-vista.aspx
This link shows how to install the Active Directory (AD) Admin pack in Windows Vista

Snippet for launching an Click-Once application

While a less common deployment scenario, perhaps. This code will launch an application installed through Click-Once. (Notably, assuming it is already installed)

Dim runningProc As System.Diagnostics.Process
runningProc = New
System.Diagnostics.Process

'Do not receive an event when the process
exists
runningProc.EnableRaisingEvents = False

runningProc.Start("c:\Documents and Settings\" & UserName &
"\Start Menu\AppName.appref-ms")

What is an "Application Reference"?

Aside

Complete aside... this song got stuck in my head after viewing... He actually seemed pretty good to me :)

SQL Server 2005 on Vista

Latest adventure has been moving my development environment to a new laptop (with more RAM, etc) Installing SQL Server 2005 on Vista was a challenge for some reason..

Using the MSDN-provided SQL Server Developer Edition, ran into the error "The feature(s) specified are not valid for this edition of SQL Server" Which features(s)?

Backed off doing a full install, and instead installed in this order

1. Workstation components
2. Database engine
3. Reporting Services

Reporting services did not configure itself automatically during the install, but not a big deal to do it afterward using the Reporting Services Configuration console in SQL 2005.