En este post vamos a ver el funcionamiento y las configuraciones de Microsoft Entra Domain Services, que una vez instaladas las RSAT, es básicamente igual que un Active Directory clásico que hemos configurado y administrador a lo largo de los años, sólo hay que tener en cuenta algunas particularidades.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Si accedemos a la consola de Usuarios y equipos de Active Directory, está será la organización que nos vamos a encontrar por defecto, luego podemos crear nuevas Unidades Organizativas (OU) y organizar el AD según nos convenga en nuestra infraestructura:

• Vamos a explicar las más importantes y las particularidades de cada una, para empezar, tenemos la Unidad Organizativa (OU), AADDC Computers, en esta OU se van a ir añadiendo todas las máquinas que unamos a nuestro dominio, luego crearemos otras OUs y podemos mover estas máquinas a las nuevas OUs para tener más organizado nuestro Active Directory:

• La OU AADDC Users, va a contener todos los usuarios y grupos que se sincronizan desde Microsoft Entra ID, aquí no debemos mover los usuarios ni grupos de OU, ni editarlos, ni cambiar passwords…, nada, no los debemos tocar, si queremos editarlos lo debemos hacer desde Microsoft Entra ID, y los cambios se sincronizaran con Microsoft Entra Domain Services, lo que si podemos hacer es crear usuarios y grupos locales propios del dominio de AD en otras OU, y usar estos usuarios por ejemplo para algún tema de servicios:

• La OU AADDSDomainAdmin, es un contenedor protegido y reservado para las operaciones del servicio gestionado, microsoft delega ciertos privilegios allí para que la infraestructura funcione de forma transparente sin otorgarnos los permisos de «Enterprise Admin» o «Domain Admin» tradicionales del Active Directory clásico, NO debemos tocar absolutamente nada de lo que vemos en esta OU, ni cambiarle la contraseña al usuario dcaasadmin, ni modificar el grupo AADDS Service Administrators Group, el usuario dcaasadmin, Microsoft lo utiliza de forma automatizada para realizar tareas de mantenimiento, aplicar parches de seguridad del sistema operativo a los controladores de dominio, monitorizar la salud del directorio y asegurar la replicación subyacente, si le cambiamos la contraseña o intentamos deshabilitarlo, bloquearemos los scripts de automatización de Azure y el servicio pasará automáticamente a estado «Alert» o «Unhealthy» en nuestro portal y podríamos llegar a romper la infraestructura desplegada:

• En la OU Domain Controllers, al igual que en un Active Directory clásico se van a ubicar nuestros controladores de dominio, en este caso los dos DC PaaS que se han desplegado con el servicio de Microsoft Entra Domain Services:

• Estas son las OUs nuevas que nos hemos creado:

• Hemos movido esta máquina a una de las OU nuevas que nos hemos creado:

• Al igual que el Active Directory clásico, esta es la consola de Administración de directivas de grupo y estas son las GPO que trae por defecto, AADDC Computers GPO, AADC Users GPO, Default Domain Controllers Policy y Default Domain Policy, NO EDITAR NI TOCAR bajo ningún concepto, si queremos aplicar alguna GPO, creamos una nueva y la vinculamos sobre la OU que nos interese, también podemos trabajarlas aplicando filtros de seguridad a grupos y usuarios, como hicimos en este post, como podemos ver la replicación entre los controladores de dominio es correcta:

• La GPO AADDC Computers GPO vinculada sobre la OU AADDC Computers tiene esta configuración para que los miembros el grupo AAD DC Administrators sean administradores locales de las máquinas de nuestro dominio, esta GPO tiene problemas con los equipos que están en idioma español o cualquier idioma diferente al Inglés, ya que el grupo administrators no existe, en español el grupo es administradores, por lo que la GPO se aplica pero los usuarios de grupo AAD DC Administrators una vez hagan logon en las máquinas no van a ser administradores locales:

• Para solucionarlo, hemos creado esta GPO:
• Abrimos la consola de Administración de Directivas de Grupo, clic derecho sobre Objetos de directiva de grupo y seleccionamos Nuevo, le damos el nombre LocalAdmin, clic derecho sobre la nueva GPO y damos a Editar, no dirigimos a la siguiente ruta:
• Configuración del equipo > Preferencias > Configuración de Panel de control -> Usuarios y grupos locales, clic derecho en el espacio en blanco > Nuevo > Grupo local.
• Configuración clave dentro del grupo:
• Acción: Actualizar
• Nombre de grupo: Aquí está el secreto, no lo escribas a mano, hacemos clic en el desplegable de la derecha y buscamos el grupo integrado Administradores (integrados).
• Nota técnica, al seleccionarlo desde el desplegable, la GPO no guarda el texto «Administradores», sino que guarda el SID universal S-1-5-32-544, de esta forma, si el equipo está en español, francés o inglés, la GPO afectará al grupo correcto de administración local.
• Miembros, clic en Agregar y buscamos el grupo del dominio: RAGASYS\AAD DC Administrators.

• También podemos vincular esta GPO a las OUs personalizadas que hemos creado:

• Para hacer una prueba, hemos creado esta GPO, con este filtrado de seguridad y la hemos vinculado sobre la OU AADDC Users:

• Si volvemos a iniciar sesión con un usuario perteneciente a este grupo, se nos abre la calculadora:

• Nuestro DNS podemos administrarlo como lo hemos hecho siempre en Active Directory clásico:

• Hemos creado estor registros CNAME para nuestros Controladores de dominio:

• Ya podemos acceder a la consola DNS por nombre en lugar de por IP:

• Nos podemos crear zonas de búsqueda inversa al igual que hacemos en Active Directory clásico, y como vemos se han replicado correctamente del dc01 al dc02:

• En el DNS no se debe de tocar nada más, ni reenviadores ni ningún tema de configuración.
• En la consola de Sitios y servicios de Active Directory no debemos de tocar nada, ya que como es un servicio PaaS podemos averiar la replicación entre los controladores de dominio, comentan que se pueden crear subredes, pero según he estado viendo y trabajando prefiero dejarlo tal cuál viene, NO TOCAR:

Saludos y espero que os sea de ayuda

La entrada Funcionamiento y Configuraciones de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como instalar las herramientas de administración remota RSAT en una máquina virtual unida a nuestro dominio, y así poder administrar el dominio de Microsoft Entra Domain Services al igual que hemos hecho siempre con nuestros controladores de dominio on-premise.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Esta es la configuración de red de la máquina dónde vamos a instalar las herramientas de administración remota RSAT, como podemos ver los DNS son las IPs de los controladores de dominio PaaS que se desplegamos con el servicio de Microsoft Entra Domain Services:

• Verificamos las comunicaciones con nuestros dos controladores de dominio PaaS:

• Unimos la máquina al dominio con el usuario al que elegimos como administrador del dominio:

• Una vez unido al dominio, reiniciamos y podemos iniciar sesión con este usuario en la máquina:

• Ejecutamos este comando para instalar las herramientas de administración remota RSAT que vamos a necesitar para administrar nuestro domino de Microsoft Entra Domain Services, Install-WindowsFeature -Name RSAT-AD-Tools, RSAT-DNS-Server, GPMC -IncludeAllSubFeature
• Ejecutando este comando tendremos las Consolas que tiene un Controlador de Dominio:
• Usuarios y equipos de Active Directory (ADUC)
• Administración de Directivas de Grupo (GPMC)
• Administrador de DNS
• Centro de Administración de Active Directory (ADAC)
• Sitios y servicios de Active Directory
• Dominios y confianzas de Active Directory
• Editor ADSI (ADSI Edit)

• Si nos abrimos el Administrador del Servidor > Herramientas, podemos ver todas las consolas que hemos instalado:

Saludos y espero que os resulte de ayuda

La entrada Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo desplegar y configurar Microsoft Entra Domain Services (MEDS), veremos el despliegue de este servicio y las configuraciones iniciales para empezar a funcionar.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a realizar será crearnos nuestro dominio administrado, para ello, desde Azure portal accedemos a Microsoft Entra Domain Services > + Crear:

• Sobre Datos básicos le indicamos la Suscripción, el Grupo de recursos, le indicamos el Nombre de dominio DNS, la Región y el SKU, en SKU seleccionaremos Estándar, para implementaciones en producción seleccionar Enterprise o Prémium, clic en Siguiente:

• Sobre Redes seleccionamos la Red virtual que tenemos desplegada en nuestra infraestructura con la subred que configuramos para este servicio, en este caso 192.168.130.0/24, clic en Siguiente:

• Sobre Administración seleccionamos Administrar pertenencia al grupo e incluiremos los miembros que van a ser los Administradores de Microsoft Entra Domain Services, los usuarios que sean miembros de este grupo serán los administradores de nuestro dominio, estos usuarios que se incluyan aquí no van a ser administradores de dominio como en un Active Directory clásico, en este servicio administrado Microsoft no nos proporciona un administrador del dominio total, nos ofrece este grupo y el servicio PaaS de Microsoft Entra Domain Services una vez desplegado, le asigna automáticamente los permisos necesarios a este grupo sobre el dominio, vamos lo que hace básicamente es delegar los permisos necesarios en el Active Directory para poder trabajar y configurar lo que necesitemos en nuestra infraestructura, clic en Siguiente:

• Sobre Sincronización seleccionamos el Tipo de sincronización, en este caso Todo, clic en Siguiente:

• Sobre Configuración de seguridad lo dejamos todo por defecto, clic en Siguiente:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, clic en Siguiente:

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

• Aceptamos:

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

• Si accedemos al grupo de recursos que nos creamos anteriormente, podemos ver todos los recursos que se han creado:

• Si accedemos al recurso Microsoft Entra Domain Services (ragasys.net), sobre información general, podemos ver, que el estado del dominio está En ejecución:

• Como podemos ver se muestra una advertencia que debemos corregir, pulsamos sobre la flecha:

• Ejecutamos el diagnóstico:

• El diagnóstico nos indica que debemos de establecer la configuración del servidor DNS de direcciones IP de servicio de dominios administrados 192.168.130.4,192.168.130.5 para las redes virtuales West Europe/opnsense-vnet/SubnetMEDS-192_168_130_0-24, estas dos direcciones IP son los dos controladores de dominio de nuestra infraestructura PaaS, clic a Corregir:

• De nuevo nos indica los problemas detectados (Registros de DNS) y como solucionarlo, clic sobre Corregir:

• Como vemos, los diagnósticos se han completado correctamente:

• Si accedemos a Redes Virtuales > opnsense-vnet > Servidores DNS, podemos ver que se han agregado los dos controladores de dominio como servidores DNS de nuestra red virtual:

• Si accedemos a Redes Virtuales > opnsense-vnet > Dispositivos conectados, podemos ver los Dispositivos conectados a nuestra vnet, en este caso está conectado nuestro firewall opnsense y los dos controladores de dominio PaaS que hemos desplegado:

• Ahora en el grupo de seguridad de red que se nos ha creado tras el despliegue (aadds-nsg), vemos las reglas que incluye por defecto, tanto las de entrada como las de salida:

• Para que todas las comunicaciones pasen por nuestro firewall OPNsense desplegado en Azure, debemos de crear estas dos reglas en el grupo de seguridad de red, una de entrada y otra de salida:

• Para terminar y que nuestros usuarios de Microsoft Entra ID puedan iniciar sesión en el dominio de Microsoft Entra Domain Services, deben de hacer un cambio de contraseña para habilitar el hash de contraseña en Microsoft Entra Domain Services:

• Nosotros hemos realizado el cambio de contraseña al usuario que incluimos en el grupo AAD DC Administrators:

• En el próximo post instalaremos las RSAT en una máquina unida a este dominio y veremos que los accesos a estos controladores de dominio es exactamente igual que los que nos montamos en una infraestructura on-premise.

Saludos y espero que os sea de ayuda

La entrada Despliegue y configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver cómo preparar los recursos de nuestra infraestructura, para el despliegue, la instalación y configuración de Microsoft Entra Domain Services (MEDS), veremos la red virtual a crear con la subred, las tablas de rutas que tenemos que configurar, creación de reglas en Fortigate on-premise y OPNsense Azure y grupo de administración de Microsoft Entra Domain Services para administrar nuestro dominio.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vamos a ver la red virtual que tenemos creada en Azure y la subred que vamos a utilizar para desplegar este servicio PaaS de Microsoft Entra Domain Services.
• Esta es la red virtual que vamos a utilizar con su espacio de direcciones configurado:

• Esta es la subred que vamos a utilizar para este servicio:

• Ahora, nos creamos esta tabla de rutas, llamada rt_meds_fw para enseñarle a los futuros controladores de dominio cómo responder a los servidores que tengamos en Azure y a los que tengamos en nuestra infraestructura on-premise, a través del firewall OPNsense que tenemos montado en Azure, importante no incluir NUNCA en esta tabla de ruta el rango de la subred donde van a estar los controladores de dominio de Microsoft Entra Domain Services 192.168.130.0/24:

• Modificamos la tabla de rutas MasterRoutes_rgs que ya la teníamos creada, para obligar a los servidores que tenemos en Azure a pasar por el firewall cuando busquen el Active Directory:

• Una vez creadas las tablas de rutas, tenemos que configurar las reglas o políticas en nuestros firewalls, tal y como vemos en topología de nuestra infraestructura, podemos ver que tenemos dos firewalls, un Fortigate para a parte on-premise y un OPNsense para la parte de Azure, entre ellos, tenemos configurada una VPN site to site, para el acceso entre los recursos de ambos entornos.
• Primero vamos a mostrar la regla que tenemos creada en nuestro firewall on-premise Fortigate, con esta regla, le estamos diciendo que todos nuestros equipos ubicados en la red 192.168.14.0/24 puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Ahora vamos a mostrar las reglas que tenemos creadas en nuestro firewall de Azure OPNsense, con estas reglas, le estamos diciendo que todos nuestros equipos ubicados en las redes 192.168.128.0/24 de Azure y 192.168.14.0/24 om-premise, puedan acceder a los servicios de Microsoft Entra Domain Services, ubicados en los dos controladores de dominio que se desplegaran una vez que tengamos el servicio desplegado en Azure, en el grupo domaincontrollers_meds hemos ubicado los dos controladores de dominio, que tendrán las primeras IPs disponibles que tenga Azure para esa subred, normalmente las terminadas en .4 y .5 si usamos una máscara /24:

• Habilitamos también el ICMP para la pruebas de conexión:

• Por último, vamos a ver el grupo en Microsoft Entra ID al que tenemos que agregar los miembros que queramos que administren el dominio de Microsoft Entra Domain Services, el grupo está creado por defecto en Microsoft Entra ID, y se llama AAD DC Administrators:

Saludos y espero que os resulte de ayuda

La entrada Preparación de recursos para infraestructura de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar, instalar y configurar Microsoft Entra Domain Services (MEDS), Microsoft Entra Domain Services (anteriormente Azure Active Directory Domain Services), que forma parte de Microsoft Entra, nos va a permitir usar servicios de dominio administrados, como la unión a un dominio de Windows, directiva de grupo, LDAP y la autenticación Kerberos, sin tener que implementar, administrar o aplicar revisiones a controladores de dominio.

Con Microsoft Entra Domain Services, vamos a tener exactamente lo mismo que tendríamos con controladores de dominios on-premise de manera tradicional con el servicio o función de Active Directory Domain Services, como el directorio LDAP, DNS, GPOs, Sitios y servicios, etc…, con algunas particularidades que iremos viendo a lo largo de estos posts.

Con Microsoft Entra Domain Services tendremos:

• PaaS alojado en la nube de Azure
• Autenticación LDAP, Kerberos y NTLM
• Usuarios, Grupos, Unidades Organizativas
• GPOs
• Integración con Microsoft Entra ID
• Sin cuenta de administrador de dominio

Los servicios de dominio de Microsoft Entra Domain Services proporcionan servicios de dominio administrados como unión de dominio, directiva de grupo, LDAP, autenticación Kerberos / NTLM que es totalmente compatible con Windows Server Active Directory. Nosotros consumiremos estos servicios de dominio, sin implementar, administrar ni aplicar parches a los controladores de dominio. Microsoft Entra Domain Services se integra con el inquilino de Azure AD existente. Esta integración permite a los usuarios iniciar sesión con sus credenciales corporativas, y podremos usar grupos y cuentas de usuario existentes para proteger el acceso a los recursos.

Para entendernos, podemos decir, que esta es la parte de PaaS (Plataforma como Servicio) de nuestros controladores de dominio en Windows Server.

Para implementar Microsoft Entra Domain Services necesitamos:

• Una suscripción de Azure activa.
• Un inquilino de Microsoft Entra ID asociado con su suscripción, ya sea sincronizado con un directorio local o un directorio solo en la nube.
• Privilegios de administrador global en el inquilino de Microsoft Entra ID para habilitar Microsoft Entra Domain Services.
• Privilegios de colaborador en la suscripción de Azure para crear los recursos necesarios de Microsoft Entra Domain Services.
• Una red virtual con servidores DNS que pueden consultar la infraestructura necesaria, como el almacenamiento. Los servidores DNS que no pueden realizar consultas generales de Internet pueden impedir la capacidad de crear un dominio administrado.

El esquema de la topología de la infraestructura que vamos a utilizar será el siguiente:

Este post lo vamos a dividir en:

• Preparación de recursos para infraestructura de Microsoft Entra Domain Services
• Despliegue y configuración de Microsoft Entra Domain Services
• Instalación herramientas de administración remota RSAT en máquina virtual para Microsoft Entra Domain Services
• Funcionamiento y configuraciones de Microsoft Entra Domain Services

Saludos y espero que os sea de ayuda

La entrada Despliegue, Instalación y Configuración de Microsoft Entra Domain Services se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como añadir certificados SSL de Let’s Encrypt en Nginx Proxy Manager configurados por DNS Challenge y como DNS Provider utilizaremos Azure, que es dónde tenemos alojada nuestra zona DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Azure para Let’s Encrypt, para ello, accedemos a Zonas DNS > ragasys.eu > Administración de DNS > Registros > Agregar:

• Ahora en nuestra nuestra zona DNS de Azure y debemos de tener en cuenta estos datos:
• Nombre exacto de la zona
• Grupo de recursos donde se encuentra
• Id. de suscripción

• Creamos una aplicación, para ello, accedemos a Microsoft Entra ID > Registro de aplicaciones > Nuevo registro:

• Le indicamos el Nombre y Solo cuentas de este directorio organizativo (Inquilino único), Registrar:

• Aquí tenemos la aplicación creada:

• Ahora vamos a crear el secreto de cliente, para ello, en esta nueva aplicación, accedemos a Administrar > Certificados y secretos > Secretos de los clientes > Nuevo secreto de cliente:

• Le indicamos una descripción y el tiempo de expiración, Agregar:

• Aquí tenemos el secreto de cliente, lo copiamos y guardamos en un lugar seguro, ya que sólo nos lo mostrará una sola vez:

• Sobre la Información general de la aplicación, anotamos los siguientes valores, que serán los que utilice Nginx Proxy Manager para el DNS Challenge:

• Ahora damos permisos a la aplicación sobre la Zona DNS, con esto, nuestra aplicación ya tiene permiso para crear/eliminar registros TXT dentro de la zona ragasys.eu, el rol que debemos asignar es el de Colaborador de zona DNS:

• Como la zona ragasys.eu también la tenemos en nuestro DNS interno, nos creamos el registro CNAME _acme-challenge apuntando a _acme-challenge.ragasys.eu, para que resuelva externamente hacia Azure:

• Con esto, ya tenemos preparado la parte de la zona DNS de Azure, ahora accedemos al portal de Nginx Proxy Manager > SSL Certificates > Add SSL Certificate > Let’s Encrypt y vamos a añadir las configuraciones para obtener el certificado wildcard para para nuestro dominio:

• Añadimos Let’s Encrypt:
• Domain Names, añadimos ragasys.eu y *.ragasys.neu, nos aseguramos de incluir el dominio raíz y el wildcard, Let’s Encrypt requiere que se valide también la raíz cuando pedimos el wildcard.
• Email Address for Let’s Encrypt
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Azure.
• Rellenaremos los valores para estos campos, Tenant ID, Client ID, Client Secret, Subscription ID, Resource Group, Zone Name.
• Propagation Seconds, ponemos un valor entre 300 y 600.
• Marcamos I Agree to Let’s Encrypt Terms of Service y pulsamos Save, Nginx Proxy Manager iniciará el proceso ACME, creará el TXT _acme-challenge en la zona DNS de Azure, esperará la propagación y Let’s Encrypt validará.
• Este es el contenido del Credentials File Content:
• dns_azure_sp_client_id =
• dns_azure_sp_client_secret =
• dns_azure_tenant_id =
• dns_azure_zone1 = ragasys.eu:/subscriptions/eliddemisuscripcion/resourceGroups/zonasdnspublicas-rg/providers/Microsoft.Network/dnsZones/ragasys.eu

• Este es el registro TXT _acme-challenge que se genera, Let’s Encrypt valida que el TXT coincida con el valor que generó para esa verificación, después de emitir el certificado, Nginx Proxy Manager debería borrar automáticamente el TXT de la zona si todo funciona bien:

• Aquí podemos ver, los certificados SSL de Let’s Encrypt con Azure como DNS Provider, listos para usar en nuestros Hosts:

Saludos y espero que os sea de ayuda

La entrada Certificados SSL Let’s Encrypt en Nginx Proxy Manager y Azure como DNS Provider se publicó primero en RAGASYS SISTEMAS.

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

La entrada Registrar Windows Admin Center en Azure se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo agregar un certificado SSL de Let’s Encrypt en un nodo Proxmox VE 9.0, los haremos a través de DNS Challenge y cómo DNS Provider usaremos Azure que es donde tenemos nuestra zona DNS llamada ragasys.eu

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Azure para Let’s Encrypt, para ello, accedemos a Zonas DNS > ragasys.eu > Administración de DNS > Registros > Agregar:

• Ahora en nuestra nuestra zona DNS de Azure y debemos de tener en cuenta estos datos:
• Nombre exacto de la zona
• Grupo de recursos donde se encuentra
• Id. de suscripción

• Creamos una aplicación, para ello, accedemos a Microsoft Entra ID > Registro de aplicaciones > Nuevo registro:

• Le indicamos el Nombre y Solo cuentas de este directorio organizativo (Inquilino único), Registrar:

• Aquí tenemos la aplicación creada:

• Ahora vamos a crear el secreto de cliente, para ello, en esta nueva aplicación, accedemos a Administrar > Certificados y secretos > Secretos de los clientes > Nuevo secreto de cliente, lo copiamos y guardamos en un lugar seguro, ya que sólo nos lo mostrará una sola vez:

• Aquí tenemos los datos que necesitamos más el client secret:

• Ahora damos permisos a la aplicación sobre la Zona DNS, con esto, nuestra aplicación ya tiene permiso para crear/eliminar registros TXT dentro de la zona ragasys.eu, el rol que debemos asignar es el de Colaborador de zona DNS:

• Como la zona ragasys.eu también la tenemos en nuestro DNS interno, nos creamos el registro CNAME _acme-challenge apuntando a _acme-challenge.ragasys.eu, para que resuelva externamente hacia Azure:

• Con esto, ya tenemos preparado la parte de la zona DNS de Azure.
• Ahora en nuestro nodo de Proxmox, lo primero que vamos a realizar será crearnos una cuenta en Let’s Encrypt, para ello, sobre nuestro nodo proxmox accedemos a Centro de datos > ACME > Cuentas > Agregar:

• Le indicamos el nombre de la cuenta, un correo válido, y el directorio ACME, Registrar:

• Ya tenemos la cuenta de Let’s Encrypt generada:

• Ahora en Centro de datos > ACME > Plugins de desafío > Agregar, vamos a agregar el plugin para Azure:

• Le indicamos un ID de plugin, el retardo de validación, el API DNS
• AZUREDNS_SUBSCRIPTIONID=
• AZUREDNS_TENANTID=
• AZUREDNS_APPID=
• AZUREDNS_CLIENTSECRET=
• Agregar:

• Y aquí vemos que ya tenemos el plugin añadido:

• Los datos del plugin los obtenemos de nuestro portal de Azure.
• Ahora vamos a agregar el certificado de Let’s Encrypt al nodo proxmox, para ello accedemos a proxmoxlab11 > Certificados > ACME y usamos la cuenta de Let’s Encrypt que nos hemos creado anteriormente, Aplicar:

• Damos a Agregar para añadir el dominio:

• Introducimos el Tipo de desafío DNS, el plugin que añadimos anteriormente y el nombre de dominio de nuestro nodo Proxmox, Crear:

• Y aquí vemos que ya tenemos la configuración realizada:

• Damos a Solicitar certificados ahora y vemos cómo se han validado:

• Aquí tenemos el certificado SSL de Let’s Encrypt para nuestro nodo Proxmox:

• Accedemos a través del navegador a nuestro nodo Proxmox y vemos como reconoce el certificado SSL de Let’s Encrypt:

Saludos y espero que os sea de ayuda

La entrada Agregar certificado SSL de Let’s Encrypt en Proxmox VE 9.0 DNS Provider Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Despliegue y configuración de Firewalls OPNSense clúster HA en Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Actualizar Microsoft Entra Connect a 2.5.3.0 se publicó primero en RAGASYS SISTEMAS.

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

La entrada Azure Update Manager se publicó primero en RAGASYS SISTEMAS.

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

La entrada Azure – Programación de inicio y apagado de máquinas virtuales con Start Stop v2 se publicó primero en RAGASYS SISTEMAS.

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

La entrada Crear una zona DNS secundaria mediante la zona DNS primaria en Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Copia de seguridad y restauración de Microsoft Entra ID con Veeam se publicó primero en RAGASYS SISTEMAS.

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

La entrada Migrar IP pública con SKU Basic a SKU Standard en Azure se publicó primero en RAGASYS SISTEMAS.

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:

• A modo de información:
• Nivel de acceso: Esporádico (Cool) vs Optimizado (Hot):
• Consideración de costes, configurar la cuenta como Esporádico (Cool) reduce el coste de almacenamiento por GB, pero eleva significativamente el coste de las transacciones (operaciones de lectura/escritura/Indexación).
• Impacto en Veeam, las tareas de backup, los chequeos de integridad (Health Check) y los procesos de mantenimiento de Veeam realizan millones de transacciones de API, para repositorios de backup activos con escrituras diarias, el nivel Optimizado (Hot) suele resultar más económico en la factura global de Azure que el nivel Cool, reservando este último para Copy Jobs o archivos a más largo plazo.
• La capa Cool es ideal si utilizas el Backup Copy Job bajo estas condiciones:
• Retención a medio/largo plazo (GFS), guardas copias semanales, mensuales o anuales que apenas se van a tocar durante bastante tiempo.
• Tasa de cambio baja, los deltas o incrementales diarios no transfieren una enorme cantidad de bloques/ficheros nuevos cada día.
• Pocas restauraciones de prueba, la información está en Azure «por si ocurre un desastre» y no planeas hacer pruebas masivas de restauración con frecuencia.

Saludos y espero que os sea de ayuda

La entrada Veeam Backup & Replication – Backup Repository en Azure Blob Storage con inmutabilidad se publicó primero en RAGASYS SISTEMAS.

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:

• A modo de información:
• Nivel de acceso: Esporádico (Cool) vs Optimizado (Hot):
• Consideración de costes, configurar la cuenta como Esporádico (Cool) reduce el coste de almacenamiento por GB, pero eleva significativamente el coste de las transacciones (operaciones de lectura/escritura/Indexación).
• Impacto en Veeam, las tareas de backup, los chequeos de integridad (Health Check) y los procesos de mantenimiento de Veeam realizan millones de transacciones de API, para repositorios de backup activos con escrituras diarias, el nivel Optimizado (Hot) suele resultar más económico en la factura global de Azure que el nivel Cool, reservando este último para Copy Jobs o archivos a más largo plazo.
• La capa Cool es ideal si utilizas el Backup Copy Job bajo estas condiciones:
• Retención a medio/largo plazo (GFS), guardas copias semanales, mensuales o anuales que apenas se van a tocar durante bastante tiempo.
• Tasa de cambio baja, los deltas o incrementales diarios no transfieren una enorme cantidad de bloques/ficheros nuevos cada día.
• Pocas restauraciones de prueba, la información está en Azure «por si ocurre un desastre» y no planeas hacer pruebas masivas de restauración con frecuencia.

Saludos y espero que os resulte de ayuda

La entrada Veeam Backup & Replication – Backup Repository en Azure Blob Storage sin inmutabilidad se publicó primero en RAGASYS SISTEMAS.

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

La entrada Conmutación por error en réplicas de máquinas virtuales entre distintas regiones de Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Réplicas de máquinas virtuales entre distintas regiones de Azure se publicó primero en RAGASYS SISTEMAS.

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

La entrada Conmutación por error en réplicas de máquinas virtuales desde VMware vSphere a Azure se publicó primero en RAGASYS SISTEMAS.