11

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?

user33675
  • 1,473
  • 11
  • 11

4 Answers4

10

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.

Steven Murawski
  • 10,959
  • 41
  • 53
4

Jeffrey Snover answers the "why PowerShell" here. The post is in the context of SQL, but very much applicable here.

halr9000
  • 9,879
  • 5
  • 33
  • 34
2

I'm not sure I'd make the decision. It's not exactly either-or... you can choose to do both.

WMI can be consumed by a number of different things, not just PowerShell. Why not write your management instrumentation in PowerShell, and then wrap that WMI in some task-oriented cmdlets to make things easier on administrators? That's what some MS product teams are choosing to do, especially when they have other consumers of WMI they want to continue supporting.

If you've already got suitable .NET code, turning that into a cmdlet may be faster than turning it into a WMI provider. If that's the case, and speed is a concern, go with what's easier. But no matter what you do, you can always wrap it in a PowerShell cmdlet for admins, which is definitely the recommended approach.

Don Jones
  • 9,367
  • 8
  • 39
  • 49
0

Not sure that this can be answered with the information that you have provided so far. My gut feeling would be that you should use powershell since it sounds like you may already have some .Net code. But it really does just depend on exactly what you are trying to do.

EBGreen
  • 36,735
  • 12
  • 65
  • 85