Azure Automation - Parte 3 - Configurando las alertas

Hi,

En ese último post dedicado al servicio de Azure Automation nos vamos a centrar en la configuración de alertas para obtener la tranquilidad de que recibiremos un SMS o mail ante fallo de alguno de nuestros runbook.

En este articulo vamos a realizar una configuración de alertas no solo del estado general del runbook = "Job Status"  sino que también vamos a monitorizar los errores que se produzcan en el código de nuestro script (Powershell, Python etc...) supervisando y alertando sobre el estado de los "Job Stream".

Esta muy bien saber si la ejecución del runbook ha fallado o se ha suspendido pero... ¿y si falla alguna secuencia o parámetro de nuestro script? Por ejemplo los cmdlet de conexión a Exchange online son cambiados y/o actualizados por Microsoft o existe algún problema con la cuenta de Admin usada para conectar, en fin, podríamos poner mil condiciones que pueden afectar a la funcionalidad de nuestro código.

Tras esta breve introducción comenzamos con las configuraciones necesarias, donde el primer paso es configurar integración entre Azure automation y Azure Monitor donde el servicio de automation enviará los logs a un workspace de log analytics, a partir de aquí podremos configurar nuestras alertas y grupos de acción:

Estos son los pre-requisitos necesarios:

• Azure powershell 
• Espacio de trabajo de Log Analytics
• El ResoruceID de la cuenta de automatización que queremos integrar

1. Creación de un Workspace de log Analytics 

Si no disponemos de uno, tendremos que generarlo accediendo al portal de Azure-->En la búsqueda introducimos "analytics" y podremos generarlo desde el Marketplace:

   2.  Configurar integración cuenta automatización con Azure Monitor

El siguiente paso sería conectar powershell (Connect-Azaccount) a nuestra suscripción de azure y realizar la integración:

 Obtenemos y anotamos el ResourceID de la cuenta de automatización a integrar y del workspace de log analytics:

# Find the ResourceId for the Automation Account
Get-AzResource -ResourceType "Microsoft.Automation/automationAccounts"

# Find the ResourceId for the Log Analytics workspace
Get-AzResource -ResourceType "Microsoft.OperationalInsights/workspaces"


Creamos un script con el siguiente código, añadiendo los ResourceID obtenidos en el paso anterior y realizamos la integración:

$workspaceId = "[resource id of the log analytics workspace]"
$automationAccountId = "[resource id of your automation account]"
Set-AzDiagnosticSetting -ResourceId $automationAccountId -WorkspaceId $workspaceId -Enabled 1

Tras la integración el servicio de automation puede tardar hasta una hora en comenzar a enviar los log al espacio de trabajo de log analytics.

Para comprobar que la integración es correcta ejecutamos el siguiente código:

Get-AzDiagnosticSetting -ResourceId $automationAccountId

y en la salida nos aseguramos que "LOGS" aparece como "enabled=True"


Otra opción para asegurarnos de que todo es OK, seria acceder al servicio de Azure Monitor y en configuración de diagnostico validar que esta habilitado:

   3.  Configuración de alertas para Job Status y Job Streams


Podemos ver como se han comenzado a registrar los logs de nuestra cuenta de automation en azure monitor de la siguiente forma:

Accedemos a Azure Monitor-->Registros y ejecutamos la siguiente Query

AzureDiagnostics | where ResourceProvider == "MICROSOFT.AUTOMATION"

Una vez validado, sin salir de esta pantalla podemos comenzar a configurar alertas relativas a Job status y Job Streams sobre nuestros runbook.


En primer lugar vamos a configurar una alerta para envío de correo cuando un runbook falla o queda en estado suspendido

Esta sería la Query que tenemos que realizar y sobre ella configurar una regla de alerta:

AzureDiagnostics | where ResourceProvider == "MICROSOFT.AUTOMATION" and Category == "JobLogs" and (ResultType == "Failed" or ResultType == "Suspended") | summarize AggregatedValue = count() by RunbookName_s

La regla de alerta deber estar basada en consulta, este seria el aspecto final:

Luego debemos generar un "Grupo de acción" donde indicamos que se realizará al desencadenarse la alerta, en nuestro caso se enviará un correo electrónico a la dirección especificada (podría ser una lista de distribución para todos los interesados)

Por último debemos introducir la información necesaria para nuestra alerta y que recibiremos por correo:

Con estos sencillos pasos tendremos configurada nuestra primera alerta y el grupo de acción que podremos añadir a nuevas reglas de alerta configuradas 😄


Para configurar nuestra segunda alerta, la más  importante y que monitorizará y alertará sobre fallos en los Job Streams tenemos que realizar los mismos pasos con estos cambios:


Esta sería la consulta sobre la cual configurar la regla de alerta:

AzureDiagnostics | where ResourceProvider == "MICROSOFT.AUTOMATION" and Category == "JobStreams" and StreamType_s == "Error" | summarize AggregatedValue = count() by JobId_g

No hace falta crear otro grupo de acción, podemos usar el creado anteriormente.


Bien, una vez configuradas las reglas de alerta podemos ver su estado en la siguiente pantalla, preparadas para entra en acción:

Referencias en la web:
https://docs.microsoft.com/en-us/azure/automation/automation-manage-send-joblogs-log-analytics


Un Saludo

Azure Automation - Parte 2 - Configurando un Runbook

Hi,

Continuamos con la segunda parte de esta serie de post dedicados a Azure Automation, uno mas de los tantos servicios que hospeda el Cloud público, en este caso de Microsoft. 

Comenzamos enumerando las opciones más relevantes que tenemos dentro de la cuenta de automatización, imprescindibles para poder configurar y ejecutar nuestros Runbooks:

• Runbook: Se pueden generar nuevos o importar desde archivo o galería, basados en powershell, Python 2 o gráficos. El runbook contiene las secuencias necesarias para realizar el proceso que queremos automatizar mediante ejecución manual o programación.

• Grupos de Hybrid Worker: La función Hybrid Worker nos permite usar automation para automatizar procesos que se ejecutan onpremises u otras nubes. Podemos instalar el rol de Hybrid worker en un equipo físico o virtual, Windows o Linux que se ejecuta en nuestro Datacenter. El requisito fundamental es la conexión puerto 445 de salida hacia las url de azure. Esta función daría para un post entero, aquí os dejo mas información: https://docs.microsoft.com/es-es/azure/automation/automation-hybrid-runbook-worker

• Tareas de monitor: Función muy interesante, consta de 2 runbook, uno de monitorización y otro de acción. Un claro ejemplo seria, si en una carpeta aparece un archivo nuevo (runbook monitor) crea una copia de seguridad automáticamente (runbook de acción)

• Módulos: Necesarios para poder confeccionar nuestros script de powershell, al igual que los instalamos en nuestro equipo, también debemos añadirlo a automation (Por ejemplo el modulo MSONLINE para ejecutar procesos en Office 365). Podemos agregarlos desde local en formato zip o bien instalarlos desde la "galería de módulos".

• Credenciales: Se trata de nuestro "almacén seguro" de credenciales, donde las damos de alta para después poder añadirlas a nuestro código que conforma el runbook en cuestión. Un claro ejemplo sería unas credenciales de Administrador de algún servicio de Office 365.

Una vez descritos los fundamentos, vamos a crear nuestro runbook partiendo del siguiente escenario real:

"Usamos las reglas de transporte de Exchange Online para el tratamiento de mensajes enviados/recibidos a miembros de ciertos grupos de seguridad habilitados para correo. El mantenimiento de la membresía de estos grupos lo realizamos mediante script para la creación y actualización de contactos externos, el cual lanzamos manualmente cada día, tras la exportación de archivos CSV con estos contactos desde nuestro CRM" 

A priori simplemente deberíamos importar a automation nuestro script powershell (.ps1), crear el runbook y programar su ejecución ¿verdad? pero... nuestro script usa un archivo CSV local, el cual tenemos que ubicar en algún lugar accesible para el servicio de automation. En este caso pensamos en Hybrid Worker, no obstante no queremos instalar roles en maquinas locales y crear dependencias, nos interesa que la ejecución sea puramente en la nube así que vamos a usar el storage de azure, en concreto un File Share, para cargar ahí nuestros CSV y que estos sean consumidos por el runbook 👌

1. Creación de un File Share dentro de nuestra cuenta de almacenamiento y carga de archivos CSV

Doy por supuesto que tenemos una cuenta de storage en Azure por lo que no veremos el proceso de creación, tan sencillo como cualquier otra tarea de infraestructura en Azure

Para crear un recurso de archivos accedemos a la cuenta de almacenamiento y en el panel principal seleccionamos "Archivos", creamos un nuevo recurso indicando nombre y cuota si lo requerimos:

Una vez creado el recurso tenemos 2 opciones para cargar el/los archivos CSV requeridos por nuestro script, bien manual con el botón de carga o una idea sería usar el botón "conectar" que nos permite crear una unidad de red conectada al recurso en cualquiera de nuestras maquinas locales, tras esta conexión persistente podríamos automatizar la copia o exportación de archivos CSV a esta ubicación que a su vez sería el storage de azure 👀

       2.  Creación del runbook

Accedemos a la cuenta de automatización-->Runbooks e importamos nuestro script sin modificar su código, tal cual funciona en local, debemos seleccionar el achivo .ps1 e indicar el tipo "powershell", además de ponerle nombre:

Una vez cargado nos aparecerá disponible y podremos ver, editar, publicar, iniciar....

*Cada vez que editamos el runbook es necesario publicarlo para que sea funcional. Si no vamos a modificar nada es recomendable usar la opción "Ver"

Bien, una vez importado es necesario adecuar el script para que pueda conectar a la cuenta de almacenamiento, teniendo en cuenta que el servicio de automation no puede leer o escribir directamente en el storage de azure, da igual si son blob, table o files...así que la solución es descargar el archivo a ubicación TEMP durante la ejecución del runbook para que este pueda ser leído y por tanto crear los contactos en Exchange online a partir de el. 

Este sería nuestro resumen de edición y adecuación del script que ejecutará automation para conseguir nuestro cometido y usar ese tiempo tan preciado en otros temas de mas valor para el negocio: 

•  Variables para conectar a nuestra cuenta de almacenamiento:

$storageAccountName ="nombredelacuentadestorage"

$storageAccountKey ="clavealfanumericadelacuentadestorage"

$context = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $storageAccountKey 

• Variable donde se almacena la ubicación temporal donde se descarga el archivo CSV

$TempStorage=$env:TEMP + "\ExternalContacts.csv"

• Instrucción para la descarga desde File Share a ubicación temporal del archivo csv en cuestión:

Get-AzureStorageFileContent -ShareName nombrefileshare -Path "ExternalContacts.csv" -Destination $env:temp -Context $context

• Conexión a Exchange online donde se indica el nombre de unas credenciales que se han generado previamente con los permisos de Administrador de Exchange. De este modo evitamos escribir en nuestro código el usuario y la contraseña (explicado al inicio del post):

$UserCredential = Get-AutomationPSCredential -Name 'adm365'

$Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession -Session $Session -DisableNameChecking:$true -AllowClobber:$true | Out-Null

En el resto de script, donde no vamos a profundizar,  para conseguir la lectura del CSV y por tanto la  creación y adición de contactos a grupos habilitados para correo, tan solo debemos indicar como path del CSV esta variable $TempStorage 👌

Import-Csv $TempStorage | ForEach {New-MailContact ……………….

Solo nos quedaría probar, para ello tenemos el panel de prueba como recomendación previa a la publicación:

Y por ultimo "PUBLICAR"

        

      

      

       3. Programación del runbook 

Una vez lo tenemos testeado y publicado, es hora de programar su ejecución, en este caso será diaria a las 20:30 PM. Para ello debemos vincular una programación y si no existe ninguna, crearla. Las programaciones generadas pueden ser vinculadas o desvinculadas fácilmente a nuestros runbook

Hasta aquí este segundo post de la serie, en próximos post veremos lo más importante, monitorización y alertas sobre nuestros runbook integrando Azure Automation con Azure Monitor 

¡Un Saludo y Feliz automatización!

Azure Automation - Parte 1 - Creando la cuenta de automatización

Muy buenas a tod@s,

En esta ocasión volvemos a la carga con una serie de post relacionados con el servicio Azure Automation, el cual nos permite automatizar la creación, implementación, supervisión, mantenimiento de recursos de nuestro entorno Azure y/o sistemas externos (ejemplo Office 365).

En esta primera parte vamos a crear nuestra primera cuenta de automatización así que sin más dilación vamos al ataque.

Accedemos al portal de azure http://portal.azure.com y seleccionamos "Crear nuevo recurso" introduciendo "automation" en el campo de búsqueda:

Una vez tenemos los resultados seleccionamos "automation" y comenzamos el proceso de creación de la cuenta, introduciendo los valores obligatorios, si no disponemos de grupo de recursos habrá que crear uno, de lo contrario, usar uno existente

Más información sobre cuentas de ejecución de Azure:
https://docs.microsoft.com/es-es/azure/automation/manage-runas-account

Una vez rellenada la información obligatoria, seleccionamos crear y ya tendríamos nuestra primera cuenta de automatización preparada

Fácil ¿verdad?

En las siguientes partes de esta serie veremos como crear y programar Runbooks usando escenarios del día a día.

¡Feliz automatización!

Redirigir equipos incluidos en dominio a OU específica.

Hola,

Es bien conocido que la carpeta (ya que no es una OU), con el nombre Computers a la que van los equipos una vez los añadimos en el dominio, no es muy práctica ya que no permite asociar GPOs y además, solemos querer que los equipos vayan a otra OU creada por nosotros.

Pues bien, siempre ha existido un comando que varía ese comportamiento por defecto y nos ahorra, tener que pasar por el AD de vez en cuando para mover los nuevos equipos, los cuales, llevan unos días trabajando sin las GPOs pensadas para ellos.

Pues bien, el comando es: REDIRCMP

Y un ejemplo sería este:

REDIRCMP OU=OUdeseada,DC=Dominio,DC=local 

Espero que os sea de ayuda.

Saludos.

Azure - Crear una VM tras subir un VHD y recomendaciones

Hola,

A continuación os detallo el script necesarios para, usando Azure Powershell, crear una VM tras haber subido el disco VHD a un Container existente en un Blob Page.

Antes de detallaros el scipt, tener en cuenta lo siguiente:

- Si la máquina corre actualmente en un Hyper-V y tiene un disco VHDX, con la propia consola de Hyper-V y con la VM apagada, podéis editar el disco y partiendo de él, crear un archivo VHD Fijo.

- Crear VM en modo Generalized, se considera que el disco ha sido preparado para partiendo de él, crear varias máquinas virtuales. Por ello, a la VM modelo se le hace un sysprep antes de subir el VHD a Azure. (https://docs.microsoft.com/es-es/azure/virtual-machines/windows/capture-image-resource)

- El script es válido para una VM “Specialized”. Esto es una AzureVM creada a partir del VHD que es el mismo disco duro que estaba corriendo en una VM Hyper-V/Vmware en los que se ha convertido su disco VHDX o VMDK a VHD Fijo.

- Que tras crear la VM tenéis que instalar el agente de gestión de Azure, para el mero hecho de poder hacer Backups de la VM o bien por ejemplo utilizar opciones como resetear contraseña, monitorizarla, etc. (https://go.microsoft.com/fwlink/?LinkID=394789&clcid=0x409) A riesgo de ver errores como estos:

https://docs.microsoft.com/es-es/azure/backup/backup-azure-troubleshoot-vm-backup-fails-snapshot-timeout#the-agent-installed-in-the-vm-but-unresponsive-for-windows-vms

Script:

Este script cambia el orden y algunas pequeñas cosas, dando a mi juicio mayor sentido común, en relación a los pasos aparecidos aquí: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sa-create-vm-specialized

En el script partimos de tener un Grupo de recursos creado y el VHD subido.

$rgName = "RG1"
$location = "North Europe"
$vnetName = "Vnet1"
$vnet = New-AzVirtualNetwork -Name $vnetName -ResourceGroupName $rgName -Location $location -AddressPrefix     172.16.224.0/19 -Subnet $singleSubnet

$nsgName = "SG1"
$rdpRule = New-AzNetworkSecurityRuleConfig -Name myRdpRule -Description "Allow RDP" `
     -Access Allow -Protocol Tcp -Direction Inbound -Priority 110 `
     -SourceAddressPrefix Internet -SourcePortRange * `
     -DestinationAddressPrefix * -DestinationPortRange 3389
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $rgName -Location $location `
     -Name $nsgName -SecurityRules $rdpRule

$subnetName = "Vnet1_subnet1"
$singleSubnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix 172.16.224.0/24

$ipName = "PUblicIP1"
$pip = New-AzPublicIpAddress -Name $ipName -ResourceGroupName $rgName -Location $location -AllocationMethod Static

$nicName = "VM1Nic1"
$nic = New-AzNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id

$vmName = "Vm1"
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize "Standard_A2"

$vm = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id

$osDiskUri = https://XXXXXXXX.blob.core.windows.net/xxxxx/XXXXXX.vhd

$osDiskName = $vmName + "osDisk"
$vm = Set-AzVMOSDisk -VM $vm -Name $osDiskName -VhdUri $osDiskUri -CreateOption attach –Windows

New-AzVM -ResourceGroupName $rgName -Location $location -VM $vm –DisableBginfoExtension –credential (get-credential)

*Atentos a DisableBGINfoExtension  : De no deshabilitar tendréis problemas por ejemplo a la hora de configurar los discos como gestionados.

*-Credential: Es importante proporcionar a Azure las credenciales de un usuario administrador de la máquina, Si esto se realiza, se puede evitar la variable –DisableBgInfoExtension.

Atributos de Exchange en Active Directory con O365

Hola,

Es muy probable que tengáis un escenario con O365 sincronizado con un AD clásico vía ADConnect en el que no haya estado nunca instalado Exchange.

En este escenario descrito, no encontraréis en los usuarios y grupos locales, ciertos atributos que si están en el objeto de Azure AD, pero que allí arriba, no podéis variar, dado que el objeto está sincronizado desde el AD Clásico.  Además, cambiar el valor de estos atributos, es necesarios para poder conseguir ciertas funcionalidades, como evitar que al usuario o grupo le llegue correo externo, desaparezca de la libreta global de direcciones, etc.

Solución

Pues bien, para poder tener a vuestro en vuestro AD local los atributos que estáis viendo desactivados en O365, tenéis que ampliar el esquema utilizando la instalación de Exchange Server 2016. Yo de hecho pienso que cabría hacerlo por defecto en toda instalación nueva de ADConnect.

1. Para realizar esto, tenéis que conseguir el DVD de instalación de Exchange. El cual anteriormente era público pero ahora, para disponer de él, tendréis que recurrir a una suscripción MSDN o similar.

2. Iniciar sesión con un administrador del dominio. Mi consejo es que si no tenéis a mano el administrador original del dominio, copieis este creando uno nuevo. Los usuarios que han sido itnroducidos en grupo Admin del dominio, Administador de esquema, etc. no suelen funcionar.

3. Una vez descomprimido su contenido en el disco del DC que es Administrador de esquema (netdom query fsmo es el comando que tenéis que lanzar para saber qué DC es el administrador de Esquema) y con el CMD como administrador abierto. tenéis que lanzar el siguiente comando:

- .\Setup.exe /PrepareSchema /IAcceptExchangeServerLicencesTerms

4. Actualizar el Schema en ADConnect

y con esto, tendremos los atributos necesarios en los usuarios:

Error en Azure Backup VM por tener Discos Standard SSD

Hola

Si andáis necesitando hacer backup de Standard SSD disks en Azure. Tengo malas noticias para vosotros. No podemos realizar backup de máquinas virtuales con discos de este tipo asociados.

La solución pasa por convertirlos a Premium SSD Disk o actualizar vuestro Recovery Services Vault para realizar backup Stack 2, basado en salvado del disco tras realizar un snapshot del mismo. Por el momento no os recomiendo esta solución ya que a día de hoy, prácticamente todos los links de información del propio microsoft están "rotos" y no existe mucha información al respecto.

La solución que yo he ido adoptando es la convertir los discos a Premium y el script que utilizo es el siguiente:

* Adaptar a vuestro escenario solo las partes en rojo.

# Name of the resource group that contains the VM
$rgName = 'yourResourceGroup'

# Name of the your virtual machine
$vmName = 'yourVM'

# Choose between StandardLRS and PremiumLRS based on your scenario
$storageType = 'Premium_LRS'

# Premium capable size
# Required only if converting storage from standard to premium
$size = 'Standard_DS2_v2'

# Stop and deallocate the VM before changing the size
Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName -Force

$vm = Get-AzureRmVM -Name $vmName -resourceGroupName $rgName

# Change the VM size to a size that supports premium storage
# Skip this step if converting storage from premium to standard
$vm.HardwareProfile.VmSize = $size
Update-AzureRmVM -VM $vm -ResourceGroupName $rgName

# Get all disks in the resource group of the VM
$vmDisks = Get-AzureRmDisk -ResourceGroupName $rgName

# For disks that belong to the selected VM, convert to premium storage
foreach ($disk in $vmDisks)
{
    if ($disk.ManagedBy -eq $vm.Id)
    {
        $diskUpdateConfig = New-AzureRmDiskUpdateConfig –AccountType $storageType
        Update-AzureRmDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $rgName `
        -DiskName $disk.Name
    }
}

Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName