Opalis como ya hemos explicado en este blog tiene un montón de Integration Packs repletos de actividades ya creadas listas para ser usadas rápidamente en la creación de workflows, sin embargo en ocasiones, bien por que no exista una actividad concreta en ningún Integration Pack (IP) o por que queremos hacer un montón de cosas juntas y prefiramos usar un script en vez de muchas actividades podemos querer usar powershell en un workflow.
En principio es muy fácil.
Voy a usar un ejemplo un poco tonto porque en realidad hay una actividad para hacer lo que hace este ejemplo y por que seria mas lógico usar SCOM que Opalis para esto, pero es el que se me ha ocurrido…
El workflow hará lo siguiente:
- Pedir un nombre de un servicio a través de un “Custom Start”
- Ejecutar un powershell que mire el estado de este servicio
- Si el servicio esta parado, Hacer guardar un evento
Esta será la configuración del custom start:
En System tenéis la actividad “Run .Net Script”
En las propiedades de la actividad seleccionamos powershell como lenguaje de script y metemos el texto del script que queremos ejecutar.
Bien ahora pulsando con el botón derecho donde iría el nombre del servicio cuyo estado queremos saber podemos introducir el texto del campo que hemos pedido antes en el custom start.
Y quedara así:
Ahora tenemos que indicar que queremos que publique esta actividad en el bus de datos del workflow para que el resto de actividades puedan usar esta información.
Ahora añadimos la actividad para guardar un evento:
Como solo queremos que el script guarde el evento cuando el servicio esta parado, modificamos los parámetros de la línea que une la actividad del powershell con la que guarda el evento, lo hacemos de la siguiente forma:
Ejecutamos nuestro workflow en test
Todo ha ido bien y deberíamos tener el evento en el event log.
Hasta aquí bien y fácil.
Ahora os cuento dos “problemas”
- Opalis 6.3 aunque este instalado sobre x64 siempre usa el powershell x86 ya que en realidad es un programa x86.
- Muchos snapins de powershell pueden encontrarse instalados en la versión x64 y en ocasiones no estarán instalados en los servidores action server de Opalis.
Solución: PowerShell remoting 
Con Powershell remoting puedes ejecutar una sesión de powershell en otro servidor o pc a través de la red usando WinRM (usando los puertos 443 o 80 según lo configuremos).
Esto nos permitirá que Opalis pueda usar virtualmente cualquier snapin, pasar firewalls, administrar cosas en otros servidores que no sean action servers, etc.
Las posibilidades son muchísimas…
Para que un servidor acepte una sesión de remoting a parte de abrir winrm en el firewall teneis que tener configurado el WinRM la forma mas basica es ejecutar el comando: winrm quickconfig
Como ejemplo vamos a probar el snapin de Remote Desktop Services lo que nos permitirá hacer cosas para las que no hay IP de Opalis.
El objetivo inicial será saber que VMs están en un pool y luego pararlas todas hablando con SCVMM.
Lo primero saber como se hace por powershell lo que queremos.
#Abrimos la sesión remota, en este caso usara los credenciales de Opalis
$sb_remotesession = New-PSSession -ComputerName NombreServidorBroker
#Cargamos el snapin de RDS e interrogamos el proveedor para saber las maquinas virtuales
#que hay en un pool
[string]$StrPools= invoke-command $sb_remotesession -ScriptBlock {`
import-module RemoteDesktopServices;`
get-childitem RDS:connectionbrokervirtualdesktopspoolsNombrePoolVirtualMachines;`
}
$PoolArray=new-object System.Collections.ArrayList
$PoolArray=$StrPools.split(" ")
$i=1
foreach ($VM in $PoolArray)
{
$i+=1
if ($i -le $PoolArray.Count)
{$StrOut = $StrOut + $VM +"`n"}
else
{$StrOut = $StrOut + $VM}
}
#Muy importante cerramos la sesión remota
remove-pssession $sb_remotesession
Ahora que veo el código aquí pegado me doy cuenta de que se puede hacer mucho mas inteligentemente, pero bueno, domingo por la tarde no es momento para optimizar código 
Siguiente paso lo ponemos en un workflow de Opalis, empezando por un custom start que nos pregunte el pool cuyas VMs queremos parar.
Modificamos el script para adaptarlo a Opalis para que coja los parámetros y para que muestre las VMs por pantalla, ya que nos valdrá con que guarde los nombres en las variables.
Indicamos que queremos publicar la variable StrOut
El script esta preparado para en la variable StrOut esten todas las VMs separadas por un retorno de carro, ahora tenemos que coger esa cadena y trabajarla de forma que para Opalis cada VM implique un camino dentro del workflow.
Para partir el dato y que cada VM venga por separado usaremos la actividad Split Lines del IP “Opalis Utilities”
La siguiente actividad será buscar en SCVMM cada una de las VMs que hay que parar.
Ahora solo nos queda apagar cada VM
Ya podemos probarlo completo:
Y funciona!
Fijaros como la actividad Get VM y Shut Down VM han corrido dos veces una con cada VM que había en el pool.
Ahora creamos una nueva política
Copiamos de la política anterior a la nueva.
Nota: Siempre que uses cortar y pegar en Opalis revisa todas las actividades para ver si están bien, a veces se pierde algún parámetro.
Cambiamos el shut down VM por un Start VM
Y ya tenemos también un workflow para encender todas las VMs de un pool.
Resumen:
- Has visto lo fácil que es ejecutar Powershell desde Opalis
- Has aprendido a usar remoting de Powershell para usar snapins instaladas en otro servidor y además evitar el problema de la disparidad entre versiones de powershell x86 y x64
- Cortar y pegar en Opalis es una herramienta muy interesante…
Un saludo a todos.
Crossposting from blogs.technet.com/dmatey