Verificación DC Server Core: identificar cada opción

¿Qué es la verificación DC Server Core?

La verificación DC Server Core consiste en determinar la opción de instalación de cada controlador de dominio a partir de evidencias recopiladas en ese host. Empiece con un inventario de DC y asocie a cada entrada el tipo de instalación local, la edición y versión del sistema operativo, la hora de recopilación y el resultado de la lectura. Una etiqueta del directorio o una captura de pantalla deja una laguna en las evidencias.

El problema inmediato es operativo: un equipo ve un recordatorio sobre Server Core en una auditoría de AD y supone que tiene una lista de máquinas que debe reinstalar. Antes de aceptar esa lista, pregunte qué observó realmente el recopilador. Un recordatorio para verificar una opción de instalación es útil, pero no demuestra que un servidor concreto utilice Desktop Experience.

Separe el resultado de esta revisión de la decisión de cambio. Una opción de instalación verificada indica qué está instalado hoy. El responsable aún debe determinar qué roles y herramientas de administración debe admitir el destino, si corresponde reinstalar y cómo se validará el cambio.

Funcionamiento: separar el inventario del directorio de las evidencias del host

Microsoft documenta Server Core y Server with Desktop Experience como opciones de instalación. Core omite la interfaz de escritorio estándar y admite la administración por línea de comandos o remota. La comparación de opciones de instalación abarca Windows Server 2016, 2019, 2022 y 2025.

El directorio y el host responden a preguntas distintas. Los atributos LDAP como operatingSystem y operatingSystemVersion ayudan a organizar un inventario. En la implementación del recopilador revisada para este artículo, no distinguen Core de Desktop Experience para una misma edición de Windows Server. Conserve esos valores como contexto; no convierta la ausencia de la subcadena «Core» en un veredicto.

La página archivada de Microsoft Determinar si Server Core está en ejecución describe la comprobación de InstallationType en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion: el valor Server Core identifica esa opción de instalación. La página también presenta GetProductInfo como su prueba programática recomendada. Sus constantes históricas de producto no deben tratarse como un inventario universal de las ediciones actuales.

Para esta revisión, conserve el resultado del registro obtenido directamente de cada host. No sobrescriba el inventario del directorio con una etiqueta supuesta. Vincule los dos conjuntos de evidencias mediante la identidad del DC para que un revisor pueda saber qué máquina se inspeccionó y cuáles siguen sin leerse.

Detección: crear un registro de evidencias por DC

Paso 1 — Fijar el inventario y su alcance

Registre el dominio, el servidor de directorio consultado, la hora de recopilación y las exclusiones junto con la lista de DC. Concilie esa lista con el inventario operativo que mantiene el equipo de directorio. Un host omitido no puede pasar a estar «verificado» simplemente porque no aparece en los datos de una auditoría.

Use una fila independiente para cada DC esperado. Si falla la lectura del directorio o no se puede conciliar el inventario, conserve ese problema de forma explícita. Evite un porcentaje de éxito o una conclusión para todo el dominio mientras exista incertidumbre sobre la población evaluada.

Un registro de evidencias útil incluye:

Estos son campos propuestos para la revisión, no una afirmación de que EtcSec los recopile todos. Guarde las evidencias mediante su proceso de administración establecido, con un acceso adecuado para los registros de configuración de los controladores de dominio.

Paso 2 — Leer el tipo de instalación en el host

Use una sesión local autorizada o su mecanismo de ejecución administrativa establecido que realice la lectura en el DC previsto. El siguiente PowerShell es un ejemplo de solo lectura creado para este artículo que implementa la comprobación del registro documentada por Microsoft. No es un comando copiado de Learn y no se ha ejecutado para este artículo.

$observedAt = [DateTime]::UtcNow.ToString('o')
$hostName = $env:COMPUTERNAME
try {
    $cv = Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -ErrorAction Stop
    $os = Get-CimInstance -ClassName Win32_OperatingSystem -ErrorAction Stop
    $readOutcome = if ([string]::IsNullOrWhiteSpace($cv.InstallationType)) {
        'InstallationType missing'
    } else {
        'Read succeeded'
    }
    [pscustomobject]@{
        HostName = $hostName
        ObservedAtUtc = $observedAt
        InstallationType = $cv.InstallationType
        Edition = $os.Caption
        Version = $os.Version
        BuildNumber = $os.BuildNumber
        ReadOutcome = $readOutcome
        ReadError = $null
    }
} catch {
    [pscustomobject]@{
        HostName = $hostName
        ObservedAtUtc = $observedAt
        InstallationType = $null
        Edition = $null
        Version = $null
        BuildNumber = $null
        ReadOutcome = 'Read failed'
        ReadError = $_.Exception.Message
    }
}

Capture la salida y asóciela con la fila del inventario. Verifique que el host indicado sea el DC previsto; ejecutar una consulta del registro en la estación de administración responde a otra pregunta. Si no se puede establecer la sesión, registre ese error de transporte o acceso por separado, porque este script local nunca llegó a ejecutarse.

El ejemplo trata de forma conservadora el fallo de una lectura combinada. Si la consulta de identidad del SO falla después de que la consulta del registro tenga éxito, devuelve una fila fallida en lugar de una observación completa. Conserve la salida de diagnóstico original al investigar esos casos y repita la lectura que falta por la vía aprobada.

Paso 3 — Interpretar los resultados sin eliminar los estados desconocidos

Una lectura satisfactoria que devuelve Server Core proporciona la evidencia descrita por Microsoft. Conserve literalmente cualquier otra cadena devuelta y determine su significado para ese host antes de tomar la decisión sobre la opción de instalación. Un valor ausente o una lectura fallida sigue siendo desconocido.

No complete manualmente las celdas desconocidas a partir de DC vecinos, plantillas de despliegue o el recuerdo de la apariencia de una sesión de inicio de sesión. Pueden orientar la investigación, pero el registro de evidencias debe seguir mostrando lo que realmente se obtuvo de cada host.

Resolver las dependencias antes de planificar una reinstalación (Remediation)

Paso 1 — Cerrar primero las lagunas en las evidencias

Asigne cada DC sin leer a un responsable que pueda obtener las evidencias del host. Mantenga visibles el motivo del fallo y la siguiente acción de investigación. Corrija la vía de recopilación o resuelva el acceso mediante el proceso de administración habitual y después repita la lectura.

Una vez establecida la opción de instalación de un host, registre la decisión por separado: conservar la opción actual, probar una dependencia o planificar una sustitución. Esto evita que un recordatorio de auditoría se convierta en una instrucción automática de reinstalación.

Paso 2 — Revisar los roles y las herramientas requeridos

El catálogo de roles y servicios de Server Core de Microsoft incluye Servicios de dominio de Active Directory (AD-Domain-Services) y Servidor DNS (DNS). La disponibilidad en el catálogo no demuestra que un rol esté instalado ni que funcionen todas las dependencias de terceros de un DC concreto.

Pida al responsable que enumere las tareas de administración, supervisión, copia de seguridad, recuperación y herramientas de seguridad necesarias. Para cada elemento, identifique cómo se utilizará en el destino propuesto y quién lo probará. Una prueba de aceptación útil es una tarea concreta con salida conservada, como demostrar el procedimiento aprobado de copia de seguridad en el entorno de pruebas; «la herramienta se abre» es demasiado impreciso.

La documentación de App Compatibility Feature on Demand se aplica a Windows Server 2019, 2022 y 2025. Añade determinados componentes, incluidos MMC y el Explorador de archivos, a Core. Por tanto, ver esas herramientas no basta para identificar Desktop Experience. Este paquete no convierte la opción de instalación.

Si ese paquete es una dependencia revisada, Learn proporciona exactamente este comando de instalación mediante Windows Update:

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

Es un comando de cambio documentado, no un comando de detección; no se ha ejecutado aquí. Microsoft exige acceso de administrador, reiniciar después de la instalación y aplicar posteriormente las actualizaciones del sistema operativo. Para una fuente ISO, use el método documentado y un medio que coincida con la versión instalada de Windows Server.

Paso 3 — Planificar el cambio de opción como una instalación limpia

Para las versiones cubiertas por la página de opciones de instalación, Microsoft exige una instalación limpia para cambiar entre Core y Desktop Experience después de instalar. Eliminar un componente gráfico no es un procedimiento de conversión admitido.

Si se elige la sustitución, vincule esta revisión de evidencias con el ciclo de soporte de Windows Server y el procedimiento de actualización de controladores de dominio. Ese artículo abarca el soporte, los requisitos previos y la planificación de la transición de los DC; no proporciona una prueba local de la opción de instalación existente.

Incluya en el plan las evidencias del DC original, la opción de destino prevista, los resultados de las pruebas de dependencias y el responsable del cambio. Después de la sustitución, recopile un nuevo registro del host y concilie de nuevo el inventario. Conserve el registro anterior como historial para que el revisor pueda ver qué observación respalda cada decisión.

Contexto ANSSI: usar la recomendación tal como está escrita

ANSSI-PA-099 identifica la recomendación R19+, titulada “Utiliser Windows en « Server Core » sur le périmètre du Tier 0” en la página impresa 36. La guía ANSSI expresa una preferencia por Core en los DC para reducir la superficie de ataque y extiende la recomendación a los servidores Windows de Tier 0, especialmente a los que se comunican con recursos menos sensibles.

Use el contexto de administración segura de la guía ANSSI de Active Directory para situar la decisión dentro del modelo de administración más amplio. Esa visión general no verifica InstallationType en hosts individuales. Ni una etiqueta LDAP ni el recordatorio descrito a continuación establecen el cumplimiento de la recomendación.

Cómo detecta EtcSec este punto

El control de etc-collector revisado es ANSSI_R19_SERVER_CORE_NOT_USED, en el commit afca1b9f7bba6f076d6a6493371486071001452b. Su identificador no debe interpretarse como un resultado medido de «Core no utilizado».

Detect() no devuelve ningún hallazgo cuando su entrada de DC está vacía. En caso contrario, emite un recordatorio Info, con Count igual al número de DC en esa entrada. Ese recuento es la población que requiere verificación en el host, no un número de instalaciones Desktop Experience confirmadas.

El proveedor LDAP lee objetos de equipo y mapea operatingSystem y operatingSystemVersion. El motor de auditoría deriva los DC de los objetos de equipo recopilados tras las exclusiones aplicables. Esta vía no lee InstallationType en el registro del host; las cadenas LDAP no distinguen Core de Desktop Experience.

Use el recordatorio para abrir la revisión por DC, adjuntar las evidencias de los hosts y documentar la decisión resultante. No lo presente como un veredicto sobre la interfaz gráfica, un hallazgo de incumplimiento o una prueba de que es necesario reconstruir.

Revisión antes de cerrar la verificación

Entregue al revisor el inventario conciliado, todas las lecturas de hosts o errores, la interpretación de los valores devueltos y las decisiones sobre dependencias. Confirme que el registro final incluya las máquinas que inicialmente no se pudieron leer o enumere explícitamente las que siguen sin resolverse.

La revisión está completa cuando su alcance y sus evidencias respaldan las conclusiones declaradas para cada host. Mantenga la verificación de la opción de instalación, la compatibilidad operativa y la evaluación ANSSI más amplia como decisiones documentadas por separado.