scripts - wikipedia windows powershell

¿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. Usamos 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 Powershell
2. Clases WMI utilizando System.Management y proveedores WMI para código nativo (clase, instancia, método, evento)

¿Por qué elegiríamos Powershell sobre WMI?

Answer 1

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

Answer 2

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

Answer 3

Yo elegiría PowerShell sobre WMI por las siguientes razones:

1. Escribir un cmdlet solo agrega una clase .NET.
2. El tiempo de ejecución de PowerShell proporciona un análisis de línea de comandos integrado.
3. Al escribir su interfaz de administración en PowerShell, los administradores pueden 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 hace que la canalización esté disponible para los administradores, lo que permite que las tareas de administración de 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 visible para que los administradores trabajen, lo que da como resultado una curva de aprendizaje más corta para mantener su aplicación.

Incluso si usa la ruta WMI, PowerShell tiene soporte para trabajar con WMI (aunque hay algunas fallas).

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

Mi trabajo diario es como administrador y estoy presionando a todos los proveedores con los que trabajo para que destaquen 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. Desde el punto de vista del desarrollo, escribí (y todavía estoy trabajando) 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 por separado.

Answer 4

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

WMI puede ser consumido por una serie de cosas diferentes, no solo por PowerShell. ¿Por qué no escribir su instrumentación de administración en PowerShell y luego ajustar 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 seguir apoyando.

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