En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3k build 25600417, del 29 de julio de 2026.

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

• VMware vCenter Server 8.0 Update 3i 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.00900 build 25413364:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3k, 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 3k build 25600417:

• 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 3k build 25600417:

Saludos y espero que os resulte de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3j a 8.0 Update 3k se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3i a la versión 8.0 Update 3j 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 25205845:

• 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 3j build 25429389:

• 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.0U3j-25429389-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-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ón 8.0 Update 3j Build 25429389 :

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip –no-hardware-warning
• ESXi-8.0U3j-25429389-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3j-25429389-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.0U3j-25429389-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3j-25429389-depot.zip

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

Saludos y espero que os sea de ayuda

La entrada Actualizar VMware vSphere ESXi 8.0 Update 3i a 8.0 Update 3j con ESXCLI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3j build 25413364, del 27 de mayo de 2026.

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

• VMware vCenter Server 8.0 Update 3i 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.00800 build 25197330:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3j, 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 3j build 25413364:

• 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 3j build 25413364:

Saludos y espero que os resulte de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3i a 8.0 Update 3j se publicó primero en RAGASYS SISTEMAS.

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 veremos cómo crear un almacén de datos ZFS en Proxmox Backup Server (PBS) para los repositorios de las copias de seguridad inmutables, esta inmutabilidad será de forma manual.

La topología utilizada sería la siguiente:

• Antes de empezar, vemos que en nuestro Proxmox Backup Server, le hemos añadido tres discos de 200GB dónde vamos a montar un RAIDZ (RAID 5) con ZFS para crear el repositorio de nuestras copias de seguridad inmutables:

• Desde la consola web de nuestro PBS, accedemos a Almacenamiento/Discos, y podemos ver, que ya tenemos disponibles los tres discos de 200 GB que hemos añadido:

• Clicamos sobre Almacenamiento/Discos > ZFS:

• Creamos el pool ZFS:

• Le indicamos los tres discos que vamos a utilizar, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el Datastore al almacenamiento de nuestro PBS, como nivel de RAID en este caso le indicamos RAIDZ que equivale a un RAID 5, Crear:

• Como podemos ver, aquí se ha creado el pool de ZFS:

• Y aquí vemos, el almacén de datos creado:

• Estas son las opciones de RAID que tenemos en ZFS con Proxmox:
• Single Disk (Disco Único), es la configuración más básica, no hay redundancia. Cómo funciona: Los datos se escriben en un solo disco. Seguridad: Nula. Si el disco falla, pierdes todos los datos. Uso ideal: Pruebas, entornos de desarrollo no críticos o si tienes una estrategia de backup externa extremadamente sólida.
• Mirror (RAID 1), el clásico «espejo», requiere al menos 2 discos. Cómo funciona: Todo lo que se escribe en el Disco A se replica exactamente en el Disco B. Seguridad: Alta. Puede fallar un disco y el sistema seguirá funcionando. Rendimiento: Muy bueno en lectura (lee de ambos), pero la capacidad total es solo la de un disco.
• RAID 10 (Striped Mirrors), es una combinación de Mirroring y Striping, requiere al menos 4 discos (siempre en pares). Cómo funciona: Crea parejas de espejos (mirrors) y luego reparte los datos entre esas parejas. Seguridad: Puede fallar un disco por cada pareja de espejos. Es el más resistente y el que mejor se recupera . Rendimiento: Es el rey del rendimiento en ZFS, especialmente para bases de datos y muchas máquinas virtuales.
• RAIDZ (Equivalente a RAID 5), requiere al menos 3 discos. Cómo funciona: Utiliza un disco para «paridad», los datos se distribuyen entre todos los discos. Seguridad: Soporta el fallo de 1 disco, si falla un segundo disco antes de reemplazar el primero, se pierde todo. Capacidad: Pierdes el espacio equivalente a un disco. Nota: No se recomienda con discos mecánicos de gran capacidad (8TB+) debido al largo tiempo de reconstrucción.
• RAIDZ2 (Equivalente a RAID 6), requiere al menos 4 discos. Cómo funciona: Doble paridad distribuida. Seguridad: Soporta el fallo de 2 discos simultáneamente. Es el estándar de oro para almacenamiento masivo de datos. Capacidad: Pierdes el espacio equivalente a dos discos.
• RAIDZ3, requiere al menos 5 discos. Cómo funciona: Triple paridad distribuida. Seguridad: Soporta el fallo de hasta 3 discos. Es extremadamente seguro. Uso ideal: Solo para servidores con muchísimos discos (ej. 10 o 12 discos por vdev) donde la probabilidad de fallos múltiples es mayor.
• Una vez que hemos creado el repositorio ZFS en Proxmox Backup Server, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Almacenamiento > Agregar > Proxmox Backup Server:

• Sobre General, le indicamos el ID, Servidor y credenciales del PBS, los nodos a los que le vamos a presentar el datastore para los backups, Activar, como contenido de backup, le asignamos un nombre al datastore y le indicamos la Huella digital de nuestro PBS:

• La Huella digital del PBS, la copiamos del servidor PBS:

• Sobre Retención de respaldos, lo dejamos tal cuál nos lo muestra, ya que esto lo configuraremos en los propios trabajos de backups:

• Sobre Cifrado, le indicamos que autogenere una llave de cifrado para el cliente, Agregar:

• Descargamos la llave de cifrado y la guardamos en un lugar seguro, Cerrar:

• Y aquí tenemos ya creado y configurado nuestro datastore ZFS de Proxmox Backup Server que utilizaremos como repositorio de nuestros backups inmutables:

• Una vez creado y configurado el repositorio ZFS, vamos a crearnos una tarea de copia de seguridad inmutable, para ello, sobre nuestro cluster de Proxmox VE, accedemos a Centro de datos > Respaldo > Agregar:

• Sobre General, le indicamos el nodo (en nuestro caso, como es un clúster, Todo), el almacenamiento donde vamos a guardar los backups (Proxmox Backup Server), la programación, Compresión, Modo, le agregamos un comentario de descripción del backup y seleccionamos las máquinas a respaldar:

• Sobre Notificaciones, le podemos indicar la cuenta de correo, a la que queremos que nos lleguen los avisos de los respaldos:

• Sobre Retención, le vamos a indicar que nos mantenga los últimos 7 respaldos, a partir del séptimo irá sobrescribiendo los más antiguos, Crear:

• Aquí vemos la tarea creada:

• Ahora para probar la tarea, la vamos a lanzar de forma manual, Ejecutar ahora:

• Aquí vemos que el respaldo comienza a realizarse:

• Una vez finalizado, accedemos a nuestro Proxmox Backup Server > Almacén de datos > dts01zfspbs > Contenido, y podemos ver el contenido de nuestras copias de seguridad:

• Para hacer este backup inmutable, pulsamos sobre el símbolo del escudo GRIS que nos aparece en nuestro backup:

• Y marcamos el check Protegido, Aceptar:

• Como podemos ver, el escudo cambia a color VERDE y nos aparece el backup como protegido:

• Si intentamos eliminar su contenido, nos va a dar este mensaje de error:

• Esto pasa cuando protegemos un backup:
• El servidor le pone un atributo de «SÓLO LECTURA» a nivel de kernel de Linux.
• Incluso si un virus entra con permisos de administrador e intenta borrar la carpeta del backup, el sistema de archivos ZFS rechazará la orden porque el archivo tiene el bit de inmutabilidad activo.
• La inmutabilidad en PBS significa que el software le pone un candado digital (fattr) a los archivos en el pool de ZFS, mientras ese candado esté puesto, ni el propio Proxmox puede borrar los datos para dejar espacio a backups nuevos.
• Esta inmutabilidad que hemos mostrado es MANUAL, es decir, que por cada punto de retención que se vaya creando tendremos que habilitar de manera manual el candado.
• Esto es lo que pasaría:
• Día 1 al 7, realizamos los backups y les ponemos el candado, quedando protegidos, tenemos 7 puntos de recuperación inmutables.
• Día 8, se realiza el octavo backup y como los 7 anteriores tienen el candado activado y están protegidos, el sistema de limpieza (Prune) no puede borrar el día 1.
• Resultado, ahora tenemos 8 backups ocupando espacio en nuestro datastore ZFS.
• Tendríamos que entrar una vez por semana, quitarle el candado al más viejo (Día 1) y ponérselo al más nuevo (Día 8), esto permite que el proceso de Garbage Collection de ZFS, libere los bloques de datos del Día 1.
• Para restaurar una máquina completa sobrescribiendo la actual, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restaurar:

• Si queremos restaurar archivos, accedemos a la propia máquina > Respaldo > Almacenamiento > Seleccionamos el backup > Restauración de archivo:

• Si quisiera restaurar la máquina completa sin sobrescribir la original, dts01zfspbs > Respaldos > Seleccionamos el backup > Restaurar:

• Le indico el datastore donde la quiero restaurar, y el nuevo ID de máquina virtual, Restaurar:

Saludos y espero que os sea de ayuda

La entrada Crear almacén de datos ZFS en Proxmox Backup Server para los repositorios de copias de seguridad inmutables se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como realizar una actualización in-place de Windows Server 2022 a Windows Server 2025.

Una de las últimas novedades que nos presenta Microsoft, es que ahora podemos realizar actualizaciones in-place de Windows Server 2012 R2, 2016, 2019 y 2022 a Windows Server 2025 como una actualización de características (Feature Update) desde Windows Update, también desde una ISO podemos actualizar desde estos sistemas operativos más antiguos a Windows Server 2025.

Algunas recomendaciones antes de actualizar son:

• El servidor debe contar con las últimas actualizaciones acumulativas mensuales instaladas, especialmente parches posteriores a marzo de 2026.
• Al menos 32 GB de espacio libre en el disco de sistema.
• Realizar un backup de la máquina.
• Realizar un snapshot de la máquina.
• Los controladores de dominio y clústeres de Microsoft se recomienda no usar este método y hacer una actualización planificada como las hemos realizado siempre, en este mismo blog podréis encontrar información al respecto.
• Tener licencia de Windows Server 2025

En este link de Microsoft tenéis toda la información al completo.

• Al tratarse de un cambio crítico de plataforma, Microsoft la ofrece como una actualización opcional, pero el aviso en la configuración de Windows Update no nos va a aparecer, hasta que no hagamos este cambio en el registro de Windows.
• Abrimos el Editor del Registro con regedit:

• Navegamos hasta la ruta, HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate:

• Si no existe, creamos una clave (carpeta) llamada, AllowWindowsServerFeatureUpdate:

• Dentro de ella, creamos un valor DWORD (32 bits) con el nombre exacto, AllowWindowsServerFeatureUpdate y le asignamos el valor 1:

• Reiniciamos el equipo para que los cambios se hagan efectivos:

• Ahora vamos a Configuración > Actualización y seguridad > Windows Update
• Veremos un banner, ofreciendo la Actualización de características a Windows Server 2025
• Hacemos clic en Descargar e instalar:

• Se nos abrirá esta ventana de términos y condiciones donde se mostrará información importante sobre licenciamiento, privacidad y compatibilidad de aplicaciones,haz clic en Aceptar e instalar:

• El sistema operativo comienza a descargar los paquetes en segundo plano y preparará la instalación, este proceso mantiene intactos nuestros roles, características, configuraciones y datos seleccionando internamente la opción equivalente a Mantener ficheros, configuraciones y aplicaciones, “Keep files, settings, and apps”:

• Aquí vemos nuestro sistema migrado a Windows Server 2025:

• Una vez que el sistema se ha migrado a Windows Server 2025, debemos de:
• Verificar los servicios que teníamos operativos que sigan funcionando correctamente.
• Activar la licencia de Windows Server 2025.
• Actualizar Windows Server 2025 con los últimos parches de seguridad
• Pasado un tiempo y confirmado que el entorno es 100% operativo, podemos usar el Liberador de espacio en disco, para eliminar la carpeta old y recuperar el espacio en disco utilizado por el sistema operativo anterior.

Saludos y espero que os sea de ayuda

La entrada Actualización In-Place a Windows Server 2025 se publicó primero en RAGASYS SISTEMAS.

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

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

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

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

• 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:

• 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:

• Damos a Upgrade para proceder con la actualización:

• Comienza con la actualización:

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

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

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam ONE v13.0.1.6168 a la nueva versión 13.0.2.6723 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.1.2067 a la nueva versión 13.0.2.29, 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.2067:

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

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

• Montamos la ISO y ejecutamos el setup:

• Comienza la actualización, Upgrade:

• Seleccionamos Upgrade Veeam Backup & Replication:

• Aceptamos el EULA:

• Marcamos los checks para actualizar la licencia y recibir soporte, 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 tres de ellos, requieren 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.2.29, ha finalizado correctamente:

Saludos y espero que os resulte de ayuda

La entrada Actualizar Veeam Backup & Replication v13.0.1.2067 a v13.0.2.29 se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar Onlyoffice Document Server con Docker, este servidor de documentos de la comunidad está diseñado para facilitar la ejecución de OnlyOffice en una instancia de Nextcloud sin necesidad de configurar un servidor de documentos externo, por lo tanto, lo vamos a integrar con el servidor de nextcloud que desplegamos en el post anterior.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 26.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 onlyofficeds en nuestro DNS interno, apuntando a www y este a su vez apunta a la máquina docker dónde tenemos instalado un Nginx Proxy Manager para los accesos externos:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para el contenedor de Onlyoffice:
• sudo mkdir -p /opt/docker/nextcloud/onlyofficeds/data
• sudo mkdir -p /opt/docker/nextcloud/onlyofficeds/logs
• sudo chmod -R 755 /opt/docker/nextcloud/onlyofficeds

• Ahora vamos a crearnos el fichero .env para no dejar credenciales en texto plano en el fichero docker-compose.yaml que crearemos posteriormente, utilizando para ello variables, para ello, nos situamos en cd /opt/docker/nextcloud/onlyofficeds, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• JWT_SECRET=clave_muy_segura
• JWT_HEADER=Authorization

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

onlyoffice-ds:

image: onlyoffice/documentserver:9.4.0

container_name: onlyoffice-ds

restart: unless-stopped

#   ports:

#     – «8081:80»

environment:

– JWT_ENABLED=true

– JWT_SECRET=${JWT_SECRET}

– JWT_HEADER=${JWT_HEADER}

volumes:

– /opt/docker/nextcloud/onlyofficeds/data:/var/lib/onlyoffice

– /opt/docker/nextcloud/onlyofficeds/logs:/var/log/onlyoffice

networks:

– npmdmz-net

networks:

npmdmz-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos el archivo .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/onlyofficeds/.env

• Ahora, iniciamos el contenedor de Onlyofficeds, cd /opt/docker/nextcloud/onlyofficeds/, sudo docker compose up -d:

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

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para onlyofficeds.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: onlyofficeds.ragasyssistemas.com
• Esquema: http
• Nombre de Host/IP de reenvío: onlyoffice-ds
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos, ya tenemos acceso a nuestro Onlyoffice Document Server a través de nuestro proxy inverso con Nginx Proxy Manager:

• Para que Onlyoffice nos funcione y se integre con nuestro servidor de Nextcloud, debemos de agregar esta línea al final del fichero config.php, sudo nano /opt/docker/nextcloud/nextcloudapp/html/config/config.php, ‘allow_local_remote_servers’ => true, :

• Con sudo docker restart nextcloud-app reiniciamos la aplicación de Nextcloud:

• Ahora accedemos a nuestro Nextcloud y vamos a instalar el conector de Onlyoffice Document Server, para ello, accedemos a Aplicaciones:

• Sobre Archivos, buscamos Onlyoffice y damos a Descargar y activar:

• Una vez descargada y activada, accedemos a Apps activas, y vemos que ya la tenemos operativa:

• Ahora accedemos a Configuración de administración:

• Sobre ONLYOFFICE >Ajustes de servidor, configuramos la Dirección de ONLYOFFICE y la Clave Secreta que configuramos en nuestro .env, Guardar:

• Una vez guardada, tendremos los distintos ajustes para configurar, como las extensiones de ficheros que podremos editar con Onlyoffice:

• Ahora vamos a realizar una prueba, nos vamos a abrir un documento de Word y otro de Excel para verificar que podemos editar documentos online a través de Nextcloud:

• Edición fichero Word online:

• Edición fichero Excel online:

Saludos y espero que os sea de ayuda

La entrada Desplegar Onlyoffice Document Server con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar nextcloud con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de Nextcloud con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

Nextcloud es un espacio de trabajo digital moderno que integra herramientas clave de productividad y colaboración en una plataforma unificada y modular, fácil de usar y gestionar.

• Para empezar, vamos a ver que hemos preparado esta máquina virtual con Ubuntu Server 26.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 nextcloud en nuestra zona externa, ya que este servicio lo vamos a publicar al exterior, va a apuntar a www y este a su vez apunta a la máquina docker dónde tenemos instalado un Nginx Proxy Manager para los accesos externos:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de MariaDB y Nextcloud:
• sudo mkdir -p /opt/docker/nextcloud/nextclouddb/data
• sudo mkdir -p /opt/docker/nextcloud/nextclouddb/config
• sudo mkdir -p /opt/docker/nextcloud/nextcloudapp/html
• sudo chmod -R 755 /opt/docker/nextcloud/nextclouddb
• sudo chmod -R 755 /opt/docker/nextcloud/nextcloudapp

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.2.0/24 –gateway 172.25.2.1 -d bridge nextcloud-net, con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect nextcloud-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en cd /opt/docker/nextcloud/nextclouddb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=clave_muy_segura_root_db
• MYSQL_DATABASE=nextclouddb
• MYSQL_USER=nextclouduser
• MYSQL_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

nextcloud-db:

image: mariadb:12.2

container_name: nextcloud-db

restart: unless-stopped

env_file: .env

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/nextcloud/nextclouddb/data:/var/lib/mysql

– /opt/docker/nextcloud/nextclouddb/config:/etc/mysql/conf.d:ro

networks:

– nextcloud-net

networks:

nextcloud-net:

name: nextcloud-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de nextcloud app, para ello, nos situamos en cd /opt/docker/nextcloud/nextcloudapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

MYSQL_USER=nextclouduser

MYSQL_PASSWORD=clave_muy_segura_db

MYSQL_DATABASE=nextclouddb

NEXTCLOUD_ADMIN_USER=admnextcloud

NEXTCLOUD_ADMIN_PASSWORD=clave_muy_segura_useradmin_nextcloud

NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.ragasyssistemas.com

• Nos creamos el fichero docker-compose.yaml para el contenedor de wordpress-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

nextcloud-app:

image: nextcloud:33-apache

container_name: nextcloud-app

restart: unless-stopped

#   ports:

#     – «8080:80»

env_file: .env

environment:

– MYSQL_HOST=nextcloud-db:3306

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– NEXTCLOUD_ADMIN_USER=${NEXTCLOUD_ADMIN_USER}

– NEXTCLOUD_ADMIN_PASSWORD=${NEXTCLOUD_ADMIN_PASSWORD}

– NEXTCLOUD_TRUSTED_DOMAINS=${NEXTCLOUD_TRUSTED_DOMAINS}

– TRUSTED_PROXIES=172.25.1.0/24 # Subred de Nginx Proxy Manager External

– OVERWRITEPROTOCOL=https

volumes:

– /opt/docker/nextcloud/nextcloudapp/html:/var/www/html

networks:

– nextcloud-net    # Para comunicar con la DB

– npmdmz-net       # Para comunicar con Nginx Proxy Manager External

networks:

nextcloud-net:

external: true

npmdmz-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/nextclouddb/.env
• sudo chmod 600 /opt/docker/nextlcloud/nextcloudapp/.env

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/nextcloud/nextclouddb/.env
• sudo chmod 600 /opt/docker/nextlcloud/nextcloudapp/.env

• Iniciamos el contenedor de nextcloud-app, cd /opt/docker/nextcloud/nextcloudapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para wordpress.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: nextcloud.ragasyssistemas.com
• Esquema: http
• Nombre de Host/IP de reenvío: nextcloud-app
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos, ya tenemos acceso a nuestro nextcloud a través de nuestro proxy inverso con Nginx Proxy Manager:

Saludos y espero que os resulte de ayuda

La entrada Desplegar Nextcloud con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar Drupal con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de PostgreSQL para la base de datos que vamos a utilizar y el otro el propio de Drupal con la aplicación, este servicio irá desplegado, sobre otra máquina distinta dónde está desplegado nuestro docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

• 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 drupal apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de PostgreSQL y Drupal:
• sudo mkdir -p /opt/docker/drupal/drupaldb/data
• sudo mkdir -p /opt/docker/drupal/drupalapp/modules
• sudo mkdir -p /opt/docker/drupal/drupalapp/profiles
• sudo mkdir -p /opt/docker/drupal/drupalapp/themes
• sudo mkdir -p /opt/docker/drupal/drupalapp/sites
• sudo chmod -R 755 /opt/docker/drupal/drupaldb
• sudo chmod -R 755 /opt/docker/drupal/drupalapp
• sudo chown 33:33 /opt/docker/drupal/drupalapp/sites
• sudo chmod 775 /opt/docker/drupal/drupalapp/sites

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.2.0/24 –gateway 172.25.2.1 -d bridge drupal-net con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect drupal-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de PostgreSQL, para ello, nos situamos en cd /opt/docker/drupal/drupaldb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• POSTGRES_DB=drupaldb
• POSTGRES_USER=drupaluser
• POSTGRES_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de PostgraSQL en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

drupal-db:

image: postgres:16.6

container_name: drupal-db

restart: unless-stopped

env_file: .env

volumes:

– /opt/docker/drupal/drupaldb/data:/var/lib/postgresql/data

networks:

– drupal-net

networks:

drupal-net:

name: drupal-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de drupal app, para ello, nos situamos en cd /opt/docker/drupal/drupalapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

DRUPAL_DB_HOST=drupal-db

DRUPAL_DB_PORT=5432

DRUPAL_DB_NAME=drupaldb

DRUPAL_DB_USER=drupaluser

DRUPAL_DB_PASSWORD=clave_muy_segura_db

DRUPAL_DB_DRIVER=pgsql

• Nos creamos el fichero docker-compose.yaml para el contenedor de drupal-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

drupal-app:

image: drupal:10-apache

container_name: drupal-app

restart: unless-stopped

ports:

– 8081:80

entrypoint:

– /bin/sh

– -c

– |

# 1. Aseguramos que existan las carpetas base en el volumen

echo «Creando estructura de directorios…»

mkdir -p /var/www/html/sites/default/files/translations

# 2. Si NO existe default.settings.php en el volumen, lo traemos del backup interno de Drupal

# Nota: Las imágenes oficiales de Drupal guardan una copia en /opt/drupal/web/sites…

# pero para asegurar, lo creamos si no existe.

if [ ! -f /var/www/html/sites/default/default.settings.php ]; then

echo «Restaurando default.settings.php…»

# Intentamos copiarlo de la ubicación de la imagen si está disponible

cp /opt/drupal/web/sites/default/default.settings.php /var/www/html/sites/default/default.settings.php 2>/dev/null || touch /var/www/html/sites/default/default.settings.php

fi

# 3. Si no hay settings.php, lo creamos

if [ ! -f /var/www/html/sites/default/settings.php ]; then

echo «Creando settings.php…»

cp /var/www/html/sites/default/default.settings.php /var/www/html/sites/default/settings.php

fi

# 4. Permisos correctos para el usuario 33 (www-data)

echo «Aplicando permisos…»

chown -R 33:33 /var/www/html/sites

chmod -R 775 /var/www/html/sites/default/files

# 5. Arrancar Apache

exec apache2-foreground

env_file: .env

environment:

– DRUPAL_DATABASE_HOST=${DRUPAL_DB_HOST}

– DRUPAL_DATABASE_NAME=${DRUPAL_DB_NAME}

– DRUPAL_DATABASE_USER=${DRUPAL_DB_USER}

– DRUPAL_DATABASE_PASSWORD=${DRUPAL_DB_PASSWORD}

– DRUPAL_DATABASE_DRIVER=${DRUPAL_DB_DRIVER}

volumes:

– /opt/docker/drupal/drupalapp/modules:/var/www/html/modules

– /opt/docker/drupal/drupalapp/profiles:/var/www/html/profiles

– /opt/docker/drupal/drupalapp/themes:/var/www/html/themes

– /opt/docker/drupal/drupalapp/sites:/var/www/html/sites

networks:

– drupal-net

networks:

drupal-net:

external: true

• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/drupal/druapldb/.env
• sudo chmod 600 /opt/docker/drupal/drupalapp/.env

• Ahora, iniciamos primero el contenedor de PostgreSQL, cd /opt/docker/drupal/drupaldb/, sudo docker compose up -d:

• Iniciamos el contenedor de drupal-app, cd /opt/docker/drupal/drupalapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para Drupal.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: 192.168.14.17 IP máquina Docker02
• Puerto: 8081
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro drupal a través de nuestro proxy inverso con Nginx Proxy Manager, ahora nos va a pedir lo típico tras el primer acceso.
• Escogemos el idioma:

• Elegimos el perfil:

• Configuramos el acceso a la base de datos:

• Comienza a instalar Drupal:

• Configuración de traducciones:

• Configuramos nuestro sitio de drupal:

• Termina las traducciones:

• Iniciamos sesión en nuestro portal de drupal:

• Ya estamos listos para empezar a publicar:

Saludos y espero que os sea de ayuda

La entrada Desplegar Drupal con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como desplegar wordpress con Docker, desplegaremos dos contenedores Docker para este servicio, uno de ellos será el de MariaDB para la base de datos que vamos a utilizar y el otro el propio de WordPress con la aplicación, este servicio irá desplegado, sobre la misma máquina dónde ya desplegamos un docker con Nginx Proxy Manager, que será el que utilicemos para los certificados SSL.

• 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 wordpress apuntando a la máquina que tiene instalado el Docker con el Nginx Proxy Manager, ya que vamos a utilizar nuestro proxy inverso:

• Verificamos las versiones de Docker instaladas, docker –version, docker compose version:

• Ahora vamos a crear la estructura de directorios y permisos para los contenedores de MariaDB y WordPress:
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/data
• sudo mkdir -p /opt/docker/wprgs/wprgsdb/config
• sudo mkdir -p /opt/docker/wprgs/wprgsapp/config
• sudo chmod -R 755 /opt/docker/wprgs/wprgsdb
• sudo chmod -R 755 /opt/docker/wprgs/wprgsapp

• Ahora creamos una red personalizada para nuestro proyecto, sudo docker network create —subnet 172.25.3.0/24 –gateway 172.25.3.1 -d bridge wprgs-net, con sudo docker network ls vemos la redes que tenemos configuradas y con sudo docker network inspect wprgs-net, vemos la configuración de la red que hemos creado:

• Ahora vamos a crearnos los ficheros .env para no dejar credenciales en texto plano en los ficheros docker-compose.yaml que crearemos posteriormente, utilizando para ello variables.
• Empezaremos con el fichero .env para el contenedor de MariaDB, para ello, nos situamos en cd /opt/docker/wprgs/wprgsdb, y ejecutamos sudo nano .env:

• Y así definimos el fichero:
• MYSQL_ROOT_PASSWORD=clave_muy_segura_root_db
• MYSQL_DATABASE=wprgsdb
• MYSQL_USER=wprgsuser
• MYSQL_PASSWORD=clave_muy_segura_db

• Nos creamos el fichero docker-compose.yaml para el contenedor de MariaDB en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-db:

image: mariadb:12.2

container_name: wprgs-db

restart: unless-stopped

env_file: .env

environment:

– MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

– MYSQL_DATABASE=${MYSQL_DATABASE}

– MYSQL_USER=${MYSQL_USER}

– MYSQL_PASSWORD=${MYSQL_PASSWORD}

volumes:

– /opt/docker/wprgs/wprgsdb/data:/var/lib/mysql

– /opt/docker/wprgs/wprgsdb/config:/etc/mysql/conf.d:ro

networks:

– wprgs-net

networks:

wprgs-net:

name: wprgs-net

external: true

• Aquí vemos los ficheros creados:

• Seguimos con el fichero .env para el contenedor de wordpress app, para ello, nos situamos en cd /opt/docker/wprgs/wprgsapp, y ejecutamos sudo nano .env:

• Y así definimos el fichero:

WORDPRESS_DB_USER=wprgsuser

WORDPRESS_DB_PASS=clave_muy_segura_db

WORDPRESS_DB_NAME=wprgsdb

• Nos creamos el fichero docker-compose.yaml para el contenedor de wordpress-app en la misma ubicación, sudo nano docker-compose.yaml:

• Este sería el contenido del fichero:

services:

wprgs-app:

image: wordpress:6.9.4-php8.5-apache

container_name: wprgs-app

restart: unless-stopped

ports:

– «8081:80»

env_file: .env

environment:

– WORDPRESS_DB_HOST=wprgs-db:3306

– WORDPRESS_DB_USER=${WORDPRESS_DB_USER}

– WORDPRESS_DB_PASSWORD=${WORDPRESS_DB_PASS}

– WORDPRESS_DB_NAME=${WORDPRESS_DB_NAME}

– WORDPRESS_CONFIG_EXTRA=define(‘WP_HOME’,’https://wprgs.ragasys.net’); define(‘WP_SITEURL’,’https://wprgs.ragasys.net’); if (isset($$_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $$_SERVER[‘HTTP_X_FORWARDED_PROTO’] === ‘https’) { $$_SERVER[‘HTTPS’] = ‘on’; }

volumes:

– /opt/docker/wprgs/wprgsapp/config:/var/www/html

networks:

– wprgs-net  # Para comunicar con la DB

– npm-net    # Para comunicar con Nginx Proxy Manager

networks:

wprgs-net:

external: true

npm-net:

external: true

• Aquí debemos tener en cuenta, que la línea de los puertos 8081:80, la hemos dejado solo para verificar que el servicio se levanta en esos puertos por HTTP, una vez que configuremos nuestro Nginx Proxy Manager para el acceso por HTTPS con los certificados de Let’s Encrypt esta línea la podemos quitar o comentar, y con respecto a la variable WORDPRESS_CONFIG_EXTRA, es para indicarle al wordpress que está detrás de un proxy, también podemos ver que se conecta con la red de Nginx Proxy Manager npm-net, ya qu el acceso será a través de nuesro proxy inverso.
• Aquí vemos los ficheros creados:

• Protegemos los archivos .env aplicando estos permisos:
• sudo chmod 600 /opt/docker/wprgs/wprgsdb/.env
• sudo chmod 600 /opt/docker/wprgs/wprgapp/.env

• Ahora, iniciamos primero el contenedor de MariaDB, cd /opt/docker/wprgs/wprgsdb/, sudo docker compose up -d:

• Iniciamos el contenedor de wprgs-app, cd /opt/docker/wprgs/wprgsapp/, sudo docker compose up -d:

• Aquí vemos los contenedores levantados, sudo docker ps -a:

• Ahora accedemos a nuestro portal de Nginx Proxy Manager para crear el host para wordpress.
• Accedemos a Hosts > Hosts Proxy:

• Añadir Host Proxy:

• En la pestaña Detalles:
• Nombres de Dominio: ragasys.net
• Esquema: http
• Nombre de Host/IP de reenvío: wprgs-app
• Puerto: 80
• Bloquear Exploits Comunes
• Soporte de Websockets
• En la pestaña SSL:
• Seleccionamos el Certificado SSL que nos interese
• Marcamos Forzar SSL
• Guardar

• Aquí vemos el host creado y conectado:

• Y como vemos ya tenemos acceso a nuestro wordpress a través de nuestro proxy inverso con Nginx Proxy Manager, ahora nos va a pedir lo típico tras el primer acceso:

• Introducimos las credenciales y ya estamos dentro de nuestro wordpress, listo para empezar a publicar:

Saludos y espero que os resulte de ayuda

La entrada Desplegar WordPress con Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver de forma muy resumida las redes en docker, redes que se crean por defecto, redes que vamos a crear nosotros de manera simple y otras que crearemos algo más complejas y personalizadas, inspección de redes, eliminación de redes, etc…

• Cuando instalamos docker en nuestra máquina si le hacemos un ip a vemos que nos ha creado la interface de red docker0:

• Si hacemos un sudo docker network ls podemos listar todas las redes que docker nos crea por defecto:

• Si le hacemos un sudo docker network inspect bridge, podemos ver, que la red por defecto bridge tiene el rango de red 172.17.0.0/16 y gateway 172.17.0.1, si añadimos contenedores docker en esta red, les va a ir asignado las IPs que vaya teniendo libres de menor a mayor:

• Con sudodocker network create test1-net, nos vamos a crear una red de manera simple y sencilla:

• Aquí vemos la red creada:

• Con sudo docker network inspect test1-net, podemos ver, la configuración de esta red, y vemos que le asigna la red correlativa a la red por defecto de bridge, red 172.18.0.0/16 y gateway 172.18.0.1:

• Ahora vamos a crear otra red indicándole el rango que va a utilizar, el gateway, el driver (bridge) y el nombre de la red, para ello, ejecutamos sudo docker network create —subnet 10.10.10.0/24 –gateway 10.10.10.1 -d bridge npm-net:

• Aquí vemos la red creada:

• Con sudo docker network inspect npm-net, podemos ver, la configuración de esta red, y vemos que le asigna todo lo que le hemos indicado en el comando:

• Ahora, tenemos este docker-compose.yaml, para desplegar un contenedor Nginx Proxy Manager, y vamos a utilizar la red npm-net que hemos creado de manera personalizada con los parámetros que nos han interesado:

• Con sudo docker compose up -d levantamos el contenedor de Nginx Proxy Manager y con sudo docker ps -a vemos que ya lo tenemos levantado:

• Ahora si volvemos a ejecutar sudo docker network inspect npm-net, podemos ver, que el contenedor de Nginx Proxy Manager está utilizando la red personalizada que hemos creado anteriormente:

• Aquí tenemos nuestra aplicación levantada:

Saludos y espero que os sea de ayuda

La entrada Redes en Docker se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar Veeam Backup & Replication v13.0.1.1071 a la nueva versión 13.0.1.2067, 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.1071:

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

• Aquí tenemos ya, la nueva ISO v13.0.1.2067 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.2067, ha finalizado correctamente:

Saludos y espero que os sea de ayuda

La entrada Actualizar Veeam Backup & Replication v13.0.1.1071 a v13.0.1.2067 se publicó primero en RAGASYS SISTEMAS.

En este post veremos cómo actualizar un host ESXi versión VMware vSphere 8.0 Update 3h a la versión 8.0 Update 3i 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 25067014:

• 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 3i build 25205845:

• 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.0U3i-25205845-depot.zip:

• Para realizar el upgrade ejecutamos el comando esxcli software profile update -p ESXi-8.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-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ón 8.0 Update 3i Build 25205845:

• * NOTA a tener en cuenta esxcli software profile update -p ESXi-8.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip –no-hardware-warning
• ESXi-8.0U3i-25205845-standard nombre del perfil que contiene la versión y el número de compilación
• VMware-ESXi-8.0U3i-25205845-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.0U3i-25205845-standard -d /vmfs/volumes/SATA03NASRGS/VMware-ESXi-8.0U3i-25205845-depot.zip

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

Saludos y espero que os resulte de ayuda

La entrada Actualizar VMware vSphere ESXi 8.0 Update 3h a 8.0 Update 3i con ESXCLI se publicó primero en RAGASYS SISTEMAS.

En este post vamos a ver como actualizar nuestro vCenter Server Appliance a la última release liberada por VMware, la 8.0 Update 3i build 25197330, del 2 de marzo de 2026.

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

• VMware vCenter Server 8.0 Update 3i 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.00700 build 25092719:

• Sobre las opciones del menú nos vamos a Actualizar y Comprobamos actualizaciones, como podemos ver, tenemos disponible la release 8.0 Update 3i, 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 3i build 25197330:

• 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 3i build 25197330:

Saludos y espero que os sea de ayuda

La entrada Actualizar vCenter Server Appliance 8.0 Update 3h a 8.0 Update 3i se publicó primero en RAGASYS SISTEMAS.