Para los administradores de sistemas más avanzados, uno de los puntos débiles de Windows frente a otros sistemas operativos ha sido tradicionalmente la capacidad de administración de éste desde línea de comandos.
Windows siempre ha sido un sistema operativo muy fácil de administrar visualmente. En general todos los productos de Microsoft lo son, y esta ha sido siempre una de las principales causas de su preponderancia como sistema operativo. Sin embargo esta facilidad de uso, basada en consolas gráficas y asistentes, ha sido tradicionalmente un arma de doble filo y fuente de controversias. Por un lado la sencillez con la que se realiza cualquier tarea hace que ciertas personas ganen excesiva confianza. En muchas ocasiones esta sencillez se convierte en un grave problema que lleva a que los sistemas estén mal administrados, debido a que no se ha profundizado bien en los conceptos necesarios para una buena gestión (la sencillez de un asistente no alienta tampoco el meterse en grandes honduras). Por otra parte ha sido también un problema porque esas mismas interfaces gráficas que tanto facilitan el trabajo más común, se convierten en un estorbo a la hora de realizar tareas complejas (formadas por otras tareas individuales más simples) que precisen de cierto grado de automatización.
La consola del sistema tradicional (cmd) nunca ha sido especialmente generosa en características, y desde luego está a años luz de los “shell” de UNIX en los que se inspira. Los clásicos archivos .bat son muy limitados y es un dolor realizar con ellos cualquier interacción avanzada con el usuario.
Hace ya bastantes años Microsoft incorporó a sus sistemas operativos un subsistema de automatización llamado Windows ScriptingHost (WSH) que trataba de acortar distancias con la administración de otros entornos. WSH se basa en la escritura de código en lenguajes de script, y soporta multitud de ellos (JavaScript, VBScript, Perl, Python, TCL, Ruby, PHP… hasta COBOL!). Estos scripts permiten crear tareas mucho más complejas que con un simple .bat, además de brindar acceso a la funcionalidad de cualquier objeto COM automatizable, incluyendo por ejemplo acceso a datos, a la red o a servicios web, y las funcionalidades de diversas aplicaciones con interfaz automatizable (como las de Office entre muchas otras).
Realmente WSH supuso una gran mejora sobre lo existente hasta entonces (la línea de comandos de MS-DOS) pero también presentaba un importante problema y es que, al fin y al cabo, los administradores no tienen porque ser también programadores. Si bien es cierto que VBScript o JScript son lenguajes sencillos cuyos rudimentos se aprenden rápido, para hacer uso de las funcionalidades de administración que necesitamos es necesario asimilar el uso de objetos COM que no son nada sencillos en general. Por ejemplo WMI (Windows Management Instrumentation) o ADSI (para acceso al directorio activo).
Esta es una grave limitación puesto que para sacarle partido a WSH hay que saber programar a un cierto nivel, aparte de ser difícil de depurar y requerir mucha ceremonia (en forma de archivos XML) para combinar entre sí la funcionalidad de diversos archivos WSH.
SIGUE LEYENDO PARA APRENDER:
- El origen de PoowerShell – Monad
- Cómo usarlo
- Cómo concatenar comandos
- Cómo crear funciones propias
- Cómo exportar resultados a Excel
- Cómo filtrar y ordenar resultados
- Más comandos
- Referencias varias