Server Core DC Verification: Identify Each Installation Option

What Is Server Core DC Verification?

Server core DC verification means establishing the installation option of each domain controller from evidence collected on that host. Start with a DC inventory, then attach the local installation type, operating system edition, version, collection time, and read outcome to every entry. A directory label or a screenshot leaves an evidence gap.

The immediate problem is operational: a team sees a Server Core reminder in an AD audit and assumes it has a list of machines to rebuild. Before accepting that list, ask what the collector actually observed. A reminder to verify an installation option is useful, but it does not establish that a particular server uses Desktop Experience.

Keep the outcome of this review separate from the change decision. A verified installation option answers what is installed today. The owner still needs to establish which roles and administration tools the target must support, whether a rebuild is appropriate, and how the change will be validated.

How It Works: Separate Directory Inventory from Host Evidence

Microsoft documents Server Core and Server with Desktop Experience as installation choices. Core omits the standard desktop interface and supports command-line or remote administration. The installation options comparison covers Windows Server 2016, 2019, 2022, and 2025.

The directory and the host answer different questions. LDAP attributes such as operatingSystem and operatingSystemVersion help organize an inventory. In the collector implementation reviewed for this article, they do not distinguish Core from Desktop Experience for the same Windows Server edition. Preserve those values as context; do not turn a missing “Core” substring into a verdict.

Microsoft's archived Determining Whether Server Core Is Running describes checking InstallationType under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion: the value Server Core identifies that installation option. The page also describes GetProductInfo as its recommended programmatic test. Its historical product constants should not be treated as a universal inventory of current editions.

For this review, retain the registry result directly from each host. Do not overwrite the directory inventory with a guessed label. Link the two evidence sets using the DC identity so a reviewer can tell which machine was inspected and which machines remain unread.

Detection: Build a Per-DC Evidence Record

Step 1 — Freeze the inventory and its scope

Record the domain, directory server queried, collection time, and exclusions alongside the list of DCs. Reconcile that list with the operational inventory maintained by the directory team. An omitted host cannot become “verified” simply because it is absent from an audit payload.

Use a separate row for every expected DC. If the directory read fails or the inventory cannot be reconciled, retain that problem explicitly. Avoid a success percentage or a domain-wide conclusion while the population being assessed is uncertain.

A useful evidence record is:

These are proposed review fields, not a claim that EtcSec collects all of them. Store the evidence through your established administration process, with access appropriate for domain controller configuration records.

Step 2 — Read the installation type on the host

Use an authorized local session, or your established administrative execution mechanism that runs the read on the intended DC. The following PowerShell is an article-authored, read-only example implementing Microsoft's documented registry check. It is not a command copied from Learn, and it has not been run for this 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
    }
}

Capture the output and associate it with the inventory row. Verify that the reported host is the intended DC; running a registry query on the administration workstation answers a different question. If the session cannot be established at all, record that transport or access error separately because this local script never ran.

The example treats an unsuccessful combined read conservatively. If the OS identity query fails after the registry query succeeds, it returns a failed row rather than a complete observation. Retain the raw diagnostic output when investigating such cases and repeat the missing read through the approved route.

Step 3 — Interpret results without collapsing unknowns

A successful read returning Server Core provides the evidence described by Microsoft. Retain any other returned string verbatim and resolve its meaning for that host before making the installation-option decision. A missing value or failed read stays unknown.

Do not manually fill unknown cells from neighboring DCs, deployment templates, or the remembered appearance of a login session. These can guide investigation, but the evidence record should still show what was actually obtained from each host.

Remediation: Resolve Dependencies Before Planning a Rebuild

Step 1 — Close evidence gaps first

Assign each unread DC to an owner who can obtain the host evidence. Keep the reason for failure and the next investigation action visible. Correct the collection route or resolve access through the normal administration process, then repeat the read.

Once a host's installation option is established, record the decision separately: retain the current option, test a dependency, or plan a replacement. This prevents an audit reminder from becoming an automatic rebuild instruction.

Step 2 — Review required roles and tools

Microsoft's Server Core roles and services catalogue includes Active Directory Domain Services (AD-Domain-Services) and DNS Server (DNS). Availability in the catalogue does not demonstrate that a role is installed or that every third-party dependency on a particular DC works.

Ask the owner to list required administration tasks, monitoring, backup, recovery, and security tooling. For each item, identify how it will be operated on the proposed target and who will test it. A useful acceptance test is a specific task with retained output, such as demonstrating the approved backup workflow in the test environment; “the tool opens” is too vague.

The App Compatibility Feature on Demand documentation applies to Windows Server 2019, 2022, and 2025. It adds selected components, including MMC and File Explorer, to Core. Seeing those tools is therefore insufficient to identify Desktop Experience. This package does not convert the installation option.

If that package is a reviewed dependency, Learn gives this exact Windows Update installation command:

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

This is a documented change command, not a detection command; it has not been executed here. Microsoft requires administrator access, a restart after installation, and subsequent operating system updates. For an ISO source, use the documented method and media matching the installed Windows Server version.

Step 3 — Plan an installation-option change as a clean installation

For the versions covered by the installation options page, Microsoft requires a clean installation to change between Core and Desktop Experience after installation. Removing a graphical component is not a supported conversion procedure.

If replacement is the chosen action, connect this evidence review to the Windows Server support lifecycle and domain controller upgrade workflow. That article covers support, prerequisites, and DC transition planning; it does not supply local proof of the existing installation option.

Include the original DC evidence, intended target option, dependency test results, and change owner in the plan. After the replacement, collect a new host record and reconcile the inventory again. Preserve the earlier record as history so the reviewer can see which observation supports which decision.

ANSSI Context: Use the Recommendation as Written

ANSSI-PA-099 labels the recommendation R19+, titled “Utiliser Windows en « Server Core » sur le périmètre du Tier 0” on printed page 36. The ANSSI guide expresses a preference for Core on DCs to reduce attack surface and extends the recommendation to Tier 0 Windows servers, particularly those communicating with less sensitive resources.

Use the ANSSI Active Directory guide's secure administration context to place the decision within the wider administration model. That overview does not verify InstallationType on individual hosts. Neither an LDAP label nor the reminder described below establishes compliance with the recommendation.

How EtcSec Detects This

The reviewed etc-collector check is ANSSI_R19_SERVER_CORE_NOT_USED, at commit afca1b9f7bba6f076d6a6493371486071001452b. Its identifier must not be read as a measured “Core not used” result.

Detect() returns no finding when its DC input is empty. Otherwise it emits an Info reminder, with Count equal to the number of DCs in that input. That count is the population requiring host verification, not a count of confirmed Desktop Experience installations.

The LDAP provider reads computer objects and maps operatingSystem and operatingSystemVersion. The audit engine derives DCs from the collected computer objects after applicable exclusions. This path does not read the host registry's InstallationType; the LDAP strings do not distinguish Core from Desktop Experience.

Use the reminder to open the per-DC review, attach host evidence, and document the resulting decision. Do not report it as a GUI verdict, a non-compliance finding, or proof that a reconstruction is required.

Review Before Closing the Verification

Give the reviewer the reconciled inventory, every host read or error, the interpretation of the returned values, and the dependency decisions. Confirm that the final record includes the machines that were initially unread, or explicitly lists the unresolved ones.

The review is complete when its scope and evidence support the stated host-level conclusions. Keep installation-option verification, operational compatibility, and the broader ANSSI assessment as separately documented decisions.