• Lo primero que vamos a ver, es que versión de Homepage tenemos instalada, como vemos tenemos la versión 1.7.0 build b6b4283:

• Ahora actualizamos a la versión más reciente.
• cd /opt/docker/homepage
• docker compose pull homepage
• docker compose up -d
• Descarga la nueva versión
• Detiene el contenedor actual
• Lo recrea con la nueva imagen, manteniendo toda la configuración
  porque están montados como volúmenes:
• volumes:
• /opt/docker/homepage/config:/app/config
• /opt/docker/homepage/icons:/app/public/icons
• /opt/docker/homepage/images:/app/public/images
• /var/run/docker.sock:/var/run/docker.sock:ro

• Vemos que tenemos actualizada a la última versión disponible de Homepage, la versión 1.8.0 build 1ed2f16:

Saludos y espero que os sea de ayuda

En este post vamos a ver como desplegar homepage con Docker.

Homepage es un panel de control de aplicaciones moderno, totalmente estático, rápido, seguro, con proxy completo y altamente personalizable, con integraciones para más de 100 servicios y traducciones a varios idiomas, se configura fácilmente mediante archivos YAML o mediante la detección de etiquetas Docker.

• Nos creamos el registro DNS del tipo CNAME para homepage apuntando a la máquina que tiene instalada el Docker:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de homepage:
• sudo mkdir -p /opt/docker/homepage/config
• sudo mkdir -p /opt/docker/homepage/icons
• sudo mkdir -p /opt/docker/homepage/images
• sudo chmod -R 775 /opt/docker/homepage

• Así quedaría nuestra estructura de directorios:

• Lo siguiente que haremos será crearnos el archivo docker-compose.yml para homepage, sudo nano /opt/docker/homepage/docker-compose.yml:

• Iniciamos Nginx Proxy Manager, cd /opt/docker/homepage, sudo docker compose up -d:

• Con sudo docker ps -a, vemos el contenedor levantado:

• Con docker exec -it nginxpm sh -c «apk add –no-cache curl >/dev/null 2>&1; curl -sI http://homepage:3000«, comprobamos que Nginx Proxy Manager puede acceder a homepage:

• Ahora nos vamos al panel de administración de Nginx Proxy Manager para crear el Proxy Host:

• Add Proxy Host:

• En la pestaña Details:
• Domain Names: ragasys.eu
• Scheme: http
• Forward Hostname / IP: homepage
• Forward Port: 300
• Websockets Support
• Block Common Exploits
• En la pestaña SSL:
• Seleccionamos en Certificate nuestros certificados SSL
• Marcamos Force SSL
• Marcamos HTTP/2 Support
• Save

• Aquí vemos el host creado y online:

• Si accedemos al host homepage, vemos que ya está utilizando los certificados SSL de Let’s Encrypt, vemos también que nos da un error de validación, es un error bastante común la primera vez que accedemos a Homepage (detrás de un proxy inverso como Nginx Proxy Manager, ahora veremos cómo solucionarlo:

• Para solucionar este error vamos a editar el fichero settings.yml, sudo nano /opt/docker/homepage/docker-compose.yml:

• Y añadimos la variable, HOMEPAGE_ALLOWED_HOSTS: «homepage.ragasys.net,localhost,127.0.0.1»:

• Aplicamos los cambios, cd /opt/docker/homepage, docker compose up -d:

• Accedemos a nuestro host, https://homepage.ragasys.net y vemos que ya tenemos el panel de homepage:

• Ahora vamos a ir configurando los distintos ficheros de homepage, para ir personalizando nuestro panel, esta será la estructura de directorios y los ficheros:

• Empezaremos por el fichero sudo nano settings.yaml:

• sudo nano services.yaml, aquí muestro algunos ejemplos que tenemos que ir completando con todo lo que tenemos en nuestra infraestructura:

• sudo nano widgets.yaml, los widgets para el dashboard:

• sudo nano bookmarks.yaml, los enlaces personales para el dashboard:

• Y así nos iría quedando nuestro panel de Homepage:

Saludos y espero que os sea de ayuda

En este post vamos a ver como Actualizar Nginx Proxy Manager con Docker.

• Lo primero que vamos a ver es que versión de Nginx Proxy Manager tenemos instalada, para ello, ejecutamos docker exec nginxpm cat package.json | grep version:

• Ahora actualizamos a la versión más reciente.
• cd /opt/docker/nginxpm
• docker compose pull nginxproxymanager
• docker compose up -d
• Descarga la nueva versión
• Detiene el contenedor actual
• Lo recrea con la nueva imagen, manteniendo toda la configuración, certificados, bases de datos, etc…
  porque están montados como volúmenes:
• volumes:
• /opt/docker/nginxpm/data:/data
• /opt/docker/nginxpm/data/letsencrypt:/etc/letsencrypt
• /opt/docker/nginxpm/certs:/opt/custom-certs:ro

• Volvemos a ejecutar docker exec nginxpm cat package.json | grep version y vemos que tenemos actualizada a la última versión disponible de Nginx Proxy Manager:

• Si hacemos un docker images vemos las imágenes disponibles en nuestro sistema y con docker ps -a vemos la imagen que está en uso para nuestro Nginx Proxy Manager:

• Con docker rmi imageID podemos eliminar las imágenes que ya no están en uso, en este caso eliminamos la imagen antigua de Nginx Proxy Manager que ya no utilizamos:

Saludos y espero que os sea de ayuda

En este post vamos a ver como añadir certificados SSL personalizados en Nginx Proxy Manager.

• Para empezar, copiamos nuestros certificados wildcard en el directorio de certificados de Nginx Proxy Manager, separamos el fichero .pfx para obtener el certificado público por un lado .crt, y la clave privada por otro .key, para ello vamos a introducir los comandos:
• openssl pkcs12 -in wildcard_ragasys_net.pfx -clcerts -nokeys -out wildcard_ragasys_net.crt
• openssl pkcs12 -in wildcard_ragasys_net.pfx -nocerts -nodes -out wildcard_ragasys_net.key
• openssl pkcs12 -in wildcard_ragasys_net.pfx -cacerts -nokeys -out wildcard_ragasys_net_chain.crt

• Con este último comando (openssl pkcs12 -in wildcard_ragasys_net.pfx -cacerts -nokeys -out wildcard_ragasys_net_chain.crt) me va a dar el contenido del .crt vacío (en blanco), ya que es una entidad certificadora que he desplegado desde el Active Directory, con los certificados comprados a una entidad certificadora oficial no tendríamos este problema.
• Para solucionarlo, debo exportar el certificado de mi entidad certificadora:

• Se nos abre este asistente, Siguiente:

• Seleccionamos X.509 codificado base 64 (.CER), Siguiente:

• Le indicamos la ruta para guardarlo, Siguiente:

• Finalizamos:

• Y copiamos el contenido de este fichero .cer en el fichero .crt que estaba en blanco:

• Con esto ya tengo preparado, los tres ficheros que necesito para subirlos al Nginx Proxy Manager como certificados personalizados, .crt (clave pública), .key (clave privada) y el certificado intermedio:

• Ahora, dentro de la consola web de Nginx Proxy Manager, accedemos a Certificados > Añadir Certificado > Certificado Personalizado:

• Le indicamos un nombre y añadimos nuestros certificados (clave privada, clave pública y certificado intermedio), Guardar:

• Como podemos ver, ya lo tenemos añadido y listo para usar con nuestros hosts:

• Como podemos ver, en la ruta /opt/docker/nginxpm/data/custom_ssl nos guarda los certificados personalizados:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como agregar los Hosts en Nginx Proxy Manager utilizando los certificados SSL que hemos desplegado.

• Accedemos a Hosts > Proxy Hosts:

• Add Proxy Host:

• En la pestaña Details:
• Domain Names: ragasys.eu
• Scheme: http
• Forward Hostname / IP: IP
• Forward Port: 80
• Websockets Support
• Block Common Exploits
• En la pestaña SSL:
• Seleccionamos en Certificate nuestros certificados SSL
• Marcamos Force SSL
• Marcamos HTTP/2 Support
• Save

• Aquí vemos el host creado y online:

• Si accedemos al host, vemos que ya está utilizando los certificados SSL de Let’s Encrypt:

• Agregamos más hosts a medida que los vamos necesitando:

• En nuestro DNS interno, nos hemos creado estos registros del tipo CNAME apuntando a la máquina que tiene el contenedor Docker de nginx proxy manager:

• Si accedemos a SSL Certificates, vemos que ya tenemos los certificados en uso, una vez creados los hosts:

• Ahora vamos a crear otro host para el propio portal de Nginx Proxy Manager puerto 81 y le haremos la redirección para utilizar un certificado SSL:

• Aquí lo tenemos creado:

• Accedemos por https:

• Vemos que ya está utilizando el certificados SSL de Let’s Encrypt:

Saludos y espero que os sea de ayuda

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

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 Cloudflare, que es dónde tenemos alojadas nuestras zonas DNS.

• Para empezar, nos vamos a crear un registro tipo CAA en nuestra zona DNS de Cloudflare para Let´s Encrypt, para ello, accedemos a DNS > Registros > Agregar registro:

• Ahora vamos a crear un API Token en nuestra zona DNS de Cloudflare, accedemos a Mi Perfil > Tokens de API > Crear Token:

• Seleccionamos Editar zona DNS > Usar plantilla, también podemos usar Crear Token Personalizado:

• Le indicamos un nombre para el token, le indicamos los permisos, los recursos de zona, Ir al resumen:

• Nos muestra un resumen y creamos el token para nuestra zona:

• Aquí tenemos el token generado, debemos de copiar el valor, ya que lo mostrará sólo una vez, guardamos el token en un sitio seguro:

• Verificamos el token y vemos que es válido:

• Aquí vemos que ya tenemos el token activo:

• Con esto, ya tenemos preparado la parte de la zona DNS de Cloudflare, 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.net y *.ragasys.net, 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, nuestro email registrado en Cloudflare.
• Marcamos Use a DNS Challenge.
• En DNS Provider seleccionanamos Cloudflare.
• Pegamos el API Token que copiamos desde Cloudflare.
• 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 Cloudflare, esperará la propagación y Let’s Encrypt validará.

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

• Estos son los registros TXT _acme-challenge que se generan, 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:

• Tengo otro dominio DNS llamado ragasyssistemas.com en cloudflare, y también quiero añadir a Nginx Proxy Manager los certificados SSL de Let’s Encrypt para este dominio, para ello, vuelvo a repetir todo el proceso, y aquí vemos, que ya los tengo agregados y listos para usar en nuestros Hosts:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como desplegar Nginx Proxy Manager con Docker.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 24.04 LTS, dónde tenemos dos discos, uno de sistema y otro de datos:

• Como podemos ver, el disco de datos lo hemos montado sobre /opt/docker que es dónde vamos a ubicar todos los contenedores Dockers y sus configuraciones:

• Nos creamos el registro DNS del tipo CNAME para nginx proxy manager apuntando a la máquina que tiene instalada el Docker:

• Lo primero que vamos a realizar es actualizar nuestro sistema, sudo apt update && sudo apt upgrade -y:

• Instalamos las dependencias necesarias, sudo apt install -y ca-certificates curl gnupg lsb-release:

• Instalamos Docker desde el script oficial, curl -fsSL https://get.docker.com -o get-docker.sh, sudo sh get-docker.sh, rm get-docker.sh:

• Instalamos el plugin de Docker Compose, sudo apt install -y docker-compose-plugin:

• Verificamos las versiones, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de nginx proxy manager:
• sudo mkdir -p /opt/docker/nginxpm/data
• sudo mkdir -p /opt/docker/nginxpm/certs
• sudo chmod -R 755 /opt/docker

• Así quedaría nuestra estructura de directorios:

• Ahora creamos la red interna para Docker, esto permite que los contenedores se comuniquen sin exponer puertos externos, sudo docker network create internal-net:

• Lo siguiente que haremos será crearnos el archivo docker-compose.yml para nginx proxy manager, sudo nano /opt/docker/nginxpm/docker-compose.yml:

• Iniciamos Nginx Proxy Manager, cd /opt/docker/nginxpm, sudo docker compose up -d:

• Aquí vemos el contenedor levantado:

• Ahora accedemos al panel de administración de Nginx Proxy Manager en el puerto 81, el usuario es admin@example.com y la contraseña changeme:

• Editamos el usuario y lo personalizamos a nuestro gusto, Save:

• Cambiamos la contraseña por defecto, Save:

• Esta sería la estructura de directorios que queda configurada para el contenedor Docker de Nginx Proxy Manager:

• Con todo esto, ya tenemos nuestro contenedor Docker de Nginx Proxy Manager operativo, en los siguientes posts veremos, cómo se configuran los certificados SSL, veremos tres formas, dos de ellas con Let´s Encrypt configurado por DNS Challenge, uno con el DNS Provider por Cloudflare y otro con el DNS Provider por Azure así no exponemos hacia fuera los puertos 80 y 443, la tercera forma que veremos con los certificados serán con certificados comprados a una CA y utilizando la parte Custom para añadirlos, y en otros post veremos como desplegar otras aplicaciones con Docker como homepage utilizando el Nginx Proxy Manager con los certificados que hemos añadido, configurando los Host en nuestro Nginx Proxy Manager.
• Aquí os dejo un pequeño apunte con los comando útiles de Docker:

Link descarga en pdf

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar una VPN IPSEC de acceso remoto en un firewall Fortigate, con este tipo de VPN usando el protocolo IPSec nos podemos conectar desde cualquier equipo con conexión a Internet hacia nuestra red interna, dónde todo el tráfico irá encriptado.

• Lo primero que vamos a realizar será, crear los usuarios locales que accederán a través de la VPN:

• Para una correcta administración, los usuarios que nos hemos creado anteriormente los vamos a anidar en un grupo:

• Una vez creados los usuarios y grupos, vamos a crearnos el túnel IPSec, para ello, accedemos a VPN > Túneles Ipsec > Crear nuevo > IPsec Tunnel:

• Sobre Configuración de VPN, le indicamos un nombre y seleccionamos Acceso remoto, Siguiente:

• Sobre Autenticación, le indicamos la interface de entrada, el método de autenticación por llave compartida y el grupo de usuario, este grupo lo eliminaremos de la configuración de las fases más tarde, ya que las políticas de acceso irán configuradas con grupos y no sería necesario, Siguiente:

• Sobre Política y Enrutamiento, vamos a configurar esta política, que más tarde vamos a eliminar, ya que iremos aplicando políticas más granulares y restrictivas, habilitamos el Split Tunnel, esto hará que los usuarios que se conecten a la VPN, tengan la salida a Internet por su propia conexión y no por la nuestra, Siguiente:

• Sobre Opciones de cliente, le indicamos que guarde la contraseña, y habilitamos el Keep Alive, Crear:

• Aquí nos indica todo lo que hemos configurado, damos a Mostrar la lista de túnel:

• Vemos el túnel IPsec que nos ha creado, damos a Editar:

• Convertimos a túnel personalizado:

• Para la parte de Red, configuramos estos parámetros:

• Para la parte de Autenticación, configuramos lo siguiente:

• Para la propuesta de la fase 1, configuramos estos parámetros:

• Para XAUTH, aquí es donde quitamos el grupo que configuramos al crear el túnel, y para el Grupo de Usuarios, le indicamos que los herede de las políticas:

• Para los Selectores de fase 2, configuramos estos parámetros, damos a OK:

• Aquí tenemos ya el túnel IPsec configurado de modo personalizado:

• Antes de seguir, vamos a explicar, estos dos objetos que se han creado al crear la VPN IPsec.
• Uno de ellos es, ipsecra_range, este objeto es para asignar las direcciones IPs de los equipos que se conecten a nuestra VPN PIsec de acceso remoto:

• El otro es, ipsecra_split, este objeto es un grupo de direcciones que actúa como una «lista blanca» de destinos, su función principal es decirle al cliente VPN (FortiClient) qué tráfico debe enviar obligatoriamente a través del túnel y cuál debe ignorar para que salga por su conexión local a Internet.
• Cuando habilitamos el Split Tunneling (Túnel Dividido), el comportamiento es el siguiente:
• Si el destino está en el objeto ipsecra_split, el FortiClient enruta ese tráfico por la VPN.
• Si el destino NO está ahí, el FortiClient lo envía por la puerta de enlace predeterminada del usuario (su internet doméstico).

• También podemos ver, que en la interface de red que le indicamos al túnel VPN IPsec, nos ha creado esta interface virtual:

• Para terminar de configurar la VPN IPsec de acceso remoto, debemos de crear las reglas o políticas para que los equipos que se conecten a través de la VPN, tengan acceso a las redes internas configuradas en nuestro firewall, voy a mostrar sólo una de ellas ya que para las demás sería exactamente igual, editamos la regla que se nos creó al crear el túnel IPsec:

• Con esto ya tendríamos configurada y operativa nuestra VPN IPsec de acceso remoto, ahora desde cualquier equipo con conexión a internet, le instalaremos el Forticlient y configuraremos los parámetros de la VPN IPsec para conectarnos desde cualquier lugar del mundo a las redes internas de nuestra infraestructura, dónde todo el tráfico irá encriptado mediante IPsec:

• Como podemos ver ya estamos conectados y nos está sirviendo una dirección IP del rango que habíamos configurado:

• Aquí vemos el túnel levantado:

• Desde el Monitor IPsec de nuestro Fortigate podemos ver los usuarios conectados a través de la VPN:

• Desde la opción VPN > VPN Location Map podemos ver desde que parte del mundo se están conectando los usuarios que hemos creado y configurado para nuestra VPN IPsec de acceso remoto:

Saludos y espero que os resulte de ayuda

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 veremos como migrar máquinas virtuales de VMware vSphere a Microsoft Hyper-V, para ello, vamos a utilizar Windows Admin Center.

Fuente captura de pantalla y post: Microsoft Learn

• Para empezar, tenemos que tener desplegado y configurado en nuestra infraestructura Windows Admin Center, en estos post que realizamos hace algún tiempo en este mismo blog podéis ver como se instala y configura Windows Admin Center.
• Estos son los requisitos que nos indica Microsoft que debemos de tener instalados en nuestro Windows Admin Center:
• Instalamos PowerCLI, para ello, nos abrimos PowerShellcomo administrador, y ejecute el siguiente comando para instalar el módulo PowerCLI, Install-Module -Name VMware.PowerCLI:

• Comprobamos que el módulo está instalado, ejecutando, Get-Module -Name VMware.PowerCLI -ListAvailable:

• Probamos la conexión a vCenter Server mediante la ejecución de, Connect-VIServer -Server «<vCenterServerFQDN_or_IP>» -User «<username>» -Password «<password>» -Force:

• Instalamos:
• Microsoft Visual C++ Redistributable
• Paquetes redistribuibles de Visual C++ para Visual Studio 2013
• Descargamos VMware Virtual Disk Development Kit (VDDK) versión 8.0.3. Extraemos el contenido y lo copiamos en el directorio, C:\Archivos de programa\WindowsAdminCenter\Service\VDDK, debemos asegurarnos de descargar VDDK versión 8.0.3 específicamente, no se admiten otras versiones.
• Aquí las tenemos descargadas, las vamos instalando en el orden indicado:

• Uso de la puerta de enlace de Windows Admin Center V2: número de compilación de versión mínima 24102.4.12.10:

• Requisitos previos del host vCenter o ESXi

Ninguno.

• Requisitos previos del host de Windows Server

Ninguno.

• Versiones de vCenter admitidas:
• La extensión admite VMware VCenter versión 6.x o 7.x o 8.x.
• Para conectarse a vCenter desde la extensión, mantenga la siguiente información de vCenter a mano:
• Nombre de dominio completo (FQDN)
• Nombre de usuario
• Contraseña
• Sistemas operativos invitados compatibles:
• Sistemas operativos Windows:
• Windows Server 2025, 2022, 2022 Azure Edition, 2019, 2016, 2012 R2
• Windows 10, Windows 11
• Sistemas operativos basados en Debian:
• Ubuntu Linux
• Ubuntu 20.04, 24.04
• Debian 11, 12, 13

• Accedemos a nuestro Windows Admin Center:

• Nos vamos a configuración:

• Accedemos a Puerta de enlace > Extensiones > Extensiones disponibles > VM Conversion (Preview) > Instalar:

• Accedemos a Puerta de enlace > Extensiones > Extensiones instaladas > VM Conversion (Preview) y vemos que ya está instalada:

• Ahora desde Windows Admin Center > Todas las conexiones, accedemos a nuestra puerta de enlace (host de Windows Admin Center):

• Sobre Extensiones > Conversión de VM (versión preliminar), conectamos nuestro vCenter:

• Introducimos el FQDN de nuestro vCenter con sus credenciales, Enviar:

• Como podemos ver, ya estamos conectado a nuestro vCenter, y podemos visualizar todas las máquinas virtuales de VMware vSphere:

• Ahora, vamos a migrar una máquina de nuestro vCenter a un servidor de Hyper-V ubicado en un Failover Cluster, para ello, accedemos al servidor de Hyper-V en Windows Admin Center al que queramos migrar la máquina virtual:

• Sobre el Servidor de Hyper-V > Extensiones > Conversión de VM (versión preliminar), seleccionamos la máquina virtual y damos a Sincronizar:

• Sobre Sincronizar máquina virtual, vemos la ruta de acceso para almacenar los datos, Sincronizar:

• Como podemos ver, la sincronización está en curso:

• Como vemos, la sincronización ha sido completada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, que el disco virtual de la máquina ha sido migrado al formato .vhdx que utiliza Hyper-V:

• Ahora, ya podemos crear una nueva máquina virtual y adjuntarle este disco que hemos migrado:

• Aquí tenemos ya, la máquina virtual migrada, operativa y funcionando sobre Hyper-V:

Saludos y espero que os sea de ayuda

En este post vamos a ver, como actualizar Windows 10 a Windows 11 en equipos antiguos, en los que las restricciones por TPM y compatibilidad de CPU esta actualización no es posible por el método tradicional.

• Si intentamos actualizar a MS Windows 11 Pro 24H2 en nuestro equipo nos vamos a encontrar con este problema, que nos indica, que el equipo no cumple los requisitos mínimos del sistema para instalar esta versión de Windows:

• Esto es debido al TPM 2.0 (Trusted Platform Module), el TPM es un chip físico que se encuentra en la placa base de los ordenadores, y su función es servir de almacenamiento físico de credenciales, certificados, claves de cifrado…, Windows 11 va a necesitar que tengamos el TPM 2.0 activado porque es un componente esencial para Windows Hello(forma personal para iniciar sesión usando un sistema biométrico, un PIN…) y para BitLocker (aplicación de cifrado que protege el disco duro de posibles robos de datos).
• Para solucionar este problema y poder actualizar a Windows 11 Pro 24H2 necesitamos la Imagen ISO Windows 11 Pro 24H2, la montamos en nuestro equipo y accedemos a la carpeta sources:

• Desde este mismo explorador nos abrimos un cmd:

• Como vemos, se sitúa directamente sobre el directorio sources, ejecutamos el comando setupprep /product server, aquí es dónde se produce el “engaño” al sistema indicándole que se va a instalar un Windows Server, cuando en realidad se instala un Windows 11:

• Cambiamos la forma en la configuración de descarga de actualizaciones, como veis, pone Instalar Windows Server, no le echéis cuenta:

• Le indicamos, No en este momento, Siguiente:

• Empieza a preparar el sistema:

• Aceptamos el EULA:

• Le indicamos que mantenga archivos, configuraciones y aplicaciones, Siguiente:

• Comprobando que todo está listo para instalar:

• Todo listo para instalar:

• Comienza la instalación:

• Una vez que finaliza, se reinicia el equipo, y ya vemos que se ha migrado a Windows 11:

Saludos y espero que os resulte de ayuda

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3f a la versión 8.0 Update 3h a través de ESXCLI, en este link os dejo toda la información.

• Como podemos ver, nuestros hosts ESXi está en la versión 8.0.3 build 24784735:

• Para empezar nos descargamos de la web de Broadcom WMware el patch para la instalación offline a través de la ESXCLI de ESXi 8.0 Update 3h build 25067014:

• Cargamos este archivo en un datastore de nuestro vCenter:

• Ponemos el host ESXi que queremos actualizar en modo mantenimiento:

• Accedemos por SSH al host ESXi que queremos actualizar:

• Ejecutamos el siguiente comando para listar los perfiles disponibles del parche descargado, esxcli software sources profile list -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3h-25067014-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3h-25067014-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3h-25067014-depot.zip –no-hardware-warning una vez que ha finalizado, nos indica que debemos de reiniciar, * NOTA al final explicamos el comando hay temas a tener en cuenta:

• Una vez que el host ha iniciado, lo sacamos del modo mantenimiento:

• Como podemos ver, la actualización se ha realizado correctamente y ya tenemos el host ESXi en la versión0 Update 3h Build 25067014:

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3h-25067014-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3h-25067014-depot.zip –no-hardware-warning
• ESXi-8.0U3h-25067014-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3h-25067014-depot.zip archivo utilizado para la actualización de ESXi
• –no-hardware-warning esta parte es por si nos da un error de CPU, por si la CPU de nuestro equipo no es compatible con la nueva release para que ignore este error, en mi caso la CPU de mi equipo no es compatible 100% con esta nueva reléase por eso lo añado al comando, ya que es un entorno de laboratorio, en producción el comando a ejecutar sería esxcli software profile update -p ESXi-8.0U3h-25067014-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3h-25067014-depot.zip

• Para el segundo host realizamos las mismas operaciones para actualizarlo:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3h build 25092719, del 15 de diciembre de 2025.

En este enlace os dejo la información sobre esta nueva actualización:

• VMware vCenter Server 8.0 Update 3h Release Notes
• Nos conectamos a la interfaz VAMI de nuestro VCSA a través del puerto 5480 e iniciamos sesión:

• Una vez que hemos iniciado sesión podemos ver, que nuestro VCSA está en la versión 8.0.3.00600 build 24853646:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3h, la seleccionamos y damos clic sobre Realizar copias intermedias e instalar:

• Se nos abrirá este asistente, donde aceptamos el EULA, clic a Siguiente:

• Empieza a ejecutar comprobaciones previas a la actualización:

• Omitimos y continuamos:

• Realizamos copias de seguridad del vCenter y finalizamos:

• Como podemos ver comienza el proceso de actualización:

• Como podemos ver, la instalación ha sido completada y correcta:

• Una vez finalizada, volvemos a iniciar sesión en la interfaz VAMI del VCSA a través del puerto 5480, y aquí vemos que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3h build 25092719:

• Ahora accedemos a la interface HTML5 de nuestro VCSA recién actualizado:

• Introducimos las credenciales e iniciamos:

• Aquí podemos ver también que nuestro VCSA está en la última release liberada por VMware, la 8.0 Update 3h build 25092719:

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar Veeam ONE 13.0.1.5924 a la nueva versión 13.0.1.6168 liberada por Veeam hace algunos días.

• Como podemos ver aquí, tenemos descargada la v13.0.1.6168 de Veeam ONE:

• Vemos que la versión que tenemos instalada es la 13.0.1.5924:

• Nos montamos la imagen ISO, y ejecutamos el setup para proceder con la instalación del upgrade a la 0.1.5924:

• Ejecutamos el Update:

• Seleccionamos Update Veeam ONE:

• Aceptamos el EULA:

• Nos indica que ha detectado una versión previa de Veeam ONE, y que va a actualizar a ésta última, clic sobre Next para proceder con el update:

• Damos a Install para proceder con el update:

• Comienza con la actualización:

• Como podemos ver la actualización a v13.0.1.6168, ha finalizado correctamente:

• Una vez finalizada la instalación, podemos ver, que ya tenemos instalada la última versión de Veeam ONE v13.0.1.6128:

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar Veeam ONE 12.3.0.4670 a la nueva versión 13.0.1.5924 liberada por Veeam hace algunos días.

• Como podemos ver aquí, tenemos descargada la v13.0.1.5924 de Veeam ONE:

• Vemos que la versión que tenemos instalada es la 12.3.0.4670:

• Nos montamos la imagen ISO, y ejecutamos el setup para proceder con la instalación del upgrade a la 0.1.5924:

• Ejecutamos el Upgrade:

• Seleccionamos Upgrade Veeam ONE:

• Aceptamos el EULA:

• Nos indica que ha detectado una versión previa de Veeam ONE, y que va a actualizar a ésta última, clic sobre Next para proceder con el upgrade:

• Introducimos el fichero de licencia:

• Debemos especificar una cuenta para el servicio de Veeam ONE, esta cuenta la creamos y la configuramos en la primera instalación que hicimos de Veeam ONE, por lo que en este caso, sólo debemos de introducir el password que configuramos en la instalación original:

• Comienza a verificar el sistema para identificar cualquier tipo de problema:

• Instalamos una nueva instancia de PostgreSQL:

• Le indicamos el puerto:

• Habilitamos Veeam Analytics Service:

• Clic sobre Upgrade para comenzar con el proceso de actualización a la nueva versión:

• Comienza con la actualización, aquí debemos de tener un poco de paciencia ya que el proceso es bastante lento:

• Como podemos ver la actualización a v13.0.1.5924, ha finalizado correctamente:

• Una vez finalizada la instalación, podemos ver, que ya tenemos instalada la última versión de Veeam ONE v13.0.1.5924:

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.1.180 a la nueva versión 13.0.1.1071, en este link podemos ver las nuevas características de esta versión, y en este link podemos ver la lista de vulnerabilidades que corrige.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v13.0.1.180:

• Desde aquí nos descargamos la ISO, versión 13.0.1.1071 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.0.1.1071 para Microsoft Windows descargada:

• Montamos la ISO y copiamos el ejecutable de la actualización patch a nuestra máquina de Veeam:

• Una vez copiado, lo ejecutamos y empezamos con el upgrade:

• Comienza la instalación del parche, Next:

• Comienza a comprobar compatibilidades:

• La instalación nos indica que ya está todo preparado, Install:

• Aquí vemos que la instalación del upgrade, está en curso:

• Como podemos ver, la actualización a v13.0.1.1071, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar Veeam Backup & Replication v12.3.2.4165 a la nueva versión 13.0.1.180, en este link podemos ver las nuevas características de esta versión.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v12.3.2.4165:

• Desde aquí nos descargamos la ISO, versión 13.0.1.180 para sistemas Microsoft Windows:

• Aquí tenemos ya, la nueva ISO v13.0.1.180 para Microsoft Windows descargada:

• Montamos la ISO y ejecutamos el setup:

• Damos sobre UPGRADE:

• Nos indica que necesita instalar Microsoft .NET 8.0.21, le indicamos OK:

• Seleccionamos Upgrade Veeam Backup & Replication:

• Comienza a inicializar el asistente:

• Aceptamos el EULA:

• Seleccionamos nuestra licencia de Veeam Backup & Replication v13, Next:

• Comienza a chequear las configuraciones y si nos falta algún componente, lo irá instalando:

• Nos indica los componentes que se han instalado, y que uno de ellos, requiere reinicio, Reboot:

• Una vez reiniciado, volvemos a lanzar el setup, hasta llegar al mismo punto donde nos quedamos.
• Nos indica algunos avisos de compatibilidades, pero nada importante que nos impida actualizar:

• Nos indica todos los componentes que van a ser actualizados, Upgrade:

• Comienza con la actualización, aquí debemos de tener un poco de paciencia ya que el proceso es bastante lento:

• Como podemos ver, la actualización a v13.0.1.180, ha finalizado correctamente:

• Accedemos a la consola Windows:

• Esta sería la nueva consola de Veeam Backup & Replication 13.0.1.180:

• Como novedad en esta nueva versión, también podemos acceder a través de una interface web HTML5:

• Este sería el aspecto de la nueva consola web, tendremos un panel Overview, dónde nos muestra un resumen de todo el estado de nuestra infraestructura de backups, y también tendremos el acceso a los Jobs, Backups, Repositories, Proxies…, a la consola web todavía le faltan muchas de las funcionalidades que tenemos en la consola Windows, seguramente en próximas actualizaciones irán incorporando las funcionalidades completas de la consola Windows:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como actualizar Veeam Backup & Replication v12.3.2.3617 a la nueva release v12.3.2.4165, en este link podemos ver las vulnerabilidades que corrige.

• Como podemos ver, la versión de nuestro Veeam Backup & Replication es la v12.3.2.3617:

• Nos hemos descargado el parche de actualización (.exe) para la nueva release v12.3.2.4165:

• Se nos abre el siguiente asistente para actualizar a Veeam Backup & Replication v12.3.2.4165, clic sobre Next:

• Aceptamos el EULA:

• Damos a instalar para comenzar con el upgrade:

• Comienza con la actualización:

• Como podemos ver la actualización a v12.3.2.4165, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

En este post vamos a ver como agregar un Clúster de Proxmox VE a nuestra infraestructura de backup con Veeam Backup & Replication versión 13.

• Lo primero que vamos a realizar será irnos hasta Inventory > Virtual Infraestructure > Proxmox VE > Add Server:

• Le indicamos el nombre DNS o la dirección IP del primer nodo del Cluster Proxmox VE, con una descripción:

• Introducimos las credenciales con permisos administrativos sobre el Cluster de Proxmox VE:

• Le indicamos que es un servidor de confianza:

• En caso de que la máquina virtual original no soporte snapshots, le indicamos que utilice el mayor almacenamiento disponible a nivel de archivos, Apply:

• Como podemos ver se ha agregado correctamente, Next:

• Nos muestra un resumen y finalizamos:

• Aquí nos indica que Veeam Backup para Proxmox VE, requiere al menos un worker (virtual machine) que entregue los datos respaldados desde y hacia los repositorios de respaldo, y que para un mejor rendimiento, se recomienda desplegar un Worker en cada nodo de Proxmox VE, le indicamos que Sí:

• Sobre Virtual Machine, le indicamos el nombre de la máquina, le indicamos el datastore, una descripción y los trabajos máximos concurrentes, Next:

• Sobre Network, añadimos el direccionamiento IP para la máquina virtual y los DNS:

• Sobre Summary, nos muestra un resumen de todo lo configurado, le indicamos que haga un testeo del worker y finalizamos:

• Aquí vemos que comienza el testeo del worker, tal y como le hemos indicado:

• Vemos como el worker, está desplegado sobre nuestro nodo de Proxmox VE:

• Una vez finalizado el testeo del worker, vemos que ya tenemos el primer nodo de nuestro clúster Proxmox VE añadido:

• Para los otros dos nodos, haremos lo mismo, y como podemos ver, ya tenemos añadidos los tres nodos de nuestro clúster de Proxmox VE:

• Si accedemos a Backup Infrastructure > Backup Proxies, podemos ver los tres workers desplegados, uno por cada nodo:

• Aquí los tenemos desplegados cada uno en su nodo:

Saludos y espero que os resulte de ayuda