Question

We are discussing development of an improved management infrastructure for our distributed system. We use COM, web services and .NET components. Since we’re based on Microsoft Windows Server XP/2003, I guess, we basically have two options:

1. Powershell cmdlets
2. WMI classes using System.Management and WMI providers for native code (class, instance, method, event)

Why would we choose Powershell over WMI?

Answer 1

I would choose PowerShell over WMI for the following reasons:

1. Writing a cmdlet is only adding a .NET Class.
2. The PowerShell runtime provides command line parsing built in.
3. Writing your management interface in PowerShell allows administrators the ability to integrate management of your application with that of other applications and services (like Exchange, Active Directory, or SQL Server).
4. The PowerShell environment makes the pipeline available to administrators, enabling management tasks for your application to be done more efficiently.
5. Discoverability. PowerShell, via Get-Command, Get-Member, and Get-Help, provides an extremely discoverable environment for admins to work in, resulting in a shorter learning curve to maintaining your application.

Even if you go the WMI route, PowerShell does have support for working with WMI (though there are a few glitches).

To me, PowerShell is the best way to surface a task oriented interface to an application. With the support Microsoft has been providing PowerShell, it is and will be a consistent interface to managing applications and services throughout the enterprise.

My day job is as an admin and I’m pushing all the vendors I work with towards surfacing a PowerShell management API, as this makes the learning curve and context switching for managing applications much lower. On the development side, I have written (and am still working on) a series of PowerShell cmdlets for one open source product I work with and am working on another set for a separate application.