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 vamos a ver como descargar e instalar la consola de Windows para Veeam Backup & Replication versión 13, ya que como vimos en el post anterior, a la consola web todavía le faltan muchas de las funcionalidades que tenemos en esta consola Windows.

• Para descargarnos la consola Windows de Veeam Backup & Repication versión 13, accedemos a la consola web, y clicamos sobre el enlace, Download Windows-based backup console for full experience:

• Como podemos ver, aquí la tenemos descargada:

• Procedemos con la instalación, comienza a extraer los paquetes:

• Nos indica que necesita instalar Microsoft .NET 8.0.17, Aceptar:

• Aceptamos el EULA:

• Comienza chequeando el sistema:

• Procedemos a instalar:

• Como podemos ver, la consola de Windows para Veeam Backup & Replication versión 13, se ha instalado correctamente:

• Nos abrimos la nueva consola Windows, especificamos el servidor de Veeam y conectamos:

• Validamos el certificado SSL:

• Introducimos las credenciales e iniciamos sesión:

• Aquí tendríamos la nueva consola Windows para Veeam Backup & Replication versión 13:

• La administración y configuración de Veeam Backup & Replication sería exactamente igual a como lo hemos estado haciendo siempre.

Saludos y espero que os sea de ayuda

En este post veremos cómo migrar máquinas virtuales de Hyper-V a Proxmox VE 9.0.

• Esta será la máquina virtual, que vamos a migrar de Hyper-V a Proxmox VE 9.0:

• Para empezar, copiamos el disco de la máquina virtual que queremos migrar a otro equipo desde el que tenemos acceso al hypervisor de proxmox:

• Una vez que tenemos copiado el disco, vamos a importarlo a nuestro proxmox con el comando scp E:\UBUNTU1804.vhdx root@proxmoxlab11.ragasys.net:/mnt/pve/ISO:

• Ahora nos abrimos una consola en nuestro proxmox y accedemos al directorio en el que hemos copiado el disco vhdx de Hyper-V:

• Con el comando qemu-img convert -p -f vhdx -O qcow2 UBUNTU1804.vhdx UBUNTU1804.qcow2, vamos a convertir el disco vhdx a qcow2 que es el formato que utiliza proxmox:

• Ahora nos creamos una máquina virtual sin disco:

• Ahora con este comando, le vamos a agregar el disco qcow2 a la máquina que hemos creado, qm importdisk 102 qcow2 DTS01VMCT:

• Como vemos se ha importado correctamente:

• Si accedemos al datastore, vemos que ya nos aparece el disco:

• Si accedemos al Hardware de la máquina virtual, vemos que ya nos aparece el disco virtual que hemos importado, pero nos aparece sin usar:

• Para añadirlo, lo editamos y damos a Agregar:

• Como vemos ya forma parte de la máquina virtual:

• Iniciamos la máquina virtual:

• Y aquí tenemos nuestra máquina Ubuntu migrada de Hyper-V a Proxmox funcionando y operativa:

Saludos y espero que os sea de ayuda

En este post veremos cómo desplegar una máquina virtual Windows Server 2025 sobre nuestro nodo Proxmox VE 9.0.

• Antes de empezar, sobre el datastore para las imágenes ISO, hemos cargado las siguientes imágenes ISO, para este despliegue de máquina virtual Windows vamos a utilizar las ISOs de Win_Server_2025 y virtio-win-0.1.285, la primera para el despliegue del sistema operativo y la segunda para los drivers que necesitaremos en las configuraciones que vamos a realizar, como pueden ser los tipos de controladora de discos o interfaces de red:

• Clicamos sobre, Crear VM:

• Sobre General, le indicamos el nodo, un ID, nombre y una etiqueta, Siguiente:

• Sobre SO, le indicamos la imagen ISO desde la que vamos a instalar el sistema operativo, el tipo de sistema operativo y la versión y agregamos los drivers para VirtIO, que lo podemos descargar desde su web oficial, Siguiente:

• Sobre Sistema, le indicamos los parámetros que nos interesen para nuestra infraestructura, Siguiente:

• Sobre Discos, le indicamos el Bus/Dispositivo, Controlador SCSI, Almacenamiento, Tamaño de disco y la Caché como Write back, Siguiente:

• Sobre CPU, le indicamos los parámetros que nos interesen para nuestra máquina, Siguiente:

• Sobre Memoria, le asignamos la cantidad que nos interesen para nuestra máquina, Siguiente:

• Sobre Red, le indicamos que utilice el bridge que creamos anteriormente y el Modelo, Siguiente:

• Sobre Confirmar, nos muestra un resumen de todo lo que hemos configurado, Finalizar:

• Como podemos ver, aquí tenemos nuestra máquina virtual creada:

• Para empezar con la instalación del sistema operativo, accedemos a las Opciones de la máquina virtual, y en Orden de arranque, le indicamos que el primero será el que contiene la ISO de Windows Server 2025:

• Sobre la Consola de la máquina virtual la iniciamos:

• Y a partir de aquí, ya sería una instalación típica de Windows Server:

• Algo a tener en cuenta durante la instalación, es que el disco de sistema sobre la controladora SCSI que hemos creado, no lo reconoce y necesitamos los drives VirtIO para que lo reconozca, damos a Load Driver:

• Buscamos el driver para el sistema operativo que vamos a instalar en la imagen ISO de VirtIO que configuramos al crear la máquina, Instalar:

• Una vez instalado el driver, ya vemos que detecta el disco sobre la controladora SCSI:

• Debemos cargar también el driver para la interface de red, Load Driver:

• Buscamos el driver para el sistema operativo que vamos a instalar en la imagen ISO de VirtIO que configuramos al crear la máquina, Instalar:

• A partir de aquí, realizamos una instalación típica de Windows:

• Como podemos ver, ya tenemos nuestra máquina virtual con Windows Server 2025 desplegada sobre Proxmox VE 9.0:

• Instalamos los drivers de VirtIO al completo:

• Finalizamos y reiniciamos:

• Una vez que hemos reiniciado la máquina, accedemos de nuevo a la ISO de los drivers de VirtIO, y dentro de la carpeta guest-agent, instalamos qemu-ga-x86_64, así mejoramos la integración con Proxmox:

• Aquí podemos ver, que se ha instalado todo correctamente:

• Si nos situamos sobre la máquina virtual > Resumen > IPs > Más, podemos ver, que ya nos muestra la información de las Guest Agent:

• Si queremos proteger nuestras máquinas virtuales de eliminaciones accidentales, podemos protegerlas, para ello, accedemos a la máquina virtual > Opciones >Protección y Activar:

Saludos y espero que os sea de ayuda

• En este post vamos a ver como auditar los accesos a los a los objetos en nuestros equipos unidos a un dominio de Active Directory.
• Lo primero que debemos hacer es crearnos una GPO para habilitar la auditoría de objetos en nuestro Active Directory, para ello nos abrimos la consola de Administración de directivas de grupo y sobre Objetos de directivas de grupo le indicamos que queremos crearnos una nueva GPO:

• Le damos un nombre a la GPO y la editamos:

• Accedemos a Configuración del equipo > Dircetivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría y configuramos-habilitamos la directiva Auditar el acceso a objetos:

• Ahora, esta configuración es opcional, pero muy recomendable, vamos a habilitar la auditoría avanzada, para ello, accedemos a Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Configuración de directiva avanzada de auditoría > Directiva de auditoría detallada > Acceso a objetos y configuramos-habilitamos las directivas Auditar almacenamiento extraíble y Auditar sistema de archivos:

• Una vez editada, aquí tenemos la configuración para habilitar la auditoría a objetos en nuestros equipos del AD:

• Aunque la GPO activa la auditoría, nosotros necesitamos configurar en cada equipo o mediante script qué carpetas/archivos serán auditados, vamos a ver un ejemplo:
• Para hacerlo de forma manual en una carpeta de cualquiera de nuestros equipos del dominio, debemos dar clic derecho sobre la carpeta > Propiedades > Pestaña Seguridad > Opciones avanzadas > Auditoría y agregamos:
• Usuario: Todos
• Tipo: Todo
• Se aplica a: Esta carpeta, subcarpetas y archivos
• Permisos avanzados: Crear archivos/escribir datos, Crear carpetas/anexar datos, Eliminar subcarpetas y archivos, Eliminar.

• Esto puede automatizarse mediante scripts de PowerShell, hemos creado este script, llamado auditoriausuarios.ps1, que lo podemos descargar desde este enlace, dónde vamos a auditar las carpetas del escritorio, documentos y descargas de todos los usuarios:

• Nos creamos este script en .bat, para cuando configuremos la GPO, invoquemos desde este script, al script de PowerShell:

• Ahora accedemos a cualquiera de nuestros controladores de dominio y copiamos estos dos scripts en esta ruta:

• En la consola de Administración de directivas de grupo, volvemos a editar la GPO que creamos y configuramos para la auditoria de objetos:

• Accedemos a Configuración del equipo > Directivas > Configuración de Windows > Scripts (Inicio o apagado) > Inicio > Scripts > Agregar > Examinar y añadimos el script .bat, Aceptar:

• Y así nos quedaría la GPO, completamente configurada:

• Ahora esta GPO, la vamos a vincular sobre la OU Equipos, para que empiece a auditar el acceso a los objetos:

• Como podemos ver, aquí la tenemos vinculada:

• Sobre uno de nuestros equipos del dominio ejecutamos un gpupdate /force para aplicar las nuevas directivas:

• Una vez aplicada la GPO, vamos que en las carpetas han cambiado sus permisos de auditoría:

• Con todo esto ya tenemos configurado las auditorías de los acceso a objetos en los equipos de nuestro Active Directory.
• Los registros de auditoría quedan todos guardados en el Visor de eventos de los equipos de los usuarios, en los Registros de Windows > Seguridad:

• Ahora vamos a crear y eliminar algunos ficheros de uno de nuestros equipos y veremos en el visor de eventos que usuario a creado y eliminado estos ficheros.
• Creamos estos dos ficheros:

• Eliminamos estos dos ficheros:

• Con el ID de evento 4663 vemos como se crean los ficheros:

• Y con el ID de evento 4659 vemos como se eliminan los ficheros:

Saludos y espero que os resulte de ayuda

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

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

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

• Aceptamos las condiciones y descargamos:

• Como podemos ver aquí lo tenemos descargado:

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

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

• Aquí vemos como comienza la actualización:

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

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

• Comienza a sincronizar:

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

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

Saludos y espero que os resulte de ayuda

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

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

Podemos usar el Administrador de actualizaciones de Azure para:

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

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

– Aplicar actualizaciones en tiempo real.

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

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

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

– Que están disponibles en Actualizaciones de Microsoft

– Que están disponibles en los paquetes de Linux

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

• Aplicación de revisiones a diversos recursos

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

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

– Máquinas de VMware

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

– Clústeres de Azure Local

– Aplicar revisiones entre suscripciones

Fuente: Microsoft Learn

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

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

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

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

• Como vemos, ya ha cambiado:

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

• Damos a Buscar actualizaciones:

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

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

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

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

• Damos a Agregar máquinas:

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

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

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

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

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

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

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

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

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

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

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

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

• Sobre Recursos, seleccionamos la máquina Windows:

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

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

• Damos a Revisar y crear:

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

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

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

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

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

• Sobre Recursos, seleccionamos la máquina Linux:

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

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

• Damos a Revisar y crear:

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

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

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

Saludos y espero que os sea de ayuda

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

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

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

Fuente: Microsoft Learn

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

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

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

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

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

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

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

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

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

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

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

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

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

• Y nos quedaría de la siguiente manera:

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

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

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

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

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

• Ahora guardamos los cambios:

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

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

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

Saludos y espero que os sea de ayuda

En este post vamos a ver como migrar controladores de dominio con Windows Server 2022 a Windows Server 2025.

En este laboratorio, tenemos dos controladores de dominio con Windows Server 2022, y los vamos a migrar a Windows Server 2025.

• Como podemos ver, tenemos dos controladores de dominio en nuestra infraestructura con el sistema operativo MS Windows Server 2022 Standard:

• Los roles o funciones que tienen estos servidores son los siguientes, “Servicios de dominio de Active Directory y DNS”:

• Ahora debemos desplegar dos nuevos servidores con el sistema operativo MS Windows Server 2025 Standard, los actualizamos y los configuramos como un controlador de dominio adicional:

• Empezamos la configuración de nuestros controladores de dominio adicionales asignándole un nombre y una dirección IP estática, como DNS primario le asignamos la dirección IP de uno de los controladores de dominio y como DNS secundario la dirección IP del otro controlador de dominio, más tarde, le configuraremos su propia dirección IP como DNS:

• Ahora agregamos estos equipos como un miembro más del dominio:

• Le proporcionamos las credenciales del Administrador del dominio y reiniciamos el equipo:

• Como podemos ver se ha agregado correctamente, reiniciamos el servidor:

• Para el otro equipo hacemos las mismas operaciones.
• Ahora nos vamos a la consola de Usuarios y equipos de Active Directory en el controlador de dominio principal y cómo podemos ver, estos equipos ya pertenecen al dominio ragasys.local:

• Ahora iniciamos sesión en DCRGS03 (Servidor que hemos terminado de unir al dominio) como Administrador del dominio:

• En el Administrador del servidor agregamos roles y características:

• Se nos abre el asistente típico para desplegar los roles y características, hacemos clic en siguiente:

• Sobre Tipo de instalación, elegimos la opción, Instalación basada en características o roles:

• Seleccionamos nuestro servidor dcrgs03:

• Sobre Roles de servidor, marcamos la opción Servicios de dominio de Active Directory:

• Agregamos las características:

• Clic en siguiente:

• Todas las características que requiere nuestro controlador de dominio de Active Directory se seleccionan por defecto por lo que hacemos clic en siguiente:

• Información sobre Active Directory :

• Sobre Confirmación, iniciamos el despliegue del rol Servicios de dominio de Active Directory, marcamos que reinicie automáticamente en caso necesario y clic sobre Instalar:

• Comienza el despliegue de los Servicios de dominio de Active Directory:

• Una vez finalizada la instalación cerramos el asistente:

• Sobre el Administrador del servidor promovemos este servidor a controlador de dominio:

• Sobre Configuración de implementación, marcamos la opción Agregar un controlador de dominio a un dominio existente, seleccionamos nuestro nombre de dominio y le proporcionamos las credenciales del Administrador del dominio, clic en Siguiente:

• Sobre las Opciones del controlador de dominio, seleccionamos la función de DNS, ya que es un requisito imprescindible para Active Directory, también seleccionamos que sea Catálogo Global y luego introducimos una contraseña segura que será necesaria en caso de restauración de Active Directory:

• Sobre Opciones de DNS, la dejamos por defecto, ya que el DNS lo tenemos configurado sobre el controlador de dominio principal, por lo que el controlador de dominio adicional se va a configurar automáticamente con la misma configuración que el principal:

• En Opciones adicionales, le indicamos que replique desde cualquier controlador de dominio:

• Sobre Rutas de acceso las dejamos por defecto:

• Sobre Opciones de preparación, nos indica que para instalar este controlador de dominio el asistente debe realizar las operaciones de preparar el esquema y el bosque, y preparar el dominio:

• Sobre Revisar opciones, nos muestra un resumen de las configuraciones seleccionadas, clic en Siguiente:

• Sobre Comprobación de requisitos previos, nos muestra que todas las comprobaciones se realizaron correctamente, clic a Instalar:

• Sobre Instalación, podemos ver como comienza a instalar y configurar los Servicios de dominio de Active Directory, una vez instalados, el servidor se va a reiniciar automáticamente:

• Tras el reinicio, nos abrimos la consola de Usuarios y equipos de Active Directory, y cómo podemos ver, este equipo ya está como un Domain Controller más de nuestra infraestructura:

• Para el otro controlador de dominio DCRGS04, con Windows Server 2025 realizamos las mismas operaciones, y cómo podemos ver, este equipo está también, como un Domain Controller más de nuestra infraestructura:

• También podemos comprobarlo con el comando netdom query dc:

• Con el comando repadmin /showrepl, verificamos que nuestros nuevos controlador de dominio están replicando correctamente:

• Con el comando dcdiag /test:replications comprobamos la replicación y cualquier error de replicación entre los controladores de dominio:

• Con el comando dcdiag /test:connectivity comprobamos la conectividad y cualquier error de conexión entre los controladores de dominio:

• Con el comando dcdiag /test:DNS comprobamos que el DNS esté funcionando correctamente:

• Estas mismas pruebas de diagnóstico, las debemos de realizar sobre el controlador de domino principal y así nos aseguramos que nuestros controladores de dominio estén en perfecto estado.
• Una vez que tenemos agregados los dos controladores de dominio adicionales con sistema operativo MS Windows Server 2025, y por tanto, superior a MS Windows Server 2022, vamos a proceder a transferir los roles FSMO del controlador de dominio principal al adicional, así el nuevo controlador de dominio con el Server 2025 quedará como principal.
• Todos los dominios de Active Directory disponen de cinco roles FSMO (Flexible Single Master Operations), los roles FSMO son funciones específicas que realizan los controladores de dominio a nivel de bosque o de dominio:

• Sobre cualquiera de nuestros controladores de dominio vamos a ejecutar el siguiente comando netdom query fsmo para ver quien tiene asignados estos roles FSMO, y como podemos ver todos los roles los tiene asignados nuestro primer controlador de dominio con Windows Server 2022 (dcrgs01):

• Ahora lo que vamos a realizar será transferir los cinco roles FSMO a uno de los dos controladores de dominio adicionales con Windows Server 2025 (dcrgs03), convirtiéndolo así en el domain controller principal, para ello, utilizaremos Powershell.
• Para transferir los roles fsmo del controlador de dominio dcrgs01 al controlador de domino dcrgs03, ejecutamos el siguiente comando, Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator:

• Volvemos a ejecutar el comando netdom query fsmo, y cómo podemos ver, los roles fsmo ya los tiene asignados el dcrgs03:

• También podemos usar este otro comando Move-ADDirectoryServerOperationMasterRole -Identity «DCRGS03» -OperationMasterRole 0, 1, 2, 3, 4
• Cada número se corresponde con los roles fsmo:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

• Si los cinco roles FSMO no los transferimos de forma manual, el proceso de despromoción los transferirá de forma automática a cualquier Controlador de dominio disponible, a mí personalmente prefiero hacerlo de forma manual.
• Ahora accedemos a la configuración TCP/IPv4 de nuestros nuevos controladores de dominio recién desplegados y configuramos como DNS principal su propia dirección IP y como DNS secundario la dirección IP del controlador de dominio principal:

• Ahora ya podemos despromocionar como controlador de dominio los servidores con MS Windows Server 2022, para ello, vamos a realizar lo siguiente:
• Nos abrimos el Administrador del servidor y pinchamos sobre la opción Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Sobre Roles de servidor, desmarcamos el check “Servicios de dominio de Active Directory” y sobre el asistente que se nos abre hacemos clic en “Quitar características”:

• Se nos abre el siguiente asistente, que nos indica que tenemos que disminuir el nivel, por lo tanto, hacemos clic sobre “Disminuir el nivel de este controlador de dominio”:

• Se nos vuelve a abrir otro asistente, dónde verificamos que las credenciales sean las correctas, esta es la opción más importante del asistente, ya que al ser un controlador de dominio adicional o secundario NO aparece la opción de marcar el check “Último controlador de dominio en el dominio”, clic sobre “siguiente”:

• Marcamos el check “Continuar con la eliminación” y clic sobre siguiente:

• Introducimos la nueva contraseña para el administrador local, al eliminar el rol de controlador de dominio, la cuenta de usuario de administrador pasará a formar parte de los usuarios locales de la máquina, clic sobre “siguiente”:

• Revisamos y hacemos clic sobre “Disminuir nivel”, al finalizar la operación se reiniciará el servidor:

• Como podemos ver comienza el proceso de degradación de nuestro controlador de dominio:

• El sistema nos va a indicar que ha disminuido el nivel del controlador de dominio, y se va a reiniciar automáticamente.
• Para el otro controlador de dominio (dcrgs02) con MS Windows Server 2022, realizamos las mismas operaciones.
• Una vez que los equipos han reiniciado verificamos que los dos servidores con MS Windows Server 2022 ya no son controladores de dominio, en el Administrador del servidor nos vuelve a indicar con una advertencia “Promover este servidor a controlador de dominio”:

• Sobre la consola de Usuarios y equipos de Active Directory del Controlador de dominio principal, podemos ver como los Controladores de dominio con Windows Server 2022 han pasado a formar parte del dominio como un equipo más de éste:

• Para desinstalar los binarios de los Servicios de dominio de Active Directory, lo haremos a través del Administrador del Servidor > Administrar > Quitar roles y funciones:

• Se nos abre este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor y clic sobre siguiente:

• Desmarcamos el check, Servicios de dominio de Active Directory, y Quitar características:

• Desmarcamos el check, Servidor DNS, y Quitar características:

• Una vez desmarcados estos dos checks, damos clic a “siguiente”:

• Aquí no tocamos nada, clic sobre “siguiente”:

• Nos muestra un resumen de las opciones configuradas para eliminar, le indicamos que reinicie en caso necesario y procedemos a quitar:

• Comienza con la eliminación:

• Tras el reinicio podemos ver que la eliminación ha sido correcta:

• Todo se ha eliminado correctamente, en la bandera de las advertencias, ya NO nos avisa de la promoción de este servidor a Controlador de dominio, ya que todos los binarios han sido eliminados:

• Para el otro equipo Windows Server 2022 (dcrgs02) realizamos las mismas operaciones.
• Sobre el controlador de dominio principal (dcrgs03), en Sitios y servicios de Active Directory eliminamos los dos controladores de dominio antiguos:

• Para terminar ya sólo nos quedaría elevar los Niveles Funcionales a nivel de dominio y de bosque.
• Empezaremos elevando el Nivel Funcional del bosque, para ello, nos abrimos la herramienta Dominios y Confianzas de Active Directory:

• Como podemos observar, el Nivel Funcional del bosque se encuentra en Windows Server 2016, y lo vamos a Elevar a Windows Server 2025:

• Nos indica que este cambio afecta a todo el bosque, y que una vez que hayamos elevado el nivel funcioanl del bosque, ya no podremos revertirlo, Aceptar:

• Como podemos ver, el nivel funcional se aumentó correctamente, Aceptar:

• Ahora vamos a elevar el Nivel Funcional del dominio, para ello, nos abrimos la herramienta Usuarios y equipos de Active Directory:

• Automáticamente al elevar el Nivel Funcional del bosque se eleva también el del dominio, como podemos ver, el nivel funcional del dominio se encuentra en Windows Server 2025:

• Con la herramienta Centro de Administración de Active Directory tenemos opción a Elevar los Niveles Funcionales a nivel de bosque y de dominio:

• Para terminar, vamos a cambiarle las direcciones IP a los dos Controladores de dominio nuevos, y les vamos a dejar las IPs de los controladores de dominio antiguo:

• En la consola DNS nos debería de quedar de esta forma:

• Si en nuestra infraestructura, estábamos utilizando los nombres antiguos de los controladores de dominio en algún servicio (dcrgs01 y dcrgs02), nos vamos a crear estos registros del tipo CNAME en el DNS, para que estos servicios no se vean afectados:

• Con esto ya tendríamos migrado nuestros controladores de dominio de MS Windows Server 2022 a MS Windows Server 2025.

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo convertir la versión de evaluación MS Windows Server 2025 Standard a versión completa

• Para descargarnos la versión de evaluación de MS Windows Server 2025 Standard lo podemos hacer a través de esta URL:

• Nos registramos y procedemos a su descarga:

• Como podemos ver, ya la tenemos la ISO descargada:

• Instalamos el sistema operativo como una instalación típica de Windows y lo actualizamos con los últimos parches a través de Windows Update:

• Para empezar la conversión nos abrimos un Terminal como administrador:

• Convertir Windows Server 2025 Standard:
• DISM /Online /Set-Edition:ServerStandard /ProductKey:TVRH6-WHNXV-R9WG3-9XRFY-MY832 /AcceptEULA
• Convertir Windows Server 2025 Datacenter:
• DISM /Online /Set-Edition:ServerDatacenter /ProductKey:D764K-2NDRG-47T6Q-P8T8W-YP6DF /AcceptEULA
• Convertir Windows Server 2025 Versión Azure:
• DISM /Online /Set-Edition:ServerDatacenter /ProductKey:XGN3F-F394H-FD2MY-PP6FD-8MCRC /AcceptEULA
• Introduciendo el siguiente comando me va a decir que versión tengo instalada, como podemos ver es la versión Standard de evaluación, DISM /online /Get-CurrentEdition:

• Con el siguiente comando me va a decir a que versión o versiones puedo realizar la conversión, DISM /online /Get-TargetEditions:

• Una vez que tenemos nuestra key de licencia, donde vamos a utilizar las KMS proporcionadas por Microsoft, introducimos el siguiente comando para convertir la versión de evaluación en versión completa, DISM /Online /Set-Edition:ServerStandard /ProductKey:TVRH6-WHNXV-R9WG3-9XRFY-MY832 /AcceptEULA:

• Como podemos ver, comienza a realizar la conversión:

• Una vez que ha finalizado el proceso, nos pide que reiniciemos la máquina para que la operación se realice correctamente (Y):

• Una vez que hemos reiniciado podemos ver que nuestra máquina ya se encuentra con la versión completa de MS Windows Server 2025 Standard:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como instalar MS Windows 11 Pro 24H2 en VMware vSphere.

• Si intentamos instalar MS Windows 11 Pro 24H2 en nuestro host ESXi 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 instalar Windows 11 Pro 24H2 en nuestro ESXi, vamos a usar Rufus y crear un USB booteable.
• Necesitamos:
• Imagen ISO Windows 11 Pro 24H2.
• Última versión de Rufus.
• Pen Drive USB mínimo 8 GB

• Nos abrimos Rufus 4.6 y configuramos las opciones que nos vengan bien dependiendo del equipo o máquina virtual dónde vayamos a instalar Windows 11 Pro 24H2, en mi caso, seleccionamos el dispositivo USB, la imagen ISO de Windows 11 Pro 24H2, el esquema de partición GPT y el sistema de destino UEFI, clic a EMPEZAR:

• Marcamos los checks Eliminar el requisito de más de 4 GB de RAM, Arranque seguro y TPM 2.0, Eliminar el requisito de una cuenta de Microsoft en línea, clic OK:

• Comienza a crear el USB booteable:

• Como podemos ver, el proceso ha finalizado correctamente y ya tenemos el USB booteable con la ISO de Windows 11 Pro 24H2:

• Ahora vamos a instalar Windows 11 Pro 24H2 sobre una máquina virtual en un entorno de VMware vSphere, para ello, introducimos el USB booteable en el host ESXi y se lo configuramos a la máquina virtual dónde vamos a instalar el sistema operativo:

• Volvemos a editar la configuración de la máquina virtual, y sobre Opciones de máquina virtual > Opciones de arranque marcamos el check, Durante el próximo arranque, forzar el ingreso a la pantalla de configuración EFI:

• Iniciamos la máquina virtual y acedemos por consola, seleccionamos EFI USB Device:

• Ahora ya no nos va a dar el problema de que el equipo no cumple los requisitos mínimos del sistema para instalar esta versión de Windows, a partir de aquí es una instalación típica de Windows:

• Como podemos ver aquí tenemos nuestro Windows 11 Pro 24H2 Instalado como máquina virtual sobre VMware vSphere:

Saludos y espero que os sea de ayuda

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

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

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

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

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

• Sobre Etiquetas, podemos configurar las que nos interesen:

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

• Como podemos ver, se ha implementado correctamente:

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

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

Saludos y espero que os sea de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar las políticas de contraseñas granulares en nuestro Active Directory, estas políticas van a prevalecer sobre las políticas de contraseñas configuradas en las políticas de grupo (GPO) y las asignaremos a grupos de usuarios.

• Si accedemos a la consola de Administración de directivas de grupo de nuestro Active Directory, podemos ver que tenemos esta política configurada:

• Para configurar una política distinta de contraseña a un grupo de usuarios y que prevalezca sobre esta política, debemos de acceder a la consola, Centro de Adminsitración de Active Directory > Dominio > System > Password Settings Container > Nuevo > Configuración de contraseña:

• Configuramos la política de contraseña que nos interese, y le asignamos el grupo de usuarios al que le queremos aplicar esta política:

• Y aquí tenemos, nuestra política granular creada:

Saludos y espero que os resulte de ayuda

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

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

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

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

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

• Sobre Account Type, creamos una nueva cuenta:

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

• Copiamos el código y siguiente:

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

• Continuamos:

• Y nos indica que ya podemos cerrar la ventana:

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

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

• Sobre Summary, nos muestra un resumen y finalizamos:

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

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

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

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

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

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

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

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

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

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

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

• Sobre Tenant, le indicamos el inquilino:

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

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

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

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

• Aquí vemos el progreso del backup:

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

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

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

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

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

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

• Introducimos el código:

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

• Estos son los permisos que solicita, aceptamos:

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

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

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

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

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

• Confirmamos:

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

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

Saludos y espero que os resulte de ayuda

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

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

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

• Le indicamos que Sí:

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

• Lo confirmamos y le indicamos que Sí:

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

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

• Seleccionamos la interface de red y aceptamos:

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

• Y ya saben a migrar se ha dicho.

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un servidor DHCP Relay en un firewall Fortigate, este DHCP relay va a escuchar las peticiones DHCP que se producen en la red, y las va a encaminar hacia un servidor DHCP que se encuentra en otra red para que éste las atienda, el servidor DHCP dará una respuesta que enviará hacia el DHCP relay configurado en nuestro Fortigate, y éste la trasladará al cliente que hizo la petición.

• Para empezar, vamos a ver que tenemos configurado nuestro servidor DHCP con el ámbito de red que queremos asignar a nuestros equipos clientes, y estas serían las distintas configuraciones del ámbito:

• Ahora en nuestro firewall fortigate vamos a acceder a Red > Interfaces y editaremos la red dónde vamos a configurar nuestro servidor DHCP relay:

• Sobre la edición de la interface de red, vamos a habilitar el servidor DHCP y en Avanzado seleccionamos el modo Relay, tipo Regular y ponemos la IP del servidor DHCP dónde hemos configurado el ámbito para esta red, en este caso, he puesto dos servidores DHCP ya que en mi infraestructura tengo montado un failover cluster para este servicio con balaceo de carga 50%-50%:

• Como podemos ver, ya lo tenemos configurado:

• Ahora accedemos a una máquina cliente de nuestra infraestructura, y como podemos ver, ya se le está sirviendo el direccionamiento IP y las opciones del ámbito que hemos configurado, todo ello, a través del DHCP relay configurado en el fortigate:

• En nuestra consola del servidor DHCP, podemos ver la concesión de direcciones para esta red:

Saludos y espero que os sea de ayuda

En este post vamos a ver como deshabilitar la ejecución del símbolo de sistema a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > Impedir acceso al símbolo del sistema:

• Habilitamos la GPO, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar el símbolo del sistema:

• Si intentamos abrir un símbolo del sistema nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como deshabilitar la ejecución de PowerShell a través de una GPO en nuestro Active Directory.

• Accedemos a cualquiera de nuestros controladores de dominio, nos abrimos la consola de Administración de directivas de grupo > Objetos de directivas de grupo > Nuevo:

• Le asignamos un nombre y aceptamos:

• Clic derecho sobre la GPO y editamos:

• Accedemos a Configuración de usuario > Directivas > Plantillas administrativas > Sistema > No ejecutar aplicaciones de Windows especificadas:

• Habilitamos la GPO, sobre Lista de aplicaciones no permitidas damos a Mostrar y escribimos la lista que pueden ejecutar PowerShell, clic en Aceptar:

• Una vez creada la GPO, la vamos a vincular sobre la unidad organizativa que nos interese aplicarla:

• Como podemos ver, aquí la tenemos vinculada:

• Si accedemos al dominio con cualquiera de estos usuarios, no vamos a poder ejecutar PowerShell:

• Si intentamos abrir un Powershell nos va a saltar este mensaje de error:

Saludos y espero que os resulte de ayuda