Archivo del blog

10 noviembre 2026

Koozali SME Server en 2026: ¿la alternativa olvidada para las pymes?

Hace unos días un amigo me llamó para hacerme una consulta bastante habitual.

Trabaja en una pequeña gestoría de barrio. Son cuatro empleados, una impresora multifunción que ya ha visto tiempos mejores, equipos de distintas generaciones con Windows 10 y Windows 11, en diferentes versiones, y un NAS donde se guardan la mayoría de los documentos aunque nadie tenía demasiado claro cómo estaba configurado,. A todo esto había que añadir alguna necesidad puntual de trabajar desde casa, poco tiempo para tareas de administración y varios años de visitas de distintas tiendas de informática, cada una dejando sus propios cambios y configuraciones.

Nada fuera de lo normal.

Mientras hablábamos me empezaron a aparecer las soluciones que solemos mencionar casi por inercia: Microsoft365, un NAS de Synology, una máquina con Proxmox, un docker con varios servicios montados en contenedores.

Todas válidas.

Pero también pensé que muchas veces intentamos resolver problemas sencillos con soluciones más complejas de lo que realmente necesitan.

Porque la pregunta no era cómo montar la infraestructura más moderna posible, sino algo mucho más simple:

"¿Qué solución dejarías montada si sabes que no vas a estar ahí cada vez que algo falle?"

Y entonces me acordé de un viejo conocido.

Koozali SME Server.

Hacía años que no escuchaba hablar de él, pero la idea seguía siendo interesante: un único servidor capaz de cubrir buena parte de las necesidades de una pequeña empresa sin obligarte a mantener media docena de servicios distintos.

La curiosidad pudo más que la nostalgia, así que decidí montar una máquina virtual en Proxmox y comprobar si los recuerdos eran mejores que la realidad.

La pregunta era sencilla:

¿Sigue teniendo sentido Koozali SME Server en 2026 o es uno de esos proyectos que sobreviven únicamente porque quienes lo utilizamos hace años le guardamos cariño?



Vamos a verlo.

Paso 1.

Vamos a verlo en Proxmox, ya que mi lab y mis pruebas las hago en este entorno, pero es perfectamente válido para usarlo en un equipo para él solo.

Voy a configurar una VM con lo siguiente, pero fijo que funciona con menos recursos aún.

  • 2 vCPU
  • 4 GB RAM
  • 40 GB disco VirtIO SCSI
  • Red VirtIO
  • BIOS SeaBIOS

  • Y así le configuramos la ISO que nos descargamos de la web: Descarga

    Una vez creado el VM, lanzamos la instalación:


    Ahora escogemos el idioma, por ahora la instalación es muy factible;


    Aquí llegamos al núcleo de la instalación:



    Configuramos teclado, fecha y hora y empezamos con la instalación del programa, no muy lejos de cualquier otra distribución de Linux que podamos tener.

    La sensación inicial es extraña. Por un lado parece un proyecto que se ha quedado congelado en el tiempo. Por otro, precisamente esa sencillez transmite que está pensado para trabajar y no para impresionar.

    Nota: No he dicho nada antes, pero cada vez que montamos un servidor tenemos que tener una IP fija, así que revisa que no esté en DHCP...

    Paso. 2


    Configuración inicial:

    Ahora entramos y vamos a rellenar los campos que nos faltan: que no te asuste el formato centenial que tiene:


    Vale, tras poner la contraseña de admin total, vamos a poner un nombre en nuestro querido servidor:


    Ahora ponemos el nombre del equipo: En nuestro caso, será koozali_1

    Y seguimos con la red del equipo:


    Y escogemos la IP que vamos a ponerle:


    Ahora tenemos que escoger el rol que va a usar el equipo, tenemos 3: Nosotros usaremos el 3, ya que aunque Koozali también puede funcionar como puerta de enlace y firewall, hoy la mayoría de pequeñas empresas ya disponen de un router que cumple esa función y ya que quería reproducir un escenario lo más parecido posible al que probablemente encontraría en una oficina real.

    • Servidor y puerta de enlace → Servidor + router/firewall de la red.
    • Servidor privado y puerta de enlace → Igual que el anterior, pero más cerrado hacia Internet.
    • Servidor-solo → Solo ofrece servicios (archivos, correo, VPN, etc.), el router sigue siendo otro equipo.


    Ahora ponemos nuestra IP de enlace:


    Apagamos el DHCP para que no se choque con nuestro router:


    Luego nuestro DNS favorito:


    Y ahora esperamos a que se complete la instalación de nuestro servidor:

    Os pongo la pantalla completa para que veáis la UI de todo el proceso.


    Paso 3.


    Ahora entramos por página web para iniciar la configuración final.

    htpp://192.168.1.250/SManager


    Vale, ya tenemos acceso a nuestro servidor Koozali, con el usuario: Admin.



    Conclusiones


    Después de dedicar unas horas a instalarlo, configurarlo y pelearme con algunos detalles de la puesta en marcha, mi conclusión es bastante sencilla.

    Koozali SME Server sigue funcionando. Y quizás eso ya dice bastante.

    La interfaz acusa el paso de los años, algunas decisiones parecen sacadas de otra época y hay características que hoy damos por supuestas que aquí no aparecen de forma tan evidente. Uno de los ejemplos que más me llamó la atención fue la ausencia de opciones para gestionar RAID durante la instalación.

    Sin embargo, también es cierto que buena parte de los servicios que una pequeña empresa necesita siguen estando ahí: gestión de usuarios, compartición de archivos, correo, VPN, servicios web y administración centralizada.

    ¿Lo pondría mañana en la gestoría de mi amigo? Seguramente no.

    ¿Lo descartaría solo porque su interfaz parece antigua? Tampoco.

    Lo interesante de Koozali no es cómo se ve, sino cuántos servicios es capaz de poner en funcionamiento con muy poca complejidad. Y en entornos donde nadie quiere administrar cinco plataformas distintas, eso sigue teniendo valor.

    01 noviembre 2026

    Una vuelta por mi laboratorio doméstico


    Estado actual de mi homelab



    Hace bastante tiempo que hablo de herramientas concretas, pruebas y servicios, pero pocas veces he enseñado cómo está organizado realmente mi laboratorio a día de hoy.

    La base de todo sigue siendo Proxmox. Con el paso de los años he probado distintas formas de montar entornos de pruebas y, para mi uso, sigue siendo una de las opciones más cómodas para gestionar máquinas virtuales y contenedores desde un único lugar, así ahorro espacio y energía.

    Actualmente tengo varias máquinas y contenedores con funciones muy distintas.


    La capa de virtualización


    Dentro de Proxmox mantengo diferentes sistemas según las necesidades de cada servicio.

    Debian: administración y automatización


    Mi máquina Debian es probablemente la más utilizada de todo el laboratorio ya que es donde tengo instalado Ansible y es donde gestiono buena parte de la infraestructura.

    Lo utilizo principalmente para mantener actualizado el entorno completo. En lugar de conectarme una por una a cada máquina para lanzar actualizaciones, comprobar paquetes o realizar tareas repetitivas, puedo hacerlo todo de forma centralizada mediante playbooks.

    Reconozco que tardé demasiado en descubrir Ansible. Durante años hice muchas tareas manualmente porque "solo eran unos minutos". El problema es que esos minutos se repetían una y otra vez.

    Desde que empecé a utilizarlo cambió bastante mi forma de administrar el laboratorio. Ya no se trata únicamente de ahorrar tiempo. También me permite ser más consistente, documentar lo que hago y repetir procesos cuando lo necesito sin depender de la memoria o de una colección interminable de comandos guardados en notas.

    De todas las herramientas que he incorporado al homelab en los últimos años, probablemente Ansible sea una de las que más impacto ha tenido en mi día a día. Me abrió la puerta a una forma mucho más cómoda de gestionar sistemas y entender la automatización.

    Ubuntu: el cerebro de la IA local


    La máquina Ubuntu está dedicada prácticamente por completo a la inteligencia artificial local.

    Aquí es donde se ejecuta Ollama y donde residen los distintos modelos de lenguaje que voy probando, se  podría decirse que es el "cerebro" del laboratorio.

    Además, es con diferencia la máquina que más recursos consume de toda la infraestructura. Los modelos actuales no se conforman precisamente con poca memoria o unos pocos núcleos, así que decidí reservar una máquina específica para esta función.

    Mantener la IA aislada del resto de servicios me permite experimentar con nuevos modelos, actualizar versiones y realizar pruebas sin afectar a otras partes del laboratorio. Es una separación que agradezco especialmente cuando toca hacer cambios, porque los modelos pueden ser bastante exigentes y no siempre sale todo bien a la primera.

    Aunque tengo varios servicios funcionando en paralelo, esta es probablemente la máquina más potente de todo el entorno. Al final, cuando empiezas a jugar con modelos de lenguaje locales, entiendes rápidamente por qué el hardware termina convirtiéndose en parte de la conversación.



    Pi-hole


    Uno de los servicios más veteranos del laboratorio y, probablemente, el más utilizado.

    Llegó cuando mis hijos empezaron a utilizar más dispositivos conectados y yo quería tener algo más de control sobre lo que ocurría en la red doméstica. Lo instalé originalmente en una Raspberry Pi 3B+ y durante bastante tiempo funcionó sin dar ningún problema.

    De hecho, fue uno de los motivos que me empujó a montar el servidor actual. A medida que se fueron sumando móviles, tablets, televisores... la Raspberry empezó a quedarse corta para todo lo que tenía que gestionar, el problema fué al querer comprar una rpi4 o una rpi5 que valían mucho más que mi actual equipo.

    Actualmente Pi-hole se encarga del filtrado DNS de toda la red doméstica, bloqueando publicidad, dominios no deseados y determinadas conexiones antes incluso de que lleguen a los dispositivos.

    Es una de esas herramientas que pasan completamente desapercibidas mientras funcionan. Pero el día que la apagas, todo el mundo se da cuenta enseguida.

    Metube


    Lo utilizo para gestionar determinadas descargas mediante una interfaz web sencilla.

    Es un servicio pequeño, pero muy práctico para evitar depender constantemente de la línea de comandos.

    Jellyfin


    Mi servidor multimedia.

    Aquí centralizo películas, series y otros contenidos para poder acceder a ellos desde cualquier dispositivo de casa sin depender de plataformas externas.

    Además, aproveché para digitalizar mi colección de DVD. Hacía años que apenas los utilizaba y, siendo sincero, ya no tengo ningún lector conectado de forma permanente en casa. De esta forma puedo seguir disfrutando de ese contenido sin tener que buscar discos cada vez que quiero ver algo y conectar trastos en el comedor.

    Como efecto secundario, también conseguí liberar bastante espacio físico. Cualquiera que haya acumulado películas durante años sabe que unas cuantas estanterías recuperadas siempre vienen bien para otros proyectos.

    Máquinas Windows


    También mantengo varios sistemas Windows destinados exclusivamente a pruebas y laboratorio.

    Actualmente cuento con:

    • Windows Server Core 2019.
    • Windows 11, configurado como mi SAW (Secure Admin Workstation) para el entorno Windows.
    La idea es disponer de un entorno lo más parecido posible a los escenarios que puedo encontrar en el trabajo o durante sesiones de aprendizaje.

    Windows Server Core me resulta especialmente útil para practicar administración sin depender de una interfaz gráfica, obligándome a utilizar PowerShell, gestión remota y otras herramientas que muchas veces terminan siendo el camino más eficiente en entornos reales.

    Por otro lado, mantengo Windows 11 como estación de administración segura del laboratorio. Desde ella realizo tareas administrativas, pruebas de herramientas y validaciones de configuración antes de aplicarlas en otros sistemas.

    Aunque la parte de Linux ocupa una parte importante del laboratorio, sigo dedicando tiempo a la plataforma Microsoft. Al fin y al cabo, es una tecnología con la que llevo trabajando muchos años y sigue formando parte de mi día a día.

    CasaOS como puerta de entrada


    Además de la infraestructura principal, utilizo CasaOS como capa de acceso para varios servicios desplegados mediante contenedores. 

    Su objetivo es bastante simple: disponer de un panel cómodo desde el que acceder rápidamente a las aplicaciones que utilizo con más frecuencia y, al mismo tiempo, tener un entorno donde probar nuevos contenedores sin comprometer el resto del laboratorio.

    Una de las cosas que más me gustan de CasaOS es precisamente esa facilidad para desplegar servicios en cuestión de minutos. Prácticamente cada día aparecen nuevos proyectos interesantes y resulta muy cómodo poder probarlos de forma rápida antes de decidir si merecen un hueco permanente en la infraestructura.

    Si un servicio demuestra ser útil, estable y seguro tras un tiempo de uso, entonces me planteo migrarlo a una máquina o contenedor dedicado dentro de Proxmox. 

    De esta forma puedo experimentar sin poner en riesgo otros servicios que ya forman parte del día a día.

    Actualmente tengo desplegados:

    Open WebUI:  La interfaz que utilizo para interactuar con Ollama estilo chatGPT.

    Nginx: Lo utilizo como servidor web y punto de publicación para distintos servicios internos.

    n8n: Mi plataforma de automatización, aquí recogemos "webhoooks" para interactuar con nuestro lab y Petete, la IA interna que se encarga de gestionarlo y avisarme por si pasa algo.

    Excalidraw: Seguramente sea la aplicación más utilizada de CasaOS, al final pasará a Proxmox.
    La instalé inicialmente por curiosidad y pensando en hacer algún esquema rápido, pero la realidad es que quienes más la aprovechan son mis hijos. La utilizan para practicar caligrafía, hacer ejercicios de matemáticas, dibujar y escribir cualquier cosa que se les ocurra, es una pizarra infinita. 
    Al final se ha convertido en una especie de pizarra digital disponible desde cualquier dispositivo de casa.
    No era el uso que tenía pensado cuando la instalé, pero probablemente sea uno de los servicios que más horas de uso acumula de todo el laboratorio. Y de paso gastamos bastantes menos folios y salvamos el Amazonas.

    Fastfetch: Un pequeño servicio que utilizo para verificar información de sistemas y realizar consultas rápidas, no es especialmente complejo, pero resulta cómodo tenerlo siempre disponible, es más por curiosidad que por otra cosa.

    La instalación de CasaOS reside sobre dos discos configurados en RAID0. Al tratarse principalmente de un entorno de pruebas y servicios no críticos quería hacer pruebas de configuración, para ver como se comportaba, pero si algún día algo se rompe, la idea es poder reconstruirlo rápidamente en lugar de protegerlo como si fuera un entorno de producción.

    PD: Actualmente CasaOS está en desuso. Parece que el desarrollo está centrándose en ZimaOS y, mientras tanto, estoy revisando otras alternativas como LGM-OS, que la verdad me está sorprendiendo bastante.

    Intentando no complicarlo más de la cuenta

    Como casi todos los homelabs, este entorno ha cambiado muchas veces a lo largo de los años.

    He añadido servicios, eliminado otros, migrado sistemas y probado herramientas de todo tipo. Algunas se han quedado durante años y otras apenas han durado un fin de semana antes de desaparecer.

    Con el tiempo he llegado a una conclusión bastante simple: mantener un laboratorio útil suele ser más interesante que acumular aplicaciones que apenas utilizamos. Es fácil instalar veinte contenedores en una tarde. Lo difícil es mantenerlos actualizados, documentados y funcionando cuando realmente los necesitas.

    También creo que herramientas como CasaOS, LGM, ZimaOS o similares son una excelente puerta de entrada al mundo del homelabber. Permiten perder el miedo a Docker, descubrir nuevos servicios y entender todo lo que se puede montar en casa con relativamente poco esfuerzo.

    Pero muchas veces el aprendizaje de verdad empieza cuando quieres ir un poco más allá. Cuando intentas entender qué está pasando por debajo, automatizar tareas con Ansible, montar un proxy inverso, gestionar copias de seguridad o mover un servicio a una máquina dedicada porque ya forma parte de tu día a día.

    A día de hoy intento que cada máquina tenga una función clara. Algunas están orientadas a automatización, otras a inteligencia artificial, otras a multimedia y otras simplemente a experimentar.

    Y siendo sincero, probablemente dentro de unos meses esta misma publicación ya esté desactualizada.

    Eso también forma parte de tener un homelab. Empiezas instalando una aplicación por curiosidad, después pruebas otra más y, casi sin darte cuenta, terminas reorganizando toda la infraestructura para hacer hueco a una nueva idea.

    09 octubre 2026

    Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

    La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcione con mi Proxmox, y no es por otra cosa que "sus bajos recursos" para lanzar una IA.

    La base del proyecto es un contenedor LXC en Proxmox utilizando una imagen de Ubuntu. Una vez desplegado, le hemos asignado recursos sin demasiada compasión, actualizado todos los paquetes y preparado el terreno para empezar a jugar con la IA local.


    Pero antes; ¿Qué es Ollama y para qué sirve?

    Ollama permite ejecutar modelos de inteligencia artificial directamente en tu ordenador o servidor, sin depender de plataformas externas ni enviar tus conversaciones a servicios en la nube.

    Con él puedes descargar y ejecutar modelos como Llama, Qwen, Gemma o DeepSeek, además de integrarlos en otras aplicaciones mediante una API. Si quieres una interfaz gráfica, puedes combinarlo con Open WebUI y tener tu propio asistente de IA accesible desde el navegador.

    Lo mejor es que puedes montarlo en tu propio servidor Linux, controlar qué modelos utilizas y experimentar con inteligencia artificial en tu homelab sin necesidad de contratar servicios de pago.

    Pero recuerda: El rendimiento dependerá del hardware y de la memoria disponibles.


    Primer paso: instalar Ollama


    La instalación es tan sencilla como ejecutar un comando por terminal, pero antes necesitamos tener instalado zstd, que es un algoritmo de compresión de datos, como ZIP o GZIP.

    Así que primero vamos a instalarlo:

        sudo apt install zstd -y

    Y con el zstd --version comprobamos que está


    La instalación es tan sencilla como ejecutar:

        curl -fsSL https://ollama.com/install.sh | sh


    Una vez completada la instalación, aprovechamos para instalar también el cliente SSH y dejar el entorno listo para trabajar cómodamente desde cualquier terminal.

    Y con eso, primer objetivo cumplido: Ollama ya está instalado



    Intentando aprovechar la iGPU

    Como el equipo dispone de gráfica integrada Intel, la idea era intentar exprimirla para acelerar la ejecución de los modelos, ya que no tenemos una gráfica Nvidia ni una AMD.... así que vamos  a intentar aprovecharla.

    Lo primero fue detener el servicio de Ollama y lanzarlo manualmente utilizando Vulkan:


    Una vez parado ponemos:

        OLLAMA_VULKAN=1 ollama serve

    El resultado fue prometedor: Ollama detectaba la GPU, sabía que existía... pero prácticamente la ignoraba por tratarse de una iGPU. Vamos, que la veía pero no quería salir con ella...


    Forzando el uso de la gráfica integrada

    Para convencer a Ollama de que la iGPU también merece amor, editamos el servicio:

        nano /etc/systemd/system/ollama.service

    Y añadimos las siguientes líneas extras:

    Environment="OLLAMA_VULKAN=1" 
    Environment="OLLAMA_IGPU_ENABLE=1"


    Tras reiniciar el servicio parecía que todo iba a funcionar... pero no. La GPU seguía resistiéndose.


    El problema real: permisos


    Después de varias pruebas, descubrimos que el verdadero problema no estaba en Vulkan ni en Ollama, sino en los permisos.

    El usuario que ejecuta Ollama no pertenecía al grupo con acceso a los dispositivos gráficos, por lo que la aplicación simplemente no podía utilizarlos, así que un pequeño ajuste en los grupos del sistema, reinicio correspondiente y... ahora sí. Ollama podía acceder correctamente a la iGPU.



    Y comprobamos que ahora el grupo ollama tiene acceso:


    Primera prueba de fuego

    Con todo funcionando, llegó el momento más satisfactorio de cualquier instalación: descargar el primer modelo.

    Como estamos trabajando en un equipo modesto y sin una gráfica dedicada potente, la descarga y preparación inicial requiere algo de paciencia. Aproximadamente cinco minutos de espera para el primer arranque.

    Nada dramático. Tiempo suficiente para un café y para pensar en la siguiente locura que vamos a intentar automatizar



    Conclusiones


    La instalación de Ollama sobre Proxmox ha resultado mucho más sencilla de lo esperado. La parte más delicada ha sido conseguir que la gráfica integrada Intel fuese realmente utilizable, pero una vez resuelto el tema de permisos, todo ha quedado funcionando correctamente.


    Petete ya está vivo.



    Porque, seamos sinceros, la inteligencia artificial está muy bien para generar imágenes espectaculares, escribir poemas o discutir sobre filosofía. Pero su verdadera prueba de fuego será evitar que vuelva a descubrir a las dos de la madrugada que el almacenamiento está al 100% y media infraestructura ha decidido declararse en huelga. Esa será su primera tarea. Y probablemente la más importante. 😅






    19 septiembre 2026

    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. 😄

    Koozali SME Server en 2026: ¿la alternativa olvidada para las pymes?

    Hace unos días un amigo me llamó para hacerme una consulta bastante habitual. Trabaja en una pequeña gestoría de barrio. Son cuatro empleado...