Cerrar
InicioAzureMicrosoft Azure: Ahorro de Costes en WVD [Detener Equipos Sin Sesiones]

Microsoft Azure: Ahorro de Costes en WVD [Detener Equipos Sin Sesiones]

Hoy vamos a ver como podemos detener nuestros equipos en Azure los cuales no tienen sesiones activas, algo que siempre deberíamos tener presente en entornos de pago por uso. Claramente en un entorno Cloud donde se paga por uso, tener servidores de Escritorio Remoto o de WVD iniciados y sin usuarios, no tiene sentido.

Voy a mostraros como podemos detener correctamente hosts de sesión (desasignarlos en Azure) que no tienen sesiones iniciadas, de forma simple: ejecutando un Webhook desde PowerShell. Para ello, vamos necesitar realizar algunas configuraciones:

  • Creación de tareas programadas en los hosts de sesión [utilizaremos las GPO de Active Directory]
  • Creación de un runbook de apagado de equipos de Azure [PowersShell]
  • Creación de un webhook partiendo del runbook creado

Lo que haré, será crear un pequeño script que se ejecutará mediante una tarea programada cada 30 minutos y buscará sesiones activas en los host de sesión donde se ejecute dicho script. Para buscar sesiones activas, lo haré de la forma más simple que se me ha ocurrido, que es vía Get-Process.

Antes de continuar, como casi siempre, aquí va la infografía de hoy:

Lo que intento mostrar es un entorno de WVD con hosts de sesión sin sesiones activas, los cuales vía PowerShell los apagaré invocando un WebHook (Invoke-RestMethod -Method post -Uri $UrlWebhook). Como sabéis, MSFT recientemente ha publicado en versión preliminar la posibilidad de que cuando un usuario se quieran conectar vía WVD a un hosts de sesión apagado, lo encienda automáticamente: Windows Virtual Desktop: Inicio Automático de un Hosts de Sesión (versión preliminar). Pero tenemos nada “nativo” para apagar hosts de sesión que no tiene sesiones activas. Si podemos apagarlos o encenderlos sin más a una hora determinada, pero no en base a sesiones activas a excepción de esto: Escalado de hosts de sesión con Azure Automation: Azure | Microsoft Docs.

Pero bueno, que no hay nada “sencillo” y rápido de configurar para detener (que no apagar únicamente, porque si apagáis el equipo desde Windows, Azure sigue facturando por el equipo) una máquina virtual cuando no tenemos sesiones activas. Pues dicho esto y, a petición de un cliente el cual pedía que, fuera del horario de apagado normal (de lunes a viernes a las 22:00) si aún tuviéramos algún hosts de sesión iniciado sin sesiones, que se apagase para ahorrarse algunos €.

Todos tenemos a usuarios que, fuera de esos horarios laborables y normales, necesiten en algún momento determinado el iniciar alguna máquina virtual para trabajar fuera de horas  pero luego también queremos apagarlo para seguir ahorrándonos esos € tan valiosos. Pues para cumplir este objetivo, yo he realizando las siguientes configuraciones:

  • Crear una GPO que cierre las sesiones lleven desconectadas 1 hora
  • Crear una GPO que cree un tarea programada para ejecutar un script de PowerShell cada 30 min (comprobando que ya no existen sesiones iniciadas)
  • Crear un runbook de apagado de la máquina virtual y de ahí, obtener un webhook para utilizarlo en el script de PowerShell ejecutando en la tarea programada

Además, de todo esto, he creado una GPO para habilitar  el bucle invertido en modo merge aplicado a todos los WVD donde iniciarán sesión nuestros usuarios. De esta forma podemos asignar directivas de usuario para las sesiones que se inician en los WVD.

Dicho todo esto, vamos a iniciar la configuración, lo primero que configuraré será habilitar las directivas de bucle invertido: Loopback processing of Group Policy la cual se asignará a la OU donde tenemos los hosts de sesión de nuestro WVD.

Una vez que ya tenemos aplicada la directiva de bucle invertido en los WVD, ya podemos aplicar a la Unidad Organizativa de los WVD la directiva de límite de sesión desconecta (directiva de usuario). Prefiero configurar esta GPO a nivel de usuarios, porque así puedo denegársela a quien considere (administradores por ejemplo). Esta configuración es imprescindible, porque sino si no se desconectan nunca las sesiones siempre las tendríamos desconectadas durante horas.

Ahora crearé otra GPO que tendrá la siguiente configuración:

  • Copiar script desde la red al equipo local a la carpeta C:\Windows\Scripts

Además, esta GPO configurará la tarea programada la cual tendrá la siguiente configuración:

  • Ejecución con la cuenta SYSTEM

  • Se ejecutará todos los días a partir de las 22:00 cada 30 minutos, de esta forma, si la máquina aún sigue encendida porque alguien no la ha apagado, estará comprobando cada 30 min si aún sigue habiendo sesiones activas

La tarea ejecutará el script que previamente se ha copiado a C:\Windows\Scripts con la siguiente configuración:

El script es de lo más sencillo, aquí os lo dejo como texto para copiar/pegar si así lo queréis:

$UrlWebhook = ‘https://e3018f31-47e1-4a8c-923d-bbb8b083002c.webhook.ne.azure-automation.net/webhooks?token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’
$checkConnection = get-process -name Explorer
if($checkConnection.ProcessName){
Write-Host “Hay usuarios con sesión iniciada”
}else{
Invoke-RestMethod -Method post -Uri $UrlWebhook
}

Es muy sencillo de entender, primero meto en una variable la URL del WebHook (aquí os dejo el enlace al artículo donde os explico como detalle como crear un Webhook: Microsoft Azure: Iniciar un Runbook desde un Webhook llamado desde PowerShell). Después en otra variable busco un proceso que todos sabemos que tiene que existir cuando hay una sesión iniciada, que es el Explore.exe. Y luego tenemos un IF  en donde si existe el proceso Explore.exe dejaremos un comentario vía Write-host (que nunca veremos, pero para las pruebas me venía bien tenerlo visible) y sino existiese el proceso Explorer.exe activo entonces tiene que ejecutar el Webhook vía Invoke-RestMethod porque se supone que no hay ningún usuario con alguna sesión activa.

Aquí ya os muestro la tarea programada ya crear en el equipo y como ya tenemos también el fichero copiado localmente en la carpeta C:\Windows\Scripts.

Una vez que, ya tenemos el proceso en producción y se de la condición de que alguna máquina virtual de los WVD esté iniciada a partir de las 22.00 la tarea programada se ejecutará cada 30 minutos (cada uno que lo ajuste como considere) y sino hay sesiones activas .. apagará el servidor vía webhook.

Aquí os dejo las capturas de pantalla con la evidencia de que se ha ejecutado el script y no ha encontrado sesiones activas (proceso explorer.exe) y aquí vemos que  la máquina virtual se está apagando:

En cuestión de segundos la vemos desasignada (ya no tiene coste significativo en Azure)

Y por último, si vamos al registro de actividad del equipo, podemos ver claramente que se ha apagado el equipo y el usuario que ha ejecutado ese proceso en la cuenta de automatización con la que estamos ejecutando los diferentes runbook que tengamos:

Como habéis podido apreciar, el script más simple .. no digo que imposible, pero vamos.. Cada cual que busque la forma de detectar sesiones activas como considere, pero esta me parece sencilla y eficiente.

No he entrado en los detalles de la configuración del runbook y webhook que se necesitan porque ya lo había comentado en otro artículo, el cual os he puesto el enlace, pero espero que se haya entendido sin mayor problema. Igualmente, os dejo aquí el código del script de apagado de equipos que podéis utilizar en los runbooks de Azure:

$connectionName = “AzureRunAsConnection”
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName
$RG = “Nombre-Grupo-Recursos-Donde-Están-Las-MV
$VM = “Nombre-VM
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
Stop-AzureRmVM -ResourceGroupName $RG -Name $VM -Force

Si lo que queréis es iniciar algún servidor, entonces cambiáis Stop-AzureRmVM por Start-AzureRmVm

Ahora, como siempre, os toca probarlo a vosotros!!

Infraestructura IT:
Microsoft Endpoint M
NO HAY COMENTARIOS

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This