Instalación de sistemas operativos en red

La instalación de sistemas operativos en red no empieza cuando introducimos un USB, montamos una imagen ISO o iniciamos el asistente de instalación. Empieza bastante antes: cuando analizamos qué servicios debe prestar el servidor, cuántos equipos van a conectarse, qué recursos necesitamos y cómo podremos recuperar el sistema si algo sale mal.

Esta forma de plantear la instalación es importante porque un servidor no es simplemente un ordenador más potente. Es un sistema que asume responsabilidades para otros usuarios y equipos. Puede encargarse de autenticar cuentas, almacenar archivos, resolver nombres, asignar direcciones IP, publicar aplicaciones, gestionar impresoras o proporcionar acceso remoto.

Por eso, instalar un sistema operativo en red implica mucho más que copiar archivos en un disco. Hay que comprobar la compatibilidad del hardware, preparar el almacenamiento, elegir un método de instalación, configurar la red, aplicar actualizaciones, proteger el acceso administrativo y demostrar que los clientes pueden utilizar los servicios previstos.

Mi experiencia en desarrollo de software me enseñó a analizar los problemas, dividirlos en partes y construir soluciones que se puedan mantener. Aplico el mismo criterio cuando trabajo con servidores: separo el proceso en requisitos, planificación, instalación, configuración, pruebas y documentación. Esta estructura reduce la improvisación y facilita localizar los errores.

En esta guía explicaré todo el proceso de instalación de sistemas operativos en red utilizando como referencia un servidor de aula. El objetivo será preparar una máquina capaz de comunicarse con varios clientes y quedar lista para incorporar posteriormente servicios de usuarios, archivos, DNS u otros roles. El procedimiento es aplicable tanto a Windows Server como a distribuciones Linux orientadas a servidor.

Qué es un sistema operativo en red y para qué sirve

Un sistema operativo en red es un sistema preparado para administrar usuarios, equipos, servicios y recursos compartidos de forma centralizada. Puede ejecutarse directamente sobre un servidor físico o dentro de una máquina virtual.

Su finalidad principal no es ofrecer una experiencia de escritorio a una sola persona. Está pensado para responder a las solicitudes de varios clientes y mantener los servicios disponibles durante periodos prolongados.

Un ordenador personal también puede compartir una carpeta o una impresora. La diferencia está en el alcance y en la forma de administrar esos recursos. En un sistema operativo en red encontramos herramientas específicas para controlar identidades, permisos, registros, actualizaciones, acceso remoto y recuperación.

Diferencias entre un sistema operativo monopuesto y uno en red

Un sistema operativo monopuesto está orientado al uso directo de una persona. La administración suele realizarse localmente, las cuentas pertenecen al propio equipo y el ordenador puede apagarse cuando no se utiliza.

En cambio, un sistema operativo de servidor presta servicios a otros dispositivos. Se espera que funcione de forma estable, que pueda administrarse remotamente y que mantenga una configuración coherente.

Aspecto	Sistema monopuesto	Sistema operativo en red
Finalidad	Uso individual	Prestación de servicios
Administración	Principalmente local	Centralizada y remota
Usuarios	Cuentas locales	Usuarios y grupos centralizados
Disponibilidad	Uso puntual	Funcionamiento prolongado
Seguridad	Protección del equipo	Protección de identidades, recursos y comunicaciones
Recuperación	Centrada en el dispositivo	Orientada a restaurar servicios y datos

Esta diferencia afecta a todas las decisiones posteriores. Un fallo en un equipo personal suele afectar a una sola persona. Un fallo en un servidor de archivos, de autenticación o de nombres puede interrumpir el trabajo de toda una organización.

Modelo cliente-servidor frente a redes igual a igual

En una red igual a igual, cada equipo puede compartir recursos con los demás. Es una solución sencilla para redes pequeñas, pero se vuelve difícil de administrar cuando aumenta el número de usuarios.

Imaginemos un aula con veinte ordenadores. En un grupo de trabajo, podríamos necesitar crear las mismas cuentas en cada máquina y revisar individualmente los permisos. Si una persona cambia de contraseña o abandona el centro, habría que modificar varios equipos.

En el modelo cliente-servidor, las identidades y los recursos se administran desde puntos controlados. Los clientes solicitan servicios y el servidor los proporciona. Esto permite aplicar criterios comunes de acceso, seguridad y mantenimiento.

El entorno suele incluir:

• Equipos cliente.
• Uno o varios servidores.
• Conmutadores, routers, puntos de acceso y cableado.
• Direcciones IP y servicios de nombres.
• Usuarios, grupos y cuentas de equipo.
• Recursos compartidos.
• Políticas de seguridad y procedimientos de recuperación.

Funciones, roles y servicios de un servidor

Un sistema operativo en red puede asumir diferentes funciones. No es necesario instalarlas todas en la misma máquina, y hacerlo sin una necesidad real aumentaría el mantenimiento y la superficie de exposición.

Entre los roles más habituales encontramos:

• Servidor de archivos.
• Servidor de impresión.
• Servicio de directorio.
• Servidor DNS.
• Servidor DHCP.
• Servidor web.
• Servidor de copias de seguridad.
• Servidor de acceso remoto.
• Servidor de virtualización.

Además de prestar esos servicios, el sistema debe permitir gestionar identidades, aplicar permisos, registrar eventos, monitorizar recursos, ejecutar tareas programadas y recuperar el funcionamiento después de un fallo.

La idea más importante es sencilla: antes de comenzar la instalación de sistemas operativos en red debemos saber qué responsabilidad asumirá la máquina. Esa responsabilidad determina el hardware, el almacenamiento, la red y las medidas de protección que necesitaremos.

Qué debes preparar antes de instalar un sistema operativo en red

Uno de los errores más frecuentes consiste en adaptar el proyecto al ordenador que tenemos delante. Vemos un equipo libre, comprobamos que enciende y empezamos a instalar. Después descubrimos que no tiene suficiente memoria, que la tarjeta de red no dispone de un controlador compatible o que el disco no puede soportar el volumen de datos previsto.

La pregunta inicial no debería ser “¿qué puedo instalar en este equipo?”, sino “¿qué debe hacer el servidor y qué necesita para hacerlo de forma segura?”.

Durante mi etapa en consultoría aprendí a escuchar y entender las necesidades antes de hablar de herramientas. En la preparación de un servidor aplico el mismo principio: primero defino usuarios, servicios, disponibilidad y crecimiento; después selecciono el sistema y los recursos.

Define los usuarios, servicios y nivel de disponibilidad

Antes de revisar procesadores o discos, conviene responder a una serie de preguntas:

1. ¿Cuántos usuarios utilizarán el servidor?
2. ¿Cuántos equipos cliente se conectarán?
3. ¿Qué servicios prestará?
4. ¿Cuántos datos almacenará inicialmente?
5. ¿Cuánto pueden crecer esos datos?
6. ¿Durante qué horario debe estar disponible?
7. ¿Cuánto tiempo puede permanecer interrumpido?
8. ¿Qué copias de seguridad necesitaremos?
9. ¿Qué aplicaciones deben ser compatibles?
10. ¿Quién administrará la máquina?

No requiere los mismos recursos un servidor de laboratorio utilizado por cinco estudiantes que un servidor de archivos que debe atender a decenas de personas durante toda la jornada.

En nuestro ejemplo, prepararemos un servidor de aula con veinte clientes. La máquina permitirá practicar posteriormente con usuarios, archivos y servicios de red. No será un servidor de producción, pero debemos instalarlo con un procedimiento ordenado.

Comprueba procesador, memoria RAM y almacenamiento

El procesador debe utilizar una arquitectura compatible con el sistema operativo. En una instalación actual es habitual trabajar con arquitectura de 64 bits, pero no debemos darlo por supuesto. Hay que comprobar tanto la CPU como la imagen que vamos a instalar.

También debemos revisar:

• Número de núcleos e hilos.
• Compatibilidad con las instrucciones requeridas.
• Soporte de virtualización.
• Activación de Intel VT-x o AMD-V cuando sea necesario.

La memoria RAM debe permitir ejecutar el sistema base, los servicios y las tareas administrativas sin agotar los recursos. En una máquina virtual también debemos reservar memoria suficiente para el anfitrión.

Como punto de partida didáctico, el documento propone 2 CPU virtuales, 4 GB de RAM y entre 50 y 60 GB de disco para una práctica básica. Estas cifras sirven para un laboratorio, pero no deben trasladarse automáticamente a un servidor real.

En el almacenamiento debemos valorar algo más que la capacidad:

• Rendimiento.
• Latencia.
• Estado de las unidades.
• Compatibilidad de la controladora.
• Posibilidad de ampliar el espacio.
• Necesidad de redundancia.
• Separación entre sistema y datos.

Un disco puede tener espacio suficiente y seguir siendo inadecuado si presenta errores, ofrece un rendimiento insuficiente o no puede detectarse durante la instalación.

Revisa la tarjeta de red, los controladores y el firmware

El servidor necesita al menos una interfaz de red reconocida por el sistema operativo. Antes de instalar debemos comprobar el modelo, la velocidad, los controladores disponibles y la compatibilidad con la infraestructura.

En entornos más avanzados pueden utilizarse varias interfaces para separar el tráfico de usuarios, administración, almacenamiento o copias de seguridad. En un aula suele bastar una interfaz, aunque una máquina virtual puede utilizar dos adaptadores: uno para acceder temporalmente a Internet y otro para la red interna del laboratorio.

También debemos revisar el firmware:

• Modo BIOS o UEFI.
• Configuración de la controladora de almacenamiento.
• Secure Boot.
• TPM, cuando proceda.
• Opciones de virtualización.
• Orden de arranque.

Cambiar el modo de arranque o la controladora después de instalar puede impedir que el sistema se inicie. Por eso estas decisiones deben tomarse antes.

Prepara una matriz de compatibilidad

Una matriz de compatibilidad ayuda a convertir las comprobaciones en decisiones documentadas.

Elemento	Qué debemos revisar	Resultado esperado
CPU	Arquitectura, núcleos y virtualización	Compatible con el sistema y los servicios
RAM	Capacidad instalada y ampliable	Suficiente para la carga prevista
Discos	Capacidad, estado y controladora	Detectados y sin alertas
Red	Modelo, controlador y enlace	Interfaz reconocida y estable
Firmware	UEFI, BIOS y Secure Boot	Configuración coherente
Aplicaciones	Versiones y requisitos	Compatibilidad comprobada
Clientes	Sistemas y protocolos	Acceso posible desde los equipos previstos

La matriz no tiene que ser compleja. Su utilidad consiste en evitar que las comprobaciones queden únicamente en la memoria de quien realiza la instalación.

Diseña el nombre, la dirección IP, la puerta de enlace y el DNS

Nuestro servidor también necesita una identidad dentro de la red. Para el ejemplo utilizaremos:

Parámetro	Valor
Nombre	SRV-AULA-01
Dirección IPv4	192.168.50.10
Prefijo	/24
Puerta de enlace	192.168.50.1
Red de clientes	192.168.50.0/24
DNS temporal	El autorizado por el centro
DNS definitivo	El definido para el servicio del laboratorio

Debemos reservar el nombre y la dirección antes de instalar. Esto evita duplicidades y facilita que la documentación coincida con la configuración real.

Cómo planificar los discos, las particiones y los sistemas de archivos

La planificación del almacenamiento condiciona el mantenimiento futuro del servidor. Una instalación puede funcionar correctamente el primer día y convertirse en un problema meses después si el volumen del sistema se queda sin espacio, los registros crecen sin control o los datos están mezclados con los archivos del sistema.

No existe un particionado válido para todos los casos. Debemos justificarlo según la capacidad disponible, los servicios, el crecimiento y el procedimiento de copia.

MBR o GPT: qué esquema de particionado elegir

MBR es un esquema tradicional relacionado principalmente con equipos antiguos y arranque BIOS. Presenta limitaciones en el número de particiones y en el manejo de discos de gran capacidad.

GPT es el esquema habitual en instalaciones modernas con UEFI. Admite más particiones, funciona mejor con discos grandes y conserva información redundante de la tabla de particiones.

Característica	MBR	GPT
Entorno habitual	BIOS y equipos antiguos	UEFI y equipos actuales
Número de particiones	Más limitado	Mayor flexibilidad
Discos grandes	Presenta limitaciones	Adecuado
Metadatos	Tabla principal única	Copias y comprobaciones
Elección recomendada	Solo por compatibilidad	Instalaciones modernas

Para nuestro servidor de aula elegiría UEFI y GPT, siempre que el hipervisor o el equipo físico sean compatibles. La combinación reproduce mejor un entorno actual y permite trabajar con una estructura de particiones flexible.

Cuándo separar el sistema, los datos y los registros

Separar el sistema y los datos puede facilitar las copias, las restauraciones, las cuotas y la ampliación del espacio. También evita que un crecimiento inesperado de los archivos compartidos llene directamente el volumen del sistema.

Podemos distinguir:

• Partición de arranque.
• Volumen del sistema operativo.
• Volumen de datos.
• Volumen de registros.
• Área de intercambio en Linux.
• Zona temporal para procesos de copia o restauración.

Sin embargo, crear demasiadas particiones en un disco pequeño también tiene inconvenientes. Podríamos terminar con espacio libre en un volumen y falta de capacidad en otro.

Para un laboratorio con 60 GB de disco, una configuración razonable sería dejar que el instalador cree las particiones de arranque necesarias y dedicar aproximadamente 40 o 50 GB al sistema. Si queremos practicar la separación de datos, podemos añadir un segundo disco virtual. Esta solución suele ser más flexible que fragmentar excesivamente una única unidad pequeña.

NTFS y ReFS en servidores Windows

NTFS es el sistema de archivos habitual en Windows Server. Admite permisos, cuotas, compresión, cifrado y archivos de gran tamaño. Por su compatibilidad, es una elección adecuada para el volumen del sistema y para numerosos volúmenes de datos.

ReFS está orientado a determinados escenarios de resiliencia e integridad. No sustituye automáticamente a NTFS. Antes de utilizarlo hay que comprobar que el rol y las funciones previstas sean compatibles.

En una práctica general utilizaría NTFS. Es preferible trabajar con una opción compatible y conocida antes que escoger una tecnología más específica sin una necesidad concreta.

ext4, XFS y Btrfs en servidores Linux

En Linux encontramos varias posibilidades:

• ext4 es estable y adecuado para una gran variedad de servidores.
• XFS se utiliza habitualmente en determinados entornos y ofrece un buen comportamiento con volúmenes y archivos grandes.
• Btrfs incorpora funciones avanzadas, como instantáneas y comprobaciones, aunque su conveniencia depende de la distribución.
• swap proporciona espacio de intercambio y forma parte del diseño de almacenamiento.

Para un servidor Linux de aula, ext4 suele ser una opción sencilla y apropiada. No necesitamos introducir complejidad si el objetivo principal consiste en aprender la instalación, la red y la administración inicial.

Para qué sirven LVM y RAID

LVM permite crear y administrar volúmenes lógicos en Linux. Facilita algunas ampliaciones y reorganizaciones sin depender únicamente de las particiones físicas tradicionales.

RAID combina varias unidades para mejorar el rendimiento, la disponibilidad o ambos. No es una copia de seguridad. Si eliminamos un archivo por error o un ataque cifra la información, el cambio puede propagarse a todos los discos del conjunto.

En Windows existen también tecnologías para administrar discos y espacios de almacenamiento. Lo importante durante la planificación es diferenciar tres conceptos:

• Capacidad.
• Disponibilidad.
• Copia de seguridad.

Añadir discos no resuelve por sí solo los tres problemas.

Ejemplo de particionado para un servidor de aula

Nuestro diseño podría quedar así:

Volumen	Tamaño orientativo	Sistema de archivos	Uso
Arranque o EFI	Según el instalador	FAT32 u otro requerido	Inicio del sistema
Sistema	50 GB	NTFS o ext4	Sistema y herramientas
Datos	Segundo disco o espacio restante	NTFS, ext4 o XFS	Prácticas y recursos
Swap	Según el diseño de Linux	swap	Apoyo de memoria

Mi paso por ingeniería de software reforzó la importancia de pensar con estructura. En almacenamiento, esa estructura consiste en saber qué guardamos, cuánto puede crecer y cómo lo restauraremos. No separo volúmenes por costumbre, sino cuando la separación aporta una ventaja real.

Métodos de instalación de sistemas operativos en red

No todas las instalaciones deben realizarse del mismo modo. La elección depende del número de equipos, la frecuencia con la que repetiremos el proceso, el grado de personalización y la infraestructura disponible.

Para una sola máquina de laboratorio, la instalación manual es perfectamente válida. Para decenas de equipos idénticos, repetir el asistente uno por uno sería lento y propenso a diferencias.

Instalación manual

La instalación manual se realiza interactuando con el asistente. Elegimos el idioma, la edición, el disco, las particiones, los componentes y la configuración inicial.

Es adecuada cuando:

• Estamos aprendiendo el proceso.
• Solo tenemos uno o pocos servidores.
• Cada máquina requiere una configuración distinta.
• Necesitamos tomar decisiones durante la instalación.

Una secuencia general sería:

1. Verificar la imagen de instalación.
2. Preparar el medio de arranque.
3. Configurar UEFI o BIOS.
4. Iniciar el instalador.
5. Seleccionar idioma, edición y teclado.
6. Revisar discos y controladores.
7. Crear o seleccionar las particiones.
8. Elegir los componentes.
9. Copiar los archivos y reiniciar.
10. Proteger la cuenta administrativa.

La principal ventaja es la flexibilidad. La desventaja es que dos instalaciones realizadas manualmente pueden terminar con configuraciones diferentes.

Instalación desatendida o automatizada

Una instalación desatendida utiliza un archivo de respuestas o una configuración declarativa. Ese archivo puede definir el idioma, el nombre del equipo, las particiones, los paquetes y otras opciones.

La automatización aporta:

• Repetibilidad.
• Homogeneidad.
• Menos errores manuales.
• Mayor facilidad para auditar el proceso.
• Ahorro de tiempo en despliegues frecuentes.

Windows dispone de mecanismos para utilizar archivos de respuesta y herramientas de despliegue. En Linux pueden utilizarse sistemas como autoinstall, cloud-init o Kickstart, dependiendo de la distribución.

Debemos evitar guardar contraseñas o secretos sin protección. También conviene probar la configuración en una máquina virtual aislada antes de utilizarla en varios equipos.

Instalación por red mediante PXE

La instalación por red permite arrancar un equipo sin utilizar un USB o DVD local. El cliente obtiene una configuración de red y descarga el cargador o el instalador desde un servidor.

El proceso general es:

1. El cliente arranca desde la interfaz de red.
2. Recibe una dirección y los datos de arranque.
3. Descarga el cargador.
4. Accede a la imagen o al instalador.
5. Continúa de forma manual o automatizada.

Este método puede apoyarse en DHCP, PXE, TFTP, HTTP y repositorios de imágenes.

Es especialmente interesante en aulas y organizaciones con numerosos equipos. No obstante, requiere una infraestructura bien configurada y controles que eviten el despliegue sobre máquinas no autorizadas.

Clonación de equipos y máquinas virtuales

La clonación copia una instalación preparada a otras máquinas. Es rápida y útil cuando el hardware o las máquinas virtuales son homogéneos.

Antes de capturar la imagen maestra debemos:

• Instalar solo los componentes comunes.
• Aplicar las actualizaciones necesarias.
• Eliminar datos personales y archivos temporales.
• Generalizar el sistema cuando proceda.
• Apagar correctamente la máquina.
• Capturar la imagen.
• Personalizar cada copia después del despliegue.

En Windows, Sysprep puede utilizarse para preparar una instalación reutilizable. Clonar una máquina sin generalizar puede duplicar nombres, identificadores, claves o configuraciones de red.

Qué método elegir en cada escenario

Escenario	Método recomendado
Un servidor de laboratorio	Instalación manual
Varios servidores con configuración repetida	Instalación automatizada
Aula con numerosos equipos	Instalación por red
Máquinas virtuales idénticas	Plantilla o clonación
Equipos con hardware muy diferente	Manual o automatizada con controladores adecuados

La instalación de sistemas operativos en red no mejora por utilizar el método más complejo. Mejora cuando elegimos el procedimiento que mejor encaja con el escenario.

Cómo verificar una imagen ISO antes de instalarla

La imagen debe proceder de una fuente legítima o autorizada. También conviene comprobar su integridad mediante una suma hash.

En Linux:

sha256sum nombre-imagen.iso

En PowerShell:

Get-FileHash .\nombre-imagen.iso -Algorithm SHA256

El resultado debe compararse con el valor publicado por la fuente correspondiente. Esta comprobación ayuda a detectar archivos incompletos o modificados.

Cómo instalar un servidor en una máquina virtual

La virtualización es especialmente útil para aprender. Nos permite crear servidores y clientes dentro de un entorno aislado, repetir la instalación y probar configuraciones sin modificar directamente el equipo físico.

Un hipervisor administra las máquinas virtuales. El equipo físico es el anfitrión y el sistema instalado dentro de la máquina es el invitado.

Diferencias entre hipervisores de tipo 1 y tipo 2

Los hipervisores de tipo 1 se ejecutan directamente sobre el hardware. Son habituales en entornos dedicados a virtualización de servidores.

Los de tipo 2 funcionan como una aplicación sobre el sistema operativo del anfitrión. Son apropiados para formación, pruebas y laboratorios personales.

Tipo	Funcionamiento	Uso habitual
Tipo 1	Directamente sobre el hardware	Centros de datos y servidores
Tipo 2	Sobre un sistema operativo anfitrión	Aula, pruebas y formación

Para una práctica en un ordenador personal, un hipervisor de tipo 2 suele ser suficiente.

Cuánta CPU, memoria y capacidad de disco asignar

Debemos asignar recursos sin dejar al anfitrión sin capacidad para funcionar.

Una configuración inicial para nuestro laboratorio podría ser:

• 2 CPU virtuales.
• 4 GB de RAM.
• Disco virtual de 60 GB.
• Firmware UEFI.
• Una o dos interfaces de red.
• Imagen ISO montada temporalmente.

Estas cifras son orientativas. Si el anfitrión dispone de poca memoria, no debemos asignarla casi por completo al invitado. Tampoco conviene crear múltiples máquinas virtuales sin comprobar antes el espacio libre.

Los discos virtuales pueden ser de tamaño fijo o crecer dinámicamente. El crecimiento dinámico ahorra espacio al principio, aunque el archivo aumentará conforme se escriban datos.

NAT, puente, red interna o solo anfitrión

El modo de red determina con quién puede comunicarse la máquina virtual.

Modo	Comportamiento	Uso
NAT	Sale a Internet mediante el anfitrión	Descargar actualizaciones
Puente	Aparece en la red física	Acceso desde equipos reales
Red interna	Solo comunica máquinas del laboratorio	Prácticas servidor-cliente
Solo anfitrión	Comunica con el anfitrión	Administración local

Para nuestro ejemplo podemos utilizar dos adaptadores:

• Un adaptador NAT para aplicar actualizaciones.
• Un adaptador de red interna para comunicar el servidor con los clientes.

Cuando queramos comprobar el aislamiento, podremos desconectar temporalmente el adaptador NAT.

Cómo crear un laboratorio servidor-cliente

El procedimiento sería:

1. Crear una carpeta para el proyecto.
2. Crear la máquina virtual del servidor.
3. Asignar CPU, memoria y disco.
4. Configurar UEFI.
5. Añadir los adaptadores de red.
6. Montar la imagen ISO.
7. Instalar el sistema operativo.
8. Crear una máquina virtual cliente.
9. Conectar ambas máquinas a la misma red interna.
10. Configurar sus direcciones IP.
11. Comprobar la comunicación en ambos sentidos.

En clase trabajo los conceptos técnicos desde la práctica y con objetivos claros. Un laboratorio virtual encaja bien con ese enfoque porque permite observar las consecuencias de cada cambio y repetir el procedimiento cuando algo falla.

Instantáneas: cuándo utilizarlas y por qué no son copias

Una instantánea registra el estado de una máquina en un momento determinado. Puede ser útil antes de aplicar un cambio importante durante una práctica.

Sin embargo, no conviene mantener largas cadenas de instantáneas sin una finalidad clara. Consumen espacio, pueden afectar al rendimiento y dependen del almacenamiento del hipervisor.

Una instantánea tampoco sustituye a una copia de seguridad. Si se pierde o se daña el almacenamiento que contiene la máquina, podríamos perder tanto la máquina como sus instantáneas.

Instalación paso a paso de un sistema operativo en red

Una vez terminada la planificación, podemos comenzar la instalación. El procedimiento exacto varía entre Windows Server y Linux, pero la lógica general es similar.

1. Prepara el medio y configura el arranque

Descargamos la imagen autorizada, verificamos su integridad y preparamos el medio:

• ISO montada en una máquina virtual.
• Memoria USB.
• DVD, cuando proceda.
• Arranque PXE.
• Plantilla virtual.

Después configuramos el orden de arranque y comprobamos si utilizaremos BIOS o UEFI. Si hemos elegido GPT, lo habitual será trabajar con UEFI.

2. Inicia el instalador

Seleccionamos el idioma, la distribución del teclado, la zona o las preferencias básicas que presente el asistente.

También debemos comprobar que la edición y la arquitectura coinciden con la planificación. Elegir una edición incorrecta puede limitar funciones, virtualización o licenciamiento.

3. Comprueba los discos

Antes de borrar o crear particiones, verificamos que el instalador reconoce todos los discos.

Si no aparece una unidad, debemos revisar:

• La controladora.
• El modo configurado en el firmware.
• El controlador necesario.
• La conexión física o virtual.
• El estado del dispositivo.

No conviene continuar esperando que el disco aparezca después. La causa debe resolverse antes de escribir datos.

4. Crea las particiones y los sistemas de archivos

Aplicamos el diseño preparado previamente. En nuestro laboratorio podemos dejar que el instalador cree las particiones de arranque y utilizar un volumen principal para el sistema.

Si disponemos de un segundo disco virtual, podemos reservarlo para datos. Así podremos practicar su montaje, sus permisos o sus cuotas posteriormente.

5. Selecciona los componentes

Instalamos únicamente lo necesario. Cada paquete o interfaz adicional aumenta el consumo, el mantenimiento y los elementos que debemos actualizar.

Podemos optar por:

• Interfaz gráfica, más cómoda para una primera aproximación.
• Instalación mínima, con menos componentes.
• Herramientas de administración remota.
• Utilidades de diagnóstico.
• Controladores requeridos.

Los roles principales pueden añadirse después de estabilizar el sistema base.

6. Completa la copia y protege la cuenta administrativa

El instalador copiará los archivos y reiniciará la máquina. Durante esta fase debemos crear o proteger la cuenta administrativa inicial.

La contraseña debe ser robusta y no debe compartirse entre varias personas. Si el sistema permite crear una cuenta personal con privilegios administrativos, es preferible utilizarla para las tareas habituales en lugar de trabajar siempre con la cuenta integrada.

7. Retira el medio y comprueba el primer arranque

Después de instalar, retiramos la ISO o modificamos el orden de arranque para evitar volver al instalador.

En el primer inicio comprobaremos:

• Que no aparecen errores graves.
• Que la fecha y la hora son coherentes.
• Que los discos están disponibles.
• Que la interfaz de red es reconocida.
• Que podemos iniciar sesión.
• Que el sistema muestra la edición esperada.

El primer arranque no significa que la instalación haya terminado. Solo confirma que el sistema base puede iniciarse.

Configuración inicial del servidor después de instalarlo

La configuración posterior convierte un sistema recién instalado en una máquina preparada para prestar servicios.

Yo no considero finalizada una instalación porque aparezca el escritorio o la terminal. El servidor debe tener una identidad definitiva, una red correcta, una hora sincronizada, actualizaciones aplicadas y un acceso administrativo protegido.

Asigna un nombre definitivo al servidor

El nombre debe ser:

• Único.
• Comprensible.
• Relativamente corto.
• Coherente con la política de la organización.

Para nuestro ejemplo utilizaremos SRV-AULA-01.

Otros nombres podrían ser:

SRV-FIC-01
SRV-DC-01
SRV-LNX-WEB01

Conviene fijar el nombre antes de integrar el equipo en un dominio o instalar determinados servicios.

En Windows Server podemos utilizar:

Rename-Computer -NewName "SRV-AULA-01" -Restart

En Linux:

sudo hostnamectl set-hostname srv-aula-01

Configura la fecha, la zona horaria y NTP

Una hora incorrecta afecta a los registros, la autenticación y los certificados. También dificulta relacionar una incidencia con los eventos generados por diferentes equipos.

En Linux podemos consultar el estado con:

timedatectl

Debemos seleccionar la zona horaria adecuada y utilizar un origen NTP autorizado.

Establece una dirección IP estática y los servidores DNS

Un servidor suele necesitar una dirección predecible. En nuestro ejemplo:

Dirección: 192.168.50.10
Prefijo: /24
Puerta de enlace: 192.168.50.1

En Windows podemos consultar la configuración:

Get-NetIPConfiguration
Get-NetAdapter

Y configurar una dirección:

New-NetIPAddress -InterfaceAlias "Ethernet" `
  -IPAddress 192.168.50.10 `
  -PrefixLength 24 `
  -DefaultGateway 192.168.50.1

Para configurar DNS:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" `
  -ServerAddresses 192.168.50.1

En Linux podemos consultar las interfaces y rutas:

ip address
ip route

Un ejemplo conceptual con Netplan sería:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 192.168.50.10/24
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Antes de aplicarlo definitivamente podemos utilizar:

sudo netplan try
sudo netplan apply

Al cambiar la red remotamente existe el riesgo de perder la conexión. Es recomendable conservar acceso a la consola del hipervisor o al equipo físico.

Instala controladores y herramientas de integración

Comprobamos si el sistema reconoce correctamente:

• Interfaces de red.
• Controladora de almacenamiento.
• Dispositivos virtuales.
• Resolución y consola.
• Sincronización con el hipervisor.

Las herramientas de integración pueden mejorar el funcionamiento de una máquina virtual, pero deben ser compatibles con el sistema instalado.

Configura cuentas administrativas seguras

No debemos compartir una única contraseña administrativa entre todo el equipo.

Conviene:

• Crear cuentas personales.
• Limitar los privilegios.
• Revisar los grupos administrativos.
• Deshabilitar cuentas innecesarias.
• Proteger las credenciales.
• Registrar quién realiza cada cambio.

Habilita el acceso remoto

SSH es habitual en Linux y permite administrar el servidor mediante terminal. En Windows podemos utilizar escritorio remoto, PowerShell Remoting u otras herramientas.

El acceso remoto debe habilitarse después de configurar las credenciales, la red y el cortafuegos. También debe probarse desde un cliente autorizado antes de cerrar la consola local.

Mantén activo el cortafuegos

Desactivar el cortafuegos por completo no es una solución adecuada para un problema de conectividad.

Si un servicio necesita recibir conexiones, debemos crear una regla concreta para:

• El puerto necesario.
• El protocolo correcto.
• Los orígenes autorizados.
• El perfil de red correspondiente.

En Linux podemos revisar los puertos en escucha:

ss -tulpen

En Windows:

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort

Instala únicamente los roles y paquetes necesarios

Una vez estable y actualizado el sistema base, instalamos los roles previstos. No conviene añadir servicios “por si acaso”.

Cada componente implica:

• Consumo de recursos.
• Actualizaciones.
• Configuración.
• Registros.
• Posibles vulnerabilidades.
• Trabajo de mantenimiento.

Crea una línea base del estado inicial

La línea base registra cómo se encuentra el servidor cuando sabemos que funciona correctamente.

Debe incluir:

• Versión y edición.
• Nombre.
• Fecha, hora y NTP.
• Direcciones y rutas.
• DNS.
• Discos y espacio libre.
• Paquetes y roles.
• Servicios activos.
• Puertos en escucha.
• Reglas relevantes del cortafuegos.
• Uso de CPU y memoria.
• Actualizaciones y reinicios pendientes.

Esta información será útil cuando necesitemos comparar el estado normal con el estado durante una incidencia.

Configuración inicial en Windows Server y Linux Server

Los nombres de las herramientas cambian, pero los objetivos son los mismos: identificar el sistema, configurar la red, actualizar, proteger el acceso y comprobar el funcionamiento.

Comandos básicos para Windows Server

Información general:

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsArchitecture

Configuración de red:

Get-NetIPConfiguration
Get-NetAdapter
Get-DnsClientServerAddress

Puertos en escucha:

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort

Actualizaciones instaladas:

Get-HotFix |
  Sort-Object InstalledOn -Descending |
  Select-Object -First 10

Estos comandos permiten reunir parte de la información necesaria para la línea base y para el parte de instalación.

Comandos básicos para Linux Server

Información del sistema:

uname -a
cat /etc/os-release
lscpu
free -h
lsblk -f

Red:

ip address
ip route

Hora:

timedatectl

Puertos:

ss -tulpen

La terminal no debe utilizarse como una colección de órdenes memorizadas. Cada comando debe responder a una pregunta. Por ejemplo, ip address nos indica qué direcciones tienen las interfaces, mientras que ip route muestra por dónde intentará salir el tráfico.

Mi experiencia docente me ha enseñado que explicar sin complicar no significa eliminar la precisión. Significa relacionar cada herramienta con una finalidad clara.

Cómo actualizar un sistema operativo de servidor con seguridad

Un servidor recién instalado puede necesitar actualizaciones de seguridad, mantenimiento, controladores o firmware. Aplicarlas es importante, pero no debe hacerse sin control.

Una actualización también puede introducir cambios, requerir un reinicio o afectar a la compatibilidad de una aplicación.

Tipos de actualizaciones

Podemos distinguir:

• Actualizaciones de seguridad.
• Actualizaciones de calidad o mantenimiento.
• Controladores.
• Firmware.
• Actualizaciones de características.
• Cambios de versión.

Una actualización mayor no debe tratarse como una actualización rutinaria. Puede cambiar requisitos, configuraciones y compatibilidades.

Comprueba las copias y define una ventana

Antes de actualizar:

1. Revisamos el estado actual.
2. Comprobamos el espacio libre.
3. Verificamos las copias.
4. Confirmamos el procedimiento de restauración.
5. Revisamos la compatibilidad.
6. Definimos una ventana de mantenimiento.
7. Informamos a las personas afectadas.
8. Anotamos la versión anterior.

En un laboratorio podemos crear una instantánea controlada, pero recordando que no sustituye a la copia de seguridad.

Actualiza Windows Server

Windows Server puede actualizarse mediante sus herramientas gráficas, PowerShell o sistemas centralizados.

Después debemos:

• Reiniciar si es necesario.
• Comprobar los servicios.
• Revisar los eventos.
• Probar la conectividad.
• Registrar el resultado.

Para consultar información:

Get-HotFix |
  Sort-Object InstalledOn -Descending |
  Select-Object -First 10

También podemos utilizar:

systeminfo

Actualiza Linux Server

En una distribución basada en Debian o Ubuntu:

sudo apt update
apt list --upgradable
sudo apt upgrade

Para comprobar si se recomienda reiniciar:

[ -f /var/run/reboot-required ] &&
cat /var/run/reboot-required

Antes de confirmar una actualización conviene revisar los paquetes que se modificarán.

Revisa controladores y firmware

Las actualizaciones de firmware requieren especial precaución. Deben corresponder exactamente con el dispositivo y aplicarse con una alimentación estable.

Un error o una interrupción puede impedir que el componente funcione. Por eso no debemos aplicar firmware únicamente porque existe una versión más reciente. Debe haber una razón y una comprobación de compatibilidad.

Prepara un procedimiento de reversión

Entre las opciones de recuperación encontramos:

• Desinstalar una actualización.
• Restaurar una copia.
• Recuperar desde un medio externo.
• Volver a una instantánea en un laboratorio.
• Reinstalar y restaurar los datos.

Después de actualizar no basta con comprobar que el servidor arranca. Hay que probar los servicios que presta.

Cómo comprobar la conectividad entre el servidor y los clientes

La instalación de sistemas operativos en red no termina hasta que demostramos que el servidor puede comunicarse con los clientes y que estos pueden acceder a los servicios previstos.

El diagnóstico debe realizarse por capas. Cambiar al mismo tiempo la dirección, el DNS, el cortafuegos y el servicio dificulta saber qué estaba fallando.

En clase insisto en que cada prueba debe responder a una pregunta concreta. Primero comprobamos la interfaz; después la dirección, la ruta, el DNS y el servicio. Esta secuencia convierte un problema amplio en varias comprobaciones pequeñas.

Revisa la interfaz y la configuración IP

En Windows:

ipconfig /all
Get-NetIPConfiguration

En Linux:

ip address
ip route

Debemos comprobar:

• Que la interfaz está activa.
• Que tiene una dirección válida.
• Que el prefijo coincide con la red.
• Que la puerta de enlace es correcta.
• Que los DNS son los previstos.

Una dirección 169.254.x.x en un entorno que utiliza DHCP puede indicar que el equipo no ha recibido una configuración del servidor.

Comprueba la pila TCP/IP local

IPv4:

127.0.0.1

IPv6:

::1

Windows:

ping 127.0.0.1

Linux:

ping -c 4 127.0.0.1

Esta prueba comprueba el funcionamiento local de la pila TCP/IP. No demuestra que exista comunicación con la red.

Prueba la propia dirección

Después hacemos ping a la dirección asignada al servidor. Esto ayuda a comprobar que la interfaz local responde.

Prueba otro equipo de la misma red

Desde el servidor podemos hacer ping al cliente, y desde el cliente al servidor.

Servidor:

192.168.50.10

Cliente de ejemplo:

192.168.50.20

Si ambos están en la red 192.168.50.0/24, deberían comunicarse directamente, siempre que las interfaces y los cortafuegos lo permitan.

Comprueba la puerta de enlace

ping 192.168.50.1

Si alcanzamos otros equipos de la red local, pero no la puerta de enlace, debemos revisar la dirección del router, el prefijo, la VLAN y la configuración del adaptador.

Comprueba el acceso por dirección IP

Para separar el enrutamiento de la resolución de nombres, primero probamos un destino por IP.

Windows:

tracert 8.8.8.8

Linux:

tracepath 8.8.8.8

En un entorno aislado no es necesario probar un destino externo. Podemos utilizar únicamente los equipos del laboratorio.

Verifica la resolución DNS

En Windows:

nslookup servidor.ejemplo.local

En Linux:

getent hosts servidor.ejemplo.local
dig servidor.ejemplo.local

Si el acceso por IP funciona, pero el acceso por nombre falla, el problema probablemente se encuentra en la configuración DNS, los registros o la caché.

Prueba el puerto y el servicio final

El ping no confirma que una aplicación esté funcionando.

En Windows:

Test-NetConnection 192.168.50.10 -Port 22

En Linux:

nc -zv 192.168.50.10 22

Si el servidor responde a ping, pero el puerto no está accesible, debemos comprobar:

1. Si el servicio está iniciado.
2. Si escucha en el puerto correcto.
3. Si está enlazado a la interfaz adecuada.
4. Si el cortafuegos permite la conexión.
5. Si existe conectividad en ambos sentidos.

Problemas frecuentes después de instalar el servidor

Las incidencias de red suelen parecer más complejas cuando intentamos resolverlas sin seguir un orden.

El equipo no recibe una dirección IP válida

Posibles causas:

• DHCP no disponible.
• Adaptador desconectado.
• Red virtual incorrecta.
• VLAN equivocada.
• Cable o puerto defectuoso.
• Interfaz deshabilitada.

Debemos revisar primero el enlace y después la configuración.

El servidor llega a Internet, pero no se comunica con los clientes

En una máquina virtual puede ocurrir cuando el servidor utiliza NAT y los clientes están conectados a una red interna distinta.

La solución no consiste en modificar el DNS. Debemos comprobar que las máquinas comparten al menos un adaptador dentro de la misma red virtual.

Se puede acceder por IP, pero no por nombre

Este síntoma apunta a DNS.

Revisaremos:

• DNS configurado en el cliente.
• Registro del servidor.
• Sufijo de búsqueda.
• Caché.
• Resolución mediante nslookup, dig o getent.

El ping funciona, pero el servicio no responde

Posibles causas:

• Servicio detenido.
• Puerto incorrecto.
• Cortafuegos.
• Aplicación escuchando solo en localhost.
• Restricciones de acceso.
• Error de configuración.

Debemos probar el puerto y consultar los registros del servicio.

La conexión es intermitente

Podría deberse a:

• Direcciones duplicadas.
• Pérdida de paquetes.
• Saturación.
• Problemas del adaptador.
• Cambios de red.
• Errores en el conmutador.

La documentación de las horas exactas y de los equipos afectados puede ayudar a encontrar un patrón.

Solo falla uno de los clientes

Si el resto de los equipos se conecta correctamente, debemos centrar la revisión en el cliente afectado:

• Dirección.
• Máscara.
• Puerta de enlace.
• DNS.
• Cortafuegos local.
• Estado de la interfaz.
• Caché.
• Credenciales.

Comparar su configuración con la de un cliente funcional suele resultar más útil que modificar el servidor.

Cómo documentar la instalación y las incidencias

La documentación convierte una intervención individual en un procedimiento reproducible. Permite saber qué se hizo, por qué se hizo y qué resultado produjo.

Durante mi trabajo en consultoría participé en soporte, administración, documentación y mejora de procesos. Esa experiencia reforzó una idea que aplico también a los servidores: una configuración que solo entiende quien la realizó es difícil de mantener.

Documentos mínimos de una instalación

Como mínimo, conviene conservar:

• Plan de instalación.
• Inventario.
• Matriz de compatibilidad.
• Esquema de almacenamiento.
• Ficha de red.
• Registro de instalación.
• Registro de cambios.
• Parte de incidencias.
• Informe final.

No es necesario que todos sean documentos separados. En un laboratorio pueden integrarse dentro de un único informe bien organizado.

Qué debe incluir un parte de instalación

Campo	Contenido
Identificación	Servidor, ubicación, responsable y fecha
Objetivo	Necesidad que motiva la instalación
Hardware o VM	CPU, RAM, discos, red y firmware
Sistema	Edición, versión, arquitectura y origen
Almacenamiento	Particiones, volúmenes y formatos
Red	Nombre, IP, prefijo, gateway y DNS
Componentes	Roles, paquetes y controladores
Actualizaciones	Fecha, resultado y reinicios
Pruebas	Arranque, conectividad y servicios
Incidencias	Síntomas, causa y solución
Estado final	Apto, condicionado o pendiente

Cómo describir una incidencia correctamente

Una descripción como “el servidor no funciona” no ofrece información suficiente.

Es mejor registrar:

• Fecha y hora.
• Equipo afectado.
• Síntoma observable.
• Usuarios afectados.
• Cambios recientes.
• Pruebas realizadas.
• Resultados.
• Causa confirmada o pendiente.
• Solución aplicada.
• Verificación final.

Por ejemplo:

El cliente PC-AULA-07 no resuelve el nombre SRV-AULA-01 desde las 10:15. El ping a 192.168.50.10 funciona, pero la consulta de nombres devuelve un error.

Esta descripción separa claramente la conectividad IP del problema de resolución.

Qué capturas y evidencias debes conservar

Las evidencias pueden incluir:

• Configuración IP del servidor.
• Configuración IP del cliente.
• Ping en ambos sentidos.
• Resolución de nombres.
• Prueba de puerto.
• Estado del servicio.
• Particionado.
• Versión del sistema.
• Actualizaciones instaladas.

Las capturas deben mostrar el contexto necesario y no exponer contraseñas, claves ni datos personales.

Cómo organizar los archivos y controlar sus versiones

Una estructura posible sería:

Tema1_Instalacion_SOR_ApellidoNombre/
├── 01_Planificacion.pdf
├── 02_Capturas/
├── 03_Parte_Instalacion.docx
├── 04_Incidencias.docx
└── 05_Configuracion_Red.txt

Es mejor utilizar nombres descriptivos y fechas que archivos llamados final.docx, final2.docx o definitivo_ahora_si.docx.

Lista de comprobación final

Antes de instalar

• Objetivo y servicios definidos.
• Usuarios y carga estimados.
• CPU y RAM compatibles.
• Discos revisados.
• Tarjeta de red reconocible.
• Firmware configurado.
• Imagen legítima y verificada.
• Nombre e IP reservados.
• Particionado planificado.
• Método de instalación elegido.
• Procedimiento de recuperación previsto.

Durante la instalación

• Edición y arquitectura correctas.
• Discos detectados.
• Particiones coherentes.
• Componentes mínimos.
• Cuenta administrativa protegida.
• Reinicios completados.
• Medio de instalación retirado.

Después del primer arranque

• Nombre definitivo.
• Fecha y zona horaria.
• NTP.
• Dirección IP.
• Puerta de enlace.
• DNS.
• Controladores.
• Actualizaciones.
• Acceso remoto.
• Cortafuegos.
• Roles necesarios.
• Línea base.

Antes de considerar el servidor terminado

• Comunicación con los clientes.
• Resolución de nombres.
• Acceso al puerto.
• Servicio final probado.
• Eventos revisados.
• Copia o recuperación comprobada.
• Parte de instalación completado.
• Incidencias registradas.
• Estado final documentado.

Conclusión: instalar un servidor es un proceso, no un asistente

La instalación de sistemas operativos en red debe entenderse como un proceso completo. El asistente es solamente una de sus fases.

Primero analizamos qué debe hacer el servidor. Después comprobamos la compatibilidad, diseñamos el almacenamiento y preparamos la red. Elegimos un método de instalación coherente, instalamos los componentes necesarios y protegemos el acceso administrativo.

Tras el primer arranque todavía quedan tareas importantes: configurar el nombre, la hora, la dirección IP, los DNS, las actualizaciones, el acceso remoto y el cortafuegos.

Finalmente, debemos comprobar la comunicación con los clientes, probar los servicios y conservar evidencias. Si aparece una incidencia, seguimos un orden: interfaz, configuración IP, red local, gateway, DNS y servicio.

Mi trayectoria entre ingeniería, consultoría y docencia me lleva a trabajar la tecnología con una idea sencilla: debe ser útil, clara y aplicable. En una instalación de servidor, eso significa que la solución debe funcionar, poder explicarse y quedar preparada para que otra persona pueda mantenerla.

La secuencia que conviene recordar es:

analizar → planificar → instalar → configurar → comprobar → documentar

Cuando respetamos este orden, la instalación deja de ser una sucesión de pantallas y se convierte en un procedimiento técnico controlado.

Preguntas frecuentes sobre la instalación de sistemas operativos en red

¿Qué diferencia hay entre un sistema operativo de escritorio y uno en red?

El sistema de escritorio está pensado principalmente para el uso directo de una persona. Un sistema operativo en red presta servicios a otros equipos y ofrece mecanismos de administración centralizada, acceso remoto, seguridad, monitorización y recuperación.

¿Cuánta RAM necesita un servidor?

Depende de los usuarios, los servicios y la carga. Para una práctica básica puede comenzarse con 4 GB, pero esa cifra no debe utilizarse como referencia para un servidor de producción. Debemos consultar los requisitos de la versión elegida y medir la carga real.

¿Es mejor utilizar MBR o GPT?

GPT es la opción preferente para instalaciones modernas con UEFI. MBR se reserva principalmente para equipos antiguos o escenarios que requieren compatibilidad específica.

¿Conviene separar el sistema y los datos?

Sí, cuando la capacidad y el escenario lo permiten. Facilita copias, restauraciones y ampliaciones. No obstante, dividir demasiado un disco pequeño puede provocar falta de espacio en algunos volúmenes.

¿Qué método de instalación es el más adecuado?

La instalación manual es apropiada para uno o pocos servidores. La automatizada y la instalación por red resultan más eficientes cuando debemos repetir configuraciones. La clonación es útil con equipos o máquinas virtuales homogéneos.

¿Qué ventajas ofrece una máquina virtual?

Permite repetir la instalación, crear redes aisladas, asignar recursos de forma controlada y restaurar estados durante una práctica sin modificar directamente el equipo físico.

¿Por qué el servidor responde a ping, pero no ofrece el servicio?

Porque el ping solo confirma un nivel de conectividad. El servicio puede estar detenido, utilizar otro puerto, escuchar únicamente en una interfaz local o encontrarse bloqueado por el cortafuegos.

¿RAID sustituye a una copia de seguridad?

No. RAID puede mejorar la disponibilidad o el rendimiento, pero no protege frente a eliminaciones, corrupción, ataques o errores que afecten a todo el conjunto.

¿Una instantánea sustituye a una copia de seguridad?

No. La instantánea suele depender del mismo almacenamiento que la máquina virtual y puede perderse junto con ella.

¿Qué documentación debe guardarse después de instalar?

Conviene conservar el plan, la matriz de compatibilidad, el esquema de discos, la configuración de red, las versiones, las actualizaciones, las pruebas, las incidencias y el estado final del servidor.