Verifica DC Server Core: identificare ogni opzione

Che cos'è la verifica DC Server Core?

La verifica DC Server Core consiste nell'accertare l'opzione di installazione di ogni controller di dominio tramite le evidenze raccolte su quell'host. Partite da un inventario dei DC, quindi associate a ogni voce il tipo di installazione locale, l'edizione e la versione del sistema operativo, l'ora della raccolta e l'esito della lettura. Un'etichetta nella directory o una schermata lascia una lacuna nelle evidenze.

Il problema immediato è operativo: un team vede un promemoria su Server Core in un audit AD e presume di avere un elenco di macchine da reinstallare. Prima di accettare quell'elenco, chiedete che cosa abbia effettivamente osservato il collector. Un promemoria che invita a verificare un'opzione di installazione è utile, ma non dimostra che un determinato server utilizzi Desktop Experience.

Tenete separato l'esito di questa revisione dalla decisione di modifica. Un'opzione di installazione verificata indica che cosa è installato oggi. Il responsabile deve ancora stabilire quali ruoli e strumenti di amministrazione debba supportare la destinazione, se una reinstallazione sia appropriata e come verrà convalidata la modifica.

Funzionamento: separare l'inventario della directory dalle evidenze dell'host

Microsoft documenta Server Core e Server with Desktop Experience come scelte di installazione. Core omette l'interfaccia desktop standard e supporta l'amministrazione da riga di comando o da remoto. Il confronto delle opzioni di installazione riguarda Windows Server 2016, 2019, 2022 e 2025.

La directory e l'host rispondono a domande diverse. Attributi LDAP come operatingSystem e operatingSystemVersion aiutano a organizzare un inventario. Nell'implementazione del collector esaminata per questo articolo, non distinguono Core da Desktop Experience per la stessa edizione di Windows Server. Conservate quei valori come contesto; non trasformate l'assenza della sottostringa «Core» in un verdetto.

La pagina archiviata di Microsoft Determinare se Server Core è in esecuzione descrive il controllo di InstallationType in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion: il valore Server Core identifica quell'opzione di installazione. La pagina presenta anche GetProductInfo come test programmatico consigliato. Le sue costanti di prodotto storiche non vanno considerate un inventario universale delle edizioni attuali.

Per questa revisione, conservate il risultato del registro ottenuto direttamente da ogni host. Non sovrascrivete l'inventario della directory con un'etichetta ipotizzata. Collegate i due insiemi di evidenze tramite l'identità del DC, affinché un revisore possa capire quale macchina è stata ispezionata e quali macchine restano senza lettura.

Rilevamento: costruire un registro di evidenze per ogni DC

Passaggio 1 — Fissare l'inventario e il suo perimetro

Registrate il dominio, il server di directory interrogato, l'ora della raccolta e le esclusioni insieme all'elenco dei DC. Riconciliate quell'elenco con l'inventario operativo mantenuto dal team della directory. Un host omesso non può diventare «verificato» solo perché è assente dai dati di un audit.

Usate una riga separata per ogni DC previsto. Se la lettura della directory fallisce o l'inventario non può essere riconciliato, conservate esplicitamente quel problema. Evitate una percentuale di successo o una conclusione per l'intero dominio finché la popolazione valutata è incerta.

Un registro di evidenze utile comprende:

Questi sono campi proposti per la revisione, non un'affermazione secondo cui EtcSec li raccolga tutti. Memorizzate le evidenze tramite il processo di amministrazione consolidato, con un accesso adeguato ai registri di configurazione dei controller di dominio.

Passaggio 2 — Leggere il tipo di installazione sull'host

Usate una sessione locale autorizzata oppure il meccanismo di esecuzione amministrativa consolidato che effettua la lettura sul DC previsto. Il PowerShell seguente è un esempio in sola lettura scritto per questo articolo, che implementa il controllo del registro documentato da Microsoft. Non è un comando copiato da Learn e non è stato eseguito per questo articolo.

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

Acquisite l'output e associatelo alla riga dell'inventario. Verificate che l'host indicato sia il DC previsto; eseguire una query del registro sulla workstation di amministrazione risponde a una domanda diversa. Se la sessione non può essere stabilita, registrate separatamente quell'errore di trasporto o accesso, perché questo script locale non è mai stato eseguito.

L'esempio tratta in modo prudente una lettura combinata non riuscita. Se la query sull'identità del SO fallisce dopo che la query del registro è riuscita, restituisce una riga in errore anziché un'osservazione completa. Conservate l'output diagnostico originale durante l'analisi di questi casi e ripetete la lettura mancante tramite il percorso approvato.

Passaggio 3 — Interpretare i risultati senza eliminare gli stati sconosciuti

Una lettura riuscita che restituisce Server Core fornisce l'evidenza descritta da Microsoft. Conservate letteralmente qualsiasi altra stringa restituita e chiaritene il significato per quell'host prima di prendere la decisione sull'opzione di installazione. Un valore mancante o una lettura fallita rimane sconosciuto.

Non compilate manualmente le celle sconosciute usando DC vicini, modelli di distribuzione o il ricordo dell'aspetto di una sessione di accesso. Questi elementi possono guidare l'indagine, ma il registro delle evidenze deve comunque mostrare ciò che è stato effettivamente ottenuto da ogni host.

Risolvere le dipendenze prima di pianificare una reinstallazione (Remediation)

Passaggio 1 — Colmare prima le lacune nelle evidenze

Assegnate ogni DC senza lettura a un responsabile che possa ottenere le evidenze dell'host. Mantenete visibili il motivo del fallimento e la prossima azione d'indagine. Correggete il percorso di raccolta o risolvete l'accesso tramite il normale processo di amministrazione, quindi ripetete la lettura.

Una volta accertata l'opzione di installazione di un host, registrate separatamente la decisione: mantenere l'opzione attuale, testare una dipendenza o pianificare una sostituzione. Questo impedisce che un promemoria di audit diventi un'istruzione automatica di reinstallazione.

Passaggio 2 — Esaminare i ruoli e gli strumenti necessari

Il catalogo dei ruoli e servizi di Server Core di Microsoft include Servizi di dominio Active Directory (AD-Domain-Services) e Server DNS (DNS). La disponibilità nel catalogo non dimostra che un ruolo sia installato o che funzionino tutte le dipendenze di terze parti su un determinato DC.

Chiedete al responsabile di elencare le attività di amministrazione, il monitoraggio, il backup, il ripristino e gli strumenti di sicurezza necessari. Per ogni elemento, individuate come verrà utilizzato sulla destinazione proposta e chi lo testerà. Un test di accettazione utile è un'attività specifica con output conservato, come la dimostrazione della procedura di backup approvata nell'ambiente di test; «lo strumento si apre» è troppo vago.

La documentazione di App Compatibility Feature on Demand si applica a Windows Server 2019, 2022 e 2025. Aggiunge a Core determinati componenti, tra cui MMC ed Esplora file. Vedere questi strumenti non è quindi sufficiente per identificare Desktop Experience. Questo pacchetto non converte l'opzione di installazione.

Se quel pacchetto è una dipendenza esaminata, Learn fornisce esattamente questo comando di installazione tramite Windows Update:

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

Questo è un comando di modifica documentato, non un comando di rilevamento; non è stato eseguito qui. Microsoft richiede l'accesso come amministratore, un riavvio dopo l'installazione e i successivi aggiornamenti del sistema operativo. Per una sorgente ISO, usate il metodo documentato e un supporto corrispondente alla versione installata di Windows Server.

Passaggio 3 — Pianificare il cambio di opzione come installazione pulita

Per le versioni coperte dalla pagina delle opzioni di installazione, Microsoft richiede un'installazione pulita per passare da Core a Desktop Experience o viceversa dopo l'installazione. Rimuovere un componente grafico non è una procedura di conversione supportata.

Se la sostituzione è l'azione scelta, collegate questa revisione delle evidenze al ciclo di supporto di Windows Server e alla procedura di aggiornamento dei controller di dominio. Quell'articolo riguarda il supporto, i prerequisiti e la pianificazione della transizione dei DC; non fornisce una prova locale dell'opzione di installazione esistente.

Includete nel piano le evidenze del DC originale, l'opzione di destinazione prevista, gli esiti dei test delle dipendenze e il responsabile della modifica. Dopo la sostituzione, raccogliete un nuovo registro dell'host e riconciliate nuovamente l'inventario. Conservate il registro precedente come storico, affinché il revisore possa vedere quale osservazione supporta ciascuna decisione.

Contesto ANSSI: usare la raccomandazione così come è scritta

ANSSI-PA-099 identifica la raccomandazione R19+, intitolata “Utiliser Windows en « Server Core » sur le périmètre du Tier 0” a pagina stampata 36. La guida ANSSI esprime una preferenza per Core sui DC per ridurre la superficie di attacco ed estende la raccomandazione ai server Windows del Tier 0, in particolare a quelli che comunicano con risorse meno sensibili.

Usate il contesto di amministrazione sicura della guida ANSSI Active Directory per collocare la decisione nel modello di amministrazione più ampio. Quella panoramica non verifica InstallationType sui singoli host. Né un'etichetta LDAP né il promemoria descritto di seguito dimostrano la conformità alla raccomandazione.

Come EtcSec rileva questo aspetto

Il controllo di etc-collector esaminato è ANSSI_R19_SERVER_CORE_NOT_USED, al commit afca1b9f7bba6f076d6a6493371486071001452b. Il suo identificatore non va interpretato come un risultato misurato «Core non utilizzato».

Detect() non restituisce alcun riscontro quando il suo input di DC è vuoto. Altrimenti emette un promemoria Info, con Count pari al numero di DC in quell'input. Quel conteggio è la popolazione che richiede una verifica sull'host, non il numero di installazioni Desktop Experience confermate.

Il provider LDAP legge gli oggetti computer e mappa operatingSystem e operatingSystemVersion. Il motore di audit ricava i DC dagli oggetti computer raccolti dopo le esclusioni applicabili. Questo percorso non legge InstallationType nel registro dell'host; le stringhe LDAP non distinguono Core da Desktop Experience.

Usate il promemoria per avviare la revisione per DC, allegare le evidenze degli host e documentare la decisione risultante. Non presentatelo come un verdetto sull'interfaccia grafica, un riscontro di non conformità o una prova che sia necessaria una ricostruzione.

Revisione prima di chiudere la verifica

Fornite al revisore l'inventario riconciliato, ogni lettura dell'host o errore, l'interpretazione dei valori restituiti e le decisioni sulle dipendenze. Confermate che il registro finale includa le macchine inizialmente senza lettura, oppure elenchi esplicitamente quelle ancora irrisolte.

La revisione è completa quando il suo perimetro e le sue evidenze supportano le conclusioni dichiarate per i singoli host. Mantenete la verifica dell'opzione di installazione, la compatibilità operativa e la valutazione ANSSI più ampia come decisioni documentate separatamente.