Windows PowerShellEl poder de los perfiles

Don Jones

Contenido

Shells, hosts y perfiles
Uso de perfiles
Creación de una consola personalizada
Más trucos de perfiles
Cuidado con el perfil

Si acostumbra a leer esta columna, ya sabrá que Windows PowerShell admite un sistema de perfiles. En esencia son scripts shell, con una extensión de nombre de archivo .ps1, que se ejecutan automáticamente cuando el shell está en funcionamiento. Son una excelente manera de, por ejemplo, definir alias personalizados. Puede tenerlo establecido de manera que cada vez que se ejecute el shell, el perfil defina automáticamente los alias, haciendo que estén disponibles siempre que use el shell.

El shell define los cuatro perfiles siguientes:

• Uno que se aplica a todos los shells y a todos los usuarios del equipo.
• Uno que se aplica a todos los usuarios pero sólo al shell de Microsoft PowerShell.
• Uno que se aplica al usuario actual y a todos los shells.
• Uno que se aplica al usuario actual y únicamente al shell de Microsoft PowerShell.

El concepto de "todos los shells" puede resultar un poco confuso. La terminología está arraigada en algunos de los primeros conceptos de desarrollo de Windows PowerShell que no llegaron a incluirse en el producto final. En la actualidad el término "todos los hosts" probablemente sería más adecuado.

Shells, hosts y perfiles

Como ve, el propio Windows PowerShell es un conjunto de ensamblados de Microsoft .NET Framework. Me gusta referirme a esta parte del shell como el motor de Windows PowerShell porque contiene la funcionalidad que generalmente se piensa que pertenece a Windows PowerShell. Aún así, no hay ninguna función integrada para que los usuarios interactúen con este motor. Para poder usar realmente el shell, es necesario que una aplicación de hospedaje (o host) cargue el motor.

La aplicación powershell.exe a la que probablemente está acostumbrado que se ejecute es dicho host. La aplicación gpowershell.exe incluida con Community Technology Preview (CTP) de Windows PowerShell 2.0 es otro host. Esta relación entre los hosts y los shells no es tan sencilla como he expuesto aquí pero mi explicación simplificada describe el comportamiento que se observa.

Es importante comprender que si está interactuando con el shell a través de una interfaz de línea de comandos basada en texto, probablemente estará usando el host de powershell.exe. Esto es aplicable incluso aunque haya iniciado el shell mediante un método abreviado instalado por otra aplicación, como el Shell de administración de Exchange. El Shell de administración de Exchange no es una aplicación host o shell diferente, sino que es simplemente el host de powershell.exe normal iniciado con un método abreviado que especifica un conjunto de complementos y scripts que se van a cargar de antemano. Dichos complementos son los que habilitan la funcionalidad de administración de Exchange dentro del shell. Sin embargo, usted está usando todavía el mismo shell.

Las ubicaciones (en Windows Vista) de los perfiles para el host de powershell.exe son las siguientes:

• %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Esta ubicación es para todos los usuarios del equipo y para todos los shells.
• %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Esta ubicación es para todos los usuarios del equipo pero sólo para el shell Microsoft.PowerShell.
• %PerfilDeUsuario%\Mis documentos\WindowsPowerShell\profile.ps1 Esta ubicación es para el usuario actual sólo y todos los shells.
• %PerfilDeUsuario%\Mis documentos\WindowsPowerShell\Microsoft.PowerShel_profile.ps1 Esta ubicación sólo es para el usuario actual y sólo para el shell Microsoft.PowerShell.

Estos perfiles no se crean de forma predeterminada. Sólo existen si los crea.

Cada aplicación host es responsable de cargar y ejecutar el perfil correcto. Si una aplicación de hospedaje concreta "decide" no cargar ningún perfil en absoluto, realmente no lo tiene que hacer. La ejecución de perfil no se realiza por el motor de Windows PowerShell automáticamente.

La manera más sencilla de realizar un seguimiento de todo esto es abrir simplemente el shell, escribir $profile y presionar Entrar. Eso le dará la ruta de acceso completa que el shell intenta usar como lo que creo que es el perfil "principal" (el perfil específico de shell por usuario). A continuación, puede crear o modificar dicho script, que se ejecutará cada vez que se inicie el shell.

Uso de perfiles

Un uso común de un perfil es definir los alias personalizados, como apunté anteriormente. O bien, puede agregar PSDrives personalizados (en esencia, son unidades de disco asignadas que existen por completo dentro de Windows PowerShell). Un uso menos común es crear un tipo de supershell que puede realizar cualquier tarea de administración que se pueda necesitar, basándose en los productos de software que se estén usando en su entorno. Para explicar realmente el concepto de supershell, es necesario dar cierta información general.

El grupo de producto de Microsoft que crea Windows PowerShell es responsable de muchas otras tecnologías de administración principales, entre las que se incluye Microsoft Management Console (MMC). MMC ofrece una buena analogía para explicar cómo funciona Windows PowerShell. Cuando ejecuta mmc.exe, inicia una consola en blanco que no sirve de mucho. Agrega complementos de MMC para crear una consola funcional.

Una vez que tenga configurada la consola de la manera que desee, guárdela en un archivo con una extensión de nombre de archivo .msc. Este archivo de consola guardado le permite volver a cargar rápidamente su consola personalizada en cualquier momento.

En lugar de crear consolas de MMC personalizadas, muchos administradores dependen únicamente de las consolas que se instalan junto con los productos que administran. Exchange Server, por ejemplo, crea una consola que sólo contiene el complemento de Exchange Server. Usuarios y equipos de Active Directory es otra consola previamente creada que contiene un único complemento.

Windows PowerShell funciona de manera muy parecida. El icono de Shell de administración de Exchange instalado con las herramientas de administración de Exchange Server 2007 es en realidad un método abreviado a powershell.exe con instrucciones para cargar un archivo de consola. Los archivos de la consola de shell tienen una extensión de nombre de archivo .psc1 y contienen una lista de complementos que se van a cargar de antemano (de manera muy similar a como un archivo .msc contiene una lista de complementos que MMC precarga de antemano automáticamente). Sin embargo, no está limitado a usar estas consolas de shell creadas previamente. Puede crear una consola personalizada, de la misma manera que lo haría con MMC, y usarla para llevar a cabo todas sus tareas de administración. Los perfiles desempeñan una función clave para que esto sea posible.

Creación de una consola personalizada

Para crear una consola personalizada, debería empezar por encontrar los nombres completos de cada complemento con el que desea trabajar. Asegúrese de que todas las herramientas de administración necesarias están instaladas en el equipo. A continuación, en Windows PowerShell, ejecute Get-PSSnapin –registered. Aparecerán en una lista todos los complementos registrados disponibles pero que no se han descargado todavía. A continuación, cree o edite el perfil de Windows PowerShell adecuado. Agregue los comandos Add-PSSnapin para cargar cada complemento que desea que esté siempre disponible. Esto podría incluir complementos para Exchange Server, productos de System Center y complementos de terceros, como las extensiones de la comunidad de PowerShell. A continuación, guarde su perfil (recuerde firmar digitalmente el perfil si su directiva de ejecución de Windows PowerShell lo requiere) y cierre el shell. Vuelva a abrir el shell y cargará automáticamente todos los complementos que aparecen en la lista en su perfil.

Otra técnica es cargar todos los complementos en el shell (usando Add-PSSnapin y los nombres de los complementos) y, a continuación, ejecutar Export-Console para crear un archivo de consola .psc1 que contenga todos los complementos que está usando actualmente. A continuación, puede usar este archivo de consola .psc1 para crear un nuevo método abreviado de Windows PowerShell que especifique el parámetro PSConsoleFile y su archivo .psc1 personalizado. Dicho método abreviado usaría a continuación su consola, cargando todos los complementos especificados automáticamente.

Más trucos de perfiles

Uso mi perfil de Windows PowerShell para realizar otras tareas útiles cada vez que se inicia el shell. Esto es lo que sucede cuando el shell se inicia en mi sistema:

1. Ejecuto Get-Credential para mi cuenta de administrador del dominio, almacenando los resultados en una variable denominada $cred. Con ello, $cred estará disponible a través del shell. Entonces puedo pasarla al parámetro –credential de varios cmdlets, como el cmdlet de Get-WmiObject. Puesto que $cred almacena la contraseña, puedo usar dichos cmdlets sin que se me pida una contraseña.
2. Ejecuto Cd C:\ de manera que el shell se inicia en la raíz de la unidad C: de mi PC.
3. Ejecuto New-Alias of Out-File para crear un alias denominado "of"; así puedo usar "of" en lugar de "Out-File". Lo uso mucho, por lo que tener el alias corto definido resulta muy práctico.

Intento crear una clave de prueba en la unidad HKLM: del shell, que representa la parte HKEY_LOCAL_MACHINE del registro. Si se produce un error, sé que se inició el shell sin los privilegios elevados. Normalmente necesito privilegios elevados para el trabajo que realizo y ésta es simplemente una manera rápida de saber si tengo privilegios elevados antes de empezar el trabajo serio.

Defino una función personalizada denominada Ping-Address que acepta un nombre de equipo o dirección IP, y devuelve un valor Verdadero o Falso dependiendo de si al equipo se le puede enviar un ping. Uso mucho esta función en mi trabajo, por lo que tenerla definida en mi perfil hace que esté disponible globalmente en mi shell.

Cmdlet del mes: Get-WmiObject

El observador agudo quizás se dé cuenta de que éste es un cmdlet que ya traté anteriormente, no obstante me gustaría presentar una interesante novedad que ofrece. Me encuentro a menudo con administradores que intentan recuperar información del Instrumental de administración de Windows (WMI) desde varios equipos, cuyos nombres aparecen incluidos en una lista de un archivo de texto, usando esta técnica:

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Aunque esta técnica funciona, realmente no la necesita porque Get-WmiObject puede aceptar una matriz de nombres de equipo para el parámetro –computerName. Para lograr el mismo efecto, basta con que use lo siguiente:

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

La colocación del comando Get-Content entre paréntesis fuerza al shell a ejecutar el comando y colocar los resultados (una matriz de nombres de equipo) en el parámetro –computerName.

Cuidado con el perfil

Tenga presente que powershell.exe no es la única aplicación que carga los perfiles de Microsoft.PowerShell o todos los perfiles de shell. Muchos entornos de desarrollo integrados (IDE) que admiten la compatibilidad con Windows PowerShell (incluyendo PrimalScript de SAPIEN Technologies, PowerGUI de Quest Software y PowerShell Plus de ShellTools) cargan también estos mismos perfiles para ofrecer una experiencia que refleja el host powershell.exe.

Los perfiles grandes que cargan muchos complementos pueden hacer que estas aplicaciones se inicien con mayor lentitud debido a que el motor de Windows PowerShell tiene que llevar a cabo muchas instrucciones antes de prepararse para la aplicación host. De hecho, incluso powershell.exe puede tardar algo de tiempo en iniciarse si tiene un script de perfil muy grande para ejecutar.

Los complementos que definen cmdlets con los mismos nombres pueden provocar además conflictos. Por ejemplo, si dos complementos definen un cmdlet denominado Get-User, Windows PowerShell no ejecutará ningún cmdlet hasta que no use el nombre completo del cmdlet para especificar cuál desea. El nombre completo puede que no resulte atractivo puesto que los nombres de complementos pueden ser bastante largos. Cuando me encuentro con este problema, por lo general me doy simplemente por vencido con la idea de tener esos dos complementos cargados a la vez. En su lugar, cargaré sólo el que uso con mayor frecuencia en mi perfil y usaré entonces un shell nuevo e independiente cuando tengo que cargar y usar el otro complemento.

Los perfiles de Windows PowerShell pueden ofrecer mucha comodidad adicional al shell. Sin embargo, tenga presente que si están editados de forma malintencionada con malware, los perfiles también pueden causar mucho daño. Puede proteger su perfil firmándolo digitalmente y configurando Windows PowerShell para usar su directiva de ejecución AllSigned, o bien modificar los permisos del archivo NTFS en sus perfiles (todos ellos) para que su cuenta de usuario normal no los pueda modificar.

Don Jones es el autor de Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. Puede ponerse en contacto con él a través del sitio web PowerShellCommunity.org.