Server Core DC Pruefung: Installationsoption erkennen

Was ist die Server Core DC Pruefung?

Die Prüfung von Server Core auf DCs bedeutet, die Installationsoption jedes Domänencontrollers anhand von Belegen festzustellen, die auf diesem Host erhoben wurden. Beginnen Sie mit einem DC-Inventar und ergänzen Sie jeden Eintrag um den lokalen Installationstyp, die Betriebssystemedition, die Version, den Erhebungszeitpunkt und das Ergebnis des Lesezugriffs. Eine Verzeichnisbezeichnung oder ein Screenshot lässt eine Beweislücke offen.

Das unmittelbare Problem ist betrieblicher Natur: Ein Team sieht in einem AD-Audit eine Erinnerung zu Server Core und nimmt an, damit eine Liste neu aufzubauender Maschinen zu haben. Bevor Sie diese Liste übernehmen, fragen Sie, was der Collector tatsächlich beobachtet hat. Eine Erinnerung, die Installationsoption zu prüfen, ist hilfreich, belegt aber nicht, dass ein bestimmter Server Desktop Experience verwendet.

Halten Sie das Ergebnis dieser Prüfung von der Änderungsentscheidung getrennt. Eine verifizierte Installationsoption beantwortet, was heute installiert ist. Der Verantwortliche muss weiterhin klären, welche Rollen und Verwaltungswerkzeuge das Ziel unterstützen muss, ob ein Neuaufbau angemessen ist und wie die Änderung validiert wird.

Funktionsweise: Verzeichnisinventar und Hostbelege trennen

Microsoft dokumentiert Server Core und Server with Desktop Experience als Installationsoptionen. Core verzichtet auf die standardmäßige Desktopoberfläche und unterstützt die Verwaltung über die Befehlszeile oder aus der Ferne. Der Vergleich der Installationsoptionen umfasst Windows Server 2016, 2019, 2022 und 2025.

Das Verzeichnis und der Host beantworten unterschiedliche Fragen. LDAP-Attribute wie operatingSystem und operatingSystemVersion helfen, ein Inventar zu strukturieren. In der für diesen Artikel geprüften Collector-Implementierung unterscheiden sie bei derselben Windows-Server-Edition nicht zwischen Core und Desktop Experience. Bewahren Sie diese Werte als Kontext auf; machen Sie aus einer fehlenden Teilzeichenfolge „Core“ kein Urteil.

Die archivierte Microsoft-Seite Determining Whether Server Core Is Running beschreibt die Prüfung von InstallationType unter HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion: Der Wert Server Core kennzeichnet diese Installationsoption. Die Seite nennt außerdem GetProductInfo als empfohlenen programmatischen Test. Ihre historischen Produktkonstanten sollten nicht als universelles Inventar aktueller Editionen behandelt werden.

Bewahren Sie für diese Prüfung das direkt auf jedem Host ermittelte Registrierungsergebnis auf. Überschreiben Sie das Verzeichnisinventar nicht mit einer vermuteten Bezeichnung. Verknüpfen Sie beide Belegsammlungen über die DC-Identität, damit ein Prüfer erkennen kann, welche Maschine untersucht wurde und welche Maschinen noch nicht ausgelesen wurden.

Erkennung: Einen Belegdatensatz je DC erstellen

Schritt 1 — Inventar und Umfang festhalten

Dokumentieren Sie neben der DC-Liste die Domäne, den abgefragten Verzeichnisserver, den Erhebungszeitpunkt und die Ausschlüsse. Gleichen Sie diese Liste mit dem betrieblichen Inventar des Verzeichnisteams ab. Ein ausgelassener Host wird nicht allein deshalb „verifiziert“, weil er in einem Audit-Payload fehlt.

Verwenden Sie für jeden erwarteten DC eine eigene Zeile. Falls die Verzeichnisabfrage fehlschlägt oder das Inventar nicht abgeglichen werden kann, halten Sie dieses Problem ausdrücklich fest. Vermeiden Sie eine Erfolgsquote oder eine Aussage zur gesamten Domäne, solange unklar ist, welche Gesamtheit bewertet wird.

Ein hilfreicher Belegdatensatz enthält:

Feld	Aufzubewahrender Beleg	Interpretation
DC-Identität	Hostname und Inventarreferenz	Verknüpft die Hostabfrage mit dem erwarteten DC
Umfang	Domäne, abgefragter Verzeichnisserver, Ausschlüsse	Definiert, was das Inventar abbildet
LDAP-Kontext	Unveränderte Betriebssystem- und Versionszeichenfolgen	Hilft bei Folgeprüfungen; beweist die Option nicht
Installationsoption	Unveränderter lokaler Wert von `InstallationType`	Direkter Beleg für die Installationswahl
Edition und Version	Lokale Betriebssystemidentität, Version und Build	Unterscheidet Hosts, die unterschiedliche Pläne erfordern
Erhebungszeitpunkt	Zeitstempel mit Zeitzone	Ordnet die Beobachtung zeitlich zu
Ergebnis des Lesezugriffs	Erfolg, fehlender Wert oder genaue Fehlermeldung	Bewahrt unbekannte Zustände, statt zu raten
Herkunft	Collector/Bediener und aufbewahrte Ausgabe	Ermöglicht einem unabhängigen Prüfer, die Abfrage zu wiederholen

Dies sind vorgeschlagene Prüffelder, keine Aussage, dass EtcSec sie alle erhebt. Speichern Sie die Belege über Ihren etablierten Verwaltungsprozess, mit Zugriffsrechten, die für Konfigurationsaufzeichnungen von Domänencontrollern geeignet sind.

Schritt 2 — Den Installationstyp auf dem Host auslesen

Verwenden Sie eine autorisierte lokale Sitzung oder Ihr etabliertes administratives Ausführungsverfahren, das die Abfrage auf dem vorgesehenen DC ausführt. Das folgende PowerShell-Beispiel wurde für den Artikel erstellt, liest ausschließlich Daten und setzt die von Microsoft dokumentierte Registrierungsprüfung um. Es wurde nicht aus Learn übernommen und für diesen Artikel nicht ausgeführt.

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

Erfassen Sie die Ausgabe und ordnen Sie sie der Inventarzeile zu. Prüfen Sie, ob der gemeldete Host der vorgesehene DC ist; eine Registrierungsabfrage auf der Verwaltungsworkstation beantwortet eine andere Frage. Wenn die Sitzung überhaupt nicht aufgebaut werden kann, dokumentieren Sie diesen Transport- oder Zugriffsfehler separat, da dieses lokale Skript dann nie ausgeführt wurde.

Das Beispiel behandelt eine erfolglose kombinierte Abfrage konservativ. Wenn die Abfrage der Betriebssystemidentität nach erfolgreicher Registrierungsabfrage fehlschlägt, liefert es eine Fehlerzeile statt einer vollständigen Beobachtung. Bewahren Sie bei der Untersuchung solcher Fälle die unveränderte Diagnoseausgabe auf und wiederholen Sie die fehlende Abfrage über den genehmigten Weg.

Schritt 3 — Ergebnisse interpretieren, ohne unbekannte Zustände zusammenzufassen

Eine erfolgreiche Abfrage mit dem Ergebnis Server Core liefert den von Microsoft beschriebenen Beleg. Bewahren Sie jede andere zurückgegebene Zeichenfolge unverändert auf und klären Sie deren Bedeutung für diesen Host, bevor Sie über die Installationsoption entscheiden. Ein fehlender Wert oder eine fehlgeschlagene Abfrage bleibt unbekannt.

Füllen Sie unbekannte Zellen nicht manuell anhand benachbarter DCs, Bereitstellungsvorlagen oder der erinnerten Ansicht einer Anmeldesitzung aus. Diese Informationen können die Untersuchung lenken; der Belegdatensatz sollte jedoch weiterhin zeigen, was tatsächlich von jedem Host erhoben wurde.

Abhilfe: Abhängigkeiten vor der Planung eines Neuaufbaus klären (Remediation)

Schritt 1 — Zuerst Beweislücken schließen

Weisen Sie jeden noch nicht ausgelesenen DC einem Verantwortlichen zu, der die Hostbelege erheben kann. Halten Sie den Fehlergrund und den nächsten Untersuchungsschritt sichtbar. Korrigieren Sie den Erhebungsweg oder klären Sie den Zugriff über den normalen Verwaltungsprozess und wiederholen Sie dann die Abfrage.

Sobald die Installationsoption eines Hosts feststeht, dokumentieren Sie die Entscheidung separat: die aktuelle Option beibehalten, eine Abhängigkeit testen oder einen Ersatz planen. So wird aus einer Audit-Erinnerung keine automatische Anweisung zum Neuaufbau.

Schritt 2 — Erforderliche Rollen und Werkzeuge prüfen

Microsofts Katalog der Server-Core-Rollen und -Dienste umfasst Active Directory Domain Services (AD-Domain-Services) und DNS Server (DNS). Die Verfügbarkeit im Katalog belegt weder, dass eine Rolle installiert ist, noch, dass jede Abhängigkeit von Drittanbietern auf einem bestimmten DC funktioniert.

Bitten Sie den Verantwortlichen, die erforderlichen Verwaltungsaufgaben sowie Monitoring-, Sicherungs-, Wiederherstellungs- und Sicherheitswerkzeuge aufzulisten. Legen Sie für jeden Punkt fest, wie er auf dem vorgeschlagenen Ziel betrieben wird und wer ihn testet. Ein hilfreicher Abnahmetest ist eine konkrete Aufgabe mit aufbewahrter Ausgabe, etwa der Nachweis des genehmigten Sicherungsablaufs in der Testumgebung; „das Werkzeug lässt sich öffnen“ ist zu ungenau.

Die Dokumentation zum App Compatibility Feature on Demand gilt für Windows Server 2019, 2022 und 2025. Es ergänzt Core um ausgewählte Komponenten, darunter MMC und File Explorer. Diese Werkzeuge zu sehen reicht deshalb nicht aus, um Desktop Experience zu identifizieren. Dieses Paket ändert die Installationsoption nicht.

Wenn dieses Paket eine geprüfte Abhängigkeit ist, nennt Learn genau diesen Installationsbefehl über Windows Update:

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

Dies ist ein dokumentierter Änderungsbefehl, kein Erkennungsbefehl; er wurde hier nicht ausgeführt. Microsoft verlangt Administratorzugriff, einen Neustart nach der Installation und anschließende Betriebssystemupdates. Verwenden Sie für eine ISO-Quelle das dokumentierte Verfahren und Medien, die zur installierten Windows-Server-Version passen.

Schritt 3 — Einen Wechsel der Installationsoption als Neuinstallation planen

Für die von der Seite zu den Installationsoptionen abgedeckten Versionen verlangt Microsoft eine Neuinstallation, um nach der Installation zwischen Core und Desktop Experience zu wechseln. Das Entfernen einer grafischen Komponente ist kein unterstütztes Konvertierungsverfahren.

Wenn ein Ersatz beschlossen wird, verknüpfen Sie diese Belegprüfung mit dem Ablauf zum Windows-Server-Supportlebenszyklus und Upgrade von Domänencontrollern. Dieser Artikel behandelt Support, Voraussetzungen und die Planung des DC-Übergangs; er liefert keinen lokalen Nachweis der bestehenden Installationsoption.

Nehmen Sie die ursprünglichen DC-Belege, die vorgesehene Zieloption, die Ergebnisse der Abhängigkeitstests und den Änderungsverantwortlichen in den Plan auf. Erheben Sie nach dem Ersatz einen neuen Hostdatensatz und gleichen Sie das Inventar erneut ab. Bewahren Sie den vorherigen Datensatz als Historie auf, damit der Prüfer erkennen kann, welche Beobachtung welche Entscheidung stützt.

ANSSI-Kontext: Die Empfehlung in ihrer ursprünglichen Form verwenden

ANSSI-PA-099 bezeichnet die Empfehlung als R19+, mit dem Titel „Utiliser Windows en « Server Core » sur le périmètre du Tier 0“ auf der gedruckten Seite 36. Der ANSSI-Leitfaden bevorzugt Core auf DCs zur Verringerung der Angriffsfläche und erweitert die Empfehlung auf Windows-Server des Tier 0, insbesondere solche, die mit weniger sensiblen Ressourcen kommunizieren.

Nutzen Sie den Kontext zur sicheren Administration im ANSSI-Leitfaden für Active Directory, um die Entscheidung in das umfassendere Verwaltungsmodell einzuordnen. Diese Übersicht prüft nicht InstallationType auf einzelnen Hosts. Weder eine LDAP-Bezeichnung noch die unten beschriebene Erinnerung stellt die Einhaltung der Empfehlung fest.

Wie EtcSec dies erkennt

Die geprüfte etc-collector-Prüfung ist ANSSI_R19_SERVER_CORE_NOT_USED, am Commit afca1b9f7bba6f076d6a6493371486071001452b. Ihr Bezeichner darf nicht als gemessenes Ergebnis „Core nicht verwendet“ gelesen werden.

Detect() liefert keinen Befund, wenn seine DC-Eingabe leer ist. Andernfalls erzeugt es eine Info-Erinnerung, deren Count der Anzahl der DCs in dieser Eingabe entspricht. Diese Anzahl ist die Gesamtheit, für die eine Hostprüfung erforderlich ist, keine Anzahl bestätigter Desktop-Experience-Installationen.

Der LDAP-Provider liest Computerobjekte und bildet operatingSystem und operatingSystemVersion ab. Die Audit-Engine leitet DCs nach Anwendung der jeweiligen Ausschlüsse aus den erhobenen Computerobjekten ab. Dieser Pfad liest nicht InstallationType aus der Registrierung des Hosts; die LDAP-Zeichenfolgen unterscheiden nicht zwischen Core und Desktop Experience.

Verwenden Sie die Erinnerung, um die Prüfung je DC einzuleiten, Hostbelege anzufügen und die daraus resultierende Entscheidung zu dokumentieren. Melden Sie sie nicht als GUI-Urteil, als Befund einer Regelverletzung oder als Beweis, dass ein Neuaufbau erforderlich ist.

Prüfung vor Abschluss der Verifizierung

Übergeben Sie dem Prüfer das abgeglichene Inventar, jede Hostabfrage oder jeden Fehler, die Interpretation der zurückgegebenen Werte und die Entscheidungen zu Abhängigkeiten. Bestätigen Sie, dass der endgültige Datensatz die anfangs nicht ausgelesenen Maschinen umfasst oder die ungelösten Fälle ausdrücklich aufführt.

Die Prüfung ist abgeschlossen, wenn ihr Umfang und ihre Belege die angegebenen Schlussfolgerungen auf Hostebene stützen. Dokumentieren Sie die Verifizierung der Installationsoption, die betriebliche Kompatibilität und die umfassendere ANSSI-Bewertung als getrennte Entscheidungen.