¿Por qué elegiría Powershell sobre WMI para desarrollar interfaces de administración?

Question

Estamos discutiendo el desarrollo de una infraestructura de gestión mejorada para nuestro sistema distribuido. Utilizamos COM, servicios web y componentes .NET. Dado que estamos basados ??en Microsoft Windows Server XP / 2003, supongo que básicamente tenemos dos opciones:

1. Cmdlets de Powershell
2. Clases WMI que usan System.Management y proveedores WMI para código nativo (clase, instancia, método, evento)

¿Por qué elegiríamos Powershell sobre WMI?

Answer 1

Elegiría PowerShell sobre WMI por las siguientes razones:

1. Escribir un cmdlet es solo agregar una clase .NET.
2. El tiempo de ejecución de PowerShell proporciona un análisis de línea de comandos integrado.
3. Escribir su interfaz de administración en PowerShell les permite a los administradores integrar la administración de su aplicación con la de otras aplicaciones y servicios (como Exchange, Active Directory o SQL Server).
4. El entorno de PowerShell pone la canalización a disposición de los administradores, permitiendo que las tareas de administración para su aplicación se realicen de manera más eficiente.
5. Descubrimiento. PowerShell, a través de Get-Command, Get-Member y Get-Help, proporciona un entorno extremadamente reconocible para que trabajen los administradores, lo que resulta en una curva de aprendizaje más corta para mantener su aplicación.

Incluso si sigue la ruta WMI, PowerShell tiene soporte para trabajar con WMI (aunque hay algunos problemas técnicos).

Para mí, PowerShell es la mejor manera de mostrar una interfaz orientada a tareas a una aplicación. Con el soporte que Microsoft ha proporcionado PowerShell, es y será una interfaz consistente para administrar aplicaciones y servicios en toda la empresa.

Mi trabajo diario es como administrador y estoy empujando a todos los proveedores con los que trabajo a crear una API de administración de PowerShell, ya que esto hace que la curva de aprendizaje y el cambio de contexto para administrar aplicaciones sean mucho más bajos. En el lado del desarrollo, he escrito (y todavía estoy trabajando en) una serie de cmdlets de PowerShell para un producto de código abierto con el que trabajo y estoy trabajando en otro conjunto para una aplicación separada.

Answer 2

Jeffrey Snover responde el " por qué PowerShell " aquí . La publicación está en el contexto de SQL, pero es muy aplicable aquí.

Answer 3

No estoy seguro de tomar la decisión. No es exactamente, o ... puedes elegir hacer ambas cosas.

WMI puede ser consumido por varias cosas diferentes, no solo por PowerShell. ¿Por qué no escribir su instrumentación de administración en PowerShell y luego envolver ese WMI en algunos cmdlets orientados a tareas para facilitar las cosas a los administradores? Eso es lo que algunos equipos de productos de MS eligen hacer, especialmente cuando tienen otros consumidores de WMI que desean continuar brindando soporte.

Si ya tiene un código .NET adecuado, convertirlo en un cmdlet puede ser más rápido que convertirlo en un proveedor WMI. Si ese es el caso, y la velocidad es una preocupación, ve con lo que es más fácil. Pero no importa lo que haga, siempre puede envolverlo en un cmdlet de PowerShell para administradores, que definitivamente es el enfoque recomendado.

Answer 4

No estoy seguro de que esto pueda responderse con la información que ha proporcionado hasta ahora. Mi intuición sería que deberías usar powershell ya que parece que ya tienes un código .Net. Pero en realidad solo depende exactamente de lo que está tratando de hacer.