Montando un controlador de dominio con Windows Server Core 2019 en Proxmox

Cuando monté mi laboratorio con Proxmox tenía una idea bastante clara: quería aprender, probar cosas y montar servicios que realmente me resultasen útiles.

Lo que no tenía tan claro era que, con el tiempo, ese pequeño servidor iba a acabar haciendo de todo.

Máquinas virtuales, contenedores, servicios, pruebas, Windows, Linux, Ansible… y cada vez que se me ocurre una idea nueva, hay que buscarle un hueco.

Mi Proxmox empieza estar al borde de un ataque de nervios. 😂

Y precisamente por eso, cuando llegó el momento de montar un controlador de dominio para el laboratorio, tenía claro que no quería añadir otro Windows Server con escritorio gráfico que estuviese consumiendo recursos simplemente para enseñarme un menú de inicio.

Así que decidí probar Windows Server Core 2019.

Sin escritorio.
Sin ventanas.
Sin menú de inicio.

Solo lo necesario para que el servidor haga su trabajo.

En este artículo vamos a instalar Windows Server Core 2019 en Proxmox y dejarlo preparado para convertirlo en el controlador de dominio de nuestro laboratorio.

Y aunque al principio pueda parecer un poco raro encontrarse con Windows y no tener dónde hacer clic, precisamente ahí está la gracia, y sobre todo para no caer en la tentación de usarlo para todo.

Porque si vamos a montar un laboratorio para aprender administración de sistemas, quizá también haya llegado el momento de dejar de darle al botón Siguiente, siguiente, siguiente. 😄

Así que vamos complicando este laboratorio poco a poco hasta que Proxmox pida la jubilación...

Paso 1 - Configuración inicial de Server Core

Antes de meternos en faena, quiero compartir un par de ideas que tuve cuando decidí montar este servidor.

• La primera es que Server Core no está pensado para ser un Windows de escritorio sin escritorio. 😄 Su objetivo es precisamente reducir al mínimo todo aquello que no sea necesario para que el servidor cumpla su función.

• La segunda es que, aunque al principio resulte extraño, administrar un servidor sin interfaz gráfica es una buena oportunidad para aprender otras formas de trabajar con Windows y, de paso, entender un poco mejor qué ocurre detrás de todos esos botones a los que estamos acostumbrados.

Dicho esto, vamos al lío.

A partir de aquí, la instalación es prácticamente la habitual de Windows Server: seleccionamos la edición Server Core, aceptamos la licencia, elegimos el disco de instalación y dejamos que Windows haga su trabajo.

reinicia, aparece una ventana negra... y ahí se acaba el Windows al que estamos acostumbrados😄

Bienvenidos a Server Core.

Cuando arranca por primera vez, nos pedirá la contraseña:

Una vez identificados, ponemos "sconfig" y le damos a intro.

Prácticamente vas a vivir aquí durante los primeros minutos de vida de nuestro servidor, ya que todo se gestiona con este menú:

1. Cambiar el nombre del servidor

Lo primero de todo vamos a cambiar el nombre, nada de WIN-4F7G8H2K9P; Vamos a ponerle algo que tenga sentido.

Por ejemplo: DC01 o el nombre que más prefieras para identificar al DC.

Entramos en sconfig, y escogemos la opción "(2) Nombre de equipo:" que es cambiar el nombre del equipo:

y escribimos el nombre que deseamos, en mi caso he puesto "ADCore1" y reiniciamos tras completar el cambio de nombre.

2. Configurar IP fija

Un controlador de dominio jamás debería depender de DHCP, más que nada para no tener sustos.

Por ejemplo, pondremos los siguientes datos:

• IP: 192.168.1.98
• Mascara: 255.255.255.0
• Gateway: 192.168.1.1

Desde la opción de red: (8) Network settings

Pulsamos luego en 1 y definimos nuestra configuración, en 1 porque solo tenemos una tarjeta de red:

Si seguimos las opciones, configuramos nuestra red del servidor, tras tenerlo configurado, reiniciaremos también:

* Con la opción 13, reiniciamos el equipo:

3. Configurar DNS

Ahora nos toca configurar los DNS, pondremos la IP del servidor como primario, Sí, a sí mismo, ya que cuando promocionemos a DC será también el servidor DNS y tendremos dos pájaros de un tiro.

En mi laboratorio he configurado temporalmente otro servidor DNS adicional basado en Pi-hole para determinadas pruebas.

4. Actualizar el servidor

Vale, y antes de continuar con la configuración, vamos a actualizar el Windows a tope, yo en mi caso he utilizado una MV, pero si usas un hierro, mira también de ponerle los últimos drivers al equipo.

1. sconfig
2. Pulsamos en la opción "(6) Download and Install Updates"

Pulsamos sobre la opción "a" de todas, y dejamos que se ponga al día nuestro Windows:

Y aprovecharía para tomar un café, ya que es posible que tarde un poquito en completarse.

5. Configurar la zona horaria

Parece una tontería, algo muy simple, hasta que Kerberos deja de funcionar, o los del Helpdesk no pueden planchar equipos porque la hora no esta correcta, las contraseñas caducan antes de tiempo, etc
He visto de todo por culpa de esto.

Para comprobarlo, abrimos un powershell y ponemos:

Get-Date y Get-TimeZone

Si la VM arranca con una fecha rara o con la zona horario de las China popular, ahora es el momento de arreglarlo.

6. Activar administración remota

Volvemos a entrar en "sconfig" y vamos habilitar la administración remota, que es lo que más nos interesa:

Escogeremos la opción (1) que es la más segura:



Aunque todavía no vamos a utilizar Ansible, es un buen momento para dejar preparado WinRM. Más adelante lo necesitaremos para administrar el servidor de forma remota desde PowerShell, Windows Admin Center o Ansible.

Y ahora podemos proceder a promover el DC sin problema.

Promover el DC.

Instalar el rol de Active Directory

Comprobar los roles disponibles con el comando: Get-WindowsFeature AD*

Y ahora vamos a instalar el rol AD DS con el comando:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Y ahora revisamos que ya lo tenemos instalado:

Si vienes de una instalación con interfaz gráfica, es fácil pensar que existe una opción en sconfig para promocionar el servidor. Sin embargo, la instalación de Active Directory en Server Core se realiza mediante PowerShell, algo que encaja perfectamente con la filosofía de este tipo de despliegues.

Así que nos toca aparcarlo por ahora y continuar con nuestro "amigo" el PowerShell

Ahora vamos a promoverlo con el comando: 

Install-ADDSForest -DomainName "lab.justohorrillo.local"

Recuerda que Durante el asistente te pedirá que pongas la contraseña SafeModeAdministratorPassword, la contraseña DSRM (Directory Services Restore Mode) que es una contraseña especial del controlador de dominio. 

Piensa en ella como el "modo recuperación" de Active Directory.

Piensa que tardará unos minutos en volver a estar disponible. Es un momento perfecto para ese segundo café del día. ☕☕☕☕

Tras acabar la configuración se va a reiniciar, entramos en el equipo y ponemos en powershell:

(Get-WmiObject Win32_ComputerSystem).Domain

Nos devolverá la siguiente información:

Otra comprobación interesante consiste en ejecutar los comandos Get-ADDomain y dcdiag. Ambos nos permitirán verificar que Active Directory, DNS y el resto de servicios asociados funcionan correctamente antes de continuar ampliando el laboratorio.

Montar un controlador de dominio sobre Server Core ha sido una excelente forma de salir de la zona de confort. Más allá de reducir el consumo de recursos del laboratorio, obliga a entender mejor cómo funciona Windows Server y a apoyarse en herramientas como PowerShell o incluso el famoso Windows Admin Cente desde un SAW, en lugar de depender siempre de la interfaz gráfica.

Y esto no ha hecho más que empezar. Este servidor será la base sobre la que crecerá el laboratorio con nuevos clientes, automatización y algún que otro experimento. Pero eso lo veremos en próximos artículos... siempre que Proxmox no pida la jubilación antes. 😄

Ansible: Poniendo orden en mi laboratorio Proxmox

Automatiza la gestión de tus máquinas virtuales y contenedores sin esfuerzo.

Tengo ya cómo unas diez máquinas Linux funcionando en Proxmox: Debian, Ubuntu y Alpine, cada una haciendo sus tareas diarias. Además, un Windows 11 y un Windows Server Core 2019 para las pruebas de SSCM y Azure que estoy haciendo.

Al principio no supone demasiado trabajo mantenerlas. Pero cuando empiezas a tener varias máquinas, repetir las mismas tareas una y otra vez empieza a ser bastante aburrido. Y aburrido, en este oficio, significa peligroso (porque acabas haciendo las cosas a lo loco).

Así que decidí probar Ansible. Y este es el manual de cómo lo estoy montando, con sus fallos y sus soluciones.

¿Qué quiero conseguir? 

La idea no es montar una infraestructura empresarial ni complicarnos la vida, eso ya lo hacemos en el trabajo. Quiero poder administrar mi laboratorio desde un único sitio. Nada más. Y nada menos.

 

Tabla de objetivos (con su estado real):

Objetivo	Estado
Comprobar que todas las máquinas están disponibles	✅ Hecho
Actualizar Debian y Ubuntu (apt)	✅ Hecho
Actualizar Alpine (apk)	✅ Hecho
Gestionar servicios (start/stop/restart)	🔄 En progreso
Instalar software	🔄 En progreso
Crear usuarios	🔄 En progreso
Ejecutar comandos remotos	✅ Hecho
Automatizar tareas repetitivas	🔄 En progreso
Actualizar Windows	⏳ Pendiente (requiere WinRM)
Registrar qué ha ocurrido (logs)	🔄 En progreso

Mi laboratorio

Para este manual voy a utilizar un escenario bastante parecido al que podemos encontrar en un laboratorio doméstico o de pruebas:

                         PROXMOX
                            │
             ┌──────────────┴──────────────┐
             │                             │
       ANSIBLE CONTROLLER              OTRAS VM/LXC
          Debian Linux                     │
             │                             │
      ┌──────┼────────┬─────────┐          │
      │      │        │         │          │
    Debian  Ubuntu  Alpine    Debian     Windows
      │      │        │         │        ┌───┴────┐
      │      │        │         │        │        │
     VM/LXC VM/LXC  VM/LXC    VM/LXC    Win11  WServerCore2019

No hace falta que todas las máquinas sean iguales para que esto funcione, de hecho, esa es precisamente la gracia. Tenemos diferentes distribuciones, diferentes servicios y también Windows.

---

¿Por qué necesito Ansible?

Imaginemos que quiero actualizar todos mis Debian y Ubuntu.

Sin Ansible:

SSH → Debian 1 → apt update &&  apt full-upgrade -y
SSH → Debian 2 → apt update &&  apt full-upgrade -y
SSH → Ubuntu 1 → apt update &&  apt full-upgrade -y
SSH → Debian 3 → apt update &&  apt full-upgrade -y
...

Y si tengo diez máquinas, acabamos haciendo lo mismo diez veces.

Con Ansible:

ansible servidores -m apt -a "update_cache=yes"

Y Ansible se encarga del resto.

Una orden. Todas las máquinas. Más tiempo para mí.

---

Pero tengo Alpine...

Aquí aparece una situación interesante de nuestro laboratorio.

Alpine Linux utiliza apk, mientras que Debian y Ubuntu utilizan apt.

No podemos tratar todas las máquinas exactamente igual.

Podemos organizar el inventario:

[debian]
debian01
debian02
debian03

[ubuntu]
ubuntu01
ubuntu02

[alpine]
alpine01
alpine02

[windows]
windows11
servercore2019

Ahora podemos decidir qué hacer con cada grupo.

Por ejemplo:

Debian/Ubuntu → apt
Alpine        → apk
Windows       → WinRM

Y esto nos permite empezar a ver por qué Ansible resulta tan interesante cuando nuestro laboratorio empieza a crecer.

---

¿Y Windows?

También vamos a tocar Windows.

En nuestro laboratorio tenemos:

• Windows 11 Pro
• Windows Server Core 2019

Ansible puede administrar Windows, aunque la comunicación y algunas tareas son diferentes a Linux.

Esto nos permitirá ver algo bastante útil:

                    Ansible
                       │
          ┌────────────┴────────────┐
          │                         │
        Linux                     Windows
          │                         │
    ┌─────┼─────┐              ┌────┴─────┐
    │     │     │              │          │
  Debian Ubuntu Alpine        Win11   Server Core

Así que el manual no será simplemente:

"Instala Ansible y ejecuta ping".

La idea será llevarlo desde cero hasta utilizarlo realmente en un laboratorio heterogéneo.

---

El objetivo del manual

Al terminar tendremos algo parecido a esto:

                    ┌─────────────────┐
                    │    PROXMOX      │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ Debian Ansible  │
                    │    Controller   │
                    └────────┬────────┘
                             │
             ┌───────────────┼────────────────┐
             │               │                │
             ▼               ▼                ▼
          Linux           Linux           Windows
        Debian/Ubuntu     Alpine          Win11
                                          Server 2019

Y desde nuestro Debian podremos hacer cosas como:

Actualizar servidores

ansible linux -m ...

Comprobar máquinas

ansible all -m ping

Instalar paquetes

ansible debian -m ...

Gestionar servicios

ansible linux -m ...

Y, sobre todo, empezar a crear Playbooks, que serán los que realmente nos permitirán automatizar nuestro laboratorio.

Lo primero: instalar Ansible en el nodo controlador

Un solo nodo Debian será el “jefe” que habla con todos los demás.

Requisitos previos:

• Un Debian 12 recién instalado (o cualquiera que tengas).
• Acceso por SSH a todas las máquinas objetivo (con clave pública, no contraseña).
• Python 3 (viene por defecto en Debian 12).

Instalación (en el nodo controlador):

# Actualiza el sistema
sudo apt update && sudo apt upgrade -y # Instala Ansible (desde los repos oficiales de Debian)
sudo apt install -y ansible # Verifica la instalación
ansible --versión # Verifica la versión de Phyton
python3 --version

🔑 Paso 2: Generar clave SSH para Ansible

Objetivo: Ansible se autentica sin contraseña hacia Debian/Ubuntu/Alpine y también más adelante hacia Windows (WinRM aparte).

Ahora en el controller, que en nuestro caso es en la MV Debian que tenemos en Proxmox, tenemos que ejecutar el código:

ssh-keygen -t ed25519 -b 4096 -C "ansible-controller" -f ~/.ssh/id_ed25519

    Te va a pedir passphrase: Pero lo dejamos en blanco para el laboratorio, aunque en producción tendrías que usar un usuario y contraseña segura.

📤 Paso 3: Copiar la clave pública a todas las VMs/LXC

Vamos por lo simple: ssh-copy-id

Asumiendo que el usuario destino en Linux es el mismo en todas (ej. debian/ubuntu/alpine), por ejemplo:

*NdelA: En un entorno de producción, el usuario no debe de ser nunca el "root" o Administrador en Windows por seguridad, en el lab, pues lo dejamos como queramos ;-)

ssh-copy-id -i ~/.ssh/id_ed25519.pub debian@debian01

ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@ubuntu01

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@alpine01

y así en todos los equipos que tengamos...

📌 Ojo: Revisa esto antes de empezar con el SSH.

Resulta que tenemos bloqueado el SSH con el usuario root, para habilitarlo tenemos que hacer esto:

nano /etc/ssh/sshd_config y descomentamos la línea: PasswordAuthentication y le ponemos un YES en vez de lo que tiene: 

Verás que en el Alpine, no viene configurado el Python3, viene bastante pelado por defecto, por lo que tendremos que instalarlo para que funcione:

apk update && apk add python3

Luego hacemos un python3 --version para ver si lo tenemos instalado:

🗂️ Paso 5: Inventario Ansible (para que luego todo encaje)

Ahora vamos a crear un inventario sencillo, por ejemplo:

Vamos a crear una carpeta ~/ansible-lab y dentro hacemos el fichero: inventory.ini con los nodos.

y creamos el fichero inventory.ini

Y lo probamos:

ansible pihole -i inventory.ini -m ping

Nos aparece un hermoso Warning, no te alarmes, es un aviso de Ansible sobre el descubrimiento automático de Python.
Mientras vemos que tenemos un pong, nos alegra ver que funciona.

Si te molesta el warning dichoso como a mí, en el inventory.ini, tienes que añadir una línea 
que indique explícitamente qué intérprete Python debe usar Ansible.

[linux:vars]
ansible_python_interpreter=/usr/bin/python3


Y con eso ya no nos sale el warning.

Ejecutamos el ansible linux -i inventory.ini -m setup -a 'filter=ansible_distribution' 
y nos dice las máquinas que tenemos online:


Playbooks
Ahora vamos con los playbooks con lo que queremos que hagan:

Primer creamos una carpeta dentro en la misma altura donde teníamos creado el inventory.ini:


Y aquí empieza lo bueno: vamos a crear un único Playbook que:

Detecte el sistema operativo.

Use apt en Debian/Ubuntu.

Use apk en Alpine.

Actualice los paquetes.

Nos muestre claramente qué ha hecho.

No ejecute nada en Windows.

creamos nuestro primer yml, lo vamos a llamar update-linux.yml con el contenido:



y una vez creado vamos a ejecutarlo: 

ansible-playbook -i inventory.ini playbooks/update-linux.yml

Y ya tenemos los equipos actualizados.

Y como guinda del pastel, creamos una tarea para que lo lance semanalmente 

 
Y con esto tenemos ya un laboratorio Linux completamente gestionado desde Ansible.
Hemos aprendido a:
✅ Instalar Ansible en nuestro controlador Debian
✅ Configurar acceso SSH mediante claves
✅ Crear un inventario organizado por grupos
✅ Ejecutar comandos remotos
✅ Comprobar el estado de las máquinas
✅ Detectar distribuciones automáticamente
✅ Actualizar Debian, Ubuntu y Alpine desde un único Playbook
Todo ello desde una sola consola y sin necesidad de ir conectándonos máquina por máquina.

¿Y Windows?
Windows se ha quedado aparcado por ahora.
No porque Ansible no pueda gestionarlo, sino porque requiere una configuración adicional mediante WinRM, certificados, reglas de firewall y algunos ajustes que merece la pena explicar con calma para no volvernos locos a la primera prueba.
Además, quiero enseñarlo funcionando tanto contra Windows 11 como contra Windows Server Core 2019, que es donde realmente se pone interesante.
Pero si le dais cariño al post, prometo hacer una segunda vuelta. 
De momento sigo de vacaciones, así que toca disfrutar un poco antes de volver a pelearme 
con WinRM... 😄

¿Sigues actualizando tus drivers a mano? Hazlo como un auténtico profesional

Mantener los drivers y el firmware actualizados es una tarea fundamental para garantizar la estabilidad, el rendimiento y la seguridad de los equipos corporativos, y una auténtica lata, tener los repositorios actualizados.

Aunque Windows Update cubre gran parte de las necesidades, muchos admins lo primero que hacen es bloquear el WSUS y dejarlo en modo automático, por que muchos técnicos tenemos que usar las  herramientas específicas que permiten automatizar la detección e instalación de actualizaciones de controladores, BIOS y firmware que lanzan los fabricantes de equipos.

Pero desde Hoy, gracias a herramientas como Winget, podemos desplegar fácilmente estas soluciones en nuestros equipos y posteriormente integrarlas en scripts, tareas programadas o plataformas de automatización como Ansible y tener una puerta cerrada y puesta al día sin tener que estar pendientes.

Un punto menos de seguridad puesto al día.

Herramientas oficiales por fabricante

Fabricante	Herramienta	Función principal
Dell	Dell Command Update (DCU)	Actualización de drivers, BIOS y firmware
HP	HP Image Assistant (HPIA)	Análisis y actualización de drivers, BIOS y software HP
Lenovo	Lenovo System Update	Actualización de drivers, BIOS y utilidades Lenovo

Ventajas de utilizar herramientas del fabricante

• Mayor precisión en la detección de hardware.
• Actualizaciones de BIOS y firmware.
• Compatibilidad garantizada por el fabricante.
• Automatización mediante línea de comandos.
• Integración con soluciones de gestión y despliegue.

Instalación mediante Winget

Una de las ventajas de Winget es que permite desplegar estas herramientas de forma rápida y automatizada.

Dell Command Update

winget install Dell.CommandUpdate.Universal

Lenovo System Update

winget install Lenovo.SystemUpdate

HP Image Assistant

winget install HP.HPImageAssistant

Ejemplo práctico: Dell Command Update CLI

Una vez instalado Dell Command Update, podemos utilizar su interfaz de línea de comandos para automatizar actualizaciones.

Buscar actualizaciones

dcu-cli.exe /scan


Aplicar actualizaciones

dcu-cli.exe /applyUpdates



Aplicar actualizaciones en modo silencioso

dcu-cli.exe /applyUpdates -silent

Este enfoque resulta especialmente útil para integrarlo en:

• Tareas programadas de Windows.
• Scripts de PowerShell.
• Playbooks de Ansible.
• Soluciones RMM.
• Microsoft Intune.
• SCCM/MECM.

Ejemplo de despliegue con Ansible

- name: Instalar Dell Command Update
  win_shell: |
    winget install Dell.CommandUpdate.Universal --silent --accept-source-agreements --accept-package-agreements

- name: Ejecutar actualización de drivers
  win_shell: |
    "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /applyUpdates -silent

Conclusión

La combinación de Winget y las herramientas oficiales de los fabricantes permite crear procesos de mantenimiento completamente automatizados. En el caso de Dell, Dell Command Update CLI facilita enormemente la gestión de drivers y firmware, mientras que HP y Lenovo ofrecen soluciones equivalentes que pueden integrarse en los mismos flujos de trabajo corporativos.

De esta forma, es posible mantener cientos de equipos actualizados con una intervención mínima y aprovechando herramientas ya presentes en el ecosistema Windows.