Vérification DC Server Core : option d'installation

Qu'est-ce que la vérification DC Server Core ?

La vérification DC Server Core consiste à établir l'option d'installation de chaque contrôleur de domaine à partir de preuves recueillies sur cet hôte. Commencez par un inventaire des DC, puis associez à chaque entrée le type d'installation local, l'édition et la version du système d'exploitation, l'heure de collecte et le résultat de la lecture. Une étiquette d'annuaire ou une capture d'écran laisse une lacune dans les preuves.

Le problème immédiat est opérationnel : une équipe voit un rappel Server Core dans un audit AD et suppose qu'elle dispose d'une liste de machines à réinstaller. Avant d'accepter cette liste, demandez ce que le collecteur a réellement observé. Un rappel invitant à vérifier une option d'installation est utile, mais il n'établit pas qu'un serveur donné utilise Desktop Experience.

Distinguez le résultat de cette revue de la décision de changement. Une option d'installation vérifiée indique ce qui est installé aujourd'hui. Le responsable doit encore déterminer les rôles et les outils d'administration que la cible doit prendre en charge, si une réinstallation est appropriée et comment le changement sera validé.

Fonctionnement : distinguer l'inventaire d'annuaire des preuves de l'hôte

Microsoft présente Server Core et Server with Desktop Experience comme des choix d'installation. Core omet l'interface de bureau standard et permet l'administration en ligne de commande ou à distance. La comparaison des options d'installation couvre Windows Server 2016, 2019, 2022 et 2025.

L'annuaire et l'hôte répondent à des questions différentes. Les attributs LDAP tels que operatingSystem et operatingSystemVersion aident à organiser un inventaire. Dans l'implémentation du collecteur examinée pour cet article, ils ne distinguent pas Core de Desktop Experience pour une même édition de Windows Server. Conservez ces valeurs comme contexte ; ne transformez pas l'absence de la sous-chaîne « Core » en verdict.

La page archivée de Microsoft Déterminer si Server Core est en cours d'exécution décrit la vérification de InstallationType sous HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion : la valeur Server Core identifie cette option d'installation. La page présente également GetProductInfo comme le test programmatique recommandé. Ses constantes de produit historiques ne doivent pas être considérées comme un inventaire universel des éditions actuelles.

Pour cette revue, conservez le résultat du registre directement issu de chaque hôte. Ne remplacez pas l'inventaire d'annuaire par une étiquette supposée. Reliez les deux ensembles de preuves par l'identité du DC afin qu'un relecteur puisse déterminer quelle machine a été inspectée et quelles machines restent sans lecture.

Détection : constituer un dossier de preuves par DC

Étape 1 — Figer l'inventaire et son périmètre

Consignez le domaine, le serveur d'annuaire interrogé, l'heure de collecte et les exclusions avec la liste des DC. Rapprochez cette liste de l'inventaire opérationnel tenu par l'équipe annuaire. Un hôte omis ne peut pas devenir « vérifié » simplement parce qu'il est absent des données d'un audit.

Utilisez une ligne distincte pour chaque DC attendu. Si la lecture de l'annuaire échoue ou si l'inventaire ne peut pas être rapproché, conservez explicitement ce problème. Évitez un pourcentage de réussite ou une conclusion à l'échelle du domaine tant que la population évaluée est incertaine.

Un dossier de preuves utile comprend :

Champ	Preuve à conserver	Interprétation
Identité du DC	Nom d'hôte et référence d'inventaire	Relie la lecture sur l'hôte au DC attendu
Périmètre	Domaine, serveur d'annuaire interrogé, exclusions	Définit ce que représente l'inventaire
Contexte LDAP	Chaînes brutes de système d'exploitation et de version	Aide à organiser le suivi ; ne prouve pas l'option
Option d'installation	Valeur locale brute de `InstallationType`	Preuve directe du choix d'installation
Édition et version	Identité, version et build du système d'exploitation local	Distingue les hôtes nécessitant des plans différents
Heure de collecte	Horodatage avec fuseau horaire	Situe l'observation dans le temps
Résultat de la lecture	Réussite, valeur absente ou erreur exacte	Préserve les états inconnus au lieu de les deviner
Provenance	Collecteur/opérateur et sortie conservée	Permet à un relecteur indépendant de répéter la lecture

Il s'agit de champs proposés pour la revue, et non d'une affirmation selon laquelle EtcSec les collecte tous. Conservez les preuves dans votre processus d'administration établi, avec des accès adaptés aux dossiers de configuration des contrôleurs de domaine.

Étape 2 — Lire le type d'installation sur l'hôte

Utilisez une session locale autorisée ou votre mécanisme d'exécution administrative établi, qui effectue la lecture sur le DC prévu. Le PowerShell suivant est un exemple en lecture seule rédigé pour cet article, qui met en œuvre la vérification du registre documentée par Microsoft. Ce n'est pas une commande copiée de Learn et il n'a pas été exécuté pour cet article.

$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
    }
}

Capturez la sortie et associez-la à la ligne d'inventaire. Vérifiez que l'hôte indiqué est bien le DC prévu ; une requête de registre exécutée sur le poste d'administration répond à une autre question. Si la session ne peut pas être établie, consignez séparément cette erreur de transport ou d'accès, car ce script local n'a jamais été exécuté.

L'exemple traite avec prudence l'échec d'une lecture combinée. Si la requête d'identité du système d'exploitation échoue après la réussite de la requête de registre, il renvoie une ligne en échec plutôt qu'une observation complète. Conservez la sortie de diagnostic brute lors de l'analyse de ces cas et répétez la lecture manquante par la voie approuvée.

Étape 3 — Interpréter les résultats sans effacer les états inconnus

Une lecture réussie renvoyant Server Core fournit la preuve décrite par Microsoft. Conservez toute autre chaîne renvoyée telle quelle et déterminez sa signification pour cet hôte avant de prendre la décision relative à l'option d'installation. Une valeur absente ou une lecture en échec reste inconnue.

Ne remplissez pas manuellement les cellules inconnues à partir de DC voisins, de modèles de déploiement ou du souvenir de l'apparence d'une session de connexion. Ces éléments peuvent orienter l'enquête, mais le dossier de preuves doit toujours montrer ce qui a réellement été obtenu de chaque hôte.

Résoudre les dépendances avant de planifier une réinstallation (Remediation)

Étape 1 — Combler d'abord les lacunes dans les preuves

Attribuez chaque DC sans lecture à un responsable capable d'obtenir les preuves de l'hôte. Gardez visibles la cause de l'échec et la prochaine action d'investigation. Corrigez le chemin de collecte ou résolvez l'accès dans le cadre du processus d'administration habituel, puis répétez la lecture.

Une fois l'option d'installation d'un hôte établie, consignez séparément la décision : conserver l'option actuelle, tester une dépendance ou planifier un remplacement. Cela empêche un rappel d'audit de devenir une instruction automatique de réinstallation.

Étape 2 — Examiner les rôles et les outils requis

Le catalogue des rôles et services Server Core de Microsoft comprend les services de domaine Active Directory (AD-Domain-Services) et le serveur DNS (DNS). La disponibilité dans le catalogue ne démontre pas qu'un rôle est installé ni que toutes les dépendances tierces d'un DC donné fonctionnent.

Demandez au responsable de lister les tâches d'administration, la supervision, la sauvegarde, la restauration et les outils de sécurité requis. Pour chaque élément, précisez comment il sera exploité sur la cible envisagée et qui le testera. Un test d'acceptation utile correspond à une tâche précise avec une sortie conservée, par exemple la démonstration du processus de sauvegarde approuvé dans l'environnement de test ; « l'outil s'ouvre » est trop vague.

La documentation App Compatibility Feature on Demand s'applique à Windows Server 2019, 2022 et 2025. Cette fonctionnalité ajoute certains composants, notamment MMC et l'Explorateur de fichiers, à Core. La présence de ces outils ne suffit donc pas à identifier Desktop Experience. Ce package ne convertit pas l'option d'installation.

Si ce package est une dépendance examinée, Learn fournit exactement cette commande d'installation via Windows Update :

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

Il s'agit d'une commande de changement documentée, et non d'une commande de détection ; elle n'a pas été exécutée ici. Microsoft exige un accès administrateur, un redémarrage après l'installation et les mises à jour ultérieures du système d'exploitation. Pour une source ISO, utilisez la méthode documentée et un support correspondant à la version de Windows Server installée.

Étape 3 — Prévoir une installation propre pour changer d'option

Pour les versions couvertes par la page des options d'installation, Microsoft exige une installation propre pour passer de Core à Desktop Experience ou inversement après l'installation. La suppression d'un composant graphique n'est pas une procédure de conversion prise en charge.

Si le remplacement est l'action retenue, reliez cette revue des preuves au cycle de support de Windows Server et au processus de mise à niveau des contrôleurs de domaine. Cet article traite du support, des prérequis et de la planification de la transition des DC ; il ne fournit pas de preuve locale de l'option d'installation existante.

Incluez dans le plan les preuves du DC d'origine, l'option cible envisagée, les résultats des tests de dépendances et le responsable du changement. Après le remplacement, recueillez un nouveau relevé de l'hôte et rapprochez de nouveau l'inventaire. Conservez le relevé antérieur comme historique afin que le relecteur puisse voir quelle observation étaye quelle décision.

Contexte ANSSI : utiliser la recommandation telle qu'elle est écrite

ANSSI-PA-099 désigne la recommandation R19+, intitulée “Utiliser Windows en « Server Core » sur le périmètre du Tier 0” à la page imprimée 36. Le guide ANSSI exprime une préférence pour Core sur les DC afin de réduire la surface d'attaque et étend la recommandation aux serveurs Windows du Tier 0, particulièrement ceux qui communiquent avec des ressources moins sensibles.

Utilisez le contexte d'administration sécurisée du guide ANSSI Active Directory pour replacer la décision dans le modèle d'administration plus large. Cette vue d'ensemble ne vérifie pas InstallationType sur chaque hôte. Ni une étiquette LDAP ni le rappel décrit ci-dessous n'établissent la conformité à la recommandation.

Comment EtcSec détecte ce point

Le contrôle etc-collector examiné est ANSSI_R19_SERVER_CORE_NOT_USED, au commit afca1b9f7bba6f076d6a6493371486071001452b. Son identifiant ne doit pas être interprété comme un résultat mesuré « Core non utilisé ».

Detect() ne renvoie aucun résultat lorsque son entrée de DC est vide. Sinon, il émet un rappel Info, avec Count égal au nombre de DC dans cette entrée. Ce nombre représente la population nécessitant une vérification sur l'hôte, et non un nombre d'installations Desktop Experience confirmées.

Le fournisseur LDAP lit les objets ordinateur et mappe operatingSystem et operatingSystemVersion. Le moteur d'audit déduit les DC des objets ordinateur collectés après les exclusions applicables. Ce chemin ne lit pas InstallationType dans le registre de l'hôte ; les chaînes LDAP ne distinguent pas Core de Desktop Experience.

Utilisez le rappel pour ouvrir la revue par DC, joindre les preuves des hôtes et documenter la décision qui en découle. Ne le présentez pas comme un verdict sur l'interface graphique, un constat de non-conformité ou la preuve qu'une reconstruction est requise.

Revue avant de clôturer la vérification

Remettez au relecteur l'inventaire rapproché, chaque lecture d'hôte ou erreur, l'interprétation des valeurs renvoyées et les décisions concernant les dépendances. Confirmez que le dossier final inclut les machines initialement sans lecture ou énumère explicitement celles dont le cas reste non résolu.

La revue est terminée lorsque son périmètre et ses preuves étayent les conclusions énoncées au niveau de chaque hôte. Conservez la vérification de l'option d'installation, la compatibilité opérationnelle et l'évaluation ANSSI plus large comme des décisions documentées séparément.