Si bien ejecutando scripts de PowerShell de forma local en nuestras máquinas y servidores podemos realizar grandes automatizaciones, cuando PowerShell empieza a brillar es cuando ejecutamos acciones directamente en máquinas remotas y de forma masiva. Empezamos esta serie de entradas en la que profundizaremos sobre esta tecnología viendo qué es PowerShell Remoting y cómo funciona. Os dejo el índice de la serie: Parte 1: ¿Qué es PowerShell Remoting? Parte 2: Cómo configurar PowerShell Remoting.

Con la aparición de PowerShell Core se abrió un inmenso abanico de posibilidades a la hora de ejecutar PowerShell desde distintos sistemas operativos. Hoy en día es posible ejecutar PowerShell en Linux y en MacOS, cosa que años atrás era impensable con Windows PowerShell. En los últimos tiempos son muchos los módulos que se han adaptado para poder correr en PowerShell Core, entre ellos PowerCLI. En la entrada de hoy vamos a avanzar un paso más y vamos a ver cómo ejecutar PowerShell y PowerCLI desde Docker.

Si provienes del mundo GNU/Linux y tienes cierta experiencia en el manejo de su línea de comandos es posible que al empezar con PowerShell busques instintivamente herramientas parecidas a las que ya conoces para usarlas. La buena notícia es que Microsoft se ha encargado de facilitar lo máximo posible la transición de una shell a la otra, por lo que en la entrada de hoy revisaremos una serie de cmdlets equivalentes en PowerShell a comandos de Linux así como sus alias.

En más de una ocasión me ha tocado exportar una máquina virtual de un vCenter para luego cargarla en otro y, por algún oscuro misterio, la exportación del cliente web de vSphere no me lo ha permitido. En esas situaciones nos puede ser muy útil saber exportar una máquina virtual con PowerCLI, una tarea la mar de sencilla que además nos aportará algunas funciones extra. Cómo exportar una máquina virtual con PowerCLICómo exportar una máquina virtual con PowerCLI

Una de las tecnologías con las que acostumbro a trabajar en mi día a día son firewalls SonicWall. Hace un tiempo busqué en la PowerShell Gallery algún módulo para trabajar nativamente con SonicWall desde PowerShell y mi sorpresa fue que no encontré ninguno. En las últimas semanas he estado trabajando en un módulo con el que realizar consultas a firewalls SonicWall desde PowerShell y hoy os traigo la primera versión de PSSonicWall.

Si como yo os pasáis el día conectados a una infraestructura VMware vSphere haciendo conexiones remotas a diferentes máquinas virtuales sabréis que utilizar la consola integrada de VMware no es la mejor de las opciones. Como sustitución acostumbro a utilizar RDP para las máquinas virtuales Windows y SSH para las GNU/Linux, el gran problema para mi siempre ha sido cómo gestionar toda esa cantidad de conexiones remotas. Si bien existe software para gestionar dichas conexiones siempre he encontrado que es una solución demasiado manual y que escala muy mal conforme añadimos máquinas a la ecuación.

Si bien VMware te avisa con un bonito warning al activarlos, la ESXi Shell y la administración vía SSH son herramientas valiosísimas para hacer troubleshooting en nuestros servidores ESXi. En la entrada de hoy vamos a ver cómo habilitar de forma masiva ESXi Shell y SSH con PowerCLI en nuestros host ESXi para evitar tener que hacerlo a mano uno por uno. ¿Cómo habilitar ESXi Shell y SSH con PowerCLI? Como siempre, antes de realizar cualquier acción en PowerShell/PowerCLI debemos buscar los cmdlets que nos pueden ayudar a realizar las acciones que necesitamos.

Lo más habitual cuando ejecutamos un script de PowerShell es que o bien lo ejecutemos a mano o bien lo hagamos automáticamente de forma periódica ejecutando PowerShell como tarea programada. En la entrada de hoy veremos un tercer escenario, ‘instalaremos’ un script de PowerShell como servicio de Windows. ¿Por qué ejecutar un script de PowerShell como servicio? Si bien PowerShell no está diseñado para este tipo de uso, eso no quiere decir que no podamos hacerlo.

Cuando empezamos con cualquier lenguaje de scripting es habitual que editemos nuestros scripts utilizando cualquier editor de texto como Notepad en Windows o Vi en GNU/Linux. Por suerte cuando empiezas con PowerShell enseguida te encuentras con el más que funcional Windows PowerShell ISE, un editor que puede darnos muchas horas de scripting gracias a sus funciones integradas. En la entrada de hoy vamos a empezar con lo que probablemente sea una serie sobre las bondades de Visual Studio Code para PowerShell, un editor que va a llevar nuestras sesiones de programación al siguiente nivel.

Recuerdo que uno de mis primeros casos de uso de PowerShell, que además hizo que empezara a profundizar en él, fue personalizar plantillas de sistemas operativos Windows recién desplegados. Si bien los distintos hipervisores ofrecen opciones de este tipo, ejecutar un script de PowerShell después de Sysprep es una solución que funcionará a través de cualquier hipervisor que utilicemos. En la entrada de hoy veremos cómo programar dicha ejecución y que no se destruya después del Sysprep.

Hace unos días me encontré con la necesidad de añadir a uno de mis scripts de automatización la capacidad de copiar archivos de Linux con PowerShell y descubrí un módulo perfecto para ello. Es por ello que en la entrada de hoy retomamos la sección ‘Descubriendo módulos’ (aquí podéis ver la entrada anterior) en la que cacharrearemos con el módulo WinSCP de PowerShell y copiaremos archivos desde una máquina Windows a una GNU/Linux y viceversa.

Cuando nos encontramos en la situación de tener que realizar algún tipo de troubleshooting en el storage de una solución VMware vSphere lo más típico es que tanto en la salida de comandos de PowerCLI o esxcli como en los logs del propio sistema se haga referencia a nuestros datastores por su identificador naa.*. En la entrada de hoy veremos un par one-liners con los que obtener el identificador naa de un datastore con PowerCLI.

En esta segunda y última parte de la entrada seguiremos justo donde lo dejamos en la anterior y añadiremos un poco más de funcionalidad a nuestro script buscador de máquinas virtuales fuera de backup. Concretamente veremos cómo gestionar excepciones y cómo enviar notificaciones de correo periódicas. Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 1). Detectar VMs no respaldadas por Veeam con PowerCLI (Parte 2). En la entrada anterior nos quedamos con un pequeño script con el que ya conseguíamos sacar las máquinas virtuales sin backup pero poco más:

Si hay algo que absolutamente siempre debemos tener controlado al dedillo en nuestra infraestructura es el backup, puesto que es ese salvavidas del que siempre vamos a poder tirar en caso de desastre. Una problemática habitual cuando los entornos vSphere empiezan a crecer y cuando muchas manos tocan un mismo entorno es la posibilidad de quedarnos con VMs fuera de backup y, lo más peligroso, sin que nadie se de cuenta de ello.

Uno de los factores determinantes a la hora de diseñar una tarea de automatización con PowerShell es asegurarnos de que los cmdlets que vamos a utilizar estén disponibles en la versión de PowerShell que corre en la máquina que ejecuta el código. En la entrada de hoy me gustaría compartir con vosotros un par de chuletas que he creado para hacer la consulta más sencilla. Versión de PowerShell según sistema operativoVersión de PowerShell según sistema operativo

Después de tres meses desde la última entrada retomamos la sección de PowerShell one-liners. En la entrada de hoy veremos cómo configurar un usuario local para habilitar el flag “La contraseña nunca expira” con PowerShell, y lo haremos siguiendo donde nos quedamos en la entrada anterior, utilizando WMI. Contraseña nunca expiraContraseña nunca expira " Contraseña nunca expira ¿Por qué modificar un usuario local con WMI y PowerShell? Si después de leer la introducción de la entrada os ha dado por abrir una terminal de PowerShell con una máquina Windows 10 o 2016 y habéis buscado cmdlets relacionados con usuarios locales habréis visto algo parecido a esto:

Si bien los cmdlets incorporados en PowerShell nos ofrecen la posibilidad de interactuar con multitud de aspectos de una máquina, hay veces que podemos necesitar consultar o modificar un determinado atributo y nos encontramos con que ningún cmdlet nos lo permite. En la entrada de hoy vamos a ver cómo utilizar CIM y WMI con PowerShell para intentar combatir estas situaciones. ¿Qué son CIM y WMI? CIM (Common Information Model) es un estándar abierto creado por la organización DMTF orientado a proveer una definición común para el intercambio de información entre sistemas, redes, aplicaciones y servicios.

Algo que nos pasa a todos cuando utilizamos cualquier tipo de shell es encontrarnos con la necesidad de consultar comandos escritos minutos o días atrás e incluso volver a ejecutarlos. En GNU/Linux disponemos del comando history, y en la entrada de hoy veremos qué opciones tenemos para trabajar con el historial de PowerShell. Comandos relacionados con el historial de PowerShell Como siempre, cuando queremos descubrir cmdlets relacionados con una determinada acción debemos acudir al comando Get-Command, con el que consultar dentro de nuestros módulos disponibles.

Una vez tenemos en nuestra infraestructura una herramienta de monitorización como Nagios con la que comprobamos aspectos básicos de la misma como el uso de recursos o el estado de servicios, es el momento de plantearnos monitorizar otros aspectos que nos den una visión más real del estado de nuestro entorno. En la entrada de hoy vamos a ver cómo podemos monitorizar la autenticación LDAP con PowerShell para estar siempre seguros de que la validación en nuestros controladores de dominio está funcionando de forma correcta.

En más de una ocasión me he encontrado con la necesidad de crear rangos grandes de VLANs (realmente Virtual Machine Port Groups con tag de VLAN) en infraestructuras sin switches distribuidos y con varios nodos ESXi. Si bien crear unas pocas VLANs en algunos nodos es una tarea rápida que no entraña mucho misterio, cuando los números suben se puede volver una tarea tediosa y en la que es muy fácil cometer errores.