En este post vamos a ver como registrar Windows Admin Center en Azure, esto nos va a permitir usar los servicios de Azure en el centro de administración de Windows.

• Desde nuestra consola de Windows Admin Center, accedemos a Configuración > Cuenta > Registrarse con Azure:

• Damos a Registrar:

• Copiamos el código y lo escribimos:

• Iniciamos sesión con una cuenta de Administrador Global de Azure:

• Si accedemos a nuestro Portal de Azure > Microsoft Entra ID > Administrar > Registro de aplicaciones, vemos que nos ha creado esta aplicación para nuestro Windows Admin Center, copiamos el de aplicación (cliente):

• Pegamos el de aplicación Microsoft Entra y Conectar:

• Iniciamos sesión:

• Aceptamos los permisos:

• Nos dará un error de inicio de sesión:

• Sin embargo, podemos ver que ya estamos registrados:

• Para poder iniciar sesión, accedemos a Portal de Azure > Microsoft Entra ID > Administrar > Registro de aplicaciones, seleccionamos la aplicación de Windows Admin Center:

• Y sobre Administrar > Authetication > Configuración de URI de redirección agregamos la URI de nuestro Windows Admin Center:

• Seleccionamos la Aplicación de página única:

• Introducimos el URI de nuestro Windows Admin Center en Redirigir el URI, y marcamos los checks de Flujos de concesión implícita e híbridos, Tokens de acceso, Tokens de id, Configurar:

• Como podemos ver, ya la tenemos agregada, le hemos dado a Editar y hemos añadido otra URI, ya que accedemos de estas dos formas a nuestro Windows Admin Center:

• Volvemos a iniciar sesión en nuestro Windows Admin Center, y ya vemos que tenemos la sesión iniciada:

• Ahora, desde Windows Admin Center, si accedemos a uno de nuestros equipos:

• Nos vamos a Herramientas > Centro híbrido de Azure, podemos ver los servicios de Azure que podemos configurar en las máquinas de nuestra infraestructura on-premise:

• Para ver el Centro híbrido de Azure, antes debemos de instalar en Windows Admin Center, la extensión Azure hybrid center, y así con todas las extensiones de Azure que necesitemos para configurar un servicio:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo desplegar y configurar dos firewalls OPNSense en modo clúster HA en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar es acceder a este link de dmauser, aquí vamos a encontrar un desarrollo para desplegar dos firewalls OPNSense sobre FreeBSD en modo cluster HA Activo-Activo:

• Se nos abrirá esta plantilla para el despliegue de OPNSense, sobre Deployment Scenarios le indicamos la suscripción, el grupo de recursos, la región y muy importante OPNSense Scenario que le indicamos Active-Active:

• Sobre Virtual Machine Settings le indicamos el nombre y tamaño de máquina, la URL para la descarga del script, la versión de OPNSense y la versión del agente de Azure:

• Para el despliegue y la configuración de la red virtual en Azure, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales (ésta última la configuraremos a posteriori de la plantilla de despliegue):
• Red virtual: opnsenseha-vnet168.128.0/18
• Subred Externa: Untrusted-Subnet168.191.0/27
• Subred Interna: Trusted-Subnet168.191.32/27
• LAN Azure: SubnetLAN-192_168_128_0-24
• DMZ Azure: SubnetLAN-192_168_129_0-24

• Sobre Virtual Network Settings estas serían las configuraciones para nuestra infraestructura:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, comenzamos a Crear todos los recursos de la plantilla OPNSense deployment:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente, podemos ver, los distintos recursos que ha creado el despliegue de esta plantilla:

• Accedemos al grupo de recursos y vemos todos los recursos que se nos han creado, entre ellos, dos firewalls opnsense (primario y secundario), dos Load Balancer (Externo e Interno) y una IP pública:

• Ahora vamos a clicar sobre la máquina virtual opnsense-Primary:

• En la máquina virtual accedemos a Configuración de red y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN de OPNSense que tiene asignada una IP privada del rango de la subred Untrusted, y la otra es la interface LAN que tiene asignada una IP privada del rango de la subred Trusted:

• Debemos de configurar las IPs privadas como estáticas, tanto la WAN cono la LAN:

• Para la máquina opnsense-Secondary hacemos lo mismo:

• Otro de los recursos que se han creado es el Load Balancer Interno:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP del rango de la subred Trusted:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Trusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada para equilibrar la carga entre los dos firewalls:

• Otro de los recursos que se han creado es el Load Balancer Externo:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP pública, que será la que nos dará la entrada y salida desde y hacia la WAN:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Untrusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada a modo de ejemplo para definir cómo se distribuye el tráfico entrante a todas las instancias del grupo de back-end, en este ejemplo sería una regla creada en el puerto 3389 para equilibrar la carga del tráfico RDP:

• Sobre Regla NAT de entrada, tenemos dos reglas configuradas para el acceso a los firewalls opnsense a través de su IP pública, al firewall primario se accede por el puerto 50443 y al firewall secundario por el puerto 50444, que como vemos está mapeado al puerto 443 de cada firewall:

• Sobre Reglas de salida, tenemos configurada una regla para la salida a la WAN de nuestra infraestructura, con esta regla todas las máquinas ubicadas detrás de los firewalls van a salir a Internet con la IP pública de nuestro load balancer externo:

• Para acceder a los firewalls accedemos a través de su IP pública, https://PublicIP:50443 para el primario y https://publicip:50444 para el secundario, las credenciales por defecto son root/opnsense:

• Lo primero que vamos a configurar en los firewall opnsense, va a ser la configuración de HA.
• Nos vamos primero al firewall primario y sobre System > High Availability > Settings configuramos el peer del firewall secundario:

• Ahora accedemos al firewall secundario y sobre System > High Availability > Settings configuramos el peer del firewall primario:

• Accedemos de nuevo al firewall primario y sobre System > High Availability > Status sincronizamos y reconfiguramos todo, una vez configurado este cambio, todo lo que hagamos y configuremos en el firewall opnsense primario se va a replicar en el firewall opnsense secundario:

• Veamos un ejemplo, hemos configurado los servidores NTP en el firewall primario:

• Sincronizamos todos los servicios:

• Una vez que se ha sincronizado todo, si accedemos al firewall secundario, vemos que la configuración de los servidores NTP se ha replicado correctamente:

• Como comentamos anteriormente, vamos a configurar la red local de Azure dónde se conectarán nuestras máquinas virtuales, LAN Azure: SubnetLAN-192_168_128_0-24 y DMZ Azure: SubnetDMZ-192_168_129_0-24:

• Lo siguiente que vamos a desplegar y configurar es una tabla de rutas UDR (User Definition Routes) en Azure.
• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar las subredes LAN y DMZ que configuramos anteriormente, estas subredes son dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya las tenemos asociadas:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas > Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred LAN dónde vamos a ubicar nuestras máquinas virtuales:

• La siguiente ruta será para el acceso a la subred DMZ dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Sobre Información general en la tabla de rutas, podemos ver, todo lo que se ha configurado:

• Una vez configurada la tabla de rutas, accedemos a nuestro OPNSense HA en Azure, y nos vamos a crear estas dos rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del OPNSense lo envíe por la interface WAN al gateway de la subred Untrusted, y la segunda ruta son para servicios internos de Azure, para que lo envíe por la interface LAN al gateway de la subred Trusted:

• Para todas las demás configuraciones de opnsense, podemos seguir los enlaces a estos post creados hace algún tiempo en el blog.

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar la versión de Microsoft Entra Connect a 2.5.3.0:

• Como podemos ver tenemos la versión 2.4.131.0 de Microsoft Entra Connect:

• Lo primero que vamos a realizar será descargarnos la última versión de Microsoft Entra Connect, para ello, nos vamos al Centro de administración de Microsoft Entra > Identidad > Administración híbrida > Microsoft Entra Connect > Tareas iniciales > Adminsitrar > Administrar desde el entorno local: Sincronización de Connect > Descargar el agente de sincronización de Connect:

• Aceptamos las condiciones y descargamos:

• Como podemos ver aquí lo tenemos descargado:

• Ahora en el servidor que tenemos instalado el servicio de Microsoft Entra Connect ejecutamos el msi descargado:

• Se nos abre el siguiente asistente, sobre Actualización de Microsoft Entra Connect Sync, marcamos el check Configurar autenticación basada en aplicaciones para Microsoft Entra ID (versión preliminar) y Actualizar:

• Aquí vemos como comienza la actualización:

• Sobre Conectarse a Microsoft Entra ID, conectamos con Microsoft Entra ID, para ello, introducimos las credenciales de un administrador glogal de Azure, clic en Siguiente:

• Sobre Configurar, marcamos el check para que inicie el proceso de sincronización, clic sobre Actualizar:

• Comienza a sincronizar:

• Como podemos ver, la Configuración está completa, clic en Salir:

• Aquí vemos que la versión de Microsoft Entra Connect es la nueva versión 2.5.3.0:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar Azure Update Manager para gestionar todo el proceso de actualizaciones y parcheos de nuestras máquinas virtuales tanto con sistema operativo Windows como con Linux.

Update Manager es un servicio unificado que ayuda a administrar y controlar las actualizaciones de todas las máquinas (que ejecutan un sistema operativo de servidor). Puede supervisar el cumplimiento de actualizaciones de Windows y Linux en las máquinas de Azure, los entornos locales u otros entornos de nube (conectados mediante Azure Arc) desde un único panel de administración. También puede usar Update Manager para realizar actualizaciones en tiempo real o programarlas dentro de una ventana de mantenimiento definida.

Podemos usar el Administrador de actualizaciones de Azure para:

• Unified Update Management: supervise el cumplimiento de actualizaciones en máquinas Windows y Linux (que ejecutan un sistema operativo de servidor) desde un único panel, incluidas las máquinas de Azure, los entornos locales u otros entornos de nube (conectados mediante Azure Arc).
• Opciones de aplicación de revisiones flexibles:

– Programe las actualizaciones en el mantenimiento definido por el cliente para máquinas conectadas a Azure y Arc.

– Aplicar actualizaciones en tiempo real.

– Use la aplicación automática de revisiones de invitado de máquina virtual para aplicar automáticamente actualizaciones a máquinas virtuales de Azure sin necesidad de ninguna intervención manual.

– Use la aplicación de revisiones en caliente para aplicar actualizaciones críticas a las máquinas virtuales de Azure sin necesidad de reiniciar, lo que minimiza el tiempo de inactividad

• Seguimiento de seguridad y cumplimiento: aplique revisiones críticas y de seguridad con medidas de seguridad mejoradas y seguimiento del cumplimiento.
• Evaluaciones de actualizaciones periódicas: habilite evaluaciones periódicas para comprobar si hay actualizaciones cada 24 horas.
• Ámbito dinámico: agrupe las máquinas según los criterios y aplique actualizaciones a escala.
• Informes y alertas personalizados: cree paneles personalizados para informar sobre el estado de actualización, y configure alertas para que le notifiquen los estados de actualización y los problemas que surjan.
• Control de acceso granular: use el control de acceso basado en roles (RBAC) para delegar permisos para las tareas de administración de revisiones a nivel de recurso.
• Actualizaciones de software, incluidas las actualizaciones de aplicaciones:

– Que están disponibles en Actualizaciones de Microsoft

– Que están disponibles en los paquetes de Linux

– Que se publican en Windows Server Update Services (WSUS)

• Aplicación de revisiones a diversos recursos

– Azure Virtual Machines (VM): máquinas virtuales de Windows y Linux en Azure (incluidos los servidores SQL Server). Las máquinas virtuales también incluyen las creadas con Azure Migrate, Azure Backup y Azure Site Recovery.

– Máquinas híbridas (incluidos los servidores SQL Arc) y Windows IoT Enterprise en servidores habilitados para Arc

– Máquinas de VMware

– Máquinas System Center Virtual Machine Manager (SCVMM)

– Clústeres de Azure Local

– Aplicar revisiones entre suscripciones

Fuente: Microsoft Learn

• Para explicar el servicio Azure Update Manager vamos a utilizar dos máquinas virtuales, una con Windows Server 2025 y otra con Ubuntu Server 24.04 LTS:

• Con Azure Update Manager podemos realizar las siguientes tareas:
• Configuración de las actualizaciones para que no se instalen automáticamente, y definir nosotros las programación.
• Revisión de actualizaciones pendientes.
• Instalar las actualizaciones directamente desde el portal de Azure Update Manager
• Configurar periódicamente las revisiones de actualizaciones pendientes
• Programar la instalación de actualizaciones automáticamente.
• Para empezar, accedemos al portal de Azure y nos vamos a Azure Update Manager > Máquinas y ya podremos ver todas nuestras máquinas virtuales, no hay que realizar nada para agregarlas, es automático:

• Seleccionamos las dos máquinas y clicamos sobre Actualizar la configuración:

• Cambiamos la configuración en la Orquestación de revisiones como Programaciones administradas por el cliente damos a Guardar:

• Como vemos, ya ha cambiado:

• Ahora seleccionamos las dos máquinas y damos a Comprobar la disponibilidad de actualizaciones:

• Damos a Buscar actualizaciones:

• Una vez completada la Comprobación de la disponibilidad de actualizaciones podemos ver que nuestra máquina Linux tiene 45 actualizaciones pendientes y la máquina Windows 4 actualizaciones pendientes:

• Para ver las actualizaciones pendientes de la máquina Windows pulsamos sobre 4 actualizaciones pendientes y vemos las actualizaciones que están por aplicar:

• Para ver las actualizaciones pendientes de la máquina Linux pulsamos sobre 45 actualizaciones pendientes y vemos las actualizaciones que están por aplicar:

• Ahora vamos a actualizar de forma manual estas dos máquinas, para ello, volvemos de nuevo a Azure Update Manager > Máquinas > Las seleccionamos y damos a Actualización única:

• Damos a Agregar máquinas:

• Se nos abre este asistente, sobre Máquinas seleccionamos las dos máquinas, Siguiente:

• Sobre Actualizaciones podemos seleccionar que actualizaciones queremos instalar, seleccionar por clasificación de actualización, incluir por id. de KB/paquete, excluir por id. de KB/paquete, incluir por la fecha máxima de publicación de revisiones, en este caso, vamos a instalar todo, Siguiente:

• Sobre Propiedades seleccionamos las opciones de reinicio que nos interesen y la ventana de mantenimiento en minutos, Siguiente:

• Sobre Revisar e instalar nos muestra un resumen de todo lo configurado, Instalar:

• Si accedemos a Administrar > Historial vemos que ya está en proceso la carga e instalación de las actualizaciones en ambas máquinas:

• Y aquí vemos, que ya se han implementado e instalado correctamente las actualizaciones tanto en la máquina Windows como en la Linux:

• Ahora vamos a configurar la Comprobación de la disponibilidad de actualizaciones para que se realice de forma automática y no manual, para ello, sobre Azure Update Manager > Máquinas > Las seleccionamos y damos a Actualizar configuración:

• Habilitamos la Evaluación periódica y Guardar:

• Aquí vemos, que ya se ha habilitado la Evaluación periódica:

• Sobre Información general de Azure Update Manager, podemos ver el estado de actualizaciones de nuestra infraestructura de máquinas virtuales:

• Para terminar, vamos a ver otra opción, que va a ser, como Programar actualizaciones, haremos dos programaciones una para servidores Windows y otra para servidores Linux.
• Vamos a empezar con la programación de los servidores Windows, para ello, sobre Azure Update Manager > Máquinas seleccionamos los servidores Windows y damos a Programar actualizaciones > + Crear nueva programación:

• Sobre Datos básicos, seleccionamos un grupo de recursos que nos hemos creado anteriormente, le damos un nombre a la configuración, seleccionamos la región, el ámbito de mantenimiento, la configuración de reinicio y agregamos una programación que será el segundo martes de cada mes a las 21:00h, ya que Microsoft saca las actualizaciones este día de cada mes:

• Sobre Recursos, seleccionamos la máquina Windows:

• Sobre Ámbitos dinámicos, no configuramos nada:

• Sobre Actualizaciones en + incluir la clasificación de la actualización, seleccionamos solo las que nos interesen para las Máquinas Windows, Agregar:

• Damos a Revisar y crear:

• Vemos que supera la validación, damos a Crear:

• Como podemos ver, la implementación se ha completado correctamente:

• Si accedemos al grupo de recursos, podemos ver el recurso de la Configuración de mantenimiento:

• Ahora vamos a configurar la programación de los servidores Linux, para ello, sobre Azure Update Manager > Máquinas seleccionamos los servidores Linux y damos a Programar actualizaciones > + Crear nueva programación:

• Sobre Datos básicos, seleccionamos un grupo de recursos que nos hemos creado anteriormente, le damos un nombre a la configuración, seleccionamos la región, el ámbito de mantenimiento, la configuración de reinicio y agregamos una programación que será el segundo miércoles de cada mes a las 21:00h:

• Sobre Recursos, seleccionamos la máquina Linux:

• Sobre Ámbitos dinámicos, no configuramos nada:

• Sobre Actualizaciones en + incluir la clasificación de la actualización, seleccionamos solo las que nos interesen para las Máquinas Linux, Agregar:

• Damos a Revisar y crear:

• Vemos que supera la validación, damos a Crear:

• Como podemos ver, la implementación se ha completado correctamente:

• Si accedemos al grupo de recursos, podemos ver el recurso de la Configuración de mantenimiento:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo programar el inicio y apagado de máquinas virtuales con Start Stop v2.

La característica Start/Stop VMs v2 inicia o detiene las máquinas virtuales de Azure en varias suscripciones. Inicia o detiene las máquinas virtuales según las programaciones definidas por el usuario, proporciona información desde Azure Application Insights y envía notificaciones opcionales mediante grupos de acciones. En la mayoría de los escenarios, Start/Stop VMs puede administrar las máquinas virtuales implementadas y administradas tanto por Azure Resource Manager como por Azure Service Manager (clásico), en desuso.

Esta nueva versión de Start/Stop VMs v2 proporciona una opción de automatización económica centralizada para los clientes que quieren optimizar los costos de las máquinas virtuales. Ofrece la misma funcionalidad que la versión original que estaba disponible con Azure Automation, pero está diseñada para aprovechar las ventajas de la tecnología más reciente de Azure. La versión 2 de Start/Stop para máquinas virtuales se basa en varios servicios de Azure y se cobrará en función de los servicios que se implemente y consuma.

Fuente: Microsoft Learn

• Para poder empezar a crear y usar este servicio, vamos a irnos al Marketplace buscamos start stop y seleccionamos Start/Stop VMs during off hours – V2:

• Podemos ver, que tenemos dos tipos de planes, StartStopV2 y StartStopV2-AZ, el segundo es si tenemos configuradas zonas de disponibilidad, en nuestro caso vamos a elegir el primer plan StartStopV2:

• Si accedemos a Información general, vemos que para implementar este servicio vamos a necesitar de otros servicios de Azure, como son Function App, Logic App, Application Insights, dashboard, una cuenta de almacenamiento y el Monitor, Crear:

• Sobre Básico, le indicamos la suscripción, región, grupo de recursos, Azure Function, Application Insights, cuenta de almacenamiento, el área de trabajo para logs analytics y un email para que nos lleguen las notificaciones:

• Sobre Revisar y crear, nos muestra un resumen con todo lo configurado, Crear:

• Como podemos ver, la implementación se ha realizado correctamente:

• Si accedemos al grupo de recursos, vemos todos los recursos que se nos han creado para implementar la solución:

• Para configurar esta solución vamos a utilizar las aplicaciones lógicas por programación, concretamente vamos a utilizar dos, una para iniciar las máquinas ststv2_vms_Scheduled_start y otra para detenerlas ststv2_vms_Scheduled_stop:

• Empezaremos configurando ststv2_vms_Scheduled_start para el inicio de las máquinas virtuales, para ello, accedemos al Diseñador de aplicación lógica dónde vamos a configurar el diseño de la aplicación por medio de Azure Functions:

• Empezaremos configurando el Recurrence, que es la programación de inicio de la tarea, en este caso, todos los días a las 7:45:

• Lo siguiente que vamos a configurar será la tarea del Function-Try, que como podemos ver, nos da un ejemplo de cómo lo podemos configurar, este ejemplo lo vamos a eliminar y vamos a configurar el que a nosotros nos interesa:

• En esta web de Microsoft tenemos ejemplos de cómo configurar Function-Try, que lo podemos configurar a nivel de suscripción, grupo de recursos o máquinas virtuales, en nuestro caso, lo vamos a realizar a nivel de máquinas virtuales, por lo que vamos a copiar este ejemplo:

• Como podemos ver este ejemplo incluye tres máquinas virtuales, en nuestro caso, solo lo vamos a realizar con una máquina virtual:

• Y nos quedaría de la siguiente manera:

• El Id. de recurso lo copiamos desde las propiedades de la máquina virtual:

• Esta misma Function-Try es la que vamos a utilizar para detener las máquinas virtuales, solo que cambiaremos start por stop en la acción.
• Ahora guardamos los cambios:

• Una vez que hemos guardado los cambios sobre Información general, debemos de habilitarlo:

• Ahora vamos a configurar ststv2_vms_Scheduled_stop para el apagado de las máquinas virtuales, para ello, accedemos al Diseñador de aplicación lógica dónde vamos a configurar el diseño de la aplicación por medio de Azure Functions, y hacemos exactamente lo mismo que hemos realizado para el inicio, pero cambiando la acción por stop.
• Empezaremos configurando el Recurrence, que es la programación de inicio de la tarea, en este caso, todos los días a las 19:30:

• Lo siguiente que vamos a configurar será la tarea del Function-Try, que como podemos ver, es la misma que para el inicio, pero hemos cambiado la acción a stop:

• Ahora guardamos los cambios:

• Una vez que hemos guardado los cambios sobre Información general, debemos de habilitarlo:

• Si antes de empezar todo este proceso, queremos tener más granularidad en nuestra infraestructura a la hora de iniciar y apagar máquinas virtuales, estas dos aplicaciones lógicas las podemos clonar y darle un nombre más descriptivo, y configurar el Recurrence a distintas horas según nos interese:

• Con todo esto, ya quedaría configurado nuestro encendido y apagado ordenado de máquinas virtuales de manera automatizada.

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo crear y configurar una zona DNS secundaria en Azure mediante la zona DNS primaria.

• Como podemos ver, tenemos esta zona DNS primaria en Azure, en este link podéis ver cómo se crea y se configura:

• Ahora, vamos a crear una zona DNS secundaria y delegarla en la zona DNS primaria, para ello, nos vamos a Información general > + Zona secundaria:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos y el nombre del subdominio:

• Sobre Editor de zonas DNS, lo dejamos como está:

• Sobre Etiquetas, podemos configurar las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, Crear:

• Como podemos ver, se ha implementado correctamente:

• Si accedemos al grupo de recursos, podemos ver el recurso que hemos implementado:

• Una vez que hemos creado la zona DNS secundaria ragasysweb.com, comprobamos que la delegación se ha configurado correctamente, para ello debemos verificar, que los registros del servidor de nombres NS de la zona secundaria están en la zona primaria:

Saludos y espero que os sea de ayuda

En este post vamos a ver como realizar copias de seguridad y restauraciones de Microsoft Entra ID con Veeam Backup & Replication.

Microsoft Entra ID anteriormente era conocido como Azure Active Directory, es la solución integrada de identidad y acceso a la nube utilizada por Microsoft.

• Lo primero que vamos a realizar es agregar el inquilino de Microsoft Entra ID a Veeam Backup & Replication, para ello, accedemos a Inventory > Microsoft Entra ID > Add Microsoft Entra ID Tenant:

• Sobre Tenant, añadimos el ID de nuestro inquilino de MS Entra ID, le damos una descripción y seleccionamos el repositorio para la Cache:

• Para saber cuál es el ID de nuestro inquilino de MS Entra ID, accedemos al portal de Microsoft Entra ID y sobre Identidad > Información general lo podemos ver y copiar:

• Sobre Account Type, creamos una nueva cuenta:

• Sobre Authentication, nos copiamos el código que nos ha dado Veeam y accedemos a la web indicada de Microsoft:

• Copiamos el código y siguiente:

• Seleccionamos la cuenta con la que vamos a acceder, debe de ser un administrador global de Microsoft Entra ID:

• Continuamos:

• Y nos indica que ya podemos cerrar la ventana:

• Ahora volvemos de nuevo a nuestro servidor de Veeam y continuamos, Apply:

• Sobre Apply, podemos ver que se ha agregado correctamente:

• Sobre Summary, nos muestra un resumen y finalizamos:

• Como podemos ver, ya tenemos nuestro tenant de Microsoft Entra ID, agregado:

• Si accedemos al portal del Centro de administración de Microsoft Entra, y nos vamos a Identidad > Aplicaciones > Registro de aplicaciones, podemos ver, que ya tenemos añadido nuestro Veeam:

• Ahora vamos a crear los trabajos de backups, hay dos tipos de trabajos de copia de seguridad disponibles, copia de seguridad del inquilino y copia de seguridad del registro de auditoría, empezaremos por la copia de seguridad del inquilino:

• Sobre Name, le indicamos un nombre y una descripción:

• Sobre Tenant, le indicamos el inquilino y los días de retención:

• Sobre Schedule, vamos a programar la tarea, todos los días a las 11 de la noche:

• Sobre Summary, nos muestra un resumen de todo lo que hemos configurado, le indicamos que inicie la tarea cuando demos a finalizar:

• Aquí podemos ver, que se ha iniciado la tarea:

• Como podemos ver, la copia de seguridad se ha realizado correctamente:

• Ahora vamos a configurar la copia de seguridad del registro de auditoría:

• Sobre Name, le indicamos un nombre y una descripción:

• Sobre Tenant, le indicamos el inquilino:

• Sobre Storage, le indicamos el repositorio y los días de retención:

• Sobre Schedule, vamos a programar la tarea, todos los días a las 11:30 de la noche:

• Sobre Summary, nos muestra un resumen de todo lo que hemos configurado y finalizamos:

• Aquí podemos ver, la tarea programada, la lanzamos para hacer un backup, pulsando Start:

• Aquí vemos el progreso del backup:

• Como podemos ver, la copia de seguridad se ha realizado correctamente:

• Una vez que ya tenemos los trabajos de copias de seguridad configurados y alguna copia hecha, vamos a ver como restaurar varios usuarios de Microsoft Entra ID que hayamos eliminado por equivocación, eliminamos estos tres usuarios:

• Ahora, en nuestro servidor de Veeam Backup, accedemos a Home > Backups > Disk, seleccionamos la copia del inquilino de Entra ID y damos a Restore:

• Seleccionamos los tres usuarios que queremos recuperar, y damos a Restore > Full restore:

• Sobre Users, seleccionamos los tres usuarios y el punto de restauración:

• Sobre Logon, copiamos el código que nos ha dado y acedemos a la web que nos indica:

• Introducimos el código:

• Seleccionamos la cuenta con la que vamos a acceder, debe de ser un administrador global de Microsoft Entra ID:

• Estos son los permisos que solicita, aceptamos:

• Nos indica que ya hemos iniciado sesión y podemos cerrar la ventana:

• Si volvemos a nuestro servidor de Veeam, en Logon, nos indica que ya estamos logueados, clic en siguiente:

• Sobre Options, le indicamos que sobrescriba los objetos, ya que están totalmente eliminados, le asignamos un password, y que lo cambien y que lo cambien en el primer inicio de sesión:

• Sobre Reason, podemos indicar un comentario a la restauración:

• Sobre Summary, nos muestra un resumen de todo lo que hemos ido realizando:

• Confirmamos:

• Aquí vemos que los tres usuarios se han restaurado correctamente:

• Si accedemos al Centro de administración de Microsoft Entra ID, vemos que ya tenemos los tres usuarios restaurados:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar una IP pública con SKU Basic a SKU Stantard en Microsoft Azure, a partir del 30 de septiembre de 2025, las direcciones IP públicas con SKU básicas se retirarán en Azure, las vamos a poder seguir utilizando hasta entonces; sin embargo, ya no vamos a poder crear nuevas después del 31 de marzo de 2025, para evitar posibles interrupciones del servicio, debemos actualizar a direcciones IP públicas con SKU estándar antes del 30 de septiembre de 2025, aquí vamos a ver cómo hacerlo.

• Aquí vemos que tenemos una IP pública con SKU basic, asignada a la interface de red de una máquina virtual:

• Para migrarla a SKU standard, lo primero que tenemos que hacer es desasociarla de la interface de red de la máquina virtual:

• Le indicamos que Sí:

• Una vez que la hemos desasociado de la interface de red de la máquina virtual, vamos a pinchar sobre el enlace que nos proporciona el portal de Azure, Actualizar a la SKU estándar: Microsoft recomienda una dirección IP pública de SKU estándar para las cargas de trabajo de producción:

• Lo confirmamos y le indicamos que Sí:

• Como podemos ver, ya tenemos nuestra IP pública migrada a SKU Standard:

• Para terminar, volvemos a asociarla a la interface de red de la máquina virtual:

• Seleccionamos la interface de red y aceptamos:

• Como podemos ver, ya la tenemos de nuevo asociada:

• Y ya saben a migrar se ha dicho.

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo crear repositorios de backups con inmutabilidad en Azure Blob Storage con Veeam B&R 12.2.

• Antes de empezar a configurar Azure blob storage, nos hemos creado una cuenta de almacenamiento con estas configuraciones:
• Sobre Datos básicos configuramos el nombre de la cuenta, rendimiento y redundancia:

• Sobre Avanzado, configuramos Blob Storage como Esporádico:

• Sobre Redes, lo dejamos por defecto:

• Sobre Protección de datos, desmarcamos los checks para Habilitar la eliminación y configuramos en Seguimiento > Habilitar el control de versiones para blobs, ya que cuando configuremos el repositorio en el servidor de veeam vamos a configurar la inmutabilidad, esta parte solo se puede configurar al crear la cuenta de almacenamiento:

• Sobre Cifrado, lo dejamos por defecto:

• Sobre Etiquetas, configuraríamos las que nos interesaran:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, Crear:

• Una vez creada la cuenta de almacenamiento con sus respectivas configuraciones, lo primero que tenemos que tener es un contenedor de Azure Blob Storage con un nivel de acceso Privado, y sobre Avanzado marcamos el check Habilitar la compatibilidad con la inmutabilidad de nivel de versión:

• Ahora desde nuestra consola de Veeam Backup & Replication, accedemos a Backup Infrastructure > Backup Repositories > Add Repository:

• Se nos abre el siguiente asistente, dónde seleccionamos Object storage:

• Seleccionamos Hyperscalers:

• Seleccionamos Microsoft Azure Storage:

• Seleccionamos Azure Blob Storage:

• Sobre Name le indicamos un nombre y una descripción:

• Sobre Account, añadimos nuestra cuenta de almacenamiento de Azure, nos pide el nombre de la cuenta y la shared key:

• Estos son los datos que necesitamos, nombre de la cuenta de almacenamiento y la key:

• Como podemos ver, ya tenemos la cuenta de almacenamiento añadida, le indicamos la Region y el modo de conexión Direct, clic en siguiente:

• Sobre Container seleccionamos el contenedor que nos hemos creado en Azure, y en Folder nos creamos una nueva carpeta para este repositorio:

• Como podemos ver, ya tenemos el Container y su carpeta, limitamos el almacenamiento a 1 TB, y hacemos que los backups sean inmutables por 5 días:

• Sobre Mount Server, lo dejamos tal cuál:

• Sobre Review, nos indica si nos falta algún componente, en nuestro caso, está todo correcto, Apply:

• Sobre Apply, nos muestra que todo está correcto:

• Nos muestra un resumen y finalizamos:

• Aquí vemos que ya tenemos nuestro backup repository creado, listo para empezar a volcar nuestros backups a la nube de Azure:

• Ahora, nos vamos a crear un backup copy job y usaremos este repositorio de object storage, para almacenar el backup:

• Sobre Job, le indicamos un nombre y una descripción

• Sobre Objects, añadimos el trabajo de backup que queremos replicar:

• Sobre Target, le indicamos el repositorio que nos hemos creado en Azure y los puntos de retención:

• Sobre Data Transfer, le indicamos Direct:

• Sobre Schedule, le indicamos que empiece el trabajo al finalizar el principal:

• Sobre Summary, nos muestra un resumen de todo lo configurado y finalizamos:

• Como podemos ver, el backup copy job, comienza a ejecutarse tras finalizar la configuración:

• Vemos que termina satisfactoriamente:

• Una vez finalizado, vemos en los backups, el Object Storage de la copia realizada:

• Para verificar que la inmutabilidad está funcionando correctamente, vamos a intentar eliminar el object storage:

• Y nos dará este bonito error, indicándonos que el backup no se puede eliminar porque está marcado como inmutable:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo crear repositorios de backups sin inmutabilidad en Azure Blob Storage con Veeam B&R 12.2.

• Antes de empezar a configurar Azure blob storage, nos hemos creado una cuenta de almacenamiento con estas configuraciones:
• Sobre Datos básicos configuramos el nombre de la cuenta, rendimiento y redundancia:

• Sobre Avanzado, configuramos Blob Storage como Esporádico:

• Sobre Redes, lo dejamos por defecto:

• Sobre Protección de datos, desmarcamos los checks para Habilitar la eliminación:

• Sobre Cifrado, lo dejamos por defecto:

• Sobre Etiquetas, configuraríamos las que nos interesaran:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, Crear:

• Una vez creada la cuenta de almacenamiento con sus respectivas configuraciones, lo primero que tenemos que tener es un contenedor de Azure Blob Storage con un nivel de acceso Privado:

• Ahora desde nuestra consola de Veeam Backup & Replication, accedemos a Backup Infrastructure > Backup Repositories > Add Repository:

• Se nos abre el siguiente asistente, dónde seleccionamos Object storage:

• Seleccionamos Hyperscalers:

• Seleccionamos Microsoft Azure Storage:

• Seleccionamos Azure Blob Storage:

• Sobre Name le indicamos un nombre y una descripción:

• Sobre Account, añadimos nuestra cuenta de almacenamiento de Azure, nos pide el nombre de la cuenta y la shared key:

• Estos son los datos que necesitamos, nombre de la cuenta de almacenamiento y la key:

• Como podemos ver, ya tenemos la cuenta de almacenamiento añadida, le indicamos la Region y el modo de conexión Direct, clic en siguiente:

• Sobre Container seleccionamos el contenedor que nos hemos creado en Azure, y en Folder nos creamos una nueva carpeta para este repositorio:

• Como podemos ver, ya tenemos el Container y su carpeta, limitamos el almacenamiento a 1 TB:

• Sobre Mount Server, lo dejamos tal cuál:

• Sobre Review, nos indica si nos falta algún componente, en nuestro caso, está todo correcto, Apply:

• Sobre Apply, nos muestra que todo está correcto:

• Nos muestra un resumen y finalizamos:

• Aquí vemos que ya tenemos nuestro backup repository creado, listo para empezar a volcar nuestros backups a la nube de Azure:

• Ahora, nos vamos a crear un backup copy job y usaremos este repositorio de object storage, para almacenar el backup:

• Sobre Job, le indicamos un nombre y una descripción:

• Sobre Objects, añadimos el trabajo de backup que queremos replicar:

• Sobre Target, le indicamos el repositorio que nos hemos creado en Azure y los puntos de retención:

• Sobre Schedule, le indicamos que empiece el trabajo al finalizar el principal:

• Sobre Summary, nos muestra un resumen de todo lo configurado y finalizamos:

• Como podemos ver, el backup copy job, comienza a ejecutarse tras finalizar la configuración:

• Vemos que termina satisfactoriamente:

• Una vez finalizado, vemos en los backups, el Object Storage de la copia realizada:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba y una conmutación por error en las réplicas de máquinas virtuales que hemos configurado entre las distintas regiones de Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error, el punto de recuperación y la red virtual, clic sobre Conmutación por error de prueba:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Si accedemos al Diagnóstico de arranque, podemos ver la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error y el punto de recuperación, clic sobre Conmutación por error:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Si accedemos al Diagnóstico de arranque, podemos ver la máquina levantada:

• Si accedemos al almacén de recovery services > Elementos protegidos > Elementos replicados, podmeos ver que la conmutación por error está completa:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error, Confirmación:

• Aquí vemos que la confirmación ha sido correcta:

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales entre dos regiones de Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos en nuestro entorno cloud de Azure esta máquina virtual con dos discos, uno de sistema y otro de datos, en la región de West Europe:

• Esta máquina virtual pertenece a esta red virtual ubicada también en la región de West Europe:

• Ahora nos vamos a crear un grupo de recursos llamado replicas-az-rg, ubicado en una región diferente de dónde se encuentre la máquina virtual a replicar, en nuestro caso North Europe, en este grupo de recursos vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Azure entre regiones:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred en la misma región del grupo de recursos, North Europe, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada:

• Ahora vamos a crear un almacén de recovery services, en este mismo grupo de recursos y en la región North Europe, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, Para máquinas virtuales de Azure, que en este caso es la que nos interesa, para máquinas físicas y VMware, para System Center VMM y para sitios de Hyper-V:

• Lo primero que vamos a realizar será la Asignación de red, dónde configuraremos el origen y destino:

• Así nos quedaría:

• Ahora vamos a crear las directivas de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Para máquinas físicas y VMware > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre y el Periodo de retención en días:

• Aquí vemos las directivas de replicación que nos hemos creado:

• Una vez definida la infraestructura de Site Recovery para máquinas virtuales de Azure, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales, ara ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Azure Virtual Machines:

• Le indicamos el origen de la máquina virtual que queremos replicar:

• Seleccionamos la máquina virtual:

• Sobre Configuración de replicación, seleccionamos la Ubicación y grupo de recursos el grupo de recursos, la Red y subred dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla al hacer la conmutación por error, editamos la configuración del almacenamiento y las opciones de disponibilidad:

• Sobre Administrar, le indicamos la directiva de replicación, permitimos la administración por parte de ASR y no va a crear una cuenta de Automation para el proceso:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, podemos ver, todo lo que se ha implementado:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado del proceso está en curso, en este caso, habilitando la protección, luego pasa a crear la réplica inicial, % sincronizado, esperando para el primer punto de recuperación:

• Esperamos a que el proceso termine y nos muestre el Estado como Protected, esto quiere decir, que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación, también nos muestra el estado y una vista de la infraestructura de replicación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso, nos muestra la configuración de origen y de destino:

• Sobre General > Red, nos muestra la red de origen y de destino:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual:

• Si accedemos al grupo de recursos que creamos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Sobre el grupo de recursos para las réplicas que creamos anteriormente, podemos ver la cuenta de Automation que también creamos en un paso anterior:

• Sobre el almacén de recovery services > Infraestructura de Site Recovery > Para Azure máquinas virtuales > Asignación de red, vemos las dos asignaciones que se han creado:

• Con esto, ya tendríamos configuradas las réplicas de máquinas virtuales entre distintas regiones de Azure, en el próximo post veremos cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde VMware vSphere a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error, el punto de recuperación y la red virtual, clic sobre Conmutación por error de prueba:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error y el punto de recuperación, clic sobre Conmutación por error:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de VMware vSphere On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error, Confirmación:

• Aquí vemos que la confirmación ha sido correcta:

• Una vez realizada la conmutación por error y confirmada, ya no vamos a poder replicar de nuevo desde VMware a Azure, para volver a proteger la máquina virtual, sobre Información general, damos a Volver a proteger, pero la protección será solo a nivel de Azure:

• Clic sobre Volver a proteger:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir para volver a proteger:

• Como podemos ver, ya la hemos vuelto a proteger:

• Y así nos quedaría, permitiéndonos sólo hacer una Conmutación por error planeada, a través de la cuál vamos a poder replicar desde Azure a nuestro entorno de VMware:

• Le indicamos que realice una Conmutación por error planeada desde Azure a VMware, Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, se ha realizado correctamente:

• Ya tenemos la máquina virtual levantada en nuestro entorno on-premise de VMware:

• Y desconectada en Azure:

• Para dejarlo todo como estaba originalmente, es decir, replicando desde VMware a Azure, deshabilitamos la replicación, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Aquí deshabilitamos la replicación:

• Le indicamos el motivo y Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir al deshabilitar la réplica:

• Aquí vemos que ha finalizado correctamente:

• Si accedemos de nuevo al almacén de recovery services > Elementos protegidos > Elementos replicados vemos que ya no tenemos ninguna máquina virtual replicada:

• Si quisiéramos volver a replicarla, debemos de configurarlo todo de nuevo:

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con VMware vSphere a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor vCenter con dos hipervisores ESXi configurados en un cluster HA-DRS, con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-vw-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de VMware vSphere, en este link de este mismo blog podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, Para máquinas físicas y VMware, que en este caso es la que nos interesa, para System Center VMM y para sitios de Hyper-V, que ya lo vimos en un post anterior:

• Lo primero que vamos a realizar será crearnos un Dispositivo de replicación de ASR:

• Para Agregar nuevo dispositivo de replicación, vamos a elegir la opción 1, dónde nos vamos a Descargar una OVA preparada para desplegarla en nuestro vCenter:

• Como podemos ver, aquí la tenemos descargada:

• Ahora vamos a proceder a implementarla en nuestro vCenter, para ello, sobre una de nuestras carpetas de máquinas virtuales, hacemos un clic derecho e Implementar plantilla de OVF:

• Sobre Seleccione una plantilla de OVF, vamos a seleccionar el OVA de MicrosoftDRAppliance que nos hemos descargado:

• Le indicamos el nombre a la máquina virtual que va a crear:

• Seleccionamos el hipervisor dónde se va a ejecutar la máquina virtual:

• Nos muestra un resumen del despliegue que se va a realizar, ahora cambiaremos algunas cosas, como el disco de 700 GB en modo Thick Provision, que lo pasaremos a Thin Provision, para que no nos ocupe esos 700 GB en nuestra cabina de discos:

• Seleccionamos nuestro datastore en modo Thin Provision:

• Seleccionamos la red virtual dónde vamos a desplegar la máquina:

• Nos muestra un resumen de todo lo configurado y finalizamos:

• Como podemos ver en nuestro vCenter, aquí comienza el despliegue:

• Una vez finalizado el despliegue de la OVA, iniciamos la máquina virtual y accedemos por consola:

• Aceptamos el EULA:

• Introducimos las credenciales del administrador de la máquina:

• Iniciamos sesión:

• Una vez iniciada la sesión, se nos va a abrir el navegador Edge con el acceso directamente a la web del appliance para ASR Replication, como podemos ver es un Windows Server 2019 Standard, sobre la primera parte Set up prerequisites, vemos que todo está correcto, clic en Continue:

• Sobre Appliance components, vemos que todo está actualizado y no hay actualizaciones disponibles, clic en Continue:

• Sobre Select Replication appliance connectivity, salvamos la configuración, y Continue:

• Sobre Register with Recovery Services vault, le indicamos un nombre y copiamos el ASR replication appliance key de nuestro portal de Azure, clic en Login y Continue:

• Copiamos el código e iniciamos sesión en nuestro tenant de Azure:

• Nos indica que todo está correcto y podemos cerrar esta ventana:

• Como podemos ver, comienza a registrar con el almacén de recovery services:

• Aquí vemos que el registro ha sido correcto, clic en Continue:

• El siguiente paso, será añadir nuestro servidor de vCenter y las credenciales para instalar el agente de Site Recovery en las máquinas que queramos replicar:

• Añadimos nuestro servidor vCenter:

• Aquí vemos nuestro vCenter añadido:

• Ahora añadimos las credenciales para instalar el agente de Site Recovery en las máquinas que queramos replicar:

• Aquí vemos las credenciales añadidas, clic en Continue:

• Sobre Provide physical server details, no vamos a configurar nada, ya que no vamos a configurar ni replicar ningún servidor físico, clic en Continue:

• Empieza a registrar todo lo configurado:

• Como podemos ver, ya se ha completado correctamente, ya podemos administrar el appliance de ASR:

• Ahora si accedemos a nuestro portal de Azure, Almacénes de Recovery Services > replicas-vm-vault > Infraestructura de Site recovery:

• Nos vamos a Para máquinas físicas y VMware > Dispositivos de replicación de ASR, y podemos ver que ya tenemos nuestro appliance de ASR añadido:

• Y en Elementos detectados, podemos ver, que ya reconoce a nuestro vCenter de VMware:

• Sobre Directivas de replicación, nos ha creado una por defecto, luego podemos añadir y configurar las que nos interesen:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Para máquinas físicas y VMware > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre y el Periodo de retención en días:

• Aquí vemos la directiva de replicación creada:

• Nos vamos a crear algunas políticas más, modificando el periodo de retención, estas políticas las usaremos posteriormente sobre las réplicas de las máquinas virtuales, según el periodo de retención en días que nos interese darle:

• Una vez definida la infraestructura de Site Recovery para VMware, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de VMware, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas físicas y VMware a Azure:

• Sobre Selección de origen, seleccionamos el Tipo de máquina, el Host de vCenter y las máquinas que queremos replicar:

• Sobre Configuración de origen, seleccionamos el dispositivo de replicación, las credenciales de acceso a la máquina virtual y los discos que se van a replicar:

• Sobre Propiedades de destino, seleccionamos la suscripción, el grupo de recursos, la red y subred dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error, seleccionamos la cuenta de almacenamiento en caché, los discos administrados de destino (en este caso HDD Standard) y la política de replicación:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Aquí podemos ver el progreso de todo el proceso:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra en progreso de hacer la replicación inicial:

• Como podemos ver, todo se ha ejecutado de forma correcta:

• Sobre los elementos replicados, podemos ver, que los discos empiezan a sincronizarse:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de VMware:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con VMware vSphere hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde Hyper-V a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery service > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error y la red virtual, clic sobre Aceptar:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error planeada, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, la conmutación por error planeada, se ha realizado correctamente:

• Una vez terminada la conmutación por error planeada, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

• Ahora vamos a suponer, que nuestra máquina virtual principal en el servidor on-premise de Hyper-V, no nos inicia, por el motivo que sea, vemos que esta apagada:

• Vamos a realizar entonces una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con Hyper-V a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor de Hyper-V con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-hv-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Hyper-V, en este link de este mismo blog, podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog, podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, máquinas físicas, máquinas de VMware (que lo vamos a ver en otro post), para System Center VMM, y la que nos interesa a nosotros en estos momentos que son Para sitios de Hyper-V:

• Lo primero que vamos a realizar será crearnos un Sitio de Hyper-V, donde le indicamos un nombre:

• Como vemos, ya tenemos creado el sitio:

• Lo siguiente será, agregar un host de Hyper-V, para ello nos vamos a Hosts de Hyper-V > Agregar servidor:

• Aquí se nos muestran todos los pasos para agregar el host de Hyper-V:

• Los dos primeros pasos, los cumplimos, procedemos por tanto a descargar el instalador del proveedor de Microsoft Azure Site Recovery (paso 3) y a descargar la clave de registro del almacén para registrar el host en un sitio de Hyper-V (paso 4):

• Una vez descargados, sobre nuestro servidor de Hyper-V vamos a proceder a instalar el proveedor de Microsoft Azure Site Recovery usando la clave de registro del almacén para registrar el servidor en el almacén (paso 5).
• Activamos las actualizaciones de Microsoft update:

• Damos a instalar:

• Comienza el proceso de instalación:

• Aquí vemos que ha finalizado correctamente, ahora procedemos a registrar el servidor en el almacén de recovery services de Azure, clic en Registrarse:

• Sobre Configuración del almacén, añadimos el Archivo de clave:

• Sobre Configuración de proxy, le indicamos que nos vamos a conectar directamente con Azure Site Recovery sin un servidor proxy:

• Comienza con el registro:

• Pasados unos minutos, ya tenemos nuestro servidor de Hyper-V registrado en nuestro almacén de recovery services de Azure, finalizamos:

• Para verificar que todo está correcto, nos vamos a nuestro almacén de recovery services en Azure, a la parte de Infraestructura de Site Recovery > Hosts de Hyper-V, y vemos que nos aparece como un servidor registrado y en estado Conectado:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre, el tipo de origen que será Hyper-V, el tipo de destino que será Azure, la frecuencia de copia, retención de puntos de recuperación en horas, la frecuencia de instantáneas coherentes a nivel de aplicación y la hora de inicio de la replicación inicial:

• Aquí vemos la directiva de replicación creada:

• Una vez creada, la tenemos que asociar al sitio de Hyper-V:

• Como podemos ver, ya está asociada:

• Una vez definida la infraestructura de Site Recovery para Hyper-V, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de HyperV, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas de Hyper-V a Azure:

• Sobre Entorno de origen, seleccionamos el sitio de Hyper-V que nos creamos anteriormente:

• Sobre Entorno de destino, seleccionamos la suscripción, el grupo de recursos, el modelo de implementación, el tipo de almacenamiento y la red dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error:

• Sobre el Tipo de almacenamiento debemos de hacer una aclaración, ya que vamos a usar un disco administrado (esta opción es nueva), esto no era posible usarlo antes, y teníamos que hacerlo con una cuenta de almacenamiento, de ahí que anteriormente nos creásemos esa cuenta, si usamos un discos administrados no hace falta crearnos la cuenta de almacenamiento:

• Sobre Selección de la máquina virtual, seleccionamos las máquinas que nos interesen:

• Sobre Configuración de replicación, seleccionamos el tipo de sistema operativo, el disco del sistema operativo, los discos a replicar, en este caso replicamos los dos discos que tiene la máquina virtual, le indicamos el tipo de disco administrado y la cuenta de almacenamiento en caché:

• En Directiva de replicación, seleccionamos la directiva que nos creamos anteriormente:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver que la réplica inicial está en proceso:

• Sobre el servidor de Hyper-V, y la máquina virtual a replicar > Replicación > Ver mantenimiento de la replicación, podemos ver, que la réplica se está realizando correctamente:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra esperando el primer punto de recuperación:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de Hyper-V:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con Hyper-V hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar Veeam Backup & Replication para realizar backups en Microsoft Azure.

La topología de nuestra infraestructura va a ser la siguiente:

• Para la parte On-premise:
• Dos Hypervisores ESXi configurados en un clúster HA-DRS a través de vCenter:

• Una máquina virtual con Veeam Backup & Replication Enterprise Plus con nuestros trabajos de backups de máquinas virtuales de VMware vSphere configurados:

• Sobre esta máquina, tenemos configurado dos repositorios locales y dos repositorios SMB:

• Para la parte cloud en Azure:
• Una máquina virtual con Veeam Backup & Replication Community Edition, con un disco de datos de 128 GB que utilizaremos como repositorio en la máquina on-premise:

• Tenemos una VPN IPSec Site to Site, configurada entre nuestro entorno On-premise y Microsoft Azure:

• Una vez vista toda la infraestructura desplegada, lo primero que vamos a realizar será irnos a nuestra máquina Veeam on-premise, y accedemos a Backup Infrastructure > Backup repositories > Add Repository:

• Seleccionamos Direct attached storage y Microsoft Windows:

• Sobre Name, le indicamos un nombre y una descripción:

• Sobre Server, añadimos uno nuevo, le indicamos el DNS o la IP y una descripción:

• Le indicamos las credenciales para conectarse a este servidor:

• Sobre Review, nos indica que el Transport ya existe en el servidor que queremos conectar, ya que nuestra máquina de Azure tiene instalado un Veeam Backup & Replication Community Edition:

• Aplicamos:

• Sobre Summary, nos muestra un resumen de todo lo configurado y finalizamos:

• Sobre Server, le hacemos un Populate y como vemos, podemos usar los discos de esta máquina como repositorios de nuestro veeam backup on-premise:

• Sobre Repository, le indicamos la ruta, y haciendo un Populate nos muestra la capacidad del repositorio:

• Sobre Mount Server, lo dejamos todo por defecto:

• Sobre Review, podemos ver, que el repositorio de destino ya tiene todos los componentes instalados, ya que esta máquina se le instaló un Veeam Backup & Replication Community Edition:

• Al aplicar, vemos que todo está correcto:

• Sobre Summary, nos muestra un resumen de todo lo configurado y finalizamos:

• Como podemos ver, aquí tenemos nuestro nuevo repositorio creado, listo para almacenar los backups que configuremos:

• Ahora para verificar que nuestro nuevo repositorio funciona correctamente, vamos a crear un Backup Copy Job de algunas de nuestras tareas, para ello, accedemos a Home > Backup Copy:

• Sobre Job, le indicamos un nombre, una descripción y que la copia sea inmediata, es decir, cuando termine el trabajo principal que se ejecute el Backup Copy:

• Sobre Objects, añadimos el trabajo de backup que queremos replicar:

• Sobre Target, le indicamos el repositorio que nos hemos creado en Azure y los puntos de retención:

• Sobre Data Transfer, le indicamos la opción Direct:

• Sobre Schedule, le indicamos que empiece el trabajo al finalizar el principal:

• Sobre Summary, nos muestra un resumen de todo lo configurado y finalizamos:

• Ahora lanzamos el trabajo principal, y tras éste se va a lanzar el Backup Copy Job:

• Una vez finalizado el trabajo del backup copy job, podemos ver los archivos del backup sobre el repositorio:

• Como nota a todo esto, si las máquinas virtuales de Veeam Backup (on-premise y Azure) no tienen visibilidad completa entre ellas y tampoco queremos que la tengan, debemos de habilitar estos puertos para que la máquina on-premise pueda acceder al repositorio y hacer los backups copy jobs:

• Todos estos servicios los agrupo en un solo grupo para aplicarlo a las reglas de los firewalls:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo configurar una VPN site to site entre dos redes virtuales de Azure.

Las redes virtuales pueden estar en distintas regiones y provenir de distintas suscripciones. Al conectar redes virtuales provenientes de distintas suscripciones, no es necesario que las suscripciones estén asociadas con el mismo inquilino. Este tipo de configuración crea una conexión entre dos puertas de enlace de red virtual.

Configurar una conexión de red virtual a red virtual es una forma sencilla de conectar redes virtuales. Cuando conecta una red virtual a otra mediante el tipo de conexión entre redes virtuales (VNet2VNet) es parecida a la creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de conectividad usan una puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y funcionan de la misma forma en lo relativo a la comunicación. Sin embargo, la manera en que se configura la puerta de enlace de red local es distinta.

Cuando se crea una conexión de red virtual a red virtual, el espacio de direcciones de la puerta de enlace de red local se crea y rellena automáticamente. Si actualiza el espacio de direcciones de una de las redes virtuales, la otra enruta automáticamente al espacio de direcciones actualizado. Por lo general, es más rápido y sencillo crear una conexión de red virtual a red virtual que una conexión de sitio a sitio. Sin embargo, la puerta de enlace de red local no está visible en esta configuración.

Fuente: Microsoft Learn vpns2svnettovnet

Esta será la topología utilizada en esta configuración:

• Antes de empezar, vamos a explicar la configuración que va a tener nuestra infraestructura.
• Para VNet1:

• Configuración de la red virtual.
• Name: vnet1
• Espacio de direcciones:10.1.0.0/16
• Suscripción: Seleccionamos nuestra suscripción
• Grupo de recursos: vpnvnet1-rg
• Ubicación: Oeste de Europa
• Subred
• Name: lan1vnet1
• Intervalo de direcciones:10.1.1.0/24

• Configuración de puerta de enlace de red virtual.
• Name: vnet1gw
• Grupo de recursos: Oeste de Europa
• Generación: Generación 2
• Tipo de puerta de enlace: VPN
• Tipo de VPN: Basada en rutas
• SKU: VpnGw2
• Generación: generación 2
• Red virtual: vnet1
• Intervalo de direcciones de subred de puerta de enlace:10.1.255.0/27
• Dirección IP pública: Crear nuevo
• Nombre de dirección IP pública: vnet1gwpip
• Habilitar el modo activo/activo: deshabilitado
• Configurar BGP: deshabilitado

• Conexiones.
• Tipo de conexión: Seleccionamos de red virtual a red virtual
• Establecer conectividad bidireccional: Seleccionar este valor
• Nombre de la primera conexión: vnet1-to-vnet2
• Nombre de la segunda conexión: vnet2-to-vnet1
• Región: Oeste de Europa
• Configuración:
• Primera puerta de enlace de red virtual: Seleccionamos vnet1gw
• Segunda puerta de enlace de red virtual: Seleccionamos vnet2gw
• Clave compartida (PSK): En este campo, escribimos una clave compartida para la conexión, dicha clave podemos generarla o crearla manualmente, en una conexión de sitio a sitio, la clave que usa es la misma del dispositivo local y de la conexión de puerta de enlace de red virtual, aquí el concepto es similar, salvo en que en lugar de conectarse a un dispositivo VPN, la conexión se establece con otra puerta de enlace de red virtual.
• Protocolo IKE: IKEv2

• Para VNet2:

• Configuración de la red virtual.
• Name: vnet2
• Espacio de direcciones:10.2.0.0/16
• Suscripción: Seleccionamos nuestra suscripción
• Grupo de recursos: vpnvnet2-rg
• Ubicación: Oeste de Europa
• Subred
• Name: lan1vnet2
• Intervalo de direcciones:10.2.1.0/24

• Configuración de puerta de enlace de red virtual.
• Name: vnet2gw
• Grupo de recursos: Oeste de Europa
• Generación: Generación 2
• Tipo de puerta de enlace: VPN
• Tipo de VPN: Basada en rutas
• SKU: VpnGw2
• Generación: generación 2
• Red virtual: vnet2
• Intervalo de direcciones de subred de puerta de enlace:10.2.255.0/27
• Dirección IP pública: Crear nuevo
• Nombre de dirección IP pública: vnet2gwpip
• Habilitar el modo activo/activo: deshabilitado
• Configurar BGP: deshabilitado

• Conexiones.
• Tipo de conexión: Seleccionamos de red virtual a red virtual
• Establecer conectividad bidireccional: Seleccionar este valor
• Nombre de la primera conexión: vnet1-to-vnet2
• Nombre de la segunda conexión: vnet2-to-vnet1
• Región: Oeste de Europa
• Configuración:
• Primera puerta de enlace de red virtual: Seleccionamos vnet1gw
• Segunda puerta de enlace de red virtual: Seleccionamos vnet2gw
• Clave compartida (PSK): En este campo, escribimos una clave compartida para la conexión, dicha clave podemos generarla o crearla manualmente, en una conexión de sitio a sitio, la clave que usa es la misma del dispositivo local y de la conexión de puerta de enlace de red virtual, aquí el concepto es similar, salvo en que en lugar de conectarse a un dispositivo VPN, la conexión se establece con otra puerta de enlace de red virtual.
• Protocolo IKE: IKEv2

• Empezaremos creando la red virtual vnet1, para ello, accedemos a Redes virtuales > Crear:

• Sobre Datos básicos, le indicamos, el grupo de recursos, el nombre y la región:

• Sobre Seguridad, no vamos a configurar nada, lo dejamos por defecto:

• Sobre Direcciones IP, configuramos el espacio de direcciones, y nos creamos las subredes para lan, dónde irán ubicadas las máquinas virtuales, y para la puerta de enlace de red virtual:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, si todo está bien, damos a Crear:

• Vemos que comienza a crearse:

• Aquí vemos que ya se ha completado, accedemos al nuevo recurso de vnet creado:

• Para la red virtual vnet2, seguimos los mismos pasos, cambiando el espacio de direcciones y el rango de las subredes:

• Una vez creadas las redes virtuales, vamos a crear la puerta de enlace de red virtual para la vnet1, para ello, accedemos a Puerta de enlace de red virtual > Crear:

• Sobre Datos básicos, vamos a introducir los valores descritos anteriormente:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado y que la validación ha sido superada, si todo está bien, damos a Crear:

• Una puerta de enlace puede tardar hasta 45 minutos en crearse e implementarse completamente, aquí podemos ver que la implementación se ha completado correctamente:

• Si nos vamos a Puertas de enlace de red virtual, podemos ver que ya la tenemos creada:

• La puerta de enlace de red virtual para la vnet2, se crea exactamente igual que para la vnet1, dónde también, vamos a introducir los valores descritos anteriormente:

• Si nos vamos a Puertas de enlace de red virtual, podemos ver que ya la tenemos creada:

• Una vez que ya tenemos, las dos puertas de enlace de red virtual creadas y configuradas, vamos a crear y configurar las conexiones entre estas dos puertas de enlace de red virtual, para ello, accedemos a Conexiones > Crear:

• Sobre Datos básicos, vamos a introducir los valores descritos anteriormente:

• Sobre Opciones, configuramos los parámetros descritos anteriormente:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado y que la validación ha sido superada, si todo está bien, damos a Crear:

• Como podemos ver, las conexiones se han creado correctamente:

• Si accedemos a Conexiones, podemos ver, que ya las tenemos creadas y conectadas:

• Ahora, para verificar que la VPN Site to Site entre VNets funciona correctamente, tenemos estas dos máquinas, una llamada litio en vnet1 y otra llamada sodio en vnet2, como podemos ver, ya tenemos comunicación entre ellas, a través de la VPN que hemos creado:

• Ahora vemos, que ya se está generando tráfico entre las dos conexiones:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar el tránsito de la puerta de enlace de VPN para el emparejamiento de red virtual, el emparejamiento de red virtual conecta perfectamente dos redes virtuales de Azure, combinando las dos redes virtuales en una sola, para favorecer la conectividad. El tránsito de puerta de enlace es una propiedad del emparejamiento que permite que una red virtual utilice la puerta de enlace de VPN en la red virtual emparejada para la conectividad entre redes locales o entre redes virtuales.

Esta será la topología utilizada en esta configuración:

• Antes de empezar, vamos a explicar cómo está configurada nuestra infraestructura.
• Para la parte On-premise, tenemos un firewall Fortigate, en el cuál, hay configurado una red dónde van ubicadas las máquinas de esta parte de la infraestructura y hay configurado un extremo de la VPN site to site entre la parte ON-premise y Azure, al final de estas explicaciones, os pondré un enlace a este mismo blog dónde se muestra como se configura esta VPN site to site.

• Esta es la VLAN que vamos a utilizar para la parte ON-premise:

• Aquí vemos la VPN site to site entre la parte On-premise y Azure levantada:

• Estas son las rutas estáticas hacia las redes virtuales de Azure:

• Para la parte Cloud en Azure, tenemos tres redes virtuales, una central, llamada hub-vnet, dónde se ubica la subred de puerta de enlace y dónde hemos configurado la puerta de enlace de red virtual que se encarga de la comunicación de la VPN site to site entre la parte On-premise y Azure, sobre esta vnet vamos a configurar el emparejamiento entre las vnets spoke1-vnet y spoke2-vnet y el tránsito de puerta de enlace que va a permitir comunicar estas dos vnets entre sí y va a permitir la comunicación también con la parte On-premise.
• Red virtual hub-vnet:

• Red virtual spoke1-vnet:

• Red virtual spoke2-vnet:

• Puerta de enlace de red virtual:

• Puerta de enlace de red local:

• Conexión:

• En este link os dejo como configurar una VPN site to site entre la parte On-premise y Azure.
• Una vez explicada toda la infraestructura, vamos a ver como configurar el emparejamiento entre redes virtuales y el tránsito de la puerta de enlace de VPN.
• Vamos a configurar el emparejamiento y el tránsito entre las redes virtuales hub-vnet y spoke1-vnet, para ello, accedemos a, red virtual hub-vnet > Emparejamientos > Agregar:

• Red virtual hub-vnet:
• Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo, HubToSpoke1
• Tráfico hacia la red virtual remota: Permitir
• Tráfico reenviado desde la red virtual remota: Permitir
• Puerta de enlace de red virtual: Usar la puerta de enlace de esta red virtual o el servidor de rutas
• Red virtual spoke1-vnet:
• Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo, Spoke1ToHub
• Tráfico hacia la red virtual remota: Permitir
• Tráfico reenviado desde la red virtual remota: Permitir
• Puerta de enlace de red virtual: Usar la puerta de enlace de red virtual remota o el servidor de rutas

• Como podemos ver, aquí tenemos los emparejamientos y el tránsito de puerta de enlace habilitado:

• El emparejamiento y el tránsito entre las redes virtuales hub-vnet y spoke2-vnet, se configura exactamente igual que el anterior:

• Para verificar que las máquinas virtuales de las redes virtuales spoke1-vnet y spoke2-vnet, se comunican con las máquinas virtuales del entorno on-premise, vamos a lanzar varios pings entre ellas.
• Máquina en red virtual spoke1-vnet:

• Máquina en red virtual spoke2-vnet:

• Máquina en red on-premise:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar VM Insights en las máquinas virtuales de Azure, al configurar VM Insights vamos a tener una monitorización y supervisión mucho más detallada de nuestras máquinas virtuales.

• Lo primero que vamos a realizar es crearnos las áreas de trabajo para log analytics, vamos a crear dos, una para máquinas Windows y otra para máquinas Linux:

• Sobre Datos básicos, le indicamos el grupo de recursos dónde irá ubicada, el nombre y la región:

• Sobre Etiquetas, podemos configurar las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado:

• Como podemos ver, se ha implementado correctamente:

• Aquí vemos las dos áreas de trabajo de log analytics implementadas, una para máquinas Windows y otra para máquinas Linux:

• Una vez creadas las áreas de trabajo de log analytics, vamos a habilitar VM Insigths sobre las máquinas virtuales, primero lo haremos sobre la máquina Windows, accedemos a la máquina y vamos a Supervisión > Información > Habilitar:

• Sobre Configuración de supervisión > Regla de recopilación de datos damos a Crear nuevo:

• Sobre Crear regla, le indicamos un nombre, y le indicamos el área de trabajo de log analytics que configuramos anteriormente para las máquinas Windows:

• Así nos quedaría, damos a Configurar:

• Una vez configurado, si accedemos a la Máquina > Supervisión > Información > Rendimiento, podemos ver una monitorización de la máquina mucho más completa, CPU, Memoria, IOPS discos, Bytes recibidos y enviados:

• Si sobre la máquina virtual, accedemos a Extensiones + aplicaciones podemos ver que ha instalado el agente Windows para Azure Monitor:

• Para la máquina Linux, hacemos exactamente lo mismo, eligiendo el área de trabajo de log analytics la configurada para las máquinas Linux, por lo tanto, nos quedaría así:

• Si sobre la máquina virtual, accedemos a Extensiones + aplicaciones podemos ver que ha instalado el agente Linux para Azure Monitor:

• Si accedemos al grupo de recursos que nos creamos para las áreas de trabajo de log analytics, podemos ver, las dos reglas que hemos creado:

• Si accedemos a Monitor > Información > Máquinas virtuales > Información general > Supervisado y a los grupos de recursos que nos creamos para las áreas de trabajo de log analytics, podemos ver, las dos reglas que hemos creado:

Saludos y espero que os resulte de ayuda