Tutorial completo de Feature on Demand en Windows

Las Features on Demand (características bajo demanda) de Windows son uno de esos cambios silenciosos que Microsoft introdujo hace ya varias versiones y que, sin hacer mucho ruido, han cambiado por completo la forma de instalar y mantener roles, características y componentes opcionales en Windows 10, Windows 11 y Windows Server. Si administras servidores o imágenes corporativas, entender bien cómo funcionan ya no es opcional.

En lugar de tener todo el sistema cargado de binarios que quizá no vas a usar jamás, Windows permite “quitar y poner” funciones desde repositorios locales, ISOs específicas o directamente desde Windows Update. Eso ahorra espacio en disco, mejora la seguridad y te da mucha más flexibilidad a la hora de desplegar o reparar equipos y servidores, tanto en línea como de forma desatendida.

Qué es exactamente Feature(s) on Demand en Windows

Features on Demand (FOD) es el nombre que Microsoft da a los paquetes de características opcionales que se pueden agregar o quitar de un sistema Windows en cualquier momento. Esto incluye desde recursos de idioma (mano alzada, reconocimiento de escritura, texto a voz) hasta componentes como .NET Framework 3.5 (NetFx3), herramientas de administración, consolas gráficas y muchas funciones del escritorio clásico en Server Core.

La idea de fondo es simple: los archivos necesarios para esas funciones se pueden eliminar del sistema (se quita la “carga” o payload) para ahorrar espacio, y cuando una aplicación o un administrador los necesita, Windows puede:

• Descargar el paquete desde Windows Update, si el equipo tiene acceso a Internet.
• Tomarlo de un recurso compartido de red o repositorio interno.
• Leerlo desde un medio de instalación o ISO de Features on Demand.

En entornos corporativos esto es vital: puedes crear imágenes de referencia ligeras, definir dónde se buscan los binarios mediante Directiva de grupo y controlar perfectamente qué funciones existen en los equipos y desde dónde se instalan. Nada de ventanas pidiendo un DVD a mitad de un despliegue.

Cómo funciona el almacenamiento de características (Side-by-side store y WinSxS)

Cuando se habla de Features on Demand es imposible no mencionar el almacén side-by-side y la carpeta WinSxS. En los sistemas modernos de Microsoft, WinSxS es el repositorio interno donde se guardan múltiples versiones de bibliotecas, componentes del sistema, roles y características.

Históricamente, este enfoque nació para solucionar el famoso “DLL hell”: antes, una aplicación podía depender de una versión concreta de una DLL y, si otra aplicación instalaba una versión distinta, todo se rompía. El almacén side-by-side permite que convivan varias versiones de un mismo componente, y que cada aplicación use la que le corresponde, sin sobrescribir archivos de otros programas.

Con Windows Server modernos y Windows 10/11, ese almacén side-by-side también incluye los binarios de roles y características. Cuando instalas una función desde el administrador de servidores, PowerShell o DISM, los archivos se copian desde WinSxS (o desde un repositorio externo) al sistema. Si usas Features on Demand para quitar carga, estás eliminando del equipo archivos de funciones que no están instaladas, lo que reduce el tamaño de WinSxS y del sistema en general.

Un detalle interesante es que, cuando un archivo existe tanto en el sistema como en el almacén side-by-side, físicamente solo se guarda una copia en disco, aunque lógicamente aparezca en diferentes rutas. Esto ayuda a contener el crecimiento del tamaño del sistema, pero aun así en servidores con muchos roles podría acumularse mucha “carga” innecesaria si no gestionas bien las Features on Demand.

Features on Demand en Windows Server 2012, 2016, 2019 y posteriores

Las Features on Demand se introdujeron en Windows 8 y Windows Server 2012. Desde entonces, la forma de trabajar es parecida: puedes eliminar los archivos de funciones (payload) y, más tarde, instalarlos desde una ubicación remota, Windows Update o el propio medio de instalación. Esto se aplica tanto a servidores físicos como virtuales y también a imágenes WIM o discos VHD sin conectar.

En entornos de servidor, el mecanismo típico para gestionar estas funciones es PowerShell con los cmdlets Install-WindowsFeature y Uninstall-WindowsFeature, junto con las herramientas de DISM. En Windows Server 2012/2012 R2, cuando los binarios de una característica no están disponibles localmente, el sistema intenta localizarlos siguiendo este orden:

1. Ruta de origen especificada por el propio administrador (en el asistente de Roles y características o en el comando DISM/PowerShell).
2. Configuración de la Directiva de grupo “Especificar configuración de instalación de componentes opcionales y reparación de componentes”.
3. Búsqueda en Windows Update si lo permiten las políticas y la conectividad.

Es posible anular este comportamiento por defecto indicando rutas de origen alternativas, ajustando políticas o limitando el acceso a Windows Update. De esta forma, la organización puede centralizar en un recurso compartido interno todos los archivos necesarios para instalar roles y características.

Crear un almacén de características en red (side-by-side store compartido)

Uno de los enfoques más usados en empresas es montar un repositorio compartido de características en la red, desde el que cualquier servidor puede obtener los binarios para instalar roles y funciones. Este repositorio, a menudo llamado side-by-side store, no es más que una carpeta compartida con los archivos adecuados y permisos bien configurados.

El proceso típico para prepararlo es muy sencillo: primero creas una carpeta, por ejemplo \\servidor\share\sxs, y la compartes en la red. Después, copias desde el medio de instalación de Windows Server la carpeta Sources\SxS completa a esa ruta compartida. Esos archivos serán la “carga” que usarán los servidores al instalar características bajo demanda.

La clave está en los permisos: no basta con que los usuarios puedan leer la carpeta; las cuentas de equipo de los servidores que van a usar ese almacén también necesitan permisos de lectura. Esto significa que debes conceder acceso a DOMINIO\NOMBRE_SERVIDOR$ (o a un grupo que incluya esas cuentas). Dar acceso al grupo Todos puede ser tentador, pero no es lo más recomendable desde el punto de vista de seguridad.

Una vez creado, puedes indicar este repositorio como ruta de origen al instalar funciones desde el asistente de Roles y características, desde PowerShell o desde DISM. Así, cuando el sistema no encuentre los binarios localmente, se dirigirá primero a ese almacén compartido en lugar de salir a Internet.

Instalación de .NET Framework 3.5 y otras funciones bajo demanda

Un caso muy típico con las Features on Demand es la instalación de .NET Framework 3.5 (que incluye las versiones 2.0 y 3.0). Desde Windows Server 2012 y Windows 8, los binarios de NetFx3 no vienen disponibles en el sistema por defecto; se han eliminado como parte de esa estrategia de reducir la carga inicial.

Cuando intentas habilitar .NET 3.5 sin tener los archivos, Windows Server 2012 y posteriores intentan conectarse a Windows Update para buscarlos, siempre que las directivas lo permitan. Si el servidor no tiene salida a Internet, estará obligado a obtenerlos desde un repositorio interno o medio de instalación, y ahí es donde entran en juego DISM, PowerShell y la Directiva de grupo.

De forma general, puedes instalar .NET Framework 3.5 de tres maneras: usando el cmdlet Install-WindowsFeature, el Asistente para agregar roles y características de Server Manager o la herramienta DISM. En todos los casos, la lógica es la misma: indicar la característica (NetFx3), y si hace falta, proporcionar la ruta de origen a la carpeta SxS o al archivo WIM que contiene los archivos.

Instalar .NET Framework 3.5 con PowerShell (Install-WindowsFeature)

Para muchos administradores, la forma más cómoda de manejar roles y funciones es PowerShell. Con una sesión elevada, el cmdlet Install-WindowsFeature permite habilitar .NET Framework 3.5 indicando una ruta de origen si los binarios no están en el equipo.

El flujo típico es abrir una consola de PowerShell “Ejecutar como administrador”, ya sea desde el escritorio o desde Server Core escribiendo PowerShell en el símbolo del sistema. Luego, ejecutas un comando similar a:

Install-WindowsFeature NET-Framework-Core -Source D:\Sources\SxS

En este ejemplo, la unidad D: contiene el medio de instalación de Windows Server, y la ruta Sources\SxS alberga la carga necesaria para NetFx3. Si ya tienes definida una ruta de origen predeterminada por Directiva de grupo o te vale con que intente usar Windows Update, no es obligatorio especificar el parámetro -Source, salvo que quieras forzar un repositorio concreto.

Si la política de tu organización impide salir a Internet, o si quieres asegurarte de que el servidor use siempre recursos locales, combina este enfoque con un almacén SxS en red y con la Directiva de grupo configurada para evitar descargas desde Windows Update.

Instalar .NET Framework 3.5 con el asistente de Roles y características

En entornos con interfaz gráfica, muchos admins siguen prefiriendo el clásico Asistente para agregar roles y características de Server Manager. Para instalar .NET Framework 3.5 desde ahí, seleccionas un servidor de destino (por ejemplo, uno con Windows Server 2016) y, en la página de selección de características, marcas .NET Framework 3.5.

Si las Directivas de grupo permiten el uso de Windows Update y el servidor tiene conectividad, el propio asistente intentará localizar y descargar los archivos faltantes desde Internet al pulsar en “Instalar”. No tendrás que indicar nada más. Si en cambio las políticas bloquean esa opción o prefieres otra fuente, en la pantalla de confirmación puedes usar el enlace “Especificar una ruta de acceso de origen alternativa”.

En ese campo se introduce, por ejemplo, D:\Sources\SxS\ para un medio local, o una ruta del tipo WIM:\\servidor\share\install.wim:3 si quieres tirar de un archivo WIM compartido, indicando con el número final el índice de la imagen que contiene los archivos. Tras pulsar en Aceptar y luego en Instalar, el asistente usará esa ubicación para traer el payload de .NET 3.5.

Este mismo esquema se utiliza también para instalar otras características que dependen de Features on Demand, especialmente cuando trabajas con instalaciones ligeras o servidores en redes cerradas.

Instalar .NET Framework 3.5 con DISM

La herramienta Deployment Image Servicing and Management (DISM) es la navaja suiza para administrar imágenes de Windows, tanto en línea como sin conexión. Permite habilitar o deshabilitar características, agregar paquetes y gestionar capacidades (capabilities) en FOD.

Para .NET Framework 3.5, si el equipo tiene acceso a Windows Update o ya existe una ruta de origen definida en Directiva de grupo, basta con ejecutar:

DISM /online /Enable-Feature /Featurename:NetFx3 /All

Este comando habilita NetFx3 en el sistema en ejecución. Si, por el contrario, el servidor obtiene los archivos desde el medio de instalación y no quieres que intente contactar con Windows Update ni WSUS, puedes usar:

DISM /online /Enable-Feature /Featurename:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

El parámetro /LimitAccess le dice a DISM que no busque en Windows Update ni en servidores WSUS, usando únicamente las rutas de origen indicadas. Esta forma de trabajar es especialmente útil en redes aisladas, datacenters con restricciones estrictas o cuando preparas imágenes offline montadas desde un WIM en una carpeta.

Configurar orígenes alternativos con Directiva de grupo

Para no tener que ir indicando manualmente rutas de origen cada vez que instalas una función, Windows ofrece una política específica que controla dónde buscar los archivos de características que faltan y cómo comportarse con Windows Update y WSUS.

La configuración se llama “Especificar configuración de instalación de componentes opcionales y reparación de componentes” y se encuentra en:

Configuración del equipo → Plantillas administrativas → Sistema → Especificar configuración de instalación de componentes opcionales y reparación de componentes

Al habilitarla, puedes introducir una ruta completa a una carpeta compartida o a un archivo WIM en el cuadro “Ruta de acceso del archivo de origen alternativa”. Por ejemplo:

• Carpeta compartida: \\servidor\share\carpeta
• Archivo WIM: WIM:\\servidor\share\install.wim:3 (donde 3 es el índice de la imagen con los archivos)

Además, la política incluye dos opciones clave: una para indicar que nunca se intente descargar la carga desde Windows Update y otra para que, incluso si normalmente usas WSUS, las reparaciones de componentes se descarguen directamente de Windows Update.

Con esto bien configurado, cada vez que un servidor necesite instalar una función que no tenga localmente, irá primero a tu repositorio corporativo, sin depender de que el administrador recuerde poner la ruta correcta ni de la conexión a Internet.

Quitar archivos de características con Uninstall-WindowsFeature y DISM

No todo es instalar; una parte fundamental de Features on Demand es eliminar la carga de funciones que no se usan para ahorrar espacio y reducir la superficie de ataque. En Windows Server 2012/2012 R2 y posteriores tienes dos grandes herramientas para esto: el cmdlet Uninstall-WindowsFeature y los comandos de DISM.

El cmdlet Uninstall-WindowsFeature permite tanto desinstalar la función como eliminar sus archivos de características. Si añades el parámetro -remove, el payload se borra del servidor o del VHD offline, liberando espacio en el almacén side-by-side.

Por ejemplo, para quitar los archivos del rol de Servicios de Escritorio remoto cuando ya solo queda instalado el servicio de licencias, podrías ejecutar algo como:

Uninstall-WindowsFeature -Name RDS-Licensing -ComputerName contoso_1 -Remove

En este caso, se desinstala el servicio de licencias y a continuación se eliminan los binarios asociados al rol completo de Servicios de Escritorio remoto del servidor contoso_1. Otra posibilidad es trabajar con un VHD sin conexión, desinstalando roles y quitando sus archivos directamente desde la imagen:

Uninstall-WindowsFeature -Name AD-Domain-Services,GPMC -VHD C:\WS2012VHDs\Contoso.vhd -ComputerName ContosoDC1

DISM, por su parte, permite crear imágenes WIM personalizadas en las que ya no están incluidos los archivos de ciertas características. Esto es ideal para generar medios de instalación ajustados a tus necesidades, con menos peso y con solo los componentes que realmente vas a usar en los despliegues.

Eliminar de golpe todas las cargas de funciones no usadas

En algunos escenarios, interesa ir un paso más allá y quitar del servidor todos los payloads de funciones que no estén instaladas. Esto se puede automatizar con PowerShell combinando varios comandos mediante piping.

Primero, se obtiene la lista de todas las características del servidor con Get-WindowsFeature. Luego, se filtran aquellas cuyo estado Installed sea falso usando Where-Object con un pequeño script que evalúa cada elemento de la lista. Finalmente, ese conjunto filtrado se pasa a Uninstall-WindowsFeature -Remove para eliminar todos los binarios no necesarios.

La idea es algo así como: tomar la salida de Get-WindowsFeature, filtrar donde $.Installed -eq $FALSE y encadenarlo con Uninstall-WindowsFeature -Remove. De este modo, el sistema se queda exclusivamente con la carga asociada a las funciones que realmente tienes activas, liberando una cantidad de espacio notable.

Las pruebas muestran que, en instalaciones completas, eliminar el almacén side-by-side de funciones no usadas puede ahorrar alrededor de un 10 % de espacio, y si además pasas a Server Core y limpias WinSxS, la reducción puede acercarse al 30 % en algunos casos.

Features on Demand, capacidades y repositorios en Windows 10 y Windows 11

En Windows 10 y Windows 11, Microsoft ha refinado aún más el modelo de Features on Demand; aquí se habla mucho de “capacidades” (capabilities), que se gestionan principalmente con DISM usando la opción /add-capability. Además, en escenarios concretos existen métodos para desbloquear funciones ocultas o forzar comportamientos mediante el registro.

Para Windows 10, hay un ISO de Features on Demand por cada gran versión (por ejemplo, 1809, 1903, 2004, etc.). Para Windows 11, Microsoft unificó idiomas y características opcionales en un ISO de “Languages and Optional Features”. Es importante que el ISO de FOD o L&OF coincida con la compilación de tu imagen, ya que mezclar versiones puede provocar problemas de compatibilidad.

En este contexto, Windows distingue entre dos tipos de FOD:

• FOD sin paquetes satélite: paquetes “monolíticos” donde todos los recursos (incluidos idiomas) van en un solo .cab. Se pueden agregar tanto con DISM /add-capability como con DISM /add-package.
• FOD con paquetes satélite: la parte principal es neutra en idioma y luego hay paquetes satélite para idiomas y arquitecturas. Al instalarlos, solo se agregan los satélites que aplican a tu imagen, reduciendo huella en disco. Estos solo se deben añadir con DISM /add-capability, especificando un único /CapabilityName; DISM se encarga de arrastrar todas las dependencias.

Para gestionar estas capacidades se usan comandos como /Get-Capabilities (lista de capacidades disponibles en la imagen), /Get-CapabilityInfo (detalles de una concreta) y /Remove-Capability (para quitarla). Ten en cuenta que no puedes eliminar una capacidad de la que dependen otras; Windows te lo impedirá para no dejar el sistema inconsistente.

Repositorios de FOD y uso de DISM /add-capability y /add-package

Al utilizar DISM /add-capability para preinstalar características en una imagen offline, sueles necesitar un repositorio bien formado de Features on Demand. Puedes usar directamente el ISO montado de FOD o del idioma y características opcionales, o bien exportar solo lo que necesitas a un repositorio personalizado con DISM /export-source.

Un ejemplo de flujo sería: montar la imagen de Windows (install.wim) en una carpeta, montar el ISO de FOD en otra unidad y ejecutar un comando tipo:

dism /image:C:\mount\windows /export-source /source:D: /target:C:\repository /capabilityname:App.StepsRecorder~~~~0.0.1.0

Asumiendo que D: es la unidad donde has montado el ISO de FOD, este comando extrae el paquete de la capacidad Steps Recorder, junto con la información adicional que necesita DISM, a la carpeta C:\repository. Esa carpeta se convierte en un repositorio minimizado que puedes usar como /Source al agregar capacidades en otras imágenes.

Es importante no limitarse a copiar a mano los .cab a una carpeta cualquiera: DISM requiere metadatos adicionales en el repositorio para funcionar bien, y eso es precisamente lo que asegura /export-source. De lo contrario, te arriesgas a que los comandos de /add-capability fallen o no encuentren dependencias.

Para FOD sin satélite también existe la opción de DISM /add-package, donde indicas la ruta de un .cab concreto y lo agregas como si fuera un paquete normal. Sin embargo, la práctica recomendada es unificar el procedimiento con /add-capability para todos los FOD, de forma que se gestionen de manera coherente y se resuelvan bien las dependencias, especialmente en Windows 10 y 11.

Features on Demand y compatibilidad de aplicaciones en Windows Server Core 2019

Windows Server Core ha ido ganando terreno gracias a su huella reducida, mejor seguridad y menor superficie de ataque. El problema clásico era la compatibilidad con aplicaciones y herramientas que esperaban encontrar componentes de la experiencia de escritorio. Para mitigar esto, Microsoft introdujo el paquete de compatibilidad de aplicaciones para Server Core como Feature on Demand.

Estos paquetes FoD añaden a Server Core una serie de binaries y consolas gráficas que normalmente solo estarían presentes en la edición con Desktop Experience, pero sin llegar a instalar la interfaz completa. Es una especie de punto intermedio: sigues con Server Core, pero dispones de muchas más herramientas locales para administración y diagnóstico.

Entre los componentes que puedes agregar como Features on Demand en Server Core 2019 están recursos de idioma, .NET Framework, herramientas de accesibilidad, Graphics Tools para desarrollo con Direct3D, herramientas de red (RAS, RIP Listener, SNMP), servidor OpenSSH, y una buena colección de Remote Server Administration Tools (RSAT) como ADDS/LDS Tools, DHCP, DNS, Clúster de conmutación por error, administración de GPO, IPAM, etc.

El paquete FoD de compatibilidad de aplicaciones se puede obtener de varias formas: desde Windows Update (si el servidor tiene acceso a Internet), a través de un ISO de Server FOD descargado desde el portal de licencias por volumen, el Centro de evaluación de Microsoft o Visual Studio, e incluso mediante builds Insider Preview para probar nuevas funciones antes de que lleguen a la versión final.

Instalar el paquete de compatibilidad (FoD) en Windows Server 2019 Core

En Server 2019 Core, la forma más directa de instalar el paquete de compatibilidad de aplicaciones es mediante el cmdlet Add-WindowsCapability. Si el servidor puede salir a Internet y la política lo permite, con un solo comando puedes traer el paquete completo desde Windows Update.

Por ejemplo, para instalar el paquete principal de compatibilidad de aplicaciones ServerCore.AppCompatibility basta con ejecutar:

Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0

Tras la descarga e instalación, el sistema solicitará un reinicio. Una vez reiniciado, tendrás disponibles utilidades que antes no podías ejecutar en Core, como por ejemplo Resource Monitor (resmon) o Event Viewer (eventvwr.exe), lo que hace que la gestión y solución de problemas en Server Core resulte mucho más familiar para administradores acostumbrados al entorno gráfico.

Si prefieres no depender de Windows Update, puedes montar el ISO de Server FOD (por ejemplo, adjuntándolo a la máquina virtual desde tu hipervisor) y usar Add-WindowsCapability con un parámetro -Source apuntando a la unidad del DVD virtual, combinándolo con -LimitAccess para evitar que intente contactar con Internet.

En infraestructuras virtualizadas como VMware vSphere, el flujo típico suele ser: descargar el ISO del FoD, copiarlo a un datastore, montarlo en la VM de Server Core y, dentro del servidor, localizar la unidad con el medio mediante Get-PSDrive. También puedes copiar el archivo ISO localmente al servidor y montarlo con Mount-DiskImage -ImagePath, y desde ahí instalar la capacidad correspondiente.

Esta combinación de Server Core + Feature on Demand para compatibilidad da como resultado un servidor muy ligero, seguro y eficiente, pero con las herramientas clásicas disponibles cuando hace falta, lo que ha disparado la adopción de Server Core en la versión 2019 y posteriores.

Todo este ecosistema de Features on Demand, repositorios, capacidades y políticas hace posible que planifiques desplegues mucho más limpios, con menos bloat y con un control fino de qué se instala, cuándo y desde dónde, sin perder por el camino las herramientas que necesitas para administrar y mantener tus sistemas con comodidad.